Health data interoperability

Editorial approval scope: The team checked current source fidelity, scope boundaries, dates, arithmetic, reader usefulness, practical workflow, and general-information limitations.

Interoperability has several layers

• Technical: systems connect, authenticate, transmit, receive, and respond.
• Syntactic: content follows the agreed format, version, and profile.
• Semantic: identifiers, codes, units, dates, and status retain the same meaning.
• Workflow: the right person receives the information at the right time and acts.
• Governance: authority, privacy, security, provenance, accountability, and correction are defined.

One layer can pass while another fails. A valid resource may identify the wrong client. A correctly matched authorization may arrive after scheduling. A complete message may sit in an unowned queue.

Define the use before the interface

Name the decision or action the exchange supports. Identify sender, receiver, individuals affected, data, authority, clinical or operational owner, timing, and consequence. Then choose the standard and route.

For each interface, record:

• source and destination systems, environments, owners, and versions
• identifiers, matching rules, terminology, units, and timestamps
• required fields, profiles, extensions, and attachment rules
• authentication, authorization, disclosure route, encryption, and logs
• triggers, acknowledgements, retries, duplicates, and exception queues
• correction, reconciliation, continuity, monitoring, and retirement

Standards create shared building blocks

ASTP/ONC describes FHIR as a widely used, API-focused standard made from modular resources. The HL7 FHIR specification defines resources, API patterns, profiles, and conformance artifacts.

Partners still need to agree on release, implementation guide, profile, terminology, local extensions, and workflow. “FHIR enabled” or “HL7 compatible” cannot substitute for that contract.

Preserve meaning and provenance

Store the assigning system with every identifier. Record code systems and versions. Preserve the source value when mapping. Distinguish unknown, absent, declined, and inapplicable data.

Provenance should show where information came from, when it was created and received, who authored it, and how it changed. A receiving clinician needs to distinguish direct observation, client report, caregiver report, payer status, and transformed data.

Design correction across both systems

An error can remain after the source is fixed when the destination stores a copy, derived field, report, alert, or task. Define which system owns correction, how a change is transmitted, whether prior values remain visible, and who reconciles downstream effects.

Test an identifier merge, corrected service date, revoked authorization, changed provider, amended clinical statement, and withdrawn disclosure permission where each is applicable. Record how the destination distinguishes correction, replacement, retraction, and a new event. Notify qualified owners when the change could affect care, a claim, an appeal, access, or safety. Interoperability includes a reliable repair path, not only successful first delivery.

Test correction speed as well as delivery speed. Measure both.

Authority travels separately from data

Technical access does not create a permitted use or disclosure. Apply the HIPAA Privacy Rule where the parties and information fall within its scope, then map more protective state, minor, education, consumer-health, and contract rules.

Verify personal-representative authority, involved-person routes, consent, authorization, and treatment, payment, or operations pathways as applicable. Send only the information supported by that route. The receiver's ability to display a field supplies no authority.

A fictional exchange review

Omar's practice locks 32 fictional exchanges that reached a defined review date. Twenty-eight pass transport, structure, identity, terminology, authority, workflow, and reconciliation checks: 28 of 32, or 87.5%.

One has an unmatched identifier. One uses an obsolete code. One lacks a valid disclosure route. One arrives without a downstream owner. All four stay visible. The ratio describes complete test workflows, not interoperability across other partners or real care.

Test corrections and failure paths

Include duplicates, missing fields, late messages, out-of-order events, corrected records, revoked permissions, unavailable systems, and changed versions. Confirm that rejected content produces an understandable error and an owned task.

Reconcile counts and states from source through destination and final action. Measure complete exchanges divided by exchanges due for review. Report technical failures, semantic mismatches, authority holds, and unworked exceptions separately.

The CMS interoperability overview describes federal initiatives involving specified payers and exchange capabilities. Program rules do not prove that an endpoint is live, data is complete, or a specific ABA workflow is supported.

Keep the person visible

Interoperability should improve continuity, access, correction, and understandable information. Give people accessible ways to view, question, and correct records where governing rights apply. Preserve language, AAC, sensory, and disability access in portals and communication.

Track exchange burden alongside completeness. A highly structured interface that adds duplicate family forms or hides a correction route may still fail its operational goal.

Define closure from the person's perspective: the correction appears in the systems that drive care, the family receives an understandable response, and any record that cannot be changed carries a visible link to the dispute or amendment. Delivery alone is not resolution.