Payers have a calendar to work to: under CMS's interoperability and prior authorization rule, the requirement to build and enhance FHIR APIs generally begins on January 1, 2027, with exact dates varying by plan type. Any plan for healthcare interoperability solutions should start from that deadline and work backwards.
This guide covers what the two main standards do, how they differ, what the rules ask for, and the order in which to do the work.
What healthcare interoperability solutions connect
They connect systems that were never built to talk to each other: EHRs, lab systems, billing platforms, patient portals and mobile apps. The job is to move structured information between them without losing meaning on the way.
Two standards do most of that work. HL7 describes FHIR (Fast Healthcare Interoperability Resources) as a standard for exchanging healthcare information electronically, built so that implementation is simpler without sacrificing the integrity of the information.
The older standard, HL7 v2, shaped FHIR directly. HL7's overview says FHIR was informed by lessons from v2, v3, the RIM and CDA.
How HL7 v2 and FHIR differ
HL7 v2 moves data in segments, which are reusable building blocks that can't be handled independently. FHIR moves data as resources, each one an independent object that other resources point to.
HL7's own comparison of FHIR and v2 lists the differences that matter in practice:
- A single FHIR MedicationRequest covers much of what several v2 order segments carry.
- V2 extends through Z-segments, whose meaning is opaque unless the sender explains them. FHIR extensions can sit at any level and their definitions can be looked up by URI.
- FHIR requires human-readable content for each resource. V2 generally has no required readable form.
- V2 can send only changes, using action codes. Out of the box, FHIR works in snapshot mode.
The snapshot point is the one that catches integration teams out. A feed that used to say "this field changed" now has to say "here is the whole object as it stands".
Do you have to choose between them?
No. HL7 states that FHIR can be used standalone or alongside existing standards, and that most resources are mapped to several formats, including v2.
For healthcare interoperability solutions, that makes the practical answer a hybrid. Existing hospital feeds keep running on v2, and new apps and APIs are built on FHIR. Ripping out working interfaces to reach a cleaner architecture is rarely worth the risk.
One more detail clears up a common worry. HL7's overview says you don't have to use REST to make use of resources, so a FHIR project doesn't force a single exchange style on you.
What the rules now require
For payers, the rule is specific. The CMS fact sheet for CMS-0057-F names Medicare Advantage organizations, state Medicaid and CHIP fee-for-service programs, Medicaid managed care plans, CHIP managed care entities and Qualified Health Plan issuers on the Federally Facilitated Exchanges as the impacted payers. They must maintain four FHIR APIs:
- A Patient Access API, which already exists and is updated to include prior authorization information, excluding drugs.
- A Provider Access API, new, sharing patient data with in-network providers who have a treatment relationship with the patient.
- A Payer-to-Payer API, new, moving claims, encounter, USCDI and certain prior authorization data when a patient changes payers.
- A Prior Authorization API, new, handling requests and responses, including denials with a specific reason and requests for more information.
Operational provisions began on January 1, 2026, including the requirement to give a specific denial reason. For most payers, the API work lands a year later.
Healthcare interoperability solutions for providers and app builders sit on the other side of those APIs. A payer with a Provider Access API is only useful if the clinical systems on the receiving end can consume it.
Patient access and information blocking
The earlier 21st Century Cures Act rule, summarised on HealthIT.gov, asks the industry to adopt standardized APIs so people can securely reach structured health information through smartphone apps.
It also says patients must be able to access all of their electronic health information at no cost, and it defines nine exceptions to the information blocking provisions.
If you build patient-facing software, that second point shapes your design. Export and access can't be an afterthought bolted on before launch.
A practical order of work for HL7 to FHIR integration
Whichever healthcare interoperability solutions you pick, HL7's guidance on moving from v2 to FHIR is blunt about one thing: published mappings are only a starting point. Expect implementation-specific mappings, and follow the steps below.
- Inventory every v2 feed you run, and note which elements carry local Z-segment content.
- For each v2 element with no core FHIR equivalent, search the FHIR extension registry before defining a local extension. Where you do define one, give it a URI tied to the defining system rather than the segment name.
- Settle one way to assign resource URIs, so repeated references to the same object resolve to the same resource.
- Write rules for recognising when two message fragments describe the same object, and for what happens when versions conflict.
- Decide for each resource whether it is fully identified or contained. A practitioner with only a name would typically be contained, while one with a reliable identifier may not be.
- Plan for deletes and partial updates, either by building logic that produces full snapshots or by using the FHIR Patch operation.
Steps three and four are where projects stall, because they're decisions about your data rather than code. HL7 itself notes that messaging has no settled approach to URI assignment.
Generating the human-readable narrative is the step teams leave to the end. HL7 recommends doing it with clinician input about what information matters, which is a scheduling problem as much as a technical one.
Where custom development fits
Off-the-shelf healthcare interoperability solutions cover standard feeds. The work that needs a build team is the layer on top: a portal, an app or an internal tool that reads and writes FHIR resources and keeps patients' data usable.
When we built the website, members portal and mobile app for OptimalMD, we designed and delivered the whole digital product from design through development to launch. You can read how that came together in the OptimalMD case study.
For the detail on resources and endpoints, our piece on FHIR integration for healthcare apps goes further. If the question is securing the connections between systems, healthcare API development covers it, and the wider picture sits in our healthcare software development guide.
If you're scoping a portal or app that has to sit on top of these standards, our apps and SaaS team builds exactly that. Bring the list of feeds from step one and the conversation gets concrete quickly.
Frequently asked questions
Is FHIR replacing HL7 v2?
HL7's own material doesn't say so. It describes FHIR as usable standalone or alongside existing standards, and notes that most resources map to formats including v2.
Do I need REST to use FHIR?
No. HL7's overview states that you don't have to use REST to make use of FHIR resources.
How quickly must payers answer prior authorization requests?
CMS sets 72 hours for expedited requests and seven calendar days for non-urgent ones. These timeframes don't apply to QHP issuers on the Federally Facilitated Exchanges.
Can patients get their health information for free?
Under the Cures Act final rule as summarised by HealthIT.gov, patients must be able to access all of their electronic health information, structured or unstructured, at no cost.
Cover photo by erwinbosman on Pixabay
Sources
- FHIR Overview — HL7 International
- FHIR and HL7 v2 comparison — HL7 International
