Developing software for regulated environments comes with its own set of challenges: from managing validations during updates to maintaining audit readiness and compliance. In this article, we’ve compiled answers to some of the most frequently asked questions our software development team encounters when working with clients in the life sciences and IVD industries.
Whether you’re dealing with data-heavy devices, struggling with infrastructure management, or trying to streamline development for research and production environments, you’ll find practical insights and technical recommendations to guide your next steps.
How do you handle software updates or hotfixes without invalidating previously completed system validations?
From a technical standpoint, the most you can do is set up comprehensive automated testing. Set up regression tests to cover the core functionalities of your system, which will save you and your test team precious time when preparing updates for your system.
Of course, automated tests shouldn’t be considered a replacement for validation, but merely as a tool to speed up the process leading to actual validation.
What architectural patterns support easier audit readiness and documentation generation in long-term projects?
Choosing a specific pattern almost always depends on the size of your project, its goals, and the use case. Once you are sure of all that, it’s easier to choose a pattern that fits best. In terms of audit readiness and documentation generation, you can validate your pattern by asking yourself: Does it enable me to establish a clear separation of concerns? Is it clear where the core business logic is defined? Are my services and layers properly scoped to domain areas? Are my commands and events consistently defined and auditable?
How do you manage and document third-party library usage in a way that satisfies auditors and minimizes re-validation risk?
In general, we try to stick to the following:
- Before introducing a library, ensure it is regularly maintained and widely used. Especially for non-licensed software.
- Ensure that your regression tests also cover libraries.
- Ensure that library versions are explicitly defined (not automatically set to the latest) and documented separately, to avoid the risk of invalidation in new builds. Stick to using stable versions.
- Regularly monitor for updates, vulnerabilities, and potential license changes.
What’s the best way to structure logging and error handling in regulated environments to support both debugging and compliance needs?
You should avoid generic and repetitive error messages that merely inform you of an error without providing any contextual information. Your logs should include at least the following:
- Severity – differentiation errors, warnings, and informative logs.
- Action & description – what action was performed.
- User ID – what user was performing the action.
- Timestamp – Ensure your logs include a timestamp with the appropriate precision and format.
- State changes – For compliance needs, include information on both the old and new value states if an action modifies an instance.
What are the common architectural pitfalls that lead to compliance issues during inspections, and how can they be avoided?
Three of the most common ones would be inadequate audit logging, improper user management, and missing electronic signing features. For auditing, it is essential that you implement an audit service that exposes usages that contain all the required information, as discussed in the previous question. Make sure that your timestamps are precise and saved in UTC to avoid time-zone-related issues.
As for the user management, to be compliant, ensure your software supports a user account recovery workflow that enables users to set their own passwords and meet password complexity requirements. Lastly, your software should typically include an electronic signing mechanism if an approval process is present. This can be covered by prompting the user to re-authenticate upon approval.
Should we select the same language for the frontend and backend to make hiring easier and allow developers to work on both applications?
This can seem like a great idea, and it may indeed be a great idea. However, there are other factors at play, not just the tools developers are familiar with. Other things to consider:
- Is tooling mature enough? How about its ecosystem? Is it maintained, or is it in decline?
- How does tooling fit with the requirements? Which pros and cons affect us? What about the ecosystem? Does it have great libraries that can speed up our development?
- Are your developers comfortable with developing full-stack even if the underlying tooling is the same?
To introduce and test new features quicker, we usually have separate applications for R&D and production, but this complicates things when merging new features to the production version. Is it possible to create two different versions of the software e.g. one for regulated environments and one for research use only, and with both versions having the same codebase?
Yes, this is possible. Our go-to approach to support this is using feature flags. They enable us to quickly enable or disable features or even target specific users. However, if the goal is for the two different versions to have separate binary outputs, we can achieve that with conditional compilation flags.
We are developing an application for regulated environments. Which data must be stored as electronic records? We generate a huge amount of data – do we need to store it all?
This is a very complex issue that depends on the system that generates and collects data. In short, you need to store data that would help you in an investigation if something went awry even with a QC process in place. Stored data needs to help you identify the root cause. This can be a summary of a process or snapshots of data or just some metadata that describes what was happening.
We discuss this in our Title 21 CFR Part 11 Workshop.
We produce a device that generates huge amounts of data. It is a challenge to stream it reliably and continuously to a remote system. What are our options?
If this is a regulated environment, it is important that data integrity is maintained and data loss is prevented, especially of electronic records. Having internal redundancy is a good selling point for your system, but there is only so far you can take it.
The best option is to provide users of your system with the ability to export and/or archive data. Especially as an end user might want to access the data without having access to your system. There are many ways of achieving this; choosing one depends on the system and on who your users are.
We are using an X cloud provider for our infrastructure. Lately, we have been having a hard time managing everything. Could you help?
Going through UI to setup cloud infrastructure or using provider native scripts can become a mess quickly, especially as it is hard to document what was done. Maintaining this documentation is also challenging, as cloud providers continually update their user interfaces.
An industry-standard approach is to combine the power of source control, such as Git, with a code-based infrastructure tool like Terraform or Pulumi, to obtain an auditable and trackable list of changes written in a maintainable way that is not dependent on changes to the UI.
Want to improve your software architecture to better support compliance and long-term maintainability?
Learn more about our software architecture consulting services and how we help companies build robust, auditable, and scalable systems for regulated environments.
