Skip to main content

Healthcare & FDA Industry Appendix

AI Governance for Regulated Healthcare Applications


Document Control

FieldDetails
Document TypeIndustry-Specific Appendix
Parent DocumentsAI Governance Framework (Docs 01-18)
Applies ToAI systems in healthcare, life sciences, medical devices
Regulatory ScopeFDA 21 CFR Part 11, FDA AI/ML Guidance, HIPAA, EU MDR/IVDR
Version1.0

1. Overview

1.1 Purpose

This appendix extends the AI Governance Framework for organizations developing or deploying AI systems in healthcare and life sciences contexts. It provides additional controls, documentation requirements, and regulatory mappings specific to FDA-regulated environments.

1.2 Scope

In ScopeRegulatory Framework
Software as a Medical Device (SaMD)FDA 21 CFR Part 820, EU MDR
Clinical Decision Support (CDS)FDA CDS Guidance, EU MDR
AI-Assisted DiagnosticsFDA AI/ML SaMD Framework
Drug Discovery AIFDA 21 CFR Parts 11, 210, 211
Clinical Trial AIFDA 21 CFR Part 11, ICH E6(R2)
Healthcare Operations AIHIPAA, State privacy laws
Electronic Health Records AIHIPAA, 21st Century Cures

1.3 Coditect Platform Application

For Coditect's autonomous AI development platform targeting healthcare:

Coditect Use CaseRegulatory RequirementsFramework Mapping
Autonomous code generation for SaMDFDA 21 CFR Part 11, Part 820This appendix + Docs 09, 16
Multi-agent clinical workflow automationHIPAA, FDA validationThis appendix + Docs 15, 16
AI-generated documentation for submissionsFDA 21 CFR Part 11This appendix + Doc 06

2. FDA 21 CFR Part 11 Compliance

2.1 Electronic Records Requirements

AI systems producing electronic records for FDA-regulated processes must comply with Part 11:

Part 11 RequirementAI Governance ControlImplementation
§11.10(a) ValidationSystem Card validation sectionDocumented IQ/OQ/PQ protocols
§11.10(b) Record accuracyContinuous Monitoring (Doc 16)Output verification, drift detection
§11.10(c) Record protectionSecurity controlsEncryption, access controls
§11.10(d) Audit trailsComprehensive loggingImmutable audit trail
§11.10(e) Operational checksPre-production gateInput validation, error handling
§11.10(k) Authority checksAccess control policyRole-based permissions

2.2 AI-Specific Part 11 Controls

┌─────────────────────────────────────────────────────────────┐
│ AI SYSTEM ARCHITECTURE │
│ (Part 11 Compliant Configuration) │
└─────────────────────────────────────────────────────────────┘

┌─────────────────────────┼─────────────────────────────┐
│ │ │
▼ ▼ ▼
┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│ INPUT │ │ MODEL │ │ OUTPUT │
│ VALIDATION │ │ EXECUTION │ │ CONTROLS │
│ │ │ │ │ │
│ • User auth │ │ • Version │ │ • Audit │
│ • Signature │ │ control │ │ trail │
│ • Input │ │ • Config │ │ • Digital │
│ checking │ │ locking │ │ signature │
│ • Timestamp │ │ • Isolation │ │ • Timestamp │
└─────────────┘ └─────────────┘ └─────────────┘

2.3 Audit Trail Requirements

EventRequired DataRetention
AI system accessUser ID, timestamp, action3 years minimum
Model invocationInput hash, output hash, versionLife of record + 3 years
Configuration changeBefore/after, user, timestamp, reasonLife of system
Output modificationOriginal, modified, user, reasonLife of record + 3 years
Error/exceptionError type, context, resolutionLife of system

3. FDA AI/ML SaMD Framework

3.1 Predetermined Change Control Plan (PCCP)

For AI systems subject to FDA's AI/ML SaMD framework:

PCCP ElementDocumentation RequirementFramework Reference
SaMD Pre-Specifications (SPS)Anticipated modifications descriptionSystem Card §4
Algorithm Change Protocol (ACP)Change management proceduresOperating Model §8
Performance TargetsQuantitative performance boundsSystem Card §5
Testing ProtocolValidation methodologyAIA §4
Modification ReportingReporting commitmentsMonitoring Standard

3.2 Total Product Lifecycle (TPLC) Approach

┌─────────────────────────────────────────────────────────────┐
│ TOTAL PRODUCT LIFECYCLE (TPLC) FOR AI │
└─────────────────────────────────────────────────────────────┘


┌───────────────┐ ┌───────────────┐ ┌───────────────┐
│ DESIGN & │───▶│ CLINICAL │───▶│ REGULATORY │
│ DEVELOPMENT │ │ VALIDATION │ │ SUBMISSION │
│ │ │ │ │ │
│ • Intended use│ │ • Clinical │ │ • 510(k)/PMA │
│ • Risk class │ │ studies │ │ • PCCP │
│ • Algorithm │ │ • Performance │ │ • Labeling │
│ development │ │ validation │ │ │
└───────────────┘ └───────────────┘ └───────────────┘
│ │ │
│ │ │
▼ ▼ ▼
┌───────────────┐ ┌───────────────┐ ┌───────────────┐
│ REAL-WORLD │◀───│ ONGOING │◀───│ MARKET │
│ PERFORMANCE │ │ MONITORING │ │ RELEASE │
│ │ │ │ │ │
│ • RWPE data │ │ • Drift │ │ • Deployment │
│ • Adverse │ │ detection │ │ • Training │
│ events │ │ • Retraining │ │ • Support │
│ • Updates │ │ triggers │ │ │
└───────────────┘ └───────────────┘ └───────────────┘

3.3 Risk Classification for SaMD

SaMD Risk CategoryState of HealthcareSignificanceAI Governance Tier
I (Low)Non-seriousInformsMedium
II (Medium-Low)Non-seriousDrivesHigh
II (Medium-High)SeriousInformsHigh
III (High)Serious/CriticalDrivesCritical
IV (Highest)CriticalTreats/DiagnosesCritical

4. HIPAA Compliance for AI

4.1 PHI Handling in AI Systems

HIPAA RuleAI RequirementControl
Privacy RuleMinimum necessary PHIInput filtering, anonymization
Security RuleTechnical safeguardsEncryption, access controls
Breach NotificationIncident response24-hour reporting

4.2 AI-Specific PHI Controls

┌─────────────────────────────────────────────────────────────┐
│ PHI PROCESSING ARCHITECTURE │
└─────────────────────────────────────────────────────────────┘

┌─────────────────────────────┼─────────────────────────────┐
│ │ │
▼ ▼ ▼
┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐
│ DE-IDENTIFICATION│ │ SECURE PROCESSING│ │ RE-IDENTIFICATION│
│ │ │ │ │ CONTROLS │
│ • Safe Harbor │ │ • Encrypted │ │ │
│ method │ │ transit/rest │ │ • Authorized │
│ • Expert │ │ • Access │ │ users only │
│ determination │ │ logging │ │ • Audit trail │
│ • Token mapping │ │ • Isolation │ │ • Time-limited │
└─────────────────┘ └─────────────────┘ └─────────────────┘

4.3 BAA Requirements for AI Vendors

BAA ProvisionAI-Specific Language
Permitted usesAI processing limited to contracted services
Training dataPHI NOT used for model training
De-identificationStandards for AI-processed PHI
Breach notification24-hour notification for AI incidents
Audit rightsAI system audit provisions

5. Clinical Decision Support (CDS) Classification

5.1 FDA CDS Guidance Criteria

AI-based CDS is NOT a device (exempt from FDA regulation) if ALL four criteria are met:

CriterionDescriptionDocumentation
1. Not intended for narrow populationsDoes not require analysis of device dataSystem Card intended use
2. Intended for HCP or patientUser is qualified professional or patientLabeling, user documentation
3. Intended for enabling reviewUser can independently review basisExplainability features
4. Not intended to replace HCP judgmentUser makes final clinical decisionHuman oversight requirements

5.2 CDS Classification Decision Tree

                    ┌─────────────────────┐
│ AI/ML System │
│ Healthcare Context │
└─────────────────────┘

┌─────────┴─────────┐
│ Meets ALL 4 CDS │
│ exemption criteria?│
└─────────┬─────────┘

┌───────────────┼───────────────┐
│ │ │
▼ │ ▼
┌──────────┐ │ ┌──────────────┐
│ YES │ │ │ NO │
│ │ │ │ │
│ Non-device│ │ │ Device (SaMD)│
│ CDS │ │ │ │
└──────────┘ │ └──────────────┘
│ │
│ ▼
│ ┌──────────────┐
│ │ Determine │
│ │ risk class │
│ │ (I-IV) │
│ └──────────────┘

6. Healthcare AI Documentation Templates

6.1 SaMD System Card Addendum

[Supplement to standard System Card, Document 06]

SectionRequired Content
6.1 Intended Use StatementFDA-compliant intended use, indications for use
6.2 Device ClassificationClass I/II/III, SaMD category I-IV
6.3 Clinical ValidationStudy design, patient population, performance
6.4 LabelingInstructions for use, warnings, contraindications
6.5 PCCP ReferenceIf applicable, SPS and ACP summary
6.6 Substantial EquivalencePredicate device comparison (510(k))

6.2 Clinical Validation Summary Template

## Clinical Validation Summary

### Study Design
- Study Type: [Prospective/Retrospective/Hybrid]
- Endpoints: [Primary and secondary]
- Sample Size: [N=X, power calculation]
- Population: [Inclusion/exclusion criteria]
- Comparator: [Ground truth or predicate]

### Performance Results
| Metric | Result | 95% CI | Target |
|--------|--------|--------|--------|
| Sensitivity | [X]% | [X-Y]% | >[Z]% |
| Specificity | [X]% | [X-Y]% | >[Z]% |
| AUC | [X] | [X-Y] | >[Z] |
| PPV | [X]% | [X-Y]% | >[Z]% |
| NPV | [X]% | [X-Y]% | >[Z]% |

### Subgroup Analysis
| Subgroup | N | Performance | Notes |
|----------|---|-------------|-------|
| [Age group] | [N] | [Result] | [Notes] |
| [Sex] | [N] | [Result] | [Notes] |
| [Race/Ethnicity] | [N] | [Result] | [Notes] |
| [Comorbidities] | [N] | [Result] | [Notes] |

### Failure Mode Analysis
| Failure Mode | Frequency | Clinical Impact | Mitigation |
|--------------|-----------|-----------------|------------|
| [Mode 1] | [X]% | [Impact] | [Mitigation] |

### Conclusions
[Summary of clinical validation findings and suitability for intended use]

6.3 HIPAA AI Risk Assessment Addendum

## HIPAA AI Risk Assessment

### PHI Elements Processed
| PHI Element | Processing Purpose | Minimum Necessary | Safeguard |
|-------------|-------------------|-------------------|-----------|
| [Element] | [Purpose] | [Yes/No] | [Control] |

### Security Controls
| Control Category | Implementation | Evidence |
|-----------------|----------------|----------|
| Access Control | [Description] | [Location] |
| Audit Controls | [Description] | [Location] |
| Integrity Controls | [Description] | [Location] |
| Transmission Security | [Description] | [Location] |

### Risk Analysis
| Threat | Likelihood | Impact | Risk Level | Mitigation |
|--------|------------|--------|------------|------------|
| [Threat] | [L/M/H] | [L/M/H] | [L/M/H/C] | [Control] |

### BAA Status
- Vendor: [Name]
- BAA Executed: [Yes/No/N/A]
- BAA Date: [Date]
- Special Provisions: [AI-specific terms]

7. Healthcare AI Monitoring Requirements

7.1 Real-World Performance (RWP) Monitoring

Metric CategoryMetricsFrequencyAlert Threshold
Clinical AccuracySensitivity, specificity, AUCDaily>5% degradation
Demographic ParityPerformance by subgroupWeekly>10% disparity
Error PatternsFalse positive/negative typesDailyPattern emergence
User FeedbackOverride rate, satisfactionWeekly>20% override
Adverse EventsRelated clinical eventsContinuousAny occurrence

7.2 Adverse Event Reporting

Event TypeReporting TimelineReporting Channel
Death or serious injuryWithin 24 hoursFDA MedWatch (MDR)
Malfunction (potential harm)Within 30 daysFDA MedWatch (MDR)
Near missInternal documentationQuality system
User complaint5 business daysCAPA system

7.3 Retraining Triggers

TriggerThresholdAction
Accuracy degradation>5% from baselineEvaluate retraining need
Data drift detectionPSI >0.2Mandatory evaluation
Population shift>10% demographic changeSubgroup revalidation
Clinical guideline changeExternal updateAlgorithm review
Adverse event pattern3+ similar eventsRoot cause analysis

8. Regulatory Submission Support

8.1 FDA Submission Document Checklist

For 510(k) Submissions:

DocumentAI Framework SourceStatus
Intended use statementSystem Card §1
Device descriptionSystem Card §2-3
Substantial equivalenceSaMD Addendum §6.6
Software documentationSystem Card, AI-BOM
Performance testingClinical Validation Summary
LabelingSaMD Addendum §6.4
Cybersecurity documentationSecurity assessment
PCCP (if applicable)SaMD Addendum §6.5

8.2 EU MDR Technical File for AI

MDR RequirementAI Framework Source
Device descriptionSystem Card
UDI informationAI-BOM header
Risk management fileAIA
Clinical evaluationClinical Validation Summary
Post-market surveillance planMonitoring Standard
CybersecuritySecurity controls documentation

9. Coditect Healthcare Implementation Guide

9.1 Platform Configuration for Healthcare

Coditect FeatureHealthcare ConfigurationRegulatory Basis
Audit TrailImmutable, Part 11 compliant21 CFR Part 11.10(e)
Access ControlRole-based, audit-logged21 CFR Part 11.10(d)
Electronic SignaturesPart 11 compliant signatures21 CFR Part 11.100
Validation PackageIQ/OQ/PQ documentation21 CFR Part 11.10(a)
PHI HandlingDe-identification, encryptionHIPAA Security Rule
Agent BoundariesHealthcare-specific constraintsSaMD risk controls

9.2 Coditect Healthcare Use Cases

Use CaseRegulatory PathFramework Controls
Clinical documentation generationPart 11 electronic recordsDoc 09 GenAI controls + Part 11
SaMD development automationFDA validation requirementsThis appendix + Doc 16
Clinical trial documentationICH E6(R2), Part 11This appendix + Doc 06
Healthcare workflow AIHIPAA, non-device CDSDoc 09 + HIPAA controls

9.3 Validation Approach for Coditect

┌─────────────────────────────────────────────────────────────┐
│ CODITECT HEALTHCARE VALIDATION STRATEGY │
└─────────────────────────────────────────────────────────────┘

┌─────────────────────────────┼─────────────────────────────┐
│ │ │
▼ ▼ ▼
┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐
│ INSTALLATION │ │ OPERATIONAL │ │ PERFORMANCE │
│ QUALIFICATION │ │ QUALIFICATION │ │ QUALIFICATION │
│ (IQ) │ │ (OQ) │ │ (PQ) │
│ │ │ │ │ │
│ • Infrastructure│ │ • Functional │ │ • Real-world │
│ verification │ │ testing │ │ validation │
│ • Configuration │ │ • Boundary │ │ • Output │
│ documentation │ │ testing │ │ verification │
│ • Audit trail │ │ • Error │ │ • User │
│ verification │ │ handling │ │ acceptance │
└─────────────────┘ └─────────────────┘ └─────────────────┘

10. Compliance Checklist

10.1 FDA Part 11 Compliance Checklist

RequirementControlEvidenceStatus
ValidationIQ/OQ/PQ protocolsValidation report
Audit trailImmutable loggingLog samples
Access controlRBAC implementationAccess matrix
Authority checksPermission verificationTest results
Electronic signaturesPart 11 complianceSignature policy
Record protectionEncryption, backupSecurity documentation
System documentationSOPs, maintenanceDocument repository

10.2 HIPAA Compliance Checklist

RequirementControlEvidenceStatus
Risk analysisSecurity risk assessmentAssessment report
Access managementWorkforce access controlsAccess procedures
Audit controlsActivity loggingAudit logs
Integrity controlsData validationIntegrity procedures
Transmission securityEncryptionEncryption documentation
BAA executionVendor agreementsExecuted BAAs
TrainingWorkforce trainingTraining records

10.3 SaMD Compliance Checklist

RequirementControlEvidenceStatus
Risk classificationSaMD category determinationClassification document
Quality system21 CFR Part 820 complianceQMS documentation
Design controlsDesign history fileDHF
Clinical validationPerformance studiesClinical validation report
LabelingIFU, warningsLabeling documents
Post-market surveillanceRWP monitoring planPMS plan
PCCP (if applicable)SPS and ACPPCCP documentation

RegulationReference
FDA 21 CFR Part 11https://www.ecfr.gov/current/title-21/chapter-I/subchapter-A/part-11
FDA AI/ML SaMD Frameworkhttps://www.fda.gov/medical-devices/software-medical-device-samd
FDA CDS Guidancehttps://www.fda.gov/regulatory-information/search-fda-guidance-documents
HIPAA Security Rulehttps://www.hhs.gov/hipaa/for-professionals/security
EU MDRhttps://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32017R0745

Appendix B: Glossary

TermDefinition
SaMDSoftware as a Medical Device
CDSClinical Decision Support
PCCPPredetermined Change Control Plan
SPSSaMD Pre-Specifications
ACPAlgorithm Change Protocol
TPLCTotal Product Lifecycle
RWPReal-World Performance
PHIProtected Health Information
BAABusiness Associate Agreement
MDRMedical Device Reporting (or EU Medical Device Regulation)

Document Version: 1.0
Owner: AI Governance / Regulatory Affairs
Next Review: [Date + 1 year]
Approval Required: Regulatory Affairs, Quality, AI Risk Officer


CODITECT AI Risk Management Framework

Document ID: AI-RMF-22 | Version: 2.0.0 | Status: Active


AZ1.AI Inc. | CODITECT Platform

Framework Alignment: NIST AI RMF 2.0 | EU AI Act | ISO/IEC 42001


This document is part of the CODITECT AI Risk Management Framework. For questions or updates, contact the AI Governance Office.

Repository: coditect-ai-risk-management-framework Last Updated: 2026-01-15 Owner: AZ1.AI Inc. | Lead: Hal Casteel