# Healthcare AI Governance — free starter kit

AutoGovern · reviewed 2026-09-07

Use governance metadata only. Keep patient records in your authorized systems. These templates are planning aids, not certification or clinical approval.

## Healthcare AI use-case card

- Workflow and intended use: [complete]
- Care setting, users and affected population: [complete]
- Out-of-scope uses: [complete]
- Clinical/operational owner: [complete]
- Privacy, security and clinical reviewers: [complete]
- Model, prompt, provider and tool versions: [complete]
- PHI/PII categories and approved data-flow references: [complete]
- Vendor/service and BAA review reference: [complete]
- Evaluation measures, acceptance limits and evidence: [complete]
- Human review and escalation path: [complete]
- Fallback owner and tested stop procedure: [complete]
- Pilot restrictions, decision rationale and next review: [complete]

## Vendor and data-flow review

- Exact vendor service / endpoint / fallback: [complete]
- Source, recipient and purpose: [complete]
- Data categories and permitted-use rationale: [complete]
- BAA applicability and executed agreement reference: [complete]
- Training, retention, support access and deletion terms: [complete]
- Subprocessors and approved regions: [complete]
- Security test evidence and open questions: [complete]
- Incident reporting terms and responsible owner: [complete]
- Approval conditions and next review date: [complete]

## Monitoring and incident plan

- Workflow and approved version: [complete]
- Signal, source and collection frequency: [complete]
- Coverage denominator and last successful collection: [complete]
- Metric, uncertainty and escalation threshold: [complete]
- Accountable reviewer and response target: [complete]
- Clinical safety fallback and containment steps: [complete]
- Authorized incident-system reference: [complete]
- Discovery time and privacy/legal escalation: [complete]
- Required notices and deadlines determined by reviewer: [complete]
- Corrective action, retest evidence and restart decision: [complete]

## How to use the templates

### 1. Define and register a healthcare AI use case

Owner: Clinical or operational owner + governance lead

1. Write the intended use, users, care setting, affected population and uses that are out of scope. Separate administrative assistance from clinical recommendations.
2. Record the model/provider, version, connected tools, input data, output destination and level of autonomy. Identify who can approve a release and who can stop its use.
3. Assign privacy, security and clinical reviewers. Record each required decision, evidence owner and review date; name a clinical reviewer whenever care could be affected.
4. Check applicable legal relationships and product functions. HIPAA depends on entity and data context; FDA device status depends on the software function and intended use. Escalate uncertain scope before patient-facing deployment.

Output: A use-case card with named owners, intended-use limits and a review path.

### 2. Map PHI, PII and permitted data use

Owner: Privacy officer + data owner

1. Draw each source → recipient → storage path, including subprocessors and model fallback routes. List data categories rather than copying patient records into a governance worksheet.
2. Classify the information and document the purpose and authority for each use or disclosure. Apply minimum necessary where required; provider treatment disclosures and requests are among its exceptions.
3. Choose permitted recipients, role access, retention schedules and deletion evidence. Check whether consent or a specific authorization is required for the use; do not assume every HIPAA-permitted treatment use needs a new consent.
4. If using de-identified data, document Safe Harbor or Expert Determination. Removing names or masking regex matches alone does not establish de-identification.

Output: A reviewed data-flow register and a list of unresolved permissions or retention decisions.

### 3. Review an AI vendor and its BAA

Owner: Procurement + privacy and security reviewers

1. List every service that creates, receives, maintains or transmits ePHI on your behalf. Review business-associate status and relevant subcontractor arrangements; encryption without a provider-held key does not automatically remove cloud-provider obligations.
2. Where required, confirm an executed business associate agreement covers the service. Record an agreement reference, permitted uses, incident reporting terms and return/deletion provisions.
3. Ask about data retention, training on customer content, subprocessors, support access, regions, encryption, incident response and evidence of control testing. Record unresolved answers with an owner and deadline.
4. Approve specific endpoints and fallback services through your integration controls. Recheck material contract, model, hosting and subprocessor changes before extending the approved use.

Output: A service-specific vendor decision with agreement evidence, conditions and a review date.

### 4. Test clinical quality, bias and security

Owner: Clinical reviewer + evaluation and security teams

1. Create an approved evaluation set representative of intended use. Record provenance, permissions, model/prompt version, setting and sample limitations; use synthetic examples for early workflow tests.
2. Choose task-specific measures: unsupported statements and omissions for a scribe; escalation failures for a chatbot; sensitivity, specificity and calibration for a predictive model. Clinicians set acceptance limits based on the harm of errors.
3. Examine results across relevant populations and settings with adequate sample sizes and uncertainty. Small or missing subgroup samples are unknown coverage, not a fairness pass.
4. Test access boundaries, prompt injection, data leakage, incorrect tool use, clinician overrides and service outages. Record the failed cases, corrective work and retest evidence before release.

Output: A versioned evaluation report with metrics, denominators, limits and accountable sign-off.

### 5. Approve a limited pilot with human oversight

Owner: Accountable clinical/operational lead + release reviewer

1. Review unresolved risks, vendor/data-use permissions, evaluation limits and the intended-use boundary. Document the rationale for proceeding, restricting or holding the pilot.
2. Choose a limited population, trained users, supervised actions and a review window. Explain to users what the AI can do, where it can fail and when they must escalate.
3. Define who reviews outputs before clinical or patient-facing use, who can override them, and how users report a problem. Record the approved model, prompt and tool versions.
4. Exercise the fallback and stop procedure. For care delivery, design a safe alternative workflow so stopping an AI service does not remove essential patient care.

Output: A dated pilot decision with restrictions, reviewer, fallback owner and reassessment triggers.

### 6. Monitor after release and respond to incidents

Owner: Service owner + privacy/security response team

1. Collect approved, minimized telemetry: model changes, output quality, overrides, access anomalies, destination changes and incident reports. Record the last successful collection and the population observed.
2. Set review frequency and escalation thresholds with the responsible team. Track trends with denominators; distinguish alerts from confirmed incidents and verified outcomes.
3. On suspected harm or disclosure, follow the care-safe containment plan, preserve authorized evidence, record discovery time, and involve clinical, privacy and security owners. Keep patient details in the authorized incident system.
4. Have the privacy/legal team determine reporting duties. HIPAA breach analysis considers the information, recipient, whether it was acquired/viewed, and mitigation. Individual notices are required without unreasonable delay and no later than 60 days after discovery when applicable; other recipients, contracts and laws have their own rules.
5. Record corrective actions, verify closure and rerun the relevant evaluation before restarting or expanding the workflow.

Output: A monitoring plan and an incident runbook with owners, evidence references and escalation deadlines.

## Official sources

- [HHS: Covered entities and business associates](https://www.hhs.gov/hipaa/for-professionals/covered-entities/index.html)
- [HHS: HIPAA and cloud computing](https://www.hhs.gov/hipaa/for-professionals/special-topics/health-information-technology/cloud-computing/index.html)
- [HHS: Minimum necessary requirement](https://www.hhs.gov/hipaa/for-professionals/privacy/guidance/minimum-necessary-requirement/index.html)
- [HHS: De-identification methods](https://www.hhs.gov/hipaa/for-professionals/special-topics/de-identification/index.html)
- [HHS: Breach Notification Rule](https://www.hhs.gov/hipaa/for-professionals/breach-notification/index.html)
- [NIST: AI Risk Management Framework Playbook](https://www.nist.gov/itl/ai-risk-management-framework/nist-ai-rmf-playbook)
- [FDA: Clinical Decision Support Software, January 2026](https://www.fda.gov/regulatory-information/search-fda-guidance-documents/clinical-decision-support-software)
- [ONC: Decision support intervention criteria](https://healthit.gov/test-method/decision-support-interventions/)
- [FTC: Health Breach Notification Rule guidance](https://www.ftc.gov/business-guidance/resources/complying-ftcs-health-breach-notification-rule-0)

Public guide: https://autogovern.io/healthcare-ai-governance