FHIR compliance isn't interoperability

Arinder Singh Suri wrote in HIT Consultant on August 5 that many hospital AI efforts have a data problem before they have a model problem, arguing that normalization, FHIR APIs and TEFCA-based exchange all need to work together for scale. TechBullion made a related point the same day, saying software marketed as “FHIR-compliant” can still fail to move patient data cleanly between systems. The gap those articles describe is narrow in procurement language and wide in operations. A hospital can expose a Fast Healthcare Interoperability Resources, or FHIR, endpoint and still leave analysts with mismatched code sets, missing encounter context, uneven timestamps and records that do not line up cleanly with the source electronic health record. That leaves reporting teams and AI developers spending time on translation work rather than model building or workflow deployment. (hitconsultant.net) ### If a hospital already has FHIR APIs, why are teams still stuck? FHIR defines a standard way to structure and exchange healthcare data, but the August 5 commentaries said conformance does not guarantee that data arrives in a form clinicians, operators or analysts can trust. TechBullion said hospitals still struggle to move patient data cleanly even when vendors advertise FHIR support, because the hard part is not only transport but consistency across systems. (hitconsultant.net) A medication list, a diagnosis field and a discharge event can all be technically available through FHIR and still be hard to use downstream. HIT Consultant said healthcare AI strategies break on interoperability when data is not normalized well enough to support reliable use at scale. ### What is missing between standards compliance and usable data? Terminology and workflow context are the missing layer in the two August 5 pieces. (techbullion.com) TechBullion said inconsistent terminology use, missing workflow context and payloads that are not harmonized into stable analytical domains leave downstream reporting brittle even when a FHIR endpoint exists. (hitconsultant.net) That means two hospitals can both send a FHIR Observation or Encounter resource and still mean different things operationally. A quality team may need to know whether a lab result was corrected, whether an order was actually carried out, or whether a diagnosis was provisional, final or copied forward. Those distinctions often sit in source-system behavior and metadata rather than in an API checklist. (techbullion.com) ### What does the practical fix look like inside a data platform? The operating model described in the briefing is sequential. Hospitals should ingest FHIR and other interoperability feeds with provenance intact, normalize them into governed canonical models, reconcile them against source operational systems, and only then promote them into trusted marts for quality, utilization, throughput or AI features. (hitconsultant.net) Provenance matters because teams need to know where a value came from, when it was captured and whether it was transformed on the way in. Reconciliation matters because source systems remain the reference point when records conflict, duplicate or arrive with partial context. Promotion matters because not every ingested field belongs in a production-grade reporting layer. (hitconsultant.net) ### Why does this show up so quickly in AI and value-based care? Health IT Answers wrote that value-based care needs an operational backbone, not just better analytics. That aligns with the interoperability critique: a model or dashboard is only as useful as the workflow that can act on it. In practice, hospitals need data products that support care gaps, outreach, attribution, transitions and documentation review, not only API availability. (hitconsultant.net) When the underlying records are semantically uneven, AI tools inherit the same ambiguity and produce outputs that are harder to validate or operationalize. That is an inference drawn from the sources’ description of normalization and workflow fit as prerequisites for scale. (healthitanswers.net) ### What should hospitals measure instead of just API coverage? Workflow-grade usability is the standard the August 5 pieces point toward. A hospital can ask whether a discharge feed reconciles to the EHR, whether diagnoses map consistently across service lines, whether promoted marts preserve source lineage, and whether downstream teams can reproduce the same patient state from the same inputs. Those are stronger tests than whether an endpoint exists. (hitconsultant.net) The next concrete step is governance of promoted marts and metadata. The sources point to a stack in which interoperability is judged by whether data can be trusted in analytic and clinical workflows, not by whether a vendor can check the FHIR box. (hitconsultant.net)