Don’t let poor software development decisions put your GMP Compliance at Risk

The market values compliance

The biotech instrumentation market is huge with large industries such as pharma, food and cosmetics driving a need for reliable instruments to ensure safe and consistent manufacture of regulated products (Good Manufacturing Practice; GMP). A much smaller portion of the market is R&D instrumentation, where adaptability is often favoured over compliance. 

Instrument manufacturers will make a strategic decision about which market they want to enter. The decisions an instrument manufacturer makes early in development of their instrument can have wide reaching consequences on market access further down the line. Many manufacturers prioritise beautiful, functional software but underestimate the compliance infrastructure underneath it. Fundamentally getting the software right reduces risk for your customers.

The regulatory landscape

There are two crucial pieces of legislation that underpin how software should be used and developed for GMP instrumentation. FDA 21 CFR applies in the USA and EudraLex Annex 11 applies in the EEA. These regulations define several requirements for the software including record generation, security controls, audit trails and user authentication. In addition, 21 CFR Part 820 has requirements for a Quality Management System (QMS). 

 Regulations applicable to GMP customers that good software will support. 

Note: software itself cannot be “compliant” – compliance depends on correct installation, intended use, and the surrounding processes. Software can help (or hinder) compliance.

What do GMP labs actually need from your software?

If your customers are likely to be audited by the FDA, MHRA or EU, it is important that you understand what the regulators will be looking for and how your instrument can support your customer through the audit. You will need to have a Quality Management System in use to ensure that all documentation relating to the instrument is up to date and aligned to ISO 9001. 

The report your instrument produces is the real product, not the instrument itself

This blog from Science Insights goes through the basics of a GMP audit and provides advice on how GMP labs will need to prepare. In terms of instrumentation software, it is important to understand that the software cannot just provide data capture, but also needs to support data traceability, user management, and audit-readiness. This is underlined through a few key requirements:

• Manuals and training materials. These help your customers write their own SOPs and qualify their operators, and may need to be available in several languages depending on the jurisdictions they operate in.
• Validated performance. Evidence backed claims on the accuracy, reproducibility, working range, sensitivity etc. of the instrument. Procurement is underpinned by design qualification (see below) where the product must be aligned with its intended use. Publishing your product’s performance makes this possible for your customers.
• Risk management. An instrument built to ISO 9001 will reassure GMP customers that you have followed a risk-based approach to product design. Identifying and mitigating risks during product design and development can be achieved with tools such as Failure Mode and Effects Analysis (FMEA) and applies at software, hardware and product levels.
• Cybersecurity. Vulnerabilities are a data integrity risk, and so security is a GMP concern as well as a broader IT one. Concerns such as ensuring secure connectivity to LIMS and ELNs, a well defined patching and vulnerability management plan, role-based permissions based on secure access control measures, and tamper-resistant audit trails must be addressed. 
• GDocP. Good Document Practices require data traceability and integrity along ALCOA principles (see below). Data should be attributed to users through electronic signatures (21 CFR Part 11).
• Instrument qualifications. Demonstrate the correct installation and operation of the instrument through its operational lifetime. More detail on this below.

Displaying the results of an analysis is not enough. The gap many manufacturers miss is in the traceability around SOPs, consumables, reagents, and operating conditions. 

ALCOA for data integrity. ALCOA is a core principle of GDocP. The acronym originally stood for Attributable, Legible, Contemporaneous, Original, and Accurate and was used as a set of data integrity principles in the pharmaceutical and other industries. The term has more recently been updated (ALCOA+ and ALCOA++) to include Complete, Consistent, Enduring, Available and Traceable to account for recent advances in automation, cloud-based environments and electronic records. 

Common software mistakes in GMP instrumentation

In our experience, there are a few common mistakes that instrument manufacturers make. These can be easily avoided if they are considered during instrument development. 

• Not designing for traceability from the start. Traceability and record keeping are a core tenet of cGMP. This matters for software both internally in design (i.e. baking strong data integrity and traceability controls into the software design and architecture) but also in thinking about how the product will fit into a wider traceable environment (e.g. support for barcode scanning, controls around authentication, typical user roles, etc.). All of these are difficult to put into the software late in the development process. 
• Not considering data accessibility and interoperability: Think about both interoperability requirements (i.e. LIMS integration, automation standards etc.) that are relevant for your product. But also long term accessibility of the data cGMP mandates that data should be legible and accessible for long periods after manufacture (for some biologics, up to 10 years after manufacture) so support for open or industry standard file formats is vital. 
• Treating reporting as an afterthought. Often a weak point, an exported report is often the real product generated by the software. Care should be taken to ensure that reporting is neither infinitely configurable nor extremely rigid. If a customer has to transcribe the reported results into Excel to perform simple operations like mean or standard deviation for example this is a poor outcome. 
• Ignoring localisation.  If you plan for global deployment of your instrument build software localisation into the interfaces as the software is built.
• Not having an appropriate Software Development Life Cycle (SDLC): The downstream requirement for software to have undergone validation and verification places obligations on the development of the software. Proper traceability of requirements, demonstrable testing, etc. all of which is difficult to do after the fact. A documented SDLC capturing this as part of normal development process is required. 

How software can support qualification of the instrument 

Once your instrument is on the market, each installation will need to be qualified to prove to regulators (and users) that the instrument is operating correctly. As a manufacturer, it is a good idea to provide the documentation and software tooling that makes qualification straightforward for buyers.