At the 2025 CHIME Fall Forum, Sarang Deshpande, Vice President and Chief Data and Analytics Officer at Franciscan Health, put a familiar frustration into ten words: “Everything and everyone is ready for AI except your own data.”
Any data leader at a multi-site health system knows what sits behind that line. An AI pilot performs well at the flagship hospital, where the dataset was cleaned. Then it reaches an acquired ambulatory group. The same lab is represented differently, encounter statuses do not align, and part of the clinical history is in scanned notes. While the API responds successfully, the model ends up with a different patient story.
FHIR can standardize how information is exchanged. It cannot establish whether the data is current, reconciled, complete, or fit for a specific AI decision.
In 2024, 71% of US hospitals reported using predictive AI integrated with the EHR, according to an ONC analysis. Adoption reached 86% among multi-hospital system members, compared with 37% among independent hospitals. A 2026 Stanford-led study of 3,560 US hospitals likewise found implementation uneven and dependent on local conditions.
Health systems are scaling AI faster than they are standardizing the meaning, origin, and fitness of the data feeding it. An AI-native EHR needs FHIR interoperability and governed data that is consistent, traceable, and fit for AI. The work begins with defining which data the AI can trust, under what conditions, and who is accountable when those conditions are not met.
What Does FHIR Standardize, and What Remains Local?
FHIR gives systems a common way to represent and exchange information through resources such as Patient, Observation, Condition, MedicationRequest, and Encounter. FHIR R4 provides the base specification. US Core narrows it for US use, while SMART on FHIR defines common authorization patterns.
Systems can therefore request and return information in a recognizable structure. FHIR does not establish whether a blood-pressure value is current enough, a local diagnosis code was mapped correctly, two records belong to the same person, or an absent field means “not present” rather than “not captured.”
A successful FHIR response is a transport event. It does not provide evidence that the dataset is suitable for a clinical or operational decision.
| FHIR can tell you | FHIR cannot tell you |
| How information is structured | Whether it is current enough |
| How do systems exchange it | Which source should be trusted |
| How an application requests access | Whether the data is fit for this AI decision |
| Whether the payload conforms | What the AI should do when information conflicts |
The distinction is semantic. A 2024 review of 70 FHIR studies found that terminology mapping, legacy-data transformation, annotation, and ontology work remain necessary. Legacy applications still use incompatible terminologies or unstructured data even when FHIR is available.
For AI, those differences become features, missing values, cohort exclusions, and eventually model behavior.
Why Do the Latest US Interoperability Rules Matter?
The CMS Interoperability and Prior Authorization Rule, CMS-0057-F, requires affected payers to maintain FHIR APIs for patient, provider, payer-to-payer, and prior-authorization use cases, with API requirements generally taking effect in 2027. Patient access APIs will expose more information through standardized channels.
In August 2026, HHS finalized updated versions of several FHIR implementation guides. The same rule states that the broader CMS-0062-P proposals, including payer endpoint reporting, broader API usage reporting, and drug prior authorization, remain under review. The new versions become payer requirements only if CMS completes that rulemaking.
This is why API standardization and API governance cannot be one-time compliance exercises. Versions and mappings change. ONC made the underlying problem unusually clear when it launched Cartos in September 2026, acknowledging that terminology assets can be duplicated or inconsistent across sources. Regulation can improve exchange; it cannot certify that a dataset is appropriate for a particular model.
What Should an Inference Contract Contain?
Before a model leaves the pilot, establish an inference contract: a versioned agreement between the AI use case and the clinical data pipeline. It answers five questions.
- What decision is being supported? Appointment outreach has a different tolerance for delay and missingness than a deterioration alert. “Clean data” is meaningless until the consequences and acceptable uncertainty are defined.
- Which source wins when systems disagree? Mixed EHR environments contain competing timestamps, medication lists, identities, and encounter states. Identify the authoritative source for every critical element and the fallback when it is unavailable.
- What does acceptable data look like? Define thresholds for completeness, terminology conformance, freshness, plausibility, and patient-match confidence. FHIR validity belongs in this list. Clinical data governance must also account for meaning in the originating workflow.
- Can the input be reconstructed? Trace every important feature to its source, extraction time, mapping version, and transformation logic. Without provenance, model drift can be mistaken for an interface change or a delayed feed.
- What happens when the contract fails? Suppress the recommendation, request human review, retrieve more data, or route the case elsewhere. Silent degradation is indefensible.
The contract makes data pipeline maturity measurable and gives procurement teams a stronger comparison than a demo on the vendor’s preferred dataset.
Who Owns the Trust Decision?
The CDAO should own the enterprise method, not every definition. Clinical leaders approve the meaning and consequence. Application owners explain how fields are generated. Integration teams own mappings. Security teams own permitted use. Model owners remain accountable after deployment.
KPMG’s 2026 Healthcare Board Agenda places AI-agent governance, clinical safety, data stewardship, and privacy within board oversight. That makes this ownership model a risk-management question, not an integration detail.
Name one steward for each critical data domain. A committee can review the contract, but it cannot substitute for ownership.
This is where clinical data governance and API governance meet. The former establishes meaning, quality, and accountability. The latter manages versions, interfaces, access policies, observability, and partner change. An AI-native EHR architecture needs both.
How Do Cloud Readiness and Identity Modernization Fit?
Cloud readiness can provide elastic processing, managed FHIR services, and a common data layer across sites. Moving inconsistent data into a cloud-native platform merely centralizes it. Assess cloud readiness alongside terminology services, lineage, quality monitoring, data contracts, and rollback procedures.
The same applies to identity and access management modernization. SMART on FHIR helps applications request scoped access, while the voluntary CMS Interoperability Framework goes further in its current direction of travel: purpose-of-use information, stronger identity assurance, consent controls, audit records, and query-success metrics.
For AI, identity and access management modernization must cover people, applications, service accounts, and derived datasets. Can the application use this data for this purpose, retain it for this period, and create this output?
Read More: FHIR – The Winning Edge for Successful Patient Engagement
What Should Leaders Test Before Funding the Next AI Pilot?
Ask the team or implementation partner to demonstrate six things with representative records from at least three sites:
- The same clinical concept is interpreted consistently across source systems.
- Missing, late, and conflicting inputs trigger visible, documented behavior.
- A model output can be traced back to the source data and mapping versions.
- FHIR R4 and SMART on FHIR conformance have been tested with production-like workflows, not only ideal payloads.
- Data-quality thresholds and access policies are monitored after go-live.
- A change to an EHR configuration or interface can be detected before it quietly changes model inputs.
CAQH’s 2025 research found that technology and system integration remain leading barriers to FHIR adoption plans, while providers report resource and expertise constraints. Platform selection alone rarely resolves the delivery problem.
Where Does Trigent’s Role Fit?
An AI-native EHR architecture does not necessarily require replacing every clinical application. It requires disciplined engineering between them: FHIR and legacy integration, terminology normalization, identity resolution, governed pipelines, cloud readiness, security, testing, and monitoring.
Trigent’s healthcare practice supports connectors and APIs across more than 30 EHR, CDSS, HIMS, and LIMS environments, including Epic, Cerner, Veradigm, and Athena, with support for FHIR, HL7v2, DICOM, USCDI, and X12. It also integrates structured and unstructured data, modernizes cloud platforms, secures access, and tests the complete workflow.
For a US healthcare network operating across more than 80 locations, Trigent unified fragmented data from over 250 clinics and automated its flow into NetSuite. The organization gained visibility into approximately $300,000 in quarterly leakage and replaced a 15-day manual close with an automated, real-time process.
The use case was financial, but the lesson applies directly to AI: trustworthy decisions require reconciled sources, shared definitions, traceable rules, and monitored data flows. A health system can begin with one AI-assisted decision, define its inference contract, and test it against the variation already present across the enterprise.
Planning AI across multiple EHRs?
