Tag Archives: Biotech

Compliance in the Cloud: 21 CFR Part 11 Requirements

Hello good people of the world! Today’s post is the next in the series on compliant software in the cloud. Today we’re taking a deep dive into the FDA’s 21st Code of Federal Regulations, Part 11 (21CFR11). If you’re not familiar, 21CFR11 is an ancient (written in the late 1990s) regulatory statute on the use of electronic records and electronic signatures in regulated industries such as medical device, pharmaceutical, and biologic manufacturing. Despite it’s age, 21CFR11 is the governing statute for the use of computer systems in regulated spaces, so it’s critical that we understand it well.

In this post, I’ll give a abridged version of each applicable section of the statute, and then detail the engineering and procedural requirements that are typically used to meet the statute in the design, development, and implementation of a cloud-based computerized system. Let’s go!

Subpart B §11.10, Controls for Closed Systems

  • Persons who use closed systems to create, modify, maintain, or transmit electronic records shall employ procedures and controls designed to ensure the authenticity, integrity, and, when appropriate, the confidentiality of electronic records. Controls used require the following:
    • Validation
    • Legibility
    • Record Protection
    • Limited System Access
    • Secure Audit Trails
    • Operational System Checks
    • Authority checks
    • Device Checks for data validity
    • Training
    • Policies in place for operational adherence
    • Control of Distribution
    • Change Control Procedures

Engineering requirements:

  • System shall employ HTTPS and other modern web application security technology per according to ISO/IEC 27001 and ISO/IEC 27018 standards
  • System shall employ user-level security, ensuring each user is required to maintain a unique username and password to access the system
  • System shall employ role-based permissions and limit access to only functionality required by the job role
  • System shall employ audit trail to ensure compliant activities are documented with username, time/date stamp, and reason for signature
  • System shall employ electronic signatures with username, time/date stamp, and reason for signature for GxP-related activities

Procedural requirements:

  • System shall be validated
  • Audit trails shall be reviewed
  • Appropriate training shall be assigned and managed
  • Use and administration procedures shall exist
  • Change control procedures shall exist

Subpart B §11.50, Signature Manifestation

Requirements for signature manifestation:

  • Signed electronic records shall 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; and
  • The meaning (such as review, approval, responsibility, or authorship) associated with the signature.

These are subject to the same controls as for electronic records and shall be included as part of any human readable form of the electronic record (such as electronic display or printout).

Engineering requirements:

  • System shall employ electronic signatures with username, time/date stamp, and reason for signature for GxP-related activities

Procedural requirements:

  • System shall be validated
  • Audit trails shall be reviewed
  • Appropriate training shall be assigned and managed
  • Use and administration procedures shall exist
  • Change control procedures shall exist

Subpart B §11.70, Signature/Record Linking

Electronic signatures and handwritten signatures executed to electronic records shall be linked to their respective electronic records to ensure that the signatures cannot be excised, copied, or otherwise transferred to falsify an electronic record by ordinary means.

Engineering requirements:

  • System shall employ electronic signatures with username, time/date stamp, and reason for signature for GxP-related activities
  • Electronic signatures shall be linked to specific records and cannot be transferred by any means.

Subpart C §11.100, General Requirements

Each electronic signature shall be unique to one individual and shall not be reused by, or reassigned to, anyone else.

Before an organization establishes, assigns, certifies, or otherwise sanctions an individual’s electronic signature, or any element of such electronic signature, the organization shall verify the identity of the individual.

Persons using electronic signatures shall, prior to or at the time of such use, certify to the agency that the electronic signatures in their system, used on or after August 20, 1997, are intended to be the legally binding equivalent of traditional handwritten signatures.

  • The certification shall be submitted in paper form and signed with a traditional handwritten signature, to the Office of Regional Operations (HFC-100), 5600 Fishers Lane, Rockville, MD 20857.
  • Persons using electronic signatures shall, upon agency request, provide additional certification or testimony that a specific electronic signature is the legally binding equivalent of the signer’s handwritten signature.

Engineering requirements:

  • System shall employ user-level security, ensuring each user is required to maintain a unique username and password to access the system
  • System shall employ role-based permissions and limit access to only functionality required by the job role
  • System shall employ electronic signatures with username, time/date stamp, and reason for signature for GxP-related activities
  • Electronic signatures shall be linked to specific records and cannot be transferred by any means.

Procedural requirements:

  • Procedure shall exist for systems users to sign testimony that their electronic signature is equivalent to their handwritten signature and for this testimony to be communicated to the agency

Subpart C §11.300, Controls for Identification codes/passwords

Persons who use electronic signatures based upon use of identification codes in combination with passwords shall employ controls to ensure their security and integrity. Such controls shall include:

  • Maintaining the uniqueness of each combined identification code and password, such that no two individuals have the same combination of identification code and password.
  • Ensuring that identification code and password issuances are periodically checked, recalled, or revised (e.g., to cover such events as password aging).
  • Following loss management procedures to electronically deauthorize lost, stolen, missing, or otherwise potentially compromised tokens, cards, and other devices that bear or generate identification code or password information, and to issue temporary or permanent replacements using suitable, rigorous controls.
  • Use of transaction safeguards to prevent unauthorized use of passwords and/or identification codes, and to detect and report in an immediate and urgent manner any attempts at their unauthorized use to the system security unit, and, as appropriate, to organizational management.
  • Initial and periodic testing of devices, such as tokens or cards, that bear or generate identification code or password information to ensure that they function properly and have not been altered in an unauthorized manner.

Engineering requirements:

  • System shall employ user-level security, ensuring each user is required to maintain a unique username and password to access the system
  • System shall employ role-based permissions and limit access to only functionality required by the job role
  • System shall require each user have a unique username and password
  • System shall expire passwords after a set amount of time
  • System shall lockout users after a set amount of failed login attempts
  • System shall have documented password strength requirements
  • System shall obfuscate passwords when entered and displayed on User Interfaces
  • System shall store passwords in an encrypted manner, and never display, store, or transmit passwords in plain text

Procedural requirements:

  • Procedures shall exist for the administration of users into the system
  • Procedures shall exist for the routine use of computer systems

What Engineering or Procedural requirements do you think are critical for cloud-based computer systems? Comment below!

Like this MWV (Mike Williamson Validation) blog post? Be sure to like, share, and subscribe!

Advertisement

PLC/HMI IOQ – What to Test?

PLC

Hello good people of the world! Today’s post is on initial control system Installation and Operational Qualification (IOQ) of a simple system consisting of an Human/Machine Interface (HMI), Programmable Logic Controller (PLC), and any number of end devices (valves, pumps, sensors, etc.). The question is what should be tested?

Obviously there’s a ton of guidance out there (see e.g.: GAMP) that will have a lot more detail than this post. The purpose here is to list at a high level the tests that could be expected. So let’s get started!

Installation Qualification
IQ can be its own protocol or combined with OQ in an IOQ for cases without a ton of complexity. IQ is supposed to verify the installation of hardware, software, and any peripherals. You also want to check what documentation is available/applicable here. IQ tests may include:

  • Documentation Verification (e.g. SOPs, EREC/ESIG assessment, operating/maintenance manuals, panel and electrical drawings, etc.)
  • Hardware Verification: verify the make and model of major components at a minimum
  • Software Verification: verify/record software versions. You’ve got to know what you’ll be OQ’ing!
  • Configuration Verification: verify any hardware and/or software configuration. This could be two tests, one for hardware, one for software.
  • Loop Check Verification: verify loop checks are performed.
  • Alarm Configuration Verification: ideally alarms a setup in such a way that you don’t have to functionality test them all!
  • Any other critical installation items

Operational Qualification
OQ is the meat of your control qualification. Here you want to test critical functions, that hopefully you have identified earlier (see here for one approach). OQ may test:

  • Interlock Verification including e-stops. A lot of interlocks are safety/business related, but they’re often included in OQ due to how critical they are.
  • Functional Alarm Verification – be sure to include data loss/communication alarms
  • HMI Navigation and Layout Verification
  • Restart/Recovery Verification
  • Sequence of Operations Verification

What kinds of testing are you sure to cover in your control system IOQ protocols? Comment below.

Like this MWV (Mike Williamson Validation) blog post? Be sure to like, share, and subscribe!