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.

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:

• 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.
• The software has been designed, built and tested using a disciplined, controlled and fully documented Quality Assurance methodology.
• The company creating the software has an adequate Supporting Infrastructure.

Software Features required by Part 11

Software that is Part 11 compliant is required to have some specific features to protect the integrity of the data:

User Security

There are nine specific features required to secure the user's session.

Data Transfer

Five specific features are required to secure data when transfered.

Audit Trails

There are six features required to maintain accurate audit trails.

Approval of Electronic Records

Up to four specific features are required to control the approval process.

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 intoduced into released software in such a way that maintains the integrity of the software