21 CFR Part 11
Reliability and Integrity of Electronic Records
21 CFR Part 11 is the FDA guideline that defines the criteria under which electronic records and electronic signatures are considered to be trustworthy, reliable and equivalent to paper records. Part 11, as it is commonly known, was introduced in 1997 and applies to FDA-governed industries that choose to store their primary, authoritive records electronically. It specifies the guidelines and rules for the storage, copying, access & permissions, audit logs & tracking and version control of the electronic records and the application of electronic signatures to them.
SageKey is the best software company I have worked with in a 15 year career. What distinguishes SageKey from similar software organizations is the tight bonds they build between sponsors and customers alike. Throughout my time managing this program from a sponsor point of view, SageKey was an extension of our internal team – they shared our vision and goals. And in turn, we became a better organization by learning from SageKey’s visions and goals of customer service, quality products, trust, respect and incredible can-do attitude. I am always available to discuss my experience with SageKey.
Part 11 defines an electronic record as any combination of text, graphics, data, audio, pictorial, or other information representation in digital form that is created, modified, maintained, archived, retrieved, or distributed by a computer system.Part 11 applies to all records that are defined in the underlying Acts and Regulations which govern activities in the life sciences industries. These underlying Acts and Regulations, which are referred to as the Predicate Rules, are any requirements set forth in the FDCA Act (Federal Food, Drug and Cosmetic Act), the PHS Act (Public Health Service Act), or any FDA regulation (GLP, GMP, and GCP). The predicate rules mandate what records are to be maintained, the content of those records, whether signatures are required, how long records must be maintained and so on.
Practically speaking, Part 11 requires drug makers, medical device manufacturers, biotech companies, biologics developers, and other FDA-regulated industries to implement controls, including audits, system validations, audit trails, electronic signatures, and documentation for software and systems involved in processing electronic data that are either required to be maintained by the FDA predicate rules or used to demonstrate compliance to a predicate rule. There are no grandfathering exceptions for Part 11, it applies to all existing and all newly installed systems.
Part 11 In a Nutshell
There are 3 requirements for a piece of software to be deemed Part 11 compliant:
1. The software has the specific features to address Part 11 requirements, i.e. Data Integrity & Security, Security Threats, Data Transfers, Audit Trails and Electronic Signatures.
2. The software has been designed, built and tested using a disciplined, controlled and fully documented Quality Assurance methodology.
3. The company creating the software has an adequate Supporting Infrastructure.
Need a Digital Partner?
Contact us today. We love solving problems through custom software development projects.
Quality Assurance
FDA guideline 21 CFR 820 – Quality System Regulations addresses developing and validating software for FDA regulated environments and is applicable to software used in GLP, GMP and GCP processes and software governed by Part 11. HIPAA has also adopted Part 820 as its quality standard for software that contains patient data.
Part 820 requires that a disciplined, controlled and fully documented methodology be used to develop and validate software.
A software vendor may have an excellent piece of software, however for an FDA-regulated environment, the assumption is made that if a particular aspect of the development process is not documented it did not happen and therefore the software’s integrity cannot be proven. The FDA does not accept that observing the software’s error free behavior in the past is proof that the software will behave in an error free manner in the future. The FDA will only accept a software development methodology that clearly manages the quality of the outcome.
SageKey uses a disciplined, controlled and fully documented methodology to design, build and test regulated software. Our quality assurance methodology uses an industry standard nine-step process:
Product Requirements
The Product Requirements document defines the project. It includes the list of requirements and information about the environment in which the application will be run.
Software Development Project Plan
This document lists the project’s resources and deliverables, defines the schedule of tasks to be completed and identifies the source of project funding.
Design Specifications
The Design Specifications document contains detailed information about the specific functionality of the software. Each feature or function is given an identifier that is used to trace between the specifications and their test cases.
Technical Specifications
This document describes the project’s system architecture and development tools. It outlines how the Design Specifications will be developed into software and includes a design risk assessment and a developer testing plan.
Unit Testing & Code Review
Unit testing is conducted on each functional element of the application by the developer and the results documented. Code reviews are performed as a means of improving code maintainability by ensuring adherence to coding standards. Results of the reviews are included in the Code Review Report.
Build Notes
The Build Notes document describes the software build environment and lists any specific settings or configurations that must be made to create a build of the software.
Software Quality Assurance Testing Protocol
This document identifies the testing environment and includes a description of the testers and their approaches for testing each component of the software. The document describes each test case and assigns it an identifier that traces it to a design specification.
Software Quality Assurance Testing Report
This document describes the results of the executions of the test cases. It includes a description of the software configuration tested and the results of each test case execution. The results of failed tests are entered into a Validation Error Reporting log in preparation for re-testing.
Release Notes
The Release Notes document includes a list of all files that will be deployed with the application and lists any outstanding issues, workarounds or helpful notes that will assist in the deployment, installation and use of the application.
We invite you to visit us and audit our example projects, processes and SOPs. SageKey is located in a beautiful part of Western Canada, well known for its wine, vacation spots and low impact industries.
Company’s Supporting Infrastructure
Companies that build high integrity software are required to have a set of written, approved and enacted policies called Standard Operating Procedures (SOPs) for all the core business activities that affect the software development process. These SOPs act as the foundation of the software development activity and ensure that this activity is not compromised. SageKey maintains the following SOPs to run its core business activities:
SOP and Document Management
Describes how the company manages its standard operating procedures and related documents
Staff Training
Contains records that show that the staff are qualified to do the work
Building Security
Defines how the physical security of the organization is protected and managed
Computer and Network Security
Defines how the electronic security of the organization is protected and managed
Electronic Data Backup and Recovery
Defines how the electronic data of the organization is backed up and protected
Disaster Recovery
Describes the company’s disaster recovery process
Coding Standards
Describes the coding standards adhered to by the organization and how code reviews are conducted
Source Code Control
Describes how source code versions are managed
Issue Tracking
The organization’s policies for tracking software issues from their discovery through to their resolution and testing
Software Development and Validation
A detailed description of the nine-document software development process adhered to by the organization (as described in the section above)
Software Change Control
Defines how changes are introduced into released software in such a way that maintains the integrity of the software