What the HL7 Interoperability Push Changes for Multi-Location Groups

Healthcare interoperability has been "about to arrive" for a long time. What's different now is that several pieces are landing at once: federal deadlines for health plans, certified EHRs that already expose standardized APIs, and a new push from HL7 International to bring medical device data into the same framework.

For a multi-location practice, that's genuinely useful. It's also easy to overestimate. Here's what's changing, what it means day to day, and what it won't do.

What's actually happening

HL7 is extending FHIR to devices. On March 5, 2026, HL7 International launched Caliper, a new FHIR accelerator focused on how data from medical and personal health devices is exchanged and integrated with EHRs and other systems. FHIR (Fast Healthcare Interoperability Resources) is the HL7 standard that federal rules now specify for certified EHR APIs and for the new payer APIs described below. Accelerators are industry groups that build and test implementation guides for a particular use. They don't create a mandate, but their work can shape what vendors build next, which makes them worth watching even for practices that never touch a device integration.

Health plans face federal deadlines. The CMS Interoperability and Prior Authorization Final Rule (CMS-0057-F) requires Medicare Advantage organizations, Medicaid and CHIP programs, and certain plans on the federal Exchanges to meet new prior authorization decision timeframes of 72 hours for urgent requests and seven calendar days for standard ones, with operational provisions generally beginning January 1, 2026. The same rule requires those payers to stand up FHIR-based APIs, including a Prior Authorization API, beginning January 1, 2027.

Certified EHRs already have standardized APIs. Under the 21st Century Cures Act rules, certified health IT developers had to provide FHIR-based APIs to their customers by December 31, 2022. ONC reported that more than 95% of certified developers met that deadline.

Why it matters for a multi-location group

The biggest near-term benefit is in the payer-facing work that consumes front-office and billing time.

Prior authorization is the clearest example. In the AMA's survey of 1,000 physicians in late 2024, practices reported completing an average of 39 prior authorization requests per physician per week, with physicians and staff spending about 13 hours a week on them. The 2024 CAQH Index found that providers spent an average of 24 minutes on a prior authorization request by phone, fax, or email, and 16 minutes through a health plan portal. Standardized payer APIs are meant to move more of that work into the systems staff already use.

There's also room to improve basic exchange between organizations. ONC data show that in 2021, only 16% of office-based physicians engaged in all four parts of interoperable exchange: sending, receiving, finding, and integrating patient information from outside their organization.

For a group with several locations, each of these improvements is multiplied by the number of sites and staff doing the work.

To see the scale, consider a hypothetical group whose staff submit 100 prior authorization requests a week by phone or fax. Using the CAQH averages, moving those requests to a portal would save about eight minutes each, or roughly 13 staff hours a week. Moving them into the systems staff already work in, through payer APIs, should save more, though real-world results will depend on how well each vendor implements the connection. Either way, the gain is only realized if someone tracks it. Note today's volume and average handling time before your vendors switch anything on, so you can tell whether the promised improvement actually arrived.

What it won't change

This is where expectations tend to outrun reality.

Standards cover health data, not your operations. FHIR is designed for clinical and administrative health information: patients, encounters, observations, coverage, claims, and authorizations. It isn't designed to coordinate staff schedules across locations, your intake workflow, cosmetic or retail sales, supply ordering, or the reports your partners review each month. That operational layer is where most multi-location friction lives, and interoperability standards don't reach it.

An API is a door, not a connection. A certified API means data can be requested in a standard way. Someone still has to build the connection, map the data to how your practice works, handle errors, and maintain it as both sides change. Standards make that work more predictable. They don't make it disappear.

Deadlines apply to specific parties, on their own timelines. The CMS rule applies to the payers listed above, not to every commercial plan. Practices benefit as their EHR and billing vendors connect to those payer APIs, and the timing will vary by vendor.

Internal inconsistency stays. If each location configures its tools differently, better data exchange with the outside world won't make the practice consistent on the inside.

Questions to ask your vendors now

Use these in your next renewal conversation, and ask for the answers in writing.

1. Which FHIR APIs do you support today, and on which version? CMS-0057-F points to HL7 FHIR Release 4.0.1.
2. Are you building connections to payer Prior Authorization APIs, and on what timeline?
3. Can we access our own data through your API? Is there a cost or a volume limit?
4. If we or a partner build our own connection, what documentation and support do you provide?
5. What happens to our data if we leave? Ask about format, timing, and cost of a full export.

The answers tell you which of your systems will be easy to connect and which will stay closed. That's the information you need before deciding what to keep, what to replace, and what to build around. The custom versus off-the-shelf guide covers how to weigh that decision.

Two projects, not one

It helps to think of interoperability and integration as separate pieces of work with separate budgets.

The first is external: connecting to payers, referring providers, labs, and devices. Standards, federal rules, and your EHR vendor's roadmap do much of the heavy lifting here, and your job is mostly to ask good questions and hold vendors to their answers.

The second is internal: making your own locations and tools work as one practice. No standard body will do this for you. It's the handoffs between your scheduler, intake, billing follow-up, staff management, and reporting, and it's usually where the most staff hours go.

What to do this week

Map where outside interoperability would actually save time in your practice. For most groups, that means prior authorizations, eligibility checks, and records arriving from referring providers. Then map the internal handoffs no standard will fix: the places where staff re-key data between your own tools. Why multi-location practices are rethinking best-of-breed explains a simple way to count them.

If the internal list turns out to be the longer one, the page on software for multi-location medical practices describes how we approach that side of the work.

If you're weighing what a fix would cost, our guide to how much custom software costs breaks down build, maintenance and three-year totals, and the software stack cost calculator adds up what your current tools cost today.