21 CFR 11 Compliance¶

Warning

Using CellEngine in 21 CFR 11-compliant environments requires a signed agreement with us to meet regulatory requirements. Please contact support@cellengine.com for more information.

While CellEngine offers features enabling its use in 21 CFR 11-compliant scenarios, it is your ultimate responsibility to ensure your usage of CellEngine meets all applicable rules and regulations.

Title 21 of the US Code of Federal Regulations, Part 11 regulates the use of electronic records in certain scenarios, such as when submitting records to the Food and Drug Administration. CellEngine provides features that enable its use in these regulated environments.

For the purposes of 21 CFR 11 compliance, CellEngine is considered an “open system.”

Validation¶

Subpart B, Sec. 11.10(a) requires validation of systems to ensure accuracy, reliability, consistent intended performance and the ability to discern invalid or altered documents.

CellEngine is continuously validated with several thousand automatic tests. Among other things, these comprehensive tests verify that access to resources is limited to authorized individuals; that statistics are accurate to specified tolerances; that invalid inputs are flagged and rejected; and that plots and other visualizations are correct and accurate. More specific information regarding our test system, validation framework, software development life cycle and more is available upon request.

CellEngine is proud to be the first cytometry analysis application to offer customer-specific workflow validation. We will work with you to integrate your exact analysis workflow into our test system. For example, this could include uploading files from your exact instrument, annotating them with certain metadata, gating according to your gating hierarchy and then confirming that the cell frequencies are in-range. Subsequently, we can provide you with a validation report for each release of CellEngine. Contact support@cellengine.com for more information.

Reviewable Records¶

Subpart B, Sec. 11.10(b) requires the ability to generate copies of records in both human-readable and electronic form. At any time, you may download your experiment data as follows:

A JSON file containing the complete representation of the experiment can be downloaded by clicking Export JSON from the experiment summary page.
A ZIP archive of all FCS files can be downloaded by selecting all files from the FCS Files list on the summary page and clicking Download.
A ZIP archive of all attachments can be downloaded by selecting all attachments from the Attachment list on the summary page and clicking Download.

The following additional record downloads are available:

Gated populations can be downloaded as FCS or TSV files; see exporting populations.
PDFs of illustrations can be downloaded by opening the illustration and selecting Print to PDF from the File menu. Tip: you can create a batch illustration that shows your complete gating hierarchy for each FCS file, such that all of your gate positions are viewable.
A TSV file containing statistics for your gated populations can be downloaded using the export statistics tool.

Record Retention¶

Subpart B, Sec. 11.10(c) requires that records are protected, accurate and readily retrievable throughout the records retention period. To address this requirement, you can set a Retention Policy on an experiment, which governs how long the experiment must be retained before it can be deleted. See Retention Policies for more information.

Retention Policies protect records from deletion by you and other users. Additionally, we take extensive steps to protect your data from loss due to hardware failure and natural disasters. For example, backups of your data are created automatically every hour and are retained indefinitely, and we store your FCS files in multiple, geographically redundant data centers.

Limiting System Access¶

Subpart B, Sec. 11.10(d) requires limiting system access to authorized individuals. CellEngine access requires that each individual has an account. Account identity and authenticity is provided in accordance with NIST 800-63 Identity Assurance Level (IAL) 1 and Authenticator Assurance Level (AAL) 1, which dictates requirements for user identifiers and passwords. Further access by individuals to specific resources (e.g. experiments) within CellEngine requires explicit authorization to be granted by an individual with control of the resource.

Audit Trail¶

Subpart B, Sec. 11.10(e) requires the use of audit trails to record creation, modification or deletion of electronic records. CellEngine always records actions in a read-only audit trail reporting who did what, when. Users are also able to append comments to the audit trail, helping communicate why. However, the audit trail is only visible for accounts with the 21 CFR 11 compliance add-on.

Because the detailed audit trail can be difficult to read (e.g., it records each individual gate adjustment), you can additionally create Experiment Revisions, which are immutable, permanent snapshots of experiments.

Keep the following in mind:

Revisions capture the entire state of an experiment. This includes FCS files, FCS file annotations, attachments, gates, compensations, scales, panels and illustrations.
When creating a revision, you can add brief notes to it. For example, you could state “this revision is for submission to FDA with document number XYZ.”
Revisions cannot be deleted, unless you delete the experiment to which the revision belongs. To prevent the experiment from being deleted, apply a Retention Policy.
Revisions can be viewed at any time by clicking on the revision from the revision list. Anyone with read-access to an experiment can view its revisions.
When you create a revision, your personal login session is used to electronically sign the record, indicating your authorship.
Other users with the experiment.signRevision permission may also sign an existing revision to indicate that they have reviewed and/or approved it.

Operational Systems Checks¶

Subpart B, Sec. 11.10(f) requires enforcement of permitted sequencing of steps and events, as appropriate.

CellEngine generally does not require a specific sequence of steps. However, it does enforce that revisions cannot be modified after creation and that experiments cannot be deleted while a retention policy is in effect.

Authority Checks¶

Subpart B, Sec. 11.10(g) requires that only authorized individuals can perform specific tasks. To address this requirement, CellEngine provides the following:

To sign an experiment snapshot, the experiment.read and experiment.signRevision permissions are required.
To access the system, an account is required. Organizations generally have a domain within CellEngine, of which all of their users are members.
To access an experiment, the experiment.read permission is required.
To perform an operation on an experiment, the appropriate permission is required. For example, uploading an FCS file requires fcsfile.upload. There are approximately 30 different permissions available, which can be combined into roles. For more information, see Access Management.

Input Checks¶

Subpart B, Sec. 11.10(h) requires the use of checks to determine the validity of the source of data input or operational instruction. To address this requirement, CellEngine provides the following features:

When you upload an FCS file to CellEngine, it is verified for compliance with the Flow Cytometry Standard (FCS) file format specification. This includes verification that the file can be correctly parsed and has all required sections.
You can define a set of validators that apply to FCS file annotations. For example, you can specify that the “Patient ID” column is only allowed to contain the values “P12001”, “Y12002”, “Z12003” and “D12004”; or that the the “Day” column is allowed to contain values between 0 and 60. Subsequently, if you or another user attempts to annotate a file with Patient ID K12006 or Day 61, the input will be flagged and rejected. See Annotation Validators for more information.

Training¶

Subpart B, Sec. 11.10(i) requires determination of user education, training and experience to perform assigned tasks. You are responsible for ensuring that your users of CellEngine meet this requirement; however, we can assist with onboarding and provide documentation to help train users.

Additionally, as the developers and maintainers of CellEngine, all of our staff are trained to meet this requirement.

Accountability¶

Subpart B, Sec. 11.10(j) requires policies to hold individuals accountable and responsible for actions initiated under their electronic signature. You are responsible for meeting this requirement, generally as part of your SOP for using CellEngine. Where appropriate, CellEngine provides certification statements for users to accept, such as when signing an experiment revision.

Documentation Controls¶

Subpart B, Sec. 11.10(k) requires use of appropriate controls over systems documentation.

As the developers and maintainers of CellEngine, we internally follow document control procedures for systems documentation, including operation and maintenance. As the user/customer, you have no maintenance role, but if you interpret “system operation” to mean “use of CellEngine,” you have a responsibility to follow document control procedures.

Controls for Open Systems¶

Subpart B, Sec. 11.30 requires procedures and controls designed to ensure the authenticity, integrity and confidentiality of electronic records. CellEngine uses strong encryption-in-transit (communication over HTTPS).

Signature Manifestations¶

Subpart B, Sec. 11.50 lists requirements for contents of electronic signatures. All electronic signatures placed on experiment revisions include the required elements (printed name of the signer, date and time, meaning), as well as a unique identifier for the user. See Audit Trail for more information.

Signature/Record Linking¶

Subpart B, Sec. 11.70 requires that signatures cannot be transferred to falsify an electronic record by ordinary means. Once a signature is applied to an experiment revision, it cannot be removed or modified. See Audit Trail for more information.

Electronic Signature General Requirements¶

Subpart B, Sec. 11.100(a) requires that each signature is unique to one individual and cannot be reused by or reassigned to anyone else. This is met; signatures are unique and not reusable or reassignable.

Subpart B, Sec. 11.100(b) requires verification of the identity of the individual using a signature. This is your responsibility.

Subpart B, Sec. 11.100(c) requires certification to the FDA that electronic signatures are intended to be the legally binding equivalent of traditional, handwritten signatures. This is your responsibility.

Electronic Signature Components and Controls¶

Subpart B, Sec. 11.200(a)(1) requires non-biometric signatures, including those used in CellEngine, to employ at least two distinct identification components, and lists the components required for each signing. CellEngine requires a username and password to apply an electronic signature; the password is required for every signature application.

Sec. 11.200(a)(2) requires use of signatures by only their genuine owners. It is your responsibility to ensure that your users do not share credentials.

Sec. 11.200(a)(3) requires that attempted use of an individual’s signature by anyone other than its genuine owner requires collaboration of two or more individuals. CellEngine administratively separates those who are responsible for data and those who could tamper with records; procedurally we will never apply a signature even if requested to do so by a user.

Sec. 11.200(b) does not apply; biometrics are not in use.

Controls for Identification Codes/Passwords¶

Subpart B, Sec. 11.300(a) requires each individual has a unique combination of identification code and password. Each CellEngine user has their own unique login that is only known by that person.

Sec. 11.300(b) requires that passwords are periodically checked, recalled or revised. CellEngine domain administrators can configure a maximum password age to meet this requirement. The user’s password age will be checked at sign-in.

Sec. 11.300(c) does not apply; devices cannot be used to gain access or interact with CellEngine.

Sec. 11.300(d) mandates transaction safeguards to prevent unauthorized use of credentials, and to detect and report attempts at unauthorized use. CellEngine permanently logs all sign-ins, sign-outs and authenticator (password) changes for each user.

Sec. 11.300(e) does not apply; devices cannot be used to gain access or interact with CellEngine.