What is Good Documentation Practice when developing Regulated Life Sciences Software?

ALCOA is a key framework behind GDocP 

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 was expanded (ALCOA+ and ALCOA++) to include five more principles; Complete, Consistent, Enduring, Available and Traceable. These account for more recent advances in automation, cloud-based environments and electronic records.    

Often the software you are building for your instrument is not just a tool to display results, but must also generate, transform, store, and report regulated data. As a consequence, you are essentially taking on responsibility for ensuring that the principles of GDocP are being met when your customers are using your product. 

It is important to note that these ten principles are inter-related. For example, a system that is accurate but not traceable cannot prove its accuracy under audit. Similarly, a system that is complete but not available fails at the moment of inspection. The software architecture needs to treat them as a unified framework, not ten separate feature requirements. 

What does GDocP and ALCOA++  mean for software development?

Attributable: GDocP requires that records must be traceable to the person or system that created or modified it. When applied to paper documents this principle is usually addressed with dated signatures.  

In software we see direct parallels with requirements for:

• Limiting access to the system behind authentication. 
• Unique user accounts. Shared logins (often typical on lab equipment) are non-compliant and software should be designed with support for individual user accounts. 
• All records and logged actions should be marked with the user identification derived from a valid login. 

Note that the requirements for actual Electronic Signatures are more specific (see below). 

Legible: Data must be easily read and should remain so for its full retention period. For software this involves ensuring that the data is accessible. 

• Rendered output must be human-readable, not just machine-parseable. This is important for auditing, as access to human readable records is an explicit requirement. 
• Reports and records must be exportable to durable, readable formats. This means that you cannot rely on proprietary formats (which may become deprecated) or specific software for long-term access. 
• Font rendering must support all required locales and character sets (localisation; see this blog for more on this). 

Contemporaneous: Records must be created at the time the activity occurs. This is less of an issue on electronic than paper-based systems, as by their nature electronic records are often created contemporaneously. The greater burden on software is gathering appropriate reliable evidence of contemporaneous records. 

• Timestamps should be generated automatically at point of action and not manually entered or editable by users 
• System clock synchronisation (e.g. NTP) with tamper protection to ensure date time stamps are accurate. 
• No ability to backdate records or alter records 
• Sequence logging to detect out-of-order entries (for example, controlled document or record numbers) 

Original: The first capture of data must be preserved and distinguishable from copies or transcriptions. A key point in developing instrument software and firmware for example is the appropriate definition of the raw data. ‘Raw Data’ does not necessarily mean raw signal captured by a sensor, but rather the output generated by the firmware or software without any user intervention or processing. The key point is that the original unprocessed data is preserved and available for reprocessing if required. 

• Raw data should be stored in its original, unmodified form. 
• This data should be preserved, with processing or changes creating new versioned records alongside the original. 
• Clear differentiation in the UI and audit trail between raw data and processed/derived data. 
• Immutable storage with cryptographic integrity checks. 

Accurate: Records must correctly represent any processing and what was measured or observed. Again, this is important for being able to reproduce any data processing that has occurred. For software this means keeping appropriate records and controls about how data was processed and employing controls to avoid incorrect processing where possible. 

• Validated data transformation and calculation logic with documented, testable methods. 
• Records should include any version numbers or parameters required to reproduce processing. 
• Appropriate input validation and automated range and sanity checks to flag anomalous values at point of capture. 
• Some records may require secondary or additional reviews as part of processing, and software may be required to support QA/QC review. 

Complete: All data, including any repeats, errors, or out-of-specification results, must be retained. For software this means that records should be preserved both within the software (for example not adding features to delete records) but also by having appropriate controls on where and how records are stored (i.e. not deleting files from disk external to the software). 

• No ability to selectively delete runs or results i.e. all attempts must be logged 
• Failed runs, aborted processes, and error states must be recorded, not silently discarded 
• Audit trail must capture the full history, not just successful outcomes 
• Void or cancelled records retained with reason documented 

Consistent: Processes must be applied in the same way every time, and records must reflect this. This principle is primarily achieved through appropriate documented processes (SOPs), training, and training records. For software, the workflows you design become part of your customer’s SOP, so consistency becomes something the system enforces rather than something the user must remember, which can be a tremendous advantage. 

• SOPs enforced through software workflow rather than relying on user memory 
• Consistent timestamp format and timezone handling across all records 
• Standardised units, nomenclature, and data structures across the system 
• Deviation from defined workflow triggers a documented exception, not a silent override 

Enduring: Records must remain accessible and intact for their full required retention period (often for a decade or more). For software the challenge is that the record may then outlive the thing that created it. Yet the record itself must remain readable and verifiable regardless. 

• Open, documented formats, so records can be read without the original software if required. 
• Documented and tested data migration paths, so that traceability can be demonstrated throughout. 
• Tested backup and restore procedures. 
• System enforced data retention and archiving. 

 Available: Data must be retrievable on demand, including during an inspection. Software solutions can provide significant advantages here over paper systems, but only if appropriate features are in place. 

• Search and retrieval functionality across the full archive, not just recent records 
• Access controls must not prevent authorised reviewers (including auditors) from retrieving records 
• System uptime and performance requirements appropriate to support a live inspection. 
• Offline or read-only access modes for audit scenarios where production systems must not be disturbed 

Traceable: The full history of data must be reconstructable, from origin throughout every transformation to final output. For software this is the principle that underpins many of the others. Having accurate or complete records counts for little if you cannot demonstrate the provenance of a reported result back to the raw data. 

• End-to-end audit trail from raw input to final report, with no undocumented steps 
• Every data transformation, calculation, and processing step logged with its parameters 
• Links maintained between source data, derived data, and the reports that reference them 
• Version control for methods, SOPs, and software itself, so the exact configuration at time of any record can be recovered 

Electronic signatures 

Software which is designed with the ALCOA++ principles in mind provides a good basis for resolving some of the foundational requirements for electronic signatures. 

An electronic signature is an explicit act in addition to normal activities where a user formally takes responsibility for a record change, for a specific reason, at a recorded date and time. It is meant to have the same legal weight as a wet signature on paper. 

An electronic signature has no value if the underlying data can be altered after the fact, or if you cannot say who created the record. So, the guarantees ALCOA++ provides, attribution of actions to individuals and assurance that the data has not been changed, among others, are exactly what give an electronic signature its meaning. 

In the US, 21 CFR Part 11 sets the requirements; in the EU, Annex 11 is the equivalent. For software that becomes a set of concrete constraints: 

• Each signature is bound to the specific record it signs, so it cannot be copied, moved, or reused on another record. 
• The signature captures the signer’s name, the date and time, and the meaning of the signing (authored, reviewed or approved). 
• Signing requires re-authentication at the point of signing, not merely an active session, and for non-biometric signatures at least two components, for example a user ID and a private password. 
•  It must be technically impossible for one user to sign as another, and any attempt is itself logged. 

Note that because of these constraints, a piece of software cannot be implicitly compliant; only a specific installation can be assessed as compliant. And without the appropriate electronic signature features, aligned with GDocP, compliance is highly unlikely to be achievable. 

Data storage, file formats, and customer workflows 

Data must be stored securely with tamper detection so any change to stored records must be logged and detectable. Some companies create a proprietary file format to store data, but this can create a compliance risk for your customers: if you as the manufacturer ceases support, then the customer’s data becomes inaccessible or unverifiable. It is therefore recommended to use standard file formats that are open and interoperable where possible. Enabling integration with Laboratory Information Management Systems (LIMS), Enterprise Resource Planning (ERP), and analytics platforms can also be a major purchase consideration for your customers, so consider integrations a design priority and make sure you understand how your customer will want your instrument to fit into their workflow. 

Reporting instrument outputs 

The report an instrument or software system produces can be considered the real product for a regulated customer. It is the output of all the engineering work and is how your customer will show their results. In our experience, reporting is consistently designed too late, often after the engineering development is complete. Reporting requirements should instead be defined at the proposal stage, alongside the functional requirements. Knowing what the output report must prove then drives what data must be captured, stored, and traced and can inform the engineering design. 

Common GDocP mistakes to avoid

 

There are a few common mistakes that can be easily avoided for companies developing a new instrument for a GxP environment. 

Overcomplicating requirements: getting bogged down in documentation detail rather than ensuring auditable, evidence-based outputs. 

Assuming software can be compliant in isolation: compliance is a system property, not a software property. Software (or indeed an instrument) cannot be compliant in itself, but can support compliance by creating all the tooling required by users. 

Designing reporting last: the main output of your instrument should be a key driver in the overall design and is a tangible user-facing deliverable. However, this can sometimes be left until the end of the development or not given the same attention as the main UI. 

Neglecting localisation: documentation in the wrong language for end users creates deviation risk in regulated environments. 

Not having a data integrity and traceability solution: Data integrity is hard to bolt on later and much easier to design in. A risk-based assessment such as a design FMEA surfaces traceability and integrity risks while the design is still fluid. 

Conclusion: documentation is a competitive advantage for GxP sales 

Manufacturers who treat GDocP as a design discipline, rather than a compliance task that must be bolted on before launch, produce instruments that are easier to sell into regulated markets. GxP customers will choose an instrument that simplifies their audit process through providing validation paperwork, audit trail infrastructure and the documentation needed for compliance over one that doesn’t. 

Firefinch is the embedded software team inside life science companies. We help build the software that makes a product market-ready, from instrument control through signal processing to reporting and visualisation. Our developers have decades of experience across the industry from biotech startups to multinationals. 

If you need help developing GDocP processes for your instrumentation software then get in touch with the team at Firefinch for a friendly chat. You can also download our white paper on building software for GMP instrumentation. 

Further reading

Software for Biotech Instrumentation: GMP, Validation & Best Practices 

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

Regulated Software Translation: How to Avoid Audit Failures in Global Markets