Executive Summary
ClinicAI is a data extraction and review tool that assists clinical research associates in abstracting data from patient records. It is designed with a human-in-the-loop architecture that maintains clear separation between AI-assisted extraction and regulated electronic records.
Key architectural decisions:
- AI extracts and presents data; humans review, edit, and approve
- No AI-generated data enters the EDC without explicit human action
- Complete audit trail of AI suggestions and human decisions
- Staging layer is separate from regulated record systems
Regulatory Context
21 CFR Part 11 Applicability
21 CFR Part 11 applies to electronic records that are "created, modified, maintained, archived, retrieved, or transmitted" under FDA regulations. The key question for any clinical trial technology is: what constitutes the regulated record?
In the ClinicAI workflow:
- The EDC entry is the regulated record. This is created by the human user, not by ClinicAI.
- ClinicAI's staging view is a working document. It presents extracted data for review but is not itself submitted to the FDA.
- The human transfer action creates the record. The CRA reviews the extracted data, makes any necessary edits, and enters it into the EDC.
Classification: ClinicAI functions as a data extraction and review aid, analogous to a sophisticated document reader. It is not a Software as a Medical Device (SaMD) and does not make clinical decisions. The AI reads; the human decides.
FDA Guidance on AI in Clinical Trials
FDA guidance distinguishes between AI systems that directly create or modify regulated records (which require full validation) and AI systems that provide advisory output for human decision-making (which do not require SaMD classification).
ClinicAI falls into the latter category. The architecture ensures that:
- Every AI extraction is presented as a suggestion, not a final value
- The human reviewer has full authority to accept, edit, or reject any suggestion
- The EDC entry is made by the human, with the AI serving as a reading aid
System Architecture
Staging Layer
The staging layer is a key architectural component. It mirrors the structure of the target EDC (field names, data types, expected formats) but operates as a separate, non-regulated system. This design provides several benefits:
- Clear separation: ClinicAI never writes to the regulated EDC directly
- Review workflow: Human reviewers see extracted data in a familiar format before transfer
- Edit capability: Any field can be modified before transfer to the EDC
- Audit independence: ClinicAI maintains its own audit trail separate from EDC audit trails
Human Review Interface
The review interface is designed to ensure genuine human oversight, not passive acceptance:
| Feature | Purpose |
|---|---|
| Field-by-field display | Reviewer sees each extracted value individually |
| Confidence scores | Low-confidence extractions are visually flagged |
| Source citation links | One click to view the source passage in context |
| Edit capability | Any field can be modified before acceptance |
| Explicit action required | No "accept all" option; each field requires acknowledgment |
| Cannot Determine option | AI can indicate when data is ambiguous or missing |
Audit Trail Design
What Is Logged
ClinicAI maintains a complete audit trail of all system activity:
| Event | Data Captured |
|---|---|
| Document upload | Timestamp, user ID, document hash, file metadata |
| AI extraction | Timestamp, model version, extracted values, confidence scores, source citations |
| Human review | Timestamp, user ID, field reviewed, action (accept/edit/reject) |
| Edit action | Original AI value, edited value, user ID, timestamp |
| Transfer to EDC | Timestamp, user ID, fields transferred, target system |
| User authentication | Login/logout events, session duration |
Audit Trail Integrity
- Audit records are append-only; no deletion or modification is permitted
- Each record includes a cryptographic hash linking to the previous record
- Audit data is stored in a separate database table with restricted access
- Export functionality for regulatory inspection
Access Controls
User Authentication
- Unique user IDs for all system users
- Password requirements enforced (minimum length, complexity)
- Session timeout after period of inactivity
- Multi-factor authentication available for enterprise deployments
Role-Based Permissions
| Role | Permissions |
|---|---|
| Reviewer (CRA) | Upload documents, review extractions, transfer to EDC |
| Manager | All Reviewer permissions plus view audit logs, manage users |
| Administrator | All Manager permissions plus configure protocols, system settings |
Data Security
Encryption
- Data in transit: TLS 1.3
- Data at rest: AES-256 encryption
- Database: Encrypted PostgreSQL (Supabase)
Data Handling
- Patient records processed in memory; not stored permanently unless explicitly saved
- Uploaded files deleted after processing (configurable retention)
- No patient data used for AI model training
- BAA-covered AI processing (Anthropic Claude)
Validation Considerations
System Validation
For organizations requiring formal system validation, ClinicAI provides:
- Functional requirements documentation
- Design specifications
- Test protocols (IQ, OQ, PQ templates)
- Traceability matrix
- Validation summary report template
AI Model Considerations
ClinicAI uses the Claude AI model for extraction. Key considerations:
- Model version is logged with each extraction for traceability
- Model updates are managed through change control process
- Human review layer mitigates risk of model variation
- Accuracy benchmarks available on request
Note: Because all AI output is reviewed by humans before entering the regulated record, model updates do not automatically trigger revalidation of the EDC system. The human review step provides a consistent control point regardless of AI model version.
Questions
For detailed technical questions about ClinicAI's compliance architecture, please contact: