Electronic Signature Compliance (CFR 21 Part 11) with Microsoft TFS 2013

Microsoft Team Foundation Server (TFS) 2013 is rapidly growing as a leader in the Application Lifecycle Management (ALM) domain. More and more we are finding that regulated organizations are inquiring on how to adopt TFS as an enterprise ALM solution. In the following post I will explore the topic of how TFS implements electronic signature functionality and satisfies Title 21 of the Code of Federal Regulations Part 11 (CFR 21 Part 11) requirements.

Why using Team Foundation Server for healthcare organizations?

Many clients I work with in healthcare have are investing much time into learning how TFS can be leveraged for the organization as a whole. Such requests were unheard of just a few years ago as TFS was more widely known as a software development tool. There are several reasons organizations are exploring a TFS implementation:

1. Introduce standardization across the organization for both development processes and tooling.
2. Increase efficiency by automating heavy manual processes.
3. Improving transparency within the organization. Identify areas with productivity issues that could benefit from improved processes.

The reality is that the market is changing. With increased competition from smaller companies that have much lighter and agile processes it is becoming increasingly important for established organizations to adapt.

Requirements mandated by FDA

One of the greatest challenges for established organizations is determining how to leverage an ALM solution like TFS and comply with Electronic Signature requirements as documented in CFR 21 Part 11. In order to answer this question let's first explore the requirements mandated by the FDA.

1. Validation of systems to ensure accuracy, reliability, consistent intended performance, and the ability to discern invalid or altered records.
2. The ability to generate accurate and complete copies of records in both human readable and electronic form suitable for inspection, review, and copying by the agency. Persons should contact the agency if there are any questions regarding the ability of the agency to perform such review and copying of the electronic records.
3. Protection of records to enable their accurate and ready retrieval throughout the records retention period.
4. Limiting system access to authorized individuals.
5. Use of secure, computer-generated, time-stamped audit trails to independently record the date and time of operator entries and actions that create, modify, or delete electronic records. Record changes shall not obscure previously recorded information. Such audit trail documentation shall be retained for a period at least as long as that required for the subject electronic records and shall be available for agency review and copying.
6. Use of authority checks to ensure that only authorized individuals can use the system, electronically sign a record, access the operation or
   computer system input or output device, alter a record, or perform the operation at hand.
7. Use of operational system checks to enforce permitted sequencing of steps and events, as appropriate.
8. Use of device (e.g., terminal) checks to determine, as appropriate, the validity of the source of data input or operational instruction.
9. Determination that persons who develop, maintain, or use electronic record/electronic signature systems have the education, training, and experience to perform their assigned tasks.
10. The establishment of, and adherence to, written policies that hold individuals accountable and responsible for actions initiated under their electronic signatures, in order to deter record and signature falsification.
11. Use of appropriate controls over systems documentation

Of the requirements mentioned above most are addressed with industry best practices for network security, internal standard operating procedures and training. Examples of policies that would need to be put into place.

1. Mandatory password changes at regular pre-defined intervals.
2. Implementation of password complexity rules.
3. Automatic locking of network accounts after a certain period of inactivity.
4. Locking network accounts after a certain number of failed system access attempts.

Only 2 points remain that will involve some configuration of TFS in order to satisfy the requirements.

How TFS can be leveraged to ensure validation of FDA requirements

1) Data integrity (“Validity of the source of data input”).

TFS can be configured to ensure that required fields are entered when work items (records) are created and at different points through the pre-defined workflow.

For example we could configure TFS to ensure that the “Category” and “Sub Category” fields are entered when a requirement is created.

In order to ensure the accuracy of the data the requirements workflow could be configured to allow for “Review” and “Verification” states. This coupled with a standards operating procedure and training will ensure data integrity is built into the process.

2) Approval workflow (“Authority checks”)

For systems supporting e-signature functionality it is crucial for the system confirm the identity and permissions for the user performing the e-signature (Approval). One popular approach would be to leverage the TFS security infrastructure to implement a series of configurations that would guarantee the user performing the action is legitimate. Below is the approach that can be taken:

1) Group permissions. Establish a group or a series of individuals that will have “Approval” permissions.
2) Configure the workflow to only allow for valid “Approvers” to transition a work item into an “Approved” state.
3) Automatically stamp the approvers name the approvers name into the work item based on the active directory user.
4) The addition of a field certifying the approval.

See below for an example. Note that the “Approval Certification” is mandatory.