ISO/IEC 42005 Impact Assessment Template for Healthcare AI

What ISO/IEC 42005 provides and where it sits

ISO/IEC 42005:2025 is titled AI system impact assessment. ISO describes it as a framework for identifying, evaluating and documenting the impacts of AI systems, and as a detailed methodology for assessing individual systems. It is guidance. It does not give you a form, and it does not map itself to healthcare.

ISO also states that ISO/IEC 42001 and ISO/IEC 42005 are designed to work together. In ISO's framing, 42001 makes impact assessments a consistent and required part of AI governance, while 42005 makes them thorough, systematic and actionable. For a compliance leader, that division is useful. The management system decides when an assessment is required and who is accountable. The impact assessment standard shapes the content of each assessment.

HIPAA sits alongside both. ISO/IEC 42005 is a standard, and the Security Rule at 45 CFR 164.312 (technical safeguards) is regulation. The template should keep the two apart: standards-based fields describe impact, and HIPAA fields show how technical safeguards apply to the system. The structure below is a working template for that purpose. It is not a reproduction of the standard's clause layout, so align the headings to your copy of the standard when you finalize it.

Template sections and the data each one needs

Use one record per AI system and per material change in its use. Six sections cover the elements most healthcare teams need to populate.

• 1. System and intended use: System name, owner, clinical, administrative or patient-facing workflow, user roles, models and tools involved, and a plain statement of intended use and out-of-scope use.
• 2. Foreseeable misuse: Realistic ways the system could be used outside its purpose, such as staff pasting identifiable records into an unapproved tool or treating a summary as a diagnosis.
• 3. Data and PHI handling: PHI categories entering prompts, retrieved context and outputs, where data is stored, retention settings, and which HIPAA technical safeguards the system touches.
• 4. Affected stakeholders and impacts: Patients, clinicians, administrative staff and other affected parties, with the potential benefits and harms for each, likelihood and severity ratings, and the rating method used.
• 5. Human oversight: Review and escalation points, the named approver role for each, what the reviewer sees, and what happens when no reviewer responds.
• 6. Findings, controls and review: Each finding, its runtime control, the evidence that control produces, the residual risk accepted, the accountable owner and the review triggers.

Healthcare-specific impact categories

Four categories deserve explicit fields because generic templates tend to bury them.

PHI exposure. Record each path by which PHI can reach a model, a retrieval index or an external tool, and each path by which it can leave in an output. This section should feed directly into your HIPAA security risk analysis, so reference the analysis entry rather than restating it.

Clinical decision support boundaries. State what the system may suggest and what it may never do, for example drafting a note versus recommending a treatment. A 2023 ONC proposal on predictive decision support described source-attribute information in four categories: intended use, development, evaluation of validity, fairness and effectiveness, and ongoing monitoring and use. It was a proposal and should not be treated as a current requirement, but it is a sensible cross-check for these fields.

Bias across patient populations. ONC tied risk to the extent, quality, source and representativeness of training data. Include a field for which populations the system is expected to serve, what is known about how it performs for them, and who reviews that evidence.

Human oversight. Oversight is a design decision, not a statement of intent. Record where a person must approve an action, and make sure each of those points can be enforced in the system rather than relying on staff memory.

Turning findings into runtime policy

A finding is only useful operationally if something acts on it. Each finding in the template should name one of four outcomes at the level of an individual interaction or tool call.

• Allow: Low-impact use within intended scope, such as summarizing non-clinical administrative text with no PHI. The policy still produces a record of the decision.
• Redact: PHI identified in a prompt or output that the use case does not need. The policy removes it before the model or the user sees it.
• Block: Use outside the documented intended use, or a tool call to a destination the assessment did not approve for PHI.
• Escalate for human approval: Actions the assessment places behind human oversight, such as a tool call that writes to a patient record or output that would cross a clinical decision support boundary.

Evidence that supports audit review

Write each policy as a traceable pair: the finding it implements and the evidence it generates. An auditor can then move from a risk statement to a rule to a record of what the rule did. That chain is what separates a living assessment from a document completed once and filed.

For HIPAA, the relevant evidence supports audit controls under 164.312(b). Confirm the current regulatory text before you write the mapping into the template, and record who verified it and when. Useful evidence per decision includes the policy and version applied, the interaction or tool call affected, the outcome (allow, redact, block or escalate), the approver identity and time for escalations, and the retention setting that governs the record.

Trussed enforces policy in the execution path across models, agents, tools and MCP servers, at the level of individual interactions and tool calls. Enforcement is at runtime, not reviewed after the fact, and it generates audit-ready evidence mapped to HIPAA. Trussed runs in production with healthcare and pharma organizations and can be self-managed in the customer cloud with configurable retention and data residency. Enforcement covers interactions and tool calls. Questions about model and dataset origin stay in the assessment and need their own evidence.

Keeping the assessment live

The assessment loses value if it is not revisited. Set review triggers in the template itself and name who approves a reassessment. Assign one accountable owner per system and keep a separate record of who reviews changes.

• Reassess when the model, prompt design or retrieval source changes.
• Reassess when a new tool, integration or user group is added to the workflow.
• Reassess after any incident, near miss or repeated escalation pattern.
• Review block and escalation volumes periodically and compare them with the impact ratings.
• Cross-reference the HIPAA security risk analysis entry and update both together.
• Record accepted residual risk with an approver and a date.