Adopting Interoperability: A Roadmap for Providers

What does adopting interoperability mean for a provider?

Adopting interoperability means a provider organization moves from ad hoc interfaces to a managed program in which exchange with patients, partners, payers and networks is planned, governed, staffed and measured. It covers technology such as FHIR APIs and HL7 v2 feeds, but most of the work is policy, ownership and daily operations.

Many organizations already exchange a great deal of data. What they lack is a single owner, an inventory of what flows where, and a consistent way to answer a request for data.

An adoption program fixes that in phases, so each phase delivers working exchange while building the foundations the next one needs.

Why does interoperability now sit with providers?

Providers are named actors under the federal information blocking rules, and penalties for providers now exist. That turns exchange from an IT project into an organizational duty.

• Actors: Under 45 CFR Part 171, health care providers are actors alongside developers of certified health IT and health information networks or exchanges. Practices likely to interfere with access, exchange or use of electronic health information can be information blocking unless an exception applies.
• Disincentives: The HHS final rule published on 1 July 2024 set disincentives for providers that OIG finds have committed information blocking, including treating a hospital as not a meaningful EHR user under Medicare Promoting Interoperability and a zero score in the MIPS Promoting Interoperability category for clinicians, and possible exclusion of an ACO, ACO participant or ACO provider from the Medicare Shared Savings Program for at least one year.
• Safety self-assessment: The Medicare Promoting Interoperability Program for hospitals and the MIPS Promoting Interoperability category include a SAFER Guides measure, an annual attestation to a self-assessment using the voluntary ASTP/ONC SAFER Guides.

The disincentives apply only after OIG investigates and refers a provider to CMS. For most organizations, the practical exposure is documentation: being able to show that each refusal or delay fit an exception and followed a written policy.

That documentation is an engineering problem as much as a policy one. Request intake, the decision, the person who made it and the policy applied should be captured by the systems that handle requests, not reconstructed from email when someone asks.

What are the phases of an interoperability roadmap?

An interoperability roadmap for a provider usually runs in five phases, each ending with something in production. The order matters more than the timing.

• 1. Inventory: List every interface, API connection, network and data request channel, with owner, partner, direction, standard and volume. Feeds with no owner often surface here.
• 2. Governance and policy: Set up the decision group, write the policy for answering data requests and documenting refusals, and agree consent rules for sensitive data.
• 3. Foundations: Put the shared pieces in place: an interface engine, a master patient index with match rules, terminology mapping, monitoring, and an API gateway in front of FHIR endpoints.
• 4. Exchange rollout: Bring use cases live one at a time, such as patient app access, referral documents, lab and imaging feeds, HIE or TEFCA queries and payer data exchange, each with a named clinical and technical owner.
• 5. Measure and sustain: Track exchange quality, reconcile received data into the chart, and keep up with yearly standards updates and partner upgrades.

Phases overlap in practice. A clinic can bring patient app access live in phase 4 while master patient index work continues, as long as the known gaps are written down.

Choose the first use cases by how much manual work they remove, such as faxed referrals or rekeyed outside results, rather than by which standard is newest.

Picking the first use cases

• Manual work removed: Count the faxes, phone calls and rekeyed results each candidate replaces, using the phase 1 inventory.
• Clinical risk of delay: Favor exchanges where late data harms care, such as discharge summaries to primary care or outside results before a procedure.
• Partner readiness: Start where the partner already supports a standard interface and has a test environment.
• Request exposure: Include patient access through apps early, because those requests arrive whether or not the program is ready for them.
• Measurability: Prefer use cases with a clear before and after, so the program can show results to its sponsors.

Who should govern exchange decisions?

A small cross-functional group should govern exchange decisions, with authority to approve new connections and a written process for data requests. Without it, each interface is approved by whoever happens to be asked.

• Chair: A senior leader, often the CIO or CMIO, who can settle disputes between departments.
• Privacy and compliance: The privacy officer and counsel, who own information blocking exceptions, consent policy and business associate terms.
• Health information management: The team that owns the legal record, release of information and patient identity.
• Clinical informatics: Clinicians who decide how received data appears in the chart and what must be reconciled.
• Integration lead: The engineer or architect who owns the interface engine, APIs and monitoring.

The group's first deliverable is a request policy: who may ask for which data, through which channel, how fast it is answered, and how a refusal is documented against a Part 171 exception. Engineers then build systems that record each decision.

Sensitive data needs its own rules. Substance use disorder treatment records and other categories with special federal or state protection may need tagging or consent checks before exchange, and the group should decide how those records are flagged and who may release them.

Meet on a fixed schedule and keep a register of approved connections. The register becomes the living inventory that phase 5 depends on.

Which roles does the program need?

An interoperability program needs integration engineering, interface analysis, identity, terminology, informatics and privacy skills, whether the people are employed or contracted. Small groups combine roles; large systems staff each one.

• Integration engineer: Builds and maintains interface engine channels, FHIR clients and API security.
• Interface analyst: Works with partners on specifications, test messages and go-live, and handles failed messages day to day.
• Identity steward: Reviews possible duplicate records and match exceptions, often within health information management.
• Terminology specialist: Maps local codes for labs, problems and medications to LOINC, SNOMED CT and RxNorm.
• Clinical informaticist: Designs how outside data is reviewed and reconciled into the chart.
• Privacy analyst: Handles data requests, consent restrictions and exception documentation.

An outside engineering partner can cover integration builds and peaks in demand, but identity stewardship and request decisions should stay inside the organization, because they depend on local knowledge and carry legal weight.

Write a handover plan into any outside contract. Channel documentation, test message sets and runbooks should belong to the provider, so the internal team can support every feed once the build ends.

How do you measure adoption?

Measure adoption by whether exchanged data is used, not by how many interfaces exist. Pick a few measures and report them to the governance group each quarter.

• Reconciliation rate: The share of received documents whose problems, medications and allergies were reviewed into the chart.
• Duplicate record rate: New possible duplicates per month in the master patient index, and the time taken to resolve them.
• Request turnaround: Time from a patient or partner data request to fulfillment, by channel.
• Interface health: Messages in error queues, the oldest unprocessed message and unplanned downtime per feed.
• Manual workarounds: Faxes received and outside results rekeyed, which should fall as feeds go live.

Set the baseline during phase 1. Without it, the program cannot show what changed, and funding for later phases is harder to defend.

Report each measure by use case as well as in total. A single program score can hide one failing feed behind several healthy ones.

Roadmap failure points

Interoperability programs tend to stall in the same places. Review this failure-point list at each phase gate.

• Technology first: An engine or platform bought before the inventory and governance exist, so it is configured around guesses.
• No request policy: Staff answer data requests case by case, and refusals cannot be traced to an exception.
• Data dumped, not reconciled: Outside documents arrive as attachments that clinicians never open.
• Identity left to chance: Matching rules are never tuned, so duplicates grow with every new feed.
• Everything outsourced: A vendor builds the feeds, and no one inside can troubleshoot them after handover.
• No owner after go-live: Interfaces with no named owner fail silently until a clinician notices missing results.

Each of these is cheaper to address in the phase where it starts than after several feeds depend on it.

How Agnotic can help

An adoption roadmap needs engineering capacity at the moments the plan moves from policy to production. Agnotic Technologies works as the provider's integration team for those phases: interface engine channels, FHIR API and SMART app access, patient matching and terminology services, and the monitoring that keeps feeds healthy.

Agnotic builds the systems that record request decisions and exceptions, and hands over documentation and runbooks, while the provider's governance group keeps ownership of policy, identity stewardship and clinical reconciliation rules.

Sources

• 45 CFR Part 171: Information blocking
• Federal Register: Establishment of disincentives for health care providers that have committed information blocking (1 July 2024)
• ASTP/ONC: SAFER Guides and the Promoting Interoperability measures