NIST AI Risk Management Framework in Healthcare: How GOVERN, MAP, MEASURE, and MANAGE Bridge FDA Voluntary Governance and Algorithmic Accountability

The Accountability Gap: 84% Have Committees, 12% Have Frameworks

The dominant story in healthcare AI governance right now is not ignorance—it is the gap between intention and operationalization. According to the Censinet/CHIME Foundation AI Adoption Survey 2025 (as cited in secondary sources), 84% of U.S. healthcare organizations have established AI governance committees. Only 12% have implemented a formal AI governance framework. That 72-point spread is where patient safety risk actually lives.

A committee is a roster and a meeting cadence. A framework is a documented system of controls, accountability assignments, risk-tiering criteria, and monitoring obligations that determines whether an AI tool enters clinical workflows vetted or unvetted. The same survey data shows that 59% of healthcare organizations lack a formal documented pre-implementation AI approval process. The committee exists. The algorithm still moves into clinical workflows without structured review.

The NIST AI Risk Management Framework (AI RMF 1.0) is the missing layer between those two numbers. Its four core functions—GOVERN, MAP, MEASURE, and MANAGE—are not a compliance checklist. They are the scaffold that converts a governance committee into a functioning governance system. For healthcare specifically, they are also the only U.S. voluntary framework that simultaneously maps onto mandatory obligations created by FDA SaMD lifecycle expectations, ONC HTI-1 transparency requirements, HHS Section 1557 algorithmic bias duties, and a rapidly hardening layer of state AI law. For broader regulatory context on how these agencies interact, see Artificial Intelligence in Health: The Regulatory Landscape in 2026.

Why 'Voluntary' Is Misleading: NIST AI RMF's De Facto Status in Healthcare

NIST AI RMF 1.0 was released on January 26, 2023 following a consensus-driven, open development process. The framework is formally voluntary at the federal level—no statute requires adoption, and no federal agency has issued a final rule mandating it. But in healthcare, 'voluntary' has become a technical term that obscures operational reality.

HHS OCR treats NIST AI RMF alignment as an expectation for covered entities deploying clinical AI. FDA's January 2025 draft lifecycle guidance for AI-enabled device software functions—while non-binding—reflects organizational accountability expectations that NIST AI RMF's GOVERN function is designed to satisfy. ONC's HTI-1 rule creates mandatory source attribute documentation obligations for predictive decision support interventions that operationalize what NIST calls the MAP function. Section 1557's algorithmic discrimination prohibition, enforced by HHS OCR for Medicare and Medicaid participants, makes NIST's MEASURE function effectively non-optional for any organization using AI in clinical or coverage decisions affecting those populations.

The framework's voluntary federal status is also being progressively overridden by state law. Colorado, Texas, and California have enacted statutes that convert NIST-aligned practices into enforceable legal duties for covered organizations. The result is a framework that is voluntary in name, mandatory in practice, and increasingly hard law in the states where the majority of U.S. healthcare activity occurs.

For the history of FDA's voluntary framework development trajectory, see the FDA AI/ML SaMD Action Plan: Five Commitments, Key Deliverables, and Implementation Status Through Q2 2026. The remainder of this article focuses on how each NIST function maps onto specific accountability obligations—not on the action plan's history.

GOVERN: Establishing Accountable AI Oversight Structures

The GOVERN function is the organizational foundation of the NIST AI RMF. It establishes the policies, roles, and authority structures that make every other function operational. In healthcare, GOVERN is where the gap between having a committee and having a governance system becomes concrete.

A governance committee without documented authority is advisory. The GOVERN function requires that the committee have a formal charter specifying its scope, decision rights, and escalation paths. Most critically, it must have documented authority to gate AI tools into clinical workflows—to say no, to require remediation, and to impose conditions on deployment. The 59% of organizations lacking a formal pre-implementation AI approval process do not have a functioning GOVERN structure, regardless of how often their committee meets.

The FDA's January 2025 draft lifecycle guidance for AI-enabled device software functions—while non-binding—signals what organizational accountability looks like from a regulatory standpoint. It expects manufacturers and deployers to maintain documented accountability for AI performance across the total product lifecycle. For health systems deploying FDA-cleared AI tools, this translates into a GOVERN requirement: the committee must be able to demonstrate who is accountable for each deployed AI system, under what conditions it was approved, and what triggers re-review.

RUAIH Step 1—establishment of AI policy and governance structures—directly operationalizes the GOVERN function. The September 2025 CHAI/Joint Commission guidance specifies that governance structures should define the organization's AI risk tolerance, establish a risk-tiering methodology distinguishing clinical AI from operational and administrative AI, and assign named accountability for each category.

• Draft and adopt a formal AI governance committee charter with documented decision authority, not merely advisory standing.
• Define a risk-tiering framework that distinguishes clinical decision support AI, patient-facing AI, operational AI, and administrative AI—each with different governance intensity.
• Document accountability assignments for every deployed AI system: who approved it, under what criteria, and who is responsible for ongoing performance.
• Establish a formal pre-implementation AI approval process with documented criteria—the absence of this process is the single most common GOVERN failure identified in current adoption data.
• Align committee authority with FDA organizational accountability expectations for AI-enabled devices under the January 2025 draft lifecycle guidance.

MAP: Complete AI Inventory, BAA Chain Documentation, and ONC HTI-1 Compliance

The MAP function establishes visibility. Before an organization can govern, measure, or manage its AI systems, it must know what AI systems it has. In healthcare, this is harder than it sounds—and the gap is not primarily in purpose-built AI tools procured through formal vendor evaluation processes.

The most commonly missed AI systems are embedded features in existing EHR platforms. Epic and Oracle Health both surface AI-powered features—predictive deterioration scores, scheduling optimization, clinical documentation assistance—that organizations frequently overlook in AI inventories because the AI was bundled with a platform already under contract rather than procured as a standalone AI product. A complete MAP-function inventory must include these embedded features. Each must be assessed against the SaMD classification test to determine whether it falls under FDA device regulation. For the mechanics of that classification boundary, see AI in Medicine: How the U.S. Regulatory Framework Actually Works.

BAA chain mapping is the second MAP-function obligation that organizations consistently underexecute. Every AI system that touches protected health information requires a Business Associate Agreement. The common failure mode—flagged explicitly in EFROS practice guidance—is assuming that the existing BAA with an EHR vendor covers all AI features that vendor deploys within its platform. It does not. Each AI model or service that processes PHI requires its own BAA coverage, and the chain must be mapped to confirm no gaps.

The MAP function also operationalizes ONC HTI-1 source attribute documentation obligations. Under 45 CFR 170.315(b)(11), certified EHR developers must provide structured source attributes for clinical decision support interventions: 13 attributes for evidence-based DSIs and 31 for Predictive DSIs. These attributes cover the intervention's funding source, development methodology, validation evidence, risk management practices, and intended use population. The enforcement discretion window for certain HTI-1 criteria closed February 28, 2026—organizations deploying predictive DSIs in certified EHR environments are now in a compliance posture, not a grace period. For the full ONC information blocking and HTI-1 framework, see the ONC Information Blocking Rule: What It Means for AI Systems, Agentic Workflows, and Healthcare Data Access.

MEASURE: Bias Monitoring, Drift Detection, and the Section 1557 Accountability Floor

The MEASURE function is where the voluntary-to-mandatory conversion is most stark. FDA's June 2024 Transparency for Machine Learning-Enabled Medical Devices guiding principles establish voluntary recommendations for interpretability and disclosure. They do not establish enforceable bias monitoring standards. The FDA's September 2025 Request for Public Comment on real-world performance measurement signals that robust postmarket monitoring remains an unresolved regulatory gap at the federal device level.

Section 1557 of the Affordable Care Act fills that gap for a large portion of clinical AI use cases. Any organization participating in Medicare or Medicaid that uses AI in clinical decisions, coverage determinations, or patient scheduling is subject to Section 1557's prohibition on algorithmic discrimination. HHS OCR enforcement makes bias monitoring not a best practice but a legal duty for these organizations. Coverage AI and scheduling AI are both explicitly within Section 1557's exposure vector—a point frequently underappreciated by organizations that focus their bias monitoring attention on clinical diagnostic tools while leaving administrative AI unmonitored.

The MEASURE function operationalizes this obligation. It requires organizations to establish baseline performance metrics for each high-risk AI system, define acceptable performance thresholds across demographic subgroups, and implement monitoring cadences that detect when a model's real-world performance diverges from its validated performance—a phenomenon known as model drift. For the clinical and technical definition of drift and its detection mechanisms, see Model Drift in Deployed Clinical AI: Definition, Types, Causes, Detection, and Monitoring.

• Establish demographic subgroup performance baselines for every AI system used in clinical decisions, coverage determinations, or patient scheduling affecting Medicare or Medicaid populations.
• Define acceptable performance thresholds and document the criteria that trigger re-evaluation or suspension of a deployed AI system.
• Implement drift monitoring cadences—quarterly at minimum for high-risk clinical AI—using the same demographic stratification applied at baseline.
• Do not limit bias monitoring to diagnostic AI. Coverage AI and scheduling AI carry equivalent Section 1557 exposure and require equivalent monitoring rigor.
• Document monitoring results and any remediation actions taken. The documentation is the governance artifact that demonstrates a defensible posture under Section 1557 and state AI law.

MANAGE: Human-in-the-Loop Controls, PCCP Integration, and Incident Response

The MANAGE function is the operational control layer that translates governance structures and measurement outputs into concrete post-deployment accountability. In healthcare, it has three primary components: human-in-the-loop controls for clinical decision support, Predetermined Change Control Plan integration for FDA-cleared adaptive AI devices, and incident response protocols aligned to HIPAA breach workflow.

FDA's January 2025 draft lifecycle guidance for AI-enabled device software functions establishes expectations for human oversight in clinical decision support contexts. For AI that informs clinical decisions without directly executing them, the MANAGE function requires documented protocols specifying when clinician override is expected, how override decisions are recorded, and how override patterns are fed back into performance monitoring. These are not aspirational practices—they are the organizational controls that distinguish a defensible deployment from one that cannot account for how AI outputs affected clinical decisions.

For FDA-cleared AI devices that incorporate adaptive algorithms, the Predetermined Change Control Plan is the MANAGE-function mechanism. A PCCP pre-specifies the types of model updates a manufacturer may make post-market without requiring a new submission, subject to FDA authorization. As of 2025, only approximately 10% of FDA-cleared AI/ML devices have authorized PCCPs—a significant post-market accountability gap. Organizations deploying FDA-cleared adaptive AI tools should confirm whether a PCCP exists for each device and, if so, what change types it authorizes. For the full definition and regulatory context of PCCPs, see the Predetermined Change Control Plan (PCCP): The FDA Mechanism for Iterative AI/ML Medical Device Updates. For current guidance version history and status, see the FDA PCCP Guidance for AI-Enabled Devices: Document Record, Version History, and Current Status.

Incident response is the third MANAGE component. When an AI system produces outputs that may have contributed to a patient safety event, the organization needs a documented response protocol that aligns to HIPAA breach workflow: identification, containment, notification assessment, and corrective action. The MANAGE function requires this protocol to be pre-built and tested—not improvised after an adverse event.

• Document human-in-the-loop control protocols for every clinical decision support AI: when override is expected, how it is recorded, and how override patterns feed back into MEASURE monitoring.
• Confirm PCCP status for every FDA-cleared adaptive AI device in the inventory. If no PCCP exists, document the post-market change management process the vendor uses and assess whether unauthorized modifications may have occurred.
• Develop and test an AI incident response protocol aligned to HIPAA breach workflow before an adverse event occurs.
• Establish a feedback loop from MANAGE incident data back to GOVERN—adverse events and near-misses should trigger governance committee review of the affected AI system's approval conditions.

The CHAI/Joint Commission RUAIH Bridge: From Framework to Certification Pathway

On September 17, 2025, The Joint Commission and the Coalition for Health AI jointly released The Responsible Use of AI in Healthcare (RUAIH)—a non-binding guidance document that synthesizes the NIST AI RMF and other frameworks into seven actionable governance steps. RUAIH is not a separate governance standard; it is NIST AI RMF operationalized for the organizational realities of accredited health systems.

The significance of RUAIH is not its content in isolation—it is its institutional home. The Joint Commission accredits more than 22,000 healthcare organizations nationwide. Its intent to develop a voluntary AI certification program from finalized RUAIH playbooks means that NIST AI RMF alignment will eventually be assessable through the same accreditation infrastructure health systems already operate within. For organizations building NIST-aligned governance now, that certification trajectory represents a direct return on investment.

CHAI's Applied Model Cards—sometimes described as 'AI Nutrition Labels'—are a practical MEASURE and MANAGE artifact that RUAIH recommends. A model card documents an AI system's intended use, training data characteristics, performance metrics across demographic subgroups, known limitations, and update history. Organizations implementing the MEASURE function should treat model cards as living governance documents, not one-time vendor disclosures.

State Law Hardening: When Voluntary Obligations Become Enforceable Duties

The clearest signal that NIST AI RMF alignment has moved beyond voluntary best practice is the language of state AI statutes. Three states have enacted laws that create enforceable duties for AI developers and deployers—and each statute's compliance pathway is materially easier for organizations that have already implemented NIST-aligned controls.

Colorado's Anti-Discrimination in AI Law (SB24-205), effective June 30, 2026, establishes affirmative duties for developers and deployers of high-risk AI systems to use 'reasonable care' to prevent algorithmic discrimination. The statute applies to AI that makes or substantially contributes to consequential decisions in healthcare, housing, employment, and other domains. For health systems deploying AI in clinical or coverage decisions, SB24-205 creates direct liability exposure. Organizations with documented MEASURE-function bias monitoring programs are substantially better positioned to demonstrate 'reasonable care' than those relying on vendor attestations alone.

Texas enacted the Texas Responsible Artificial Intelligence Governance Act (TRAIGA) in June 2025, effective January 1, 2026. TRAIGA explicitly recognizes defenses tied to adversarial testing and alignment with recognized AI risk frameworks. An organization that has documented NIST AI RMF implementation—including GOVERN charter, MAP inventory, MEASURE monitoring, and MANAGE controls—is in a stronger position to invoke TRAIGA's framework-alignment defense than one that has not. Note that source descriptions of TRAIGA's bill number vary across secondary sources; readers should verify the current bill designation and provisions against primary Texas legislative records before relying on specific statutory language.

California AB 316, effective 2026, adds algorithmic accountability requirements for health-related AI in the state. California's regulatory environment typically signals broader national adoption trajectories, and AB 316's healthcare-specific scope makes it directly relevant to health systems operating in or serving California populations.

What Has Hardened and What Remains Soft: An Honest Assessment

Compliance professionals need a clear-eyed map of the voluntary-to-mandatory spectrum, not a generalized claim that everything is converging toward mandatory status. As of Q2 2026, the landscape is stratified.

The honest summary: FDA guidance is still largely non-binding. No federal statute currently mandates NIST AI RMF adoption. But the framework's voluntary federal status coexists with mandatory obligations—ONC HTI-1 for certified EHR developers, Section 1557 for Medicare and Medicaid participants, and state AI statutes for covered organizations in Colorado, Texas, and California—that NIST AI RMF is the most practical governance scaffold to satisfy simultaneously. For multi-state health systems, the combination of Section 1557 exposure and state AI law obligations means that NIST AI RMF implementation is not optional in any operationally meaningful sense.

Implementation Roadmap: A Phased Approach Organized by NIST RMF Function

The following phased timeline is organized by NIST AI RMF function logic rather than regulatory deadline sequence. It reflects the dependency structure of the framework: GOVERN and MAP must be established before MEASURE can be operationalized, and MANAGE controls cannot be effectively implemented without the inventory and baseline data that MAP and MEASURE produce. The timeline is consistent with EFROS practice guidance for healthcare AI governance implementation.

Phase 1 (0–60 Days): GOVERN + MAP

• Draft and adopt a formal AI governance committee charter with documented decision authority, risk-tiering criteria, and pre-implementation approval process.
• Conduct a complete AI inventory across clinical, operational, and administrative domains—explicitly including EHR-embedded AI features from Epic, Oracle Health, and other platform vendors.
• Apply the SaMD classification assessment to each inventoried tool to determine FDA device regulatory status.
• Map BAA chain coverage for all PHI-touching AI, confirming that platform-level BAAs do not create gaps for bundled AI features.
• Document accountability assignments for each deployed AI system: approving authority, approval criteria, and responsible owner.

Phase 2 (60–120 Days): MEASURE + Document

• Establish demographic subgroup performance baselines for all high-risk AI systems, prioritizing those used in clinical decisions, coverage determinations, or scheduling affecting Medicare or Medicaid populations (Section 1557 exposure).
• Define performance thresholds and drift detection triggers for each monitored system, with documented criteria for re-evaluation or suspension.
• Implement ONC HTI-1 source attribute documentation for all Predictive DSIs in certified EHR environments—31 attributes required, enforcement discretion closed.
• Develop or adopt CHAI Applied Model Cards for each high-risk AI system as living governance documents.
• Establish a quarterly drift monitoring cadence for high-risk clinical AI.

Phase 3 (120–180 Days): MANAGE + Audit

• Document human-in-the-loop control protocols for all clinical decision support AI, including override recording and feedback mechanisms.
• Review PCCP status for every FDA-cleared adaptive AI device in the inventory; confirm authorized change types and flag devices without PCCPs for enhanced post-market monitoring.
• Develop and tabletop-test an AI incident response protocol aligned to HIPAA breach workflow.
• Conduct a governance audit against the GOVERN charter, MAP inventory, MEASURE baselines, and MANAGE controls established in Phases 1 and 2—document findings and remediation actions.
• Assess alignment with RUAIH seven steps in preparation for the Joint Commission voluntary AI certification pathway as it develops from finalized playbooks.