Conducting an ISO/IEC 42005 Impact Assessment for Clinical and Health Plan AI

What the assessment is and where it sits

ISO/IEC 42005:2025 is a voluntary standard, not a law. ISO describes it as a practical framework for identifying, evaluating and documenting the impacts of individual AI systems. ISO also states that it is designed to work hand in hand with ISO/IEC 42001, which addresses AI management at the organizational level. The practical consequence is that the assessment record belongs to a single system and should be linked to the management system, if you operate one.

In healthcare, alignment is a choice unless a contract or regulator requires it. The sequence below is a practitioner adaptation for clinical and health plan use cases. It is not a clause-by-clause reading of the standard.

The most common failure is treating the assessment as a one-time document. It then describes an intended system rather than the one running in production, with its actual permissions, data access and tool calls. The steps below are designed to keep the two connected.

Impact categories differ by use case

The harm register in step 4 can follow the elements ONC proposed in 2023 for predictive clinical decision support: likelihood and magnitude of harm, to whom each risk applies, and the source of each risk. That was a proposal framed for certified health IT, not a requirement of ISO/IEC 42005, but it is a usable template. ONC also noted that model risk assessments can help set the type, frequency and extent of evaluation activities.

Clinical decision support is used at the point of care and in other settings, so the assessment should state where output is shown and who acts on it. Patient safety and over-reliance on recommendations usually dominate. Ambient documentation shifts attention toward record accuracy and the privacy of conversations and PHI.

Health plan systems raise different questions. Utilization management and prior authorization affect access to care and timeliness, and a systematic error can fall unevenly across member groups. Claims workflows add fairness and accuracy concerns. Assess equity explicitly for these, rather than assuming a general accuracy figure covers every group.

Setting reassessment triggers, cadence and ownership

The following are practitioner recommendations rather than published requirements. Reassess when the underlying model changes, when a new tool, data source or integration is added, when the intended use or user population changes, and after a significant incident or a pattern of escalations. Add a scheduled review as a backstop, with a cadence set by the system's risk level and the reasoning documented.

Assign a system owner who is accountable for keeping the assessment current, and a governance function that approves changes and accepts residual risk. Record each reassessment as a new version that states what triggered it, what changed in the harm register and which mitigations were added or retired. Reviewing the previous version against production behavior is more useful than rewriting the document from scratch.

What runtime evidence can and cannot support

Runtime enforcement records describe individual interactions and tool calls. They are strong evidence for some assessment elements and irrelevant to others. Mapping them to HIPAA and NIST requires the full regulatory text, including the technical safeguards at 45 CFR 164.312.

• PHI handling: Supported by runtime records of allow, redact and block decisions on interactions.
• Tool-call permissions: Supported by records of which calls were allowed, blocked or escalated.
• Human oversight: Supported by records of escalations for human approval and their outcomes.
• Model lineage and dataset provenance: Not covered by runtime enforcement. Needs model and dataset documentation.
• Pre-deployment testing: Not covered by runtime enforcement. Needs clinical validation, bias and safety testing before release.
• End-to-end agentic workflow tracing: Not covered by runtime enforcement, which operates on individual interactions and tool calls. Needs separate tracing.

Where runtime policy enforcement fits

Once mitigations are defined, some of them are policy decisions: which data may reach a model, which tools an agent may call, and which actions need a person to approve. Trussed enforces policy in the execution path across models, agents, tools and MCP servers, with the actions allow, redact, block, rate limit and escalate for human approval. Enforcement happens at runtime, not through review after the fact, and the decisions generate audit-ready evidence mapped to HIPAA and NIST, including the audit controls requirement at 164.312(b).

This gives the assessment a production counterpart. The documented mitigation, for example that PHI is redacted before reaching an external model, can be shown through records of what the policy permitted and did. The evidence can also feed reassessment, because patterns of blocks and escalations show where the system is being pushed outside its assessed scope. Trussed runs in production with healthcare and pharma organizations, has operated continuously in a regulated enterprise for more than 18 months, and generates over 30 GB of audit evidence per day. It deploys self-managed in the customer cloud, with configurable retention and data residency.

It does not replace the rest of the assessment. Trussed is not a pre-deployment testing product, and it does not cover model lineage, dataset provenance or end-to-end tracing of agentic workflows. Those need their own processes and records.