FDA 21 CFR Part 11 sets the requirements for electronic records and electronic signatures used in FDA-regulated clinical activities. For oncology dosing software, compliance is not optional - dose recommendations, investigator approvals, and parameter adjustments are all records that fall under Part 11 if they are used to support regulatory submissions. Every dosing software vendor in this space claims compliance. The practical reality is that claims are easier to make than audit trails are to implement correctly.
This article examines the seven specific Part 11 requirements that are most commonly inadequately implemented in clinical dosing and TDM software, based on our review of competitor platform audit documentation and our own compliance qualification process. These are not obscure edge cases - they are requirements that appear directly in the regulation text and that FDA inspectors have cited in 483 observations at clinical sites.
Requirement 1: Audit Trail Completeness - Including System-Initiated Actions
21 CFR 11.10(e) requires that computer systems have secure, computer-generated, time-stamped audit trails that independently record operator entries and actions that create, modify, or delete electronic records. The phrase "operator entries and actions" is often interpreted narrowly to mean only manual user inputs. The FDA's interpretation is broader: any action that creates, modifies, or deletes a record requires an audit trail entry, including system-initiated actions.
In dosing software, system-initiated actions include: automatic AUC recalculation triggered by a new lab value being ingested from the EHR or EDC, automatic dose recommendation update triggered by a creatinine clearance value crossing a predefined threshold, and session timeout resulting in an incomplete record being auto-saved. Each of these creates or modifies an electronic record. Each requires an audit trail entry with the system process identifier, timestamp, and nature of the modification. Software that logs only human-initiated actions fails this requirement.
Requirement 2: Audit Trail Sequencing and Tamper Evidence
The audit trail must be tamper-evident. This means the system must be able to demonstrate that audit trail records have not been deleted or modified after creation. Simple database logging to a writable table does not satisfy this requirement if a database administrator with write access can delete or modify audit trail records.
The implementation standard that satisfies tamper-evidence is typically one of three approaches: write-once audit log storage (WORM storage, immutable cloud storage like AWS S3 Object Lock), cryptographic chaining of audit records (each record includes a hash of the previous record, making modification detectable), or a separate audit log system with access controls that prevent modification by anyone who can access the operational database. Many clinical software systems use a simple audit log table in the same database as the operational data, accessible to the same database administrators. This architecture fails the tamper-evidence requirement.
Requirement 3: Electronic Signature Manifestation
21 CFR 11.50 requires that signed electronic records contain information associated with the signing that clearly indicates: the printed name of the signer, the date and time of the signing, and the meaning of the signature (such as review, approval, responsibility, or authorship). The "meaning of the signature" requirement is often overlooked.
In dosing software, a physician's approval of a dose recommendation carries a specific meaning: they have reviewed the PK model output, assessed its clinical appropriateness for this patient, and approve the recommended dose for administration. An electronic signature that simply records "Dr. Smith approved on 2025-03-15 at 14:23" without specifying that this is an approval of a dose recommendation for a specific patient for a specific cycle does not satisfy the manifestation requirement. The signed record must contain enough contextual information that the signature's meaning is unambiguous.
Requirement 4: Linked Name and Identification Code
Part 11.100(a) requires that each person who uses electronic signatures have a unique identifying combination of components. The typical implementation is a username plus password. What is frequently inadequate is the linkage between the electronic signature identifier and the user's name in the regulatory documentation. If the audit trail records "user ID 4421 approved" and there is no system-maintained link between user ID 4421 and the name "Dr. James Chen," the audit trail does not satisfy this requirement.
The linkage must be maintained in the system and must be historically accurate - if Dr. James Chen's user ID was 4421 during the trial period, that mapping must be retrievable even if he has since left the institution and his account was deactivated. Systems that delete user account information upon deactivation are non-compliant with this requirement for regulatory record purposes.
Requirement 5: System Access Controls and Training Documentation
Part 11.10(d) requires limiting system access to authorized individuals. For dosing software, this means role-based access control: CRCs who enter PK sample data should not have the ability to modify dose recommendations; investigators who approve dose recommendations should not have the ability to alter the underlying PK model parameters; biostatisticians running population model updates should not have the ability to modify individual patient records.
The Part 11 requirement goes beyond technical access controls to include procedural documentation: there must be written procedures for access authorization, user account creation and deactivation, and what to do when an authorized user leaves the institution or changes roles. In FDA inspections at clinical sites, the most common finding related to this requirement is that access control procedures exist on paper but were not followed - specifically that accounts were not deactivated promptly when staff left. This is a site operations finding, not a software deficiency, but the software must generate the documentation needed to demonstrate timely deactivation.
Requirement 6: Operational System Checks
21 CFR 11.10(f) requires operational system checks to enforce the sequence of events when required. In the context of dosing software, the sequence of events is: PK data entered, AUC calculated, recommendation generated, investigator review completed, investigator signature applied, dose transmitted to pharmacy. The system must enforce that these events occur in the correct sequence and that no step can be completed out of order.
Specifically, the system must prevent a dose from being transmitted to pharmacy or dispensed before an investigator electronic signature approving the recommendation is on file. A dose order entered in the pharmacy system before the dosing software's signature workflow is complete represents a sequencing failure. The software's integration with the pharmacy must include a handshake that confirms signature completion before dose preparation can begin. Systems that generate a dose recommendation PDF that can be physically handed to the pharmacy without electronic signature confirmation fail this requirement.
Requirement 7: Adequate Computer System Validation
Part 11.10(a) requires that systems used to create, modify, maintain, archive, retrieve, or transmit electronic records be validated to ensure accuracy, reliability, consistent intended performance, and the ability to discern invalid or altered records. Validation is not a one-time event - it must cover the system's current configuration, including any customization done for a specific trial (custom PK models, site-specific dose decision thresholds).
The validation documentation that FDA inspectors typically request includes: installation qualification (IQ), operational qualification (OQ), and performance qualification (PQ) documentation for the current software version; a risk assessment that identifies critical functions for the software's intended use (for dosing software: AUC calculation accuracy, audit trail completeness, electronic signature workflow); and change control documentation for any modifications since the last validation, including vendor patches and updates.
Software-as-a-service (SaaS) platforms add complexity here because the software is updated by the vendor without the clinical site's direct control. Sites using SaaS clinical software must have a bridging validation strategy that covers vendor-released updates, typically through a supplier qualification agreement that specifies the vendor's validation obligations and the change notification timeline that allows sites to assess impact before an update goes live.
How to Evaluate a Vendor's Compliance Claims
When evaluating a dosing software vendor's 21 CFR Part 11 compliance claims, request the following specific documents: a summary validation report or IQ/OQ/PQ documentation for the current software version; the audit trail architecture description (what is logged, how tamper-evidence is implemented, retention period); a sample audit trail export from a test environment demonstrating the fields logged for each of the six action types described above; and the process for change control notification and bridging validation support for SaaS updates.
A vendor that cannot produce these documents, or that responds with general statements about "compliance with all applicable regulations" without specific documentation, is a vendor whose compliance claims should not be accepted at face value during vendor qualification.
Conclusion: Compliance Is in the Implementation, Not the Marketing
21 CFR Part 11 compliance for clinical dosing software is achievable, but it requires specific architectural decisions - particularly around audit trail tamper-evidence, system-initiated action logging, and sequence enforcement - that are often either underdeveloped or absent in platforms that have not undergone formal qualification against the regulation's specific requirements.
DoseMind maintains a complete validation package (IQ/OQ/PQ) for all supported software versions, with audit trail architecture designed to meet all seven requirements described here. Our compliance documentation is available for site review during vendor qualification. Contact the team at hello@dosemind.com to request the compliance documentation package.