Framework
From evidence to care.
The AIGX Responsible AI Healthcare Framework sets out how clinical safety, accountable deployment, evidence-based assurance and lifecycle oversight are assessed across healthcare AI. This page summarizes the framework. Weights, thresholds, scoring logic and calibration are controlled and not published.
Why nowHealthcare AI has become clinical decision infrastructure.
AI now influences diagnosis, triage, documentation, patient communication, claims, resource allocation and regulated medical-device functions. The same systems that improve diagnostic precision and operational efficiency also introduce exposure across patient safety, algorithmic bias, generated-content error, privacy, cybersecurity and regulatory compliance.
The governance question is not whether a system performs well in a test. It is whether the organization can defend its intended use, its evidence, its controls and its ongoing authority to operate.
Clinical expansion
AI enters care pathways
Diagnostic support, ambient documentation, patient assistants, predictive EHR models and automated triage increasingly affect clinical work.
Control gap
Evidence remains distributed
Clinical validation, data lineage, privacy review, security testing, human-factors evidence and approvals often sit across separate teams and records.
Institutional need
Decisions must be defensible
Organizations need a record of what was approved, which population and workflow were assessed, who accepted the risk, and which conditions remain open.
A practical question for leaders
Can your organization explain not only why a healthcare AI system was approved, but why it remains approved today?
ScopeAssessment follows the whole system, not only the model.
A rating is valid only for the assessed system version, intended use, deployment scope, evidence set and validity period. Five scope dimensions are fixed before assessment begins.
| Dimension | What it covers | What is expected |
|---|---|---|
| Deployment context | Hospitals, clinics, laboratories, payers, public-health agencies, digital-health vendors, device manufacturers and cloud health platforms. | Intended users, care setting, patient population, geography, interfaces, dependencies and the accountable owner. |
| Lifecycle boundary | Data acquisition through development, validation, procurement, integration, release, monitoring, change control, incident response and retirement. | Version-specific evidence across the lifecycle, including supplier and third-party model dependencies. |
| Decision impact | Diagnostic, therapeutic, triage, documentation, administrative, eligibility, prioritization and patient-communication decisions. | Classification of potential harm, reversibility, human reliance, affected populations and escalation requirements. |
| System boundary | Models, data pipelines, prompts, retrieval sources, APIs, interfaces, monitoring services and surrounding workflows. | What is included, what is excluded, and how external components are controlled. |
| Restricted use | Research prototypes, unsupported populations, unvalidated versions and prohibited autonomous clinical actions. | Restrictions labelled clearly, with production deployment prevented until evidence and approval requirements are met. |
Deployment classesThree classes carry different assurance priorities.
Class I
Diagnostic and SaMD
Computer vision, pathology, radiology, diagnostic support, automated triage, digital biomarkers and regulated software as a medical device. Assurance centres on clinical validity, benefit-risk, fail-safe behaviour, human factors and post-market performance.
Class II
Clinical generative AI and EHR
Clinical documentation, ambient scribes, patient assistants, retrieval-augmented generation, decision support and predictive EHR models. Assurance centres on grounding, control of generated error, explainability, privacy, workflow integration and clinician oversight.
Class III
Operational and claims
Prior authorization, revenue-cycle management, trial matching, resource allocation, fraud detection, scheduling and claims analytics. Assurance centres on fairness, due process, transparency, data quality, access impacts and accountable escalation.
PrinciplesTen principles anchor patient protection and accountable innovation.
These establish institutional intent. Conformance is determined by the control criteria, evidence requirements and approval processes beneath them, not by the principles alone.
| Principle | What it means in practice |
|---|---|
| Patient safety first | Clinical benefit and patient safety take priority over speed, convenience, automation or commercial advantage. |
| Human accountability | Responsibility remains with identifiable individuals and governing bodies. It is not transferred to an algorithm. |
| Clinical validity and evidence | Claims are supported by relevant, representative, reproducible and reviewable evidence. |
| Transparency and explainability | Users and affected persons receive information appropriate to their role, including limitations and uncertainty. |
| Fairness, equity and accessibility | Disparate performance and unequal impact are measured, mitigated and carried into deployment decisions. |
| Privacy and data stewardship | Health data is used lawfully, proportionately, securely and only for approved purposes. |
| Security, robustness and resilience | Systems withstand misuse, cyberattack, data shift, degraded conditions and operational disruption. |
| Human oversight and contestability | Qualified people can question, override, stop, escalate and contest AI-supported decisions. |
| Lifecycle governance | Monitoring continues through deployment, change, surveillance, incident management and retirement. |
| Independent assurance | Material claims and rating decisions are challenged, independently reviewed and improved over time. |
Governance pillarsSix pillars combine clinical, ethical, data, human and technical control.
Each pillar carries its own control criteria and evidence requirements. The relative weighting between them is part of the controlled methodology and is not published.
Pillar 01
Clinical safety and efficacy
Clinical validity, sensitivity and specificity, adverse-event prevention, usability, fail-safe mechanisms and benefit-risk evidence.
Pillar 02
Transparency and explainability
Interpretability, clinician-facing rationale, model cards, intended-use communication, limitations and patient disclosure.
Pillar 03
Fairness, equity and non-bias
Dataset representation, subgroup performance, accessibility, disparity mitigation and documented fairness decisions.
Pillar 04
Data governance and privacy
Protection of health data, lawful basis, consent, retention, provenance, de-identification and third-party data controls.
Pillar 05
Human oversight and accountability
Override, accountability, alert-fatigue controls, escalation, training and clinician autonomy.
Pillar 06
Robustness, resilience and protection
Adversarial resistance, out-of-distribution performance, cybersecurity, resilience, monitoring and recovery.
Evidence standardNo control is credited on policy language alone.
Every sub-metric resolves against a named verification artifact. Evidence must demonstrate implementation, sampling, testing, exceptions and reviewer rationale — not the existence of a document describing an intention. Artifacts must be attributable, dated, version-controlled, approved by the relevant owner and retained under applicable record-retention requirements.
| Evidence domain | Representative artifacts | Accountable owner |
|---|---|---|
| Governance | AI policy, committee charter, RACI, risk appetite, exception register, management review. | Executive sponsor or governance lead |
| Clinical assurance | Intended use, clinical evaluation, comparator analysis, human factors, safety case. | Chief medical officer or clinical safety lead |
| Data governance | Datasheets, lineage, quality metrics, labelling rules, provenance, retention evidence. | Data owner or privacy lead |
| Model assurance | Model card, evaluation protocol, reproducibility, calibration, subgroup tests, robustness. | Model owner or ML lead |
| Privacy and security | Impact assessment, access controls, encryption, penetration test, SBOM, incident records. | Privacy and security leads |
| Human oversight | Training, role matrix, override test, usability study, escalation procedures. | Clinical operations |
| Lifecycle monitoring | Performance dashboard, drift rules, incident log, corrective action, change records, surveillance. | Operations or quality |
| Third-party AI | Supplier due diligence, contracts, service levels, model-change notices, exit plan. | Procurement or vendor owner |
Assessment lifecycleNine stages produce a repeatable and reviewable outcome.
Stage 01
Application and scope
Define system, intended use, sites, population, interfaces, suppliers and applicable requirements.
Stage 02
Readiness review
Identify missing evidence, critical blockers and dependencies before assessment proceeds.
Stage 03
Document and technical review
Review governance, clinical, data, model, privacy, security and lifecycle artifacts.
Stage 04
Interviews and demonstration
Validate practice with leaders, clinicians, engineers, privacy, security and operations.
Stage 05
Independent scoring
Score sub-metrics, apply gates and document risks and confidence.
Stage 06
Quality review
A second reviewer challenges evidence sufficiency, consistency and conflicts.
Stage 07
Remediation and closure
Corrective evidence is submitted for eligible findings.
Stage 08
Rating decision
An authorized committee approves, modifies, defers or rejects the outcome.
Stage 09
Surveillance
Incidents, drift, changes and annual effectiveness are tracked and the rating updated.
Independence requirement
Individuals who designed or implemented a control do not serve as its sole evaluator. Material conflicts are disclosed, mitigated and recorded before issuance.
Outcomes and gatesA strong assessment cannot override a critical safety condition.
Outcomes are expressed on a tiered scale running from exceptional governance through to unsafe, with each tier carrying an explicit deployment permission rather than a score alone. The numeric bands behind each tier are part of the controlled methodology.
Independently of that scale, a critical gate applies. Where there is credible risk of severe patient harm, unlawful deployment, major privacy breach or uncontrolled system compromise, the gate holds the deployment decision regardless of performance elsewhere.
| Finding severity | Condition |
|---|---|
| Critical | Credible risk of severe patient harm, unlawful deployment, major privacy breach or uncontrolled compromise. |
| High | Material control failure with significant safety, privacy, fairness or security exposure. |
| Moderate | Control partially effective or evidence incomplete, without immediate severe harm. |
| Low | Minor documentation, process or optimization gap, tracked for improvement. |
Change controlAuthority to operate changes when the assumptions behind it change.
Material incidents, major updates, new clinical uses, supplier changes or withdrawal of evidence may require suspension, re-scoring or re-certification. Eight triggers are defined: a major model or software update; a new population, site or clinical use; a data source or distribution change; a supplier release or ownership change; a material incident or adverse event; a privacy, security or regulatory change; the withdrawal or expiry of evidence; and a breach of a performance, fairness or drift threshold.
Findings require containment, root-cause analysis, corrective and preventive action, accountable ownership, due dates, a validation method and closure approval.
Standards alignmentHealthcare AI sits across legal, clinical, privacy, cybersecurity and device regimes.
| Instrument | Issuing body | How the framework uses it |
|---|---|---|
| EU AI Act | European Union | High-risk obligations: risk management, data governance, technical documentation and logging, transparency, human oversight, accuracy, robustness and cybersecurity. |
| NIST AI Risk Management Framework | NIST | Govern, Map, Measure and Manage functions, including the Generative AI Profile. |
| ISO/IEC 42001 | ISO/IEC | Enterprise accountability, competence, audit, corrective action and continual improvement. |
| ISO 14971 and ISO 13485 | ISO | Medical-device risk management, design controls, validation, supplier control and surveillance. |
| ISO/IEC 27001 and 27701 | ISO/IEC | Information security and privacy management, access, incident response and supplier controls. |
| Good Machine Learning Practice | FDA, Health Canada, MHRA and partners | Representative data, sound engineering, clinical relevance, human-AI interaction and monitoring. |
| WHO guidance on AI for health | World Health Organization | Autonomy, well-being, transparency, accountability, inclusiveness, equity, sustainability and responsiveness. |
| Health privacy requirements | Applicable authorities | Access control, encryption, audit trails, lawful processing, supplier agreements, incident response and retention. |
Conformity assessment boundary
An AIGX rating is a proprietary assurance opinion and evidence-readiness indicator. It does not replace CE marking, notified-body review, FDA authorization, Health Canada licensing or any other statutory approval. Final legal classification depends on intended purpose, deployment context and applicable product law.
Full frameworkThis page summarizes the institutional edition.
The complete framework sets out the full control criteria, audit rubric, verification artifacts, evidence templates and worked assessment examples. Proprietary formulas, weights, thresholds and calibration logic are not disclosed in any edition.
AIGX-RAIH v2.1 · Responsible AI Healthcare Framework · July 2026
Legal notice
This framework is an institutional governance and assurance framework developed by AIGX Research. It is not legal, medical, regulatory or certification advice, and does not replace statutory approval, professional judgment, clinical validation, privacy review, cybersecurity testing or jurisdiction-specific requirements. Assessment outcomes apply only to the defined system, version, intended use, evidence and validity period. Third-party names, standards and legal instruments remain the property of their respective owners; references are provided for attribution and do not imply affiliation, endorsement or sponsorship.