Healthcare AI Vendor Governance
How Do Health Systems Govern AI Vendors Like Epic and Cerner?
An EHR vendor can ship AI inside the system you already run. The vendor has duties for what it supplies. Your health system still owns how each model is configured, validated locally, monitored and escalated.
Health systems govern EHR vendor AI by splitting duties. Under ONC certification rules, the vendor must apply risk management to the predictive models it supplies. The health system keeps its own inventory, local validation, configuration sign-off, performance monitoring and escalation path for every model it turns on, and treats each one as a governed AI use, not a software update.
context
Why EHR Vendor AI Needs Its Own Governance Lane
Most AI governance programs start from the tools a health system buys on purpose. EHR vendor AI arrives differently: as a feature inside a platform that is already approved, already integrated and already trusted by clinicians. That makes it easy to switch on without the review a standalone AI product would get. This page covers how health systems close that gap for vendors such as Epic and Cerner.
What the vendor is required to do
The federal certification criterion for decision support interventions, 45 CFR 170.315(b)(11), puts duties on the EHR developer for the predictive models it supplies. It states that "Intervention risk management practices must be applied for each Predictive Decision Support Intervention supplied by the health IT developer as part of its Health IT Module." The text requires the developer to analyze risks across "validity, reliability, robustness, fairness, intelligibility," and "safety, security, and privacy," to apply practices to mitigate those risks, and to put "policies and implemented controls for governance" in place.
Those are obligations on the developer. They are a useful starting point for a buyer because they give you a defined set of questions to put to the vendor and a defined set of documents to ask for.
What the rule does not hand you
The risk management paragraph is scoped to interventions "supplied by the health IT developer as part of its Health IT Module." It does not decide whether a given model is appropriate for your patients, whether it performs on your data, or who in your organization may switch it on. Those decisions stay with the health system, and a vendor certification is not a substitute for making them deliberately.
capabilities
What a Vendor Publishes and What It Leaves to You
Reading Epic's published risk management document
Epic publishes a document titled Predictive DSI - Intervention Risk Management Practices, dated March 26, 2025. It describes Epic's own process and the tools it supplies for customers to use. Epic says it releases "validation tools that allow health systems to evaluate the performance of a Predictive DSI on their own data," and that it provides "monitoring tools for organizations to detect feature drift and identify issues with model configuration and execution."
Read closely, that is a division of labor. The vendor supplies the tools. The health system has to decide who runs the validation, what result is good enough to go live, who watches the monitoring output, and what happens when it shows a problem. A tool that nobody owns does not govern anything.
Third-party research inside vendor software
Epic's document also covers models based on outside research: "When we provide Predictive DSI based on third-party research, we review and consider use case risk, complexity, and any validation already performed by that third-party." For a buyer, the practical question is which of the models in your environment were built by the vendor and which rest on someone else's work, because the evidence behind each is different and your inventory should say so.
Escalation runs in both directions
Epic states that it works "with each organization to establish protocols for assessing and escalating potential clinical risks or concerns to us," and that after investigating it will "publish any significant findings to all organizations using the relevant Predictive DSI." Your side of that arrangement is an internal route: who is allowed to raise a concern, who decides it is serious, and who contacts the vendor.
Oracle Health (formerly Cerner) and other EHR vendors
We read Epic's document for this page. We did not review an equivalent document from Oracle Health (formerly Cerner) or from any other EHR vendor, so we make no claim about what they publish. The same request applies to all of them: ask each vendor for its intervention risk management documentation and its source attribute information for every predictive model you plan to enable, and compare the answers against the same checklist.
requirements
The Controls a Health System Keeps
An inventory that includes vendor-embedded AI
Governance begins with knowing what is running. List every AI or predictive feature active in the EHR and its adjacent modules, with its purpose, the clinical workflow it touches, whether the vendor built it or licensed it, the owner on your side and the date it was approved. A model that is available to turn on but is off should be on the list too, with a note that it has not been approved.
Local validation before go-live
A vendor's validation shows the model worked for the populations and data the vendor tested. Your patients and your documentation habits may differ. Before enabling a model, run the vendor's validation tooling or your own analysis on local data, stratify results by the patient groups that matter to you, and record who reviewed the result and what threshold they accepted.
Configuration sign-off
Many models behave according to how they are configured locally. Epic says it works with organizations "to provide oversight during local model configuration." Treat the configuration as a controlled record: the inputs, thresholds and alert behavior that were approved, by whom, and a rule that any change goes back through review.
Monitoring with a named owner and a trigger
Decide in advance what monitoring output will be reviewed, how often, by whom, and what result triggers a pause or rollback. Drift reports that arrive in a dashboard nobody opens are one way a governed model can quietly become an ungoverned one.
Contract and change notice
Procurement should make the governance expectations contractual where it can: notice of material model changes, access to the risk management and source attribute documentation, and cooperation on incident review. Your counsel decides the exact terms.
ai gap
What This Page Cannot Settle for You
This page describes a governance pattern. It is not legal advice and it does not say which obligations apply to your organization. The ONC criterion binds EHR developers that hold ONC certification, and how it interacts with your contracts, your state law and your accreditation is a question for counsel and compliance. We cite Epic's document as an example of what a vendor publishes, not as an endorsement of any vendor or as a statement about how any model performs.
A governance structure also cannot make an unsuitable model suitable. Its job is to make sure the decision to use a model is made on purpose, by the right people, and is recorded and revisited.
framework
Setting Up Vendor AI Governance in Six Steps
1. Inventory every vendor-supplied model
List each predictive or AI feature in the EHR, who built it, what it influences and whether it is on or off.
2. Request the vendor documentation
Ask each vendor for its intervention risk management practices and source attribute information for every model you intend to enable.
3. Tier each model by clinical risk
Set the review depth by how close the model sits to a patient care decision and what happens if it is wrong.
4. Validate locally and record the decision
Run validation on your own data, stratify the results and document who accepted them and on what threshold.
5. Assign owners for configuration and monitoring
Name a clinical owner and a technical owner, define the monitoring review cadence and write down the pause trigger.
6. Wire in escalation and change control
Create an internal route for concerns, a contact path to the vendor and a rule that vendor model updates go through your review.
differentiation
Where This Page Fits Among Our Other Pages
This page covers governing AI that your EHR vendor supplies. For the committee that makes these decisions, see how health systems build an AI governance committee. For the wider vendor review, see how to assess AI vendor exposure in healthcare and our AI vendor evaluation checklist. For platform dependence, see AI vendor lock-in and EHR platform risk, and for unapproved tools, shadow AI in a health system.
engagement
How Kriv AI Helps
Kriv AI advises healthcare organizations on governed AI use. An engagement typically inventories the AI features already active across your clinical platforms, drafts the tiers, owners, validation steps and monitoring cadence with your clinical, quality and IT teams, and hands over a process your team can run. We do not give legal advice and we do not certify compliance.
Every engagement is scoped and priced after a short discovery call.
Related resources
Continue exploring
Straight answers
Frequently asked questions about How Do Health Systems Govern AI Vendors Like Epic and Cerner?
How do health systems govern AI vendors like Epic and Cerner?
They keep an inventory of vendor-supplied models, validate each on local data, sign off the configuration, monitor with a named owner and a pause trigger, and run an escalation path to the vendor. The vendor handles its own risk management duties.
What must a certified EHR developer do for its AI under ONC rules?
45 CFR 170.315(b)(11) requires intervention risk management practices for each predictive decision support intervention the developer supplies, covering risk analysis, mitigation and governance.
Does vendor certification replace local validation?
No. The criterion applies to the developer and does not decide whether a model works for your patients. Local validation and sign-off remain the health system's decision.
What should we ask an EHR vendor for before turning on a predictive model?
Its intervention risk management documentation, the source attribute information for that model, validation tooling for local data, monitoring tooling, and its process for notifying customers of significant findings.
Does this page say what Oracle Health (formerly Cerner) publishes?
No. We reviewed Epic's published document only. Ask Cerner and any other vendor for equivalent documentation.
Talk to the team that would do the work
Bring your requirements to a working session with the person who'll actually deliver.
Book a Discovery Call