Background
In June of 2017, the FDA issued a new draft guidance, Use of Electronic Records and Electronic Signatures in Clinical Investigations under 21 CFR Part 11 – Questions and Answers. This ‘Q&A’ draft guidance provides some reasonable, logical responses to questions posed by the IT/Tech sector within the Clinical Development space. Cutting edge technologies around handhelds, smart phones and Cloud services are not excluded from this document. The primary audience for this guidance centers on sponsors, investigators, IRBs, and CROs. This article will focus on the software/systems validation and outsourcing of electronic services aspects of the draft guidance.
The primary tenant behind the draft guidance is to address questions the industry has around newer technologies, and specifically how 21 CRF Part 11 e-records and e-signatures are potentially interpreted and applied from an IT governance standpoint. In other words, the FDA is providing its thoughts on how entities should revise procedures to ensure compliance with Part 11 requirements regardless of technology, and why a risk-based validation approach should be used when validating electronic systems, implementing audit trails and archiving electronic data. Technologies within this document include commercial off-the-shelf (COTS) and bespoke systems, outsourced electronic systems, and systems deployed for the provision/support of medical and clinical care.
Although not mentioned, the clinical IT audience would also be primary readers of this draft FDA guidance. Traditionally, sponsors and CRO IT divisions establish and provide IT governance of all things IT and technology related. Whether it be installation, validation, maintenance, and upgrading, IT is traditionally responsible for all of these activities. Quality and Compliance also play a key role in collaborating with IT to incorporate and enforce in-scope Part 11 rules. Newer technologies bare no exception and cannot ‘opt out’ when it comes to Part 11.
It has been and continues to be best practice that all systems should go through a formal GxP assessment; inclusive of Part 11 regulations to ensure proper validation and compliance. When in scope, the affected business should use a risk based software development lifecycle (SDLC) to formally scope and validate any in-scope Part 11 requirements. This could include technology or procedure based controls. FDA strongly encourages the industry to adopt electronic records and systems to improve the quality and efficiency of clinical investigations while staying compliant with Part 11.
The draft guidance is broken out into five primary sections encompassing 28 questions and responses. Of those five sections, section IV offers insight into risk-based validation, and management of outsourced electronics services/technology.
Risk Based Software Development Lifecycles (SDLCs)
Many of the questions and responses from the FDA, center around software validation and a company’s responsibility it has to assess, validate and maintain control of their systems either directly, or in partnership with vendors. The FDA’s response continues to encourage the industry to embrace a risk based approach to software validation. This was also announced in FDA’s 2003 Part 11 guidance. If systems create, use, manage, and update electronic data to support clinical trials or other regulated activities, organizations should use a risk based approach to validating these systems. What does that mean? It simply means that the organization using the system should first assess the system for its intended use, and, what will happen with the data. Based on the assessment the system will be assigned a type of risk such as low, medium or high risk. For systems that reside in the high risk category, such as COTS or custom systems, both the FDA and the industry at large recommend thorough testing and documentation. Sponsors and CROs should never allow the software vendor to validate a system ‘on their behalf’, assume that the software is ‘already validated’, or allow the vendor to ‘define the intended use of the system on behalf of the end-user’.
Risk Assessment Models for Clinical IT
A widely accepted industry risk assessment is the Good Automated Manufacturing Process (GAMP 5) model. This model defines systems by criticality and complexity such that the organization adopting the model can define and enforce clear sets of criteria for each system entering their business. Other risk assessment methodologies that are widely accepted include ICH’s Q9: Quality Risk Management and ISO 31010: 2009 Risk Management. Turning back to the GAMP model, many organizations may adopt the ‘fundamentals’ or ‘spirit’ of GAMP 5 and create their own risk matrix. Typically an organization would define systems as utilities, Off the Shelf, Custom Off the Shelf and Bespoke (custom). Class/type of electronic system carries weight as to risk and complexity. The GAMP risk assessment helps organizations determine both, usually through a series of pre-defined questions (or matrix). Once the assessment has been conducted, the system in question should have both a risk rating (low, medium, or high as noted above) and complexity. The risk would be to both the business and the patient. If Part 11 is in scope, typically the system would be rated as medium or high risk system. The complexity would also be determined; considering such things as performance, function, change and workflow. Systems cannot be both custom and off the shelf, they will be classified as one or the other.
Putting the concepts into practice, if an organization uses their risk assessment process to determine risk and complexity for a printer server; this would normally be determined to be a low risk, off the shelf system. What does that mean for the business? Depending on what controls the business decides to attach to that risk and complexity, the printer server may simply need an Installation Qualification and a User Manual. It holds no risk from a Part 11 standpoint, and therefore the need to do any type of formal validation such as Design or Performance Qualification and User Acceptance Testing are not needed. The printer server would be deemed a ‘plug-in and play’ solution.
Conversely an organization uses their risk assessment process to determine risk and complexity for an electronic data capture (EDC) system, this would typically be determined to be a high risk, custom or bespoke system. This means that the regulatory risk of the system is critical to maintaining patient safety and data integrity; meaning that most if not all of the Part 11 regulations are in scope. Additionally an EDC is a configurable system (COTS) if purchased through a vendor, or if it was built from the ground up by a business (bespoke). Either scenario requires the business to take formal steps to define the system’s intended use; gathering and approving user requirements, design specifications and a test plan that will narrate the informal and formal approach to validating the solution.
Outsourcing of Electronic Services and Technologies
Many organizations in the Life Sciences arena tend to outsource their virtual or electronic services. This gives Pharma and CRO entities access to experts, and enables them to concentrate on drug development, clinical trials, and patient well-being. Typical examples are the outsourcing of Data Management, cloud services, infrastructure services (servers, laptops, storage, etc.). Regardless of the medium in which services are procured and maintained on behalf of sponsors and CROs, the expectation is that either one or both entities are independently confirming that the outsourced entity has and maintains adequate physical and logical controls over their company, their physical space and electronic services.
Ideally the sponsor or CRO must have some sort of Vendor Supplier Audit and Governance Program in place to not only assesses the risk and use of outsourcing vendors but also to maintain governance over them. This is a regulatory requirement and best business practice expectation from the FDA. The explicit ability of an organization to demonstrate they follow a risk-based, repeatable vendor assessment and maintenance relationship with their vendors is paramount.
In regards to the risk associated with outsourcing electronic vendors, sponsors and CROs should equally consider risks and security around demonstration of system validation and documentation, the ability to generate store, reproduce and transfer regulated data in a consistent and secure manner, the ability to archive, encrypt, audit trail and ensure data integrity controls, as required by Part 11 should not only be demonstrated from a supplier audit/qualification standpoint, but that the vendor can demonstrate perpetual control over their people, processes and technologies.
Per ICH 06 guidelines and the FDA, sponsors are ultimately responsible for the quality and content of their electronic data. Per the previous paragraph, if sponsors and CROs leveraged a vendor management program, the ability to provide adequate evidence that their clinical trial data was managed in accordance with regulatory requirements. Sponsors and CROs can also establish service agreements with these electronic vendors. This establishes minimum business and regulatory expectations for the electronic vendor and the outsourcing entity. Add the vendor management process with the service agreement and a robust model will be established; helping ensure patient safety and data integrity. Procedures and documentation created to demonstrate these activities, at a minimum, should be available for the FDA to review during an inspection at any regulated facility they enter.
The FDA may not only enter and inspect a sponsor or CROs facility at any time, but may directly enter and inspect the electronics service vendor that fall under FDA regulations. Many times the records and/or data that the FDA wishes to inspect are not available at the sponsor or CROs site and will then move to inspect the records at the electronics services vendor to confirm that any and all FDA regulations are met. Again the sponsor is ultimately responsible for ensuring data integrity for the regulated data.
Summary
The FDA draft guidance serves as an excellent reference for where FDA’s position is concerning data integrity for clinical data. Although not a formal guidance yet, FDA hits on many of the fundamental best practices sponsors and CROs should embrace when dealing with in scope Part 11 data. The FDA continues to review current technology platforms and devices that are becoming very pervasive in both the commercial and Life Sciences spaces. At the end of the day, companies operating in the Life Sciences arena must have trained competent people to manage data. They must have a good quality management system (QMS) with clear, concise, and repeatable instructions that define not only what processes must be followed, but also how the work and deliverables within those processes are created. Finally, electronic technologies that create, store, transfer, update and retire clinical data must be assessed, validated and maintained in an audit ready state with change control processes to enforce chronological controlled change(s), as needed. By validating electronic systems and implementing change control procedures, high confidence in maintaining data integrity can be demonstrated. Companies adopting and incorporating in-scope 21 CFR Part 11 regulations have systems that maintain better control over data and human interactions. Best practices/requirements including audit trails, strong passwords and electronic signatures in a ‘paperless’ environment allow companies to maintain data integrity and only add value to the entire drug development process.