As a follow up to her recent webinar, “21 CFR Part 11: Vendor Vs Sponsor Responsibilities,” Forte’s EDC Product Manager, Shannon Roznoski, provides answers to attendee questions.
Is there a specification for what constitutes an electronic signature?
21 CFR Part 11 Subpart B, 11.50 defines the specific elements of an electronic signature. It requires that all signed electronic records should contain information associated with the signing that clearly indicates all of the following:
- The printed name of the signer
- The date and time when the signature was executed
- The meaning (such as review, approval, responsibility, or authorship) associated with the signature
Subpart C further describes requirements for electronic signatures. These requirements must be met in addition to the requirements in Subpart A, general provisions, and Subpart B, Electronic Records.
Are there any Part 11 requirements for using videoconference tools to consent subjects living in a different city? Does the interaction need to be recorded?
This depends on whether the participant also signed a document and if any other documentation was obtained as part of the informed consent process.
Use this draft guidance, Use of Electronic Informed Consent in Clinical Trial Investigations Questions and Answers, Draft, March 2015, to help you determine if the informed consents you obtain via video conference tools need to be recorded.
What kind of procedural control could you implement if there is a gap in audit trail within the system?
This depends on the type of data contained in the electronic record (subject data in an EDC versus non-critical user account information, such as phone number), how the data was used (direct submission to the FDA or in support of data used in an FDA submission) and the type of gap (does not capture a reason for change versus no audit trail at all). For example, let’s say the system in question does not keep a full audit trail of changes to usernames. As a result, it allows an old username for one person to be re-used as a username for another person. This breaks the requirement that electronic signatures be unique to the individual for systems that use a combination of username and password for the electronic signature.
The ideal system audits changes to usernames and prevents the creation of duplicate usernames, including historical usernames. If the system cannot do this technically, the organization could implement a policy that usernames, once assigned, cannot be changed or deleted. If a person’s username needs to change, the old account must be deactivated and a new account, with the new username, is created. Likely, there would need to be further controls implemented, such as limiting management of user accounts to a small group of people and removing permissions to delete user accounts from the account admin role.
Who is responsible for determining/defining requirements for software development? (i.e. technical controls, quality processes, product documentation)
Each software vendor develops its own interpretation of how to implement the technical controls for Part 11 compliance. These vendors then define their own quality processes and documentation using that interpretation. Ideally, this is done with an understanding of accepted industry best practices. Software vendors may also hire third-party consultants, who are experienced with Part 11, to complete an audit of their systems and provide feedback to help the company ensure it meets the requirements of Part 11.
An organization that purchases the software and intends to validate, is responsible for making sure the software vendor meets the requirements of the technical controls, follows a quality process, and produces acceptable product documentation. This can be accomplished in a number of ways, including:
- Completing software vendor audits
- Reviewing third-party audit reports from previous audits
- Asking the software vendor for referrals and talking to its current customers
Should the sponsor document the intended use in a formal document? What is the typical format?
Understanding the intended use of each software system is an important part of managing the entire portfolio of systems used within an organization. Whether it’s documented individually in a formal file or as part of an existing risk assessment/risk management process, it is a great idea to document the intended use of each system. Doing this helps you understand what regulatory considerations, if any, apply to each system, the level of risk a system has on its impact to participant safety and data quality, as well as the impact on day-to-day operations.
Want to learn more about the roles organizations and vendors play in validating an EDC system? Register for our free, upcoming webinar, Understanding, Achieving and Maintaining 21 CFR Part 11 Compliance.