Software Development and the Life Sciences – an uncomfortable union?

The worlds of regulatory compliance in Life Sciences and software development often appear to be in conflict. This can be further exacerbated depending on the level of maturity of the development model used by the software development organization.  Yet, they are required to coexist in a workable fashion – is there a way that this can be realized?

Mature vs. Mature

We will consider the case of a mature regulatory lifecycle and a mature software development lifecycle (SDLC). Attempting to merge with an immature SDLC presents additional challenges, and is beyond the scope of this discussion.

Both regulatory compliance and software development personnel need to compromise.  This is not a compromise on software quality or regulatory compliance, but on interpretation and application of the governing regulations. Some adaptation is frequently required both of practitioners and of auditors.

Compliance’s Historical Hangover

The compliance side is usually constrained by historical thinking. The Medical Devices environment typically experiences less difficulty, but those coming from Manufacturing often have the most difficulty, with Clinical Trials and Laboratory folks also experiencing some stress. The GAMP V model is usually applied in these arenas, one version of which is presented below. This model is designed to apply more to equipment and to chemical processes than to software, and therein lies the problem.

Because many auditors – including those from organizations such as the FDA – are more  familiar with this model, an expectation of seeing three specific levels of testing often exists, namely:

• Installation Qualification (IQ) – typically used to demonstrate that equipment has been installed correctly and in accordance with manufacturer’s specifications
• Operational Qualification (OQ) – demonstrate that the required functionality of the equipment is correctly fulfilled, and that the equipment operates satisfactorily
• Performance Qualification (PQ) – showing that the equipment operates correctly in the final, “production” environment.

Terminology Tangles

The concepts above do not translate well into most SDLC methodologies, and this is where friction between the two approaches often occurs.  This is further compounded by different uses of terminology.  The term “validation” may be understood by a software engineer as referring only to testing, while, to a compliance person, it could apply to the entire life-cycle.

Compromise 1: Compliance Practitioners and Auditors

The recommended way around this impasse is for compliance personnel to have a better understanding of what the regulations actually demand, and what is left open to interpretation.  The concepts of IQ, OQ and PQ are not mandated by any specific regulation, for example, but are often enforced, based on an understanding of what constitutes “current Good Manufacturing Practice.”  The better approach is to refer back to the primary regulations (often known as “predicate rules”) themselves and to determine if a particular SDLC has sufficient outputs to satisfy the regulation.  This requires more effort than simply following established auditing practices, but is worth the time invested.

Compromise 2: Software Developers and Testers

The two most common SDLC activities requiring additional work are improving traceability of requirements to developed code, and testing records.  Depending on the maturity level of the development organization, the traceability issue may be the less difficult one.  Testing requirements to be beefed up usually involve ensuring that tests compare actual with expected results, and of having test evidence that can be verified independently.

A better union?

The practical outworking of these compromises is where the challenges lie, but a better union can be reached through sensible thinking.