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 (21 CFR Part 11 or 21CFR11) requirements.
In the following study by the Gartner Inc, TFS is positioned as a leader in both vision and abilty to execute as a ALM solution. Some of the key strengths include:
- Clear vision and ease of implementation.
- Extensive support network.
- Frequent release cadence. Microsoft is providing updates every quarter.
- Online offering of TFS.
If you would like to read the full report. See below:
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:
- Introduce standardization across the organization for both development processes and tooling.
- Increase efficiency by automating heavy manual processes.
- 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.
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.
First we will need to define how TFS is categorized. In Subpart A Sec 11.3 we will find the definition of a closed system which would be a very close match for TFS:
Closed system means an environment in which system access is controlled by persons who are responsible for the content of electronic records that are on the system
Since access to TFS is typically controlled an operations team along with other critical business system we can safely make the case that TFS is a ‘closed’ system. In addition, authorization for TFS can be configured at a fine grained level to accommodate almost any operation scenario. Let’s explore these requirements:
Validation of systems to ensure accuracy, reliability, consistent intended performance, and the ability to discern invalid or altered records.
Before any electronic records management system can be used it must go through a rigorous validation process to ensure the system functions as intended for day to day use. It is important for an organization to implement a validation plan prior to using TFS in production to meet this requirement.
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.
All documentation in TFS can be easily accessed or exported for verification. From system requirements to test case protocols, these artifacts (work items as TFS calls them) can be reported on or exported through multiple mechanisms such as work item queries, SSRS reports or Excel worksheets.
Protection of records to enable their accurate and ready retrieval throughout the records retention period
All records in TFS are maintained permanently. Information cannot be permanently deleted by users of the system through the provided user interface (Visual Studio/Web Access). Although it is possible for a system administrator to permanently delete data, such access must be tightly controlled and managed by the IT infrastructure team in order to safeguard the integrity of the data.
Limiting system access to authorized individuals.
Access to TFS is controlled by Active Directory (AD). With a properly configured AD solution (more about this later) the requirement of identity verification is satisfied.
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.
All actions taken by TFS users have their AD user ID’s associated with any action taken on the system. With this tight AD integration in place TFS fully meets this requirement as every action taken by a user is logged.
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.
Use of operational system checks to enforce permitted sequencing of steps and events, as appropriate.
TFS is a configurable platform that can be designed to implement a customized workflow that guarantees users with appropriate rights can approve an electronic record (requirement, test case protocol, etc). Later on I will show how this can be accomplished.
Use of device (e.g., terminal) checks to determine, as appropriate, the validity of the source of data input or operational instruction.
Again as a configurable platform, TFS can be configured to verify the completeness and accuracy of data being entered into the system. The level of configuration required is dependent on the internal processes of the organization.
Determination that persons who develop, maintain, or use electronic record/electronic signature systems have the education, training, and experience to perform their assigned tasks.
As part of the quality system for FDA regulated organizations all users that will utilize a validated system must participate in a formal training program. The specifics are left to the organization to determine.
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.
Proper documented procedures (SOP’s) are left to the organization.
Use of appropriate controls over systems documentation
System documentation is essential and must be maintained as the system evolves. Access to this documentation must be controlled to those that are directly responsible to administer the system.
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.
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.
With the approach configured above there are 3 different points that can be audited to verify the authenticity of the electronic signature.
1) Windows AD directory has captured the identity of the approver and has stamped the user id in bother an “Approved By” custom field and in the change log.
2) The workflow has been configured to only allow a group of “Approvers” to approve.
3) The addition of a certification field as an additional manual step acting if effect as an e-signature. The ramifications of certifying “Yes” would be document in a referenced SOP.
In summary, we can see how we can use TFS in a situation where electronic signatures are required with a small amount configuration to the system. Most of FDA requirements are satisfied with a sound network infrastructure, security policies and SOPs.
If you are interested in learning more about how we can help you integrate TFS into your environment please feel free to reach out to me.
Thanks for following!