Almost nobody argues about whether Fast Healthcare Interoperability Resources (FHIR) matters anymore. Regulatory requirements keep expanding, with Centers for Medicare & Medicaid Services (CMS)-0057-F alone mandating four new FHIR application programming interfaces (APIs) on staggered deadlines. At the same time, organizations increasingly see FHIR as a foundation for interoperability, digital transformation, and emerging artificial intelligence (AI) initiatives.
Despite broad agreement on its value, adoption has been slower and more difficult than many expected. Many organizations have launched FHIR initiatives but still struggle to translate them into measurable business outcomes. The obstacles are consistent enough to name and specific enough to plan around.
Getting around it: Give every use case a business owner and an outcome metric that isn't an endpoint. Not "patient administration system (PAS) API in production" but "percentage of prior authorizations returning a determination without a phone call." The technical work doesn't change; the ability to fund the next phase does.
Getting around it: Sequence by two variables at once: regulatory deadline and data readiness. Start where the source data already lives in a system you control. That means Patient Access before Payer-to-Payer, because one reads data you already hold and the other depends on a trading partner's timeline as much as your own.
Two use cases delivered in 12 months beat 12 scoped in a slide deck. The customers we’ve seen make the most progress start with a small number of high-value use cases and build outward from what those use cases actually taught them. The ones that stall tend to start with the data model instead—and discover the mapping decisions they got wrong only when the second and third consumers show up.
Getting around it: Treat profile conformance and terminology binding as owned artifacts with named owners, not as properties the FHIR server provides. Validate against US Core Implementation Guide (US Core) and the relevant Da Vinci profiles before persistence, not at the edge. Pin your ValueSet bindings and version them. Where a source system can't produce a required element, decide explicitly whether to derive it, default it, or reject the record. An undocumented default is a data quality incident waiting to surface in someone else's dashboard.
We worked with a customer whose accountable care organization (ACO) needed insurance data out of its X12 feeds and into FHIR. The team mapped the NM1 segment into a custom extension on the Patient resource. It validated, returned data, and passed every test they wrote—and it still didn't work, because a custom extension only functions if every downstream system is told in advance to look for it: a specification and a code change for every consumer, forever.
US Core had already answered the question. Insurance belongs in Coverage, where any conformant consumer knows to look without being told. And the cost compounds: a patient with three payers produces three Coverage resources referencing that patient, exactly the pattern the Da Vinci burden reduction guides use to drive Coverage Requirements Discovery (CRD), then Documentation Templates and Rules (DTR) and Prior Authorization Support (PAS). In a Patient extension, that same data supports one interface and nothing else.
The rule that came out of it: before you write an extension, confirm the concept isn't already profiled in US Core. Extensions are for genuinely local concepts, not for the ones you didn't find.
Getting around it: Pair integration engineers with clinical informaticists on mapping decisions and write the mapping rationale down where the next team can find it. Budget for training on the standard itself, not just the toolchain. And treat workflow change as its own workstream; a technically perfect API that clinicians route around has not been adopted. In the ACO example above, the extension-versus-Coverage decision was made by an engineer working without an informatics partner—a defensible engineering choice and the wrong data-representation choice. No amount of added development capacity would have caught it.
Getting around it: Version implementation guides and profiles the way you version code and treat implementation guide (IG) revisions as potentially breaking changes with a regression suite behind them. Run conformance testing in Inferno and Touchstone in a pipeline, not a one-time certification exercise. Keep a standing governance function funded past go-live; it's cheaper than rebuilding the same capability under a new project code.
Getting around it: Own a layer above the EHR, one place where identity resolution, terminology, audit, and profile validation are applied once and reused. That's the difference between an integration you build again for every partner and a reusable interoperability foundation that can support future requirements without a new project.
That question is harder than the endpoint, and it's where most of the work actually lives. It's also the work we spend our time on across FHIR, HL7 V2, C-CDA, and X12, where the gap between adopting the standard and running on it gets closed. As organizations invest in new digital experiences, automation, analytics, and AI, the ability to operationalize standardized data will only become more important.
Ready to move from adopting FHIR to operationalizing it? Explore Infor FHIR Services.
Despite broad agreement on its value, adoption has been slower and more difficult than many expected. Many organizations have launched FHIR initiatives but still struggle to translate them into measurable business outcomes. The obstacles are consistent enough to name and specific enough to plan around.
1. The project is scoped to IT, so it's measured like an IT project
When FHIR lands as an integration initiative, success gets defined as "the endpoint is live." That's a milestone nobody outside IT can evaluate, which makes it hard to defend a budget for phase two. Business stakeholders show up at compliance deadlines and leave once the box is checked.Getting around it: Give every use case a business owner and an outcome metric that isn't an endpoint. Not "patient administration system (PAS) API in production" but "percentage of prior authorizations returning a determination without a phone call." The technical work doesn't change; the ability to fund the next phase does.
2. The roadmap is too big to start
Enterprise-wide interoperability programs generate long planning cycles, dozens of candidate use cases, and no near-term proof of value. Stakeholder patience runs out before the first deliverable ships.Getting around it: Sequence by two variables at once: regulatory deadline and data readiness. Start where the source data already lives in a system you control. That means Patient Access before Payer-to-Payer, because one reads data you already hold and the other depends on a trading partner's timeline as much as your own.
Two use cases delivered in 12 months beat 12 scoped in a slide deck. The customers we’ve seen make the most progress start with a small number of high-value use cases and build outward from what those use cases actually taught them. The ones that stall tend to start with the data model instead—and discover the mapping decisions they got wrong only when the second and third consumers show up.
3. Standing up the API gets mistaken for solving the data problem
A conformant endpoint makes data reachable. It doesn't make it reusable. The gap shows up when downstream teams spend more time reconciling data than acting on it, especially as organizations try to reuse that data across analytics, automation, and AI initiatives. The mechanics are mundane: two systems will happily return the same concept coded in three different ways, and every consumer pays the reconciliation tax separately.Getting around it: Treat profile conformance and terminology binding as owned artifacts with named owners, not as properties the FHIR server provides. Validate against US Core Implementation Guide (US Core) and the relevant Da Vinci profiles before persistence, not at the edge. Pin your ValueSet bindings and version them. Where a source system can't produce a required element, decide explicitly whether to derive it, default it, or reject the record. An undocumented default is a data quality incident waiting to surface in someone else's dashboard.
We worked with a customer whose accountable care organization (ACO) needed insurance data out of its X12 feeds and into FHIR. The team mapped the NM1 segment into a custom extension on the Patient resource. It validated, returned data, and passed every test they wrote—and it still didn't work, because a custom extension only functions if every downstream system is told in advance to look for it: a specification and a code change for every consumer, forever.
US Core had already answered the question. Insurance belongs in Coverage, where any conformant consumer knows to look without being told. And the cost compounds: a patient with three payers produces three Coverage resources referencing that patient, exactly the pattern the Da Vinci burden reduction guides use to drive Coverage Requirements Discovery (CRD), then Documentation Templates and Rules (DTR) and Prior Authorization Support (PAS). In a Patient extension, that same data supports one interface and nothing else.
The rule that came out of it: before you write an extension, confirm the concept isn't already profiled in US Core. Extensions are for genuinely local concepts, not for the ones you didn't find.
4. The gap is skills, not headcount
Adding more developers doesn't close the readiness gap, because the hard part of FHIR isn't calling a Representational State Transfer (REST) endpoint; it's deciding how clinical data should be represented. Knowing that a Health Level Seven Version 2 (HL7 V2) ADT-A08 update doesn't map cleanly onto a single Patient write, or that a Consolidated Clinical Document Architecture (C-CDA) section can legitimately produce four resources with references that have to resolve in a specific order, is clinical-informatics knowledge as much as engineering knowledge.Getting around it: Pair integration engineers with clinical informaticists on mapping decisions and write the mapping rationale down where the next team can find it. Budget for training on the standard itself, not just the toolchain. And treat workflow change as its own workstream; a technically perfect API that clinicians route around has not been adopted. In the ACO example above, the extension-versus-Coverage decision was made by an engineer working without an informatics partner—a defensible engineering choice and the wrong data-representation choice. No amount of added development capacity would have caught it.
5. It's run as a project when it behaves like a program
Implementation guides are revised. Regulations phase in on staggered dates. CMS-0057-F alone touches Prior Authorization, Provider Access, Patient Access, and Payer-to-Payer on separate timelines. A one-time implementation starts aging the week it goes live. When governance and funding both end at launch, every new requirement becomes a new project instead of a change to an existing capability.Getting around it: Version implementation guides and profiles the way you version code and treat implementation guide (IG) revisions as potentially breaking changes with a regression suite behind them. Run conformance testing in Inferno and Touchstone in a pipeline, not a one-time certification exercise. Keep a standing governance function funded past go-live; it's cheaper than rebuilding the same capability under a new project code.
6. The EHR is assumed to have it covered
Electronic health record (EHR) FHIR APIs are genuinely good at what they were built for: read access to data inside the EHR. Modern interoperability requirements reach past that boundary into payers, health information exchanges (HIEs), specialty systems, patient-facing apps, analytics platforms, and AI. Write paths, bulk export at population scale, cross-organizational identity resolution, and non-clinical data like X12 claims all sit outside what the EHR was scoped to do. The signal that you've hit the boundary is that every new integration request requires custom development, and nothing built before can be reused.Getting around it: Own a layer above the EHR, one place where identity resolution, terminology, audit, and profile validation are applied once and reused. That's the difference between an integration you build again for every partner and a reusable interoperability foundation that can support future requirements without a new project.
Operationalizing FHIR is the real challenge underneath all six
Every one of these barriers is the same mistake in a different costume: treating FHIR as a thing you install rather than a capability you operate. The organizations getting real value from it have stopped asking whether they support the standard and started asking whether the data moving across it is accurate, current, and trustworthy six months after launch.That question is harder than the endpoint, and it's where most of the work actually lives. It's also the work we spend our time on across FHIR, HL7 V2, C-CDA, and X12, where the gap between adopting the standard and running on it gets closed. As organizations invest in new digital experiences, automation, analytics, and AI, the ability to operationalize standardized data will only become more important.
Ready to move from adopting FHIR to operationalizing it? Explore Infor FHIR Services.