The result was in both systems. It was still missing.
One interface delivered the lab value. The receiving chart stored it under the wrong encounter, displayed a local code nobody recognized, and gave the on-call team no alert. Transport succeeded. Care did not.
Healthcare interoperability lives in that gap between “payload received” and “the right person can safely use this fact.” A useful project traces one fact across meaning, identity, exchange, authorization, operations, and evidence.
The six-layer test
Pick one fact, such as a potassium result, medication order, allergy, or appointment status. Walk it through six layers.
| Layer | Question | Typical evidence |
|---|---|---|
| Meaning | Do both sides interpret the fact the same way? | Profile, terminology, units, required fields |
| Identity | Is it attached to the right patient, encounter, order, and organization? | Identifier rules, match cases, merge handling |
| Exchange | How does it move and change state? | Message, API, document, event, acknowledgment |
| Authorization | Who may request, receive, or act on it? | Scopes, roles, consent, purpose, launch context |
| Operations | What happens when the path is slow, duplicated, unavailable, or changed? | Queues, alerts, retries, reconciliation, runbook |
| Evidence | How do both parties prove the intended result occurred? | Test fixtures, logs, destination record, owner sign-off |
Most troubled projects over-invest in the third row. They choose a standard, open a connection, and discover later that nobody agreed on the first two or staffed the last two.
Meaning comes before mapping
A field called status can describe collection, clinical finality, interface processing, billing state, or display state. Moving it from one schema to another is not interoperability until the parties agree which meaning survives.
Create a data contract for the use case. For every field that drives care or operations, record its definition, source authority, allowed values, units, null behavior, update rule, and downstream use. Bind coded values to named terminology and version where the program requires it. Document local codes rather than hiding them inside a transformer.
USCDI is a standardized set of health data classes and elements used in federal health IT policy. It gives programs a common data baseline, but it does not define every workflow, API behavior, or local operating rule (ASTP/ONC USCDI). Treat it as one contract input.
Identity is an exchange of its own
The wrong-patient test belongs at the start, not the final safety review. List the identifiers for patient, encounter, practitioner, organization, location, order, specimen, result, and device that matter to the chosen fact.
Then test collisions and change:
- two people share a name and birth date;
- a local medical-record number is reused outside its assigning organization;
- demographic data changes;
- duplicate records merge;
- an encounter moves between locations;
- an order is replaced or cancelled; and
- the receiver knows the identifier value but not its issuer.
FHIR resources can carry business identifiers and references, yet the implementation still needs rules for scope, issuer, matching, and provenance (HL7 FHIR Resource). A syntactically valid identifier can still be operationally useless.
Pick the exchange pattern after the event
There is no single interoperability pipe.
An HL7 v2 message may report an admission or result event. A FHIR client may read or search resources through a defined API. A document may carry a signed summary. A network may support query and exchange across participating organizations. These patterns solve different jobs and can coexist.
Use this short selection sequence:
- Name the real-world event or user action.
- Name the authoritative source before and after it.
- Name the consumer and the decision or task it performs.
- Set the timing, authorization, and completeness requirement.
- Choose the exchange pattern already supported by the participants when it satisfies the first four lines.
For the narrower standards comparison, read FHIR vs HL7 v2. The sequence matters: a standard implements the use case; it does not invent one.
FHIR, SMART, and USCDI do different jobs
These names often appear in one procurement sentence even though they answer different questions.
FHIR defines resources and exchange patterns. The SMART App Launch guide defines authorization and launch patterns for applications using FHIR, including scopes and context. USCDI defines a US data set used by federal programs. A certified API criterion can reference all three in a particular regulatory contract (HL7 SMART App Launch, ASTP/ONC standardized API).
Do not collapse them into “we have a FHIR API.” Ask instead:
- Which FHIR version and implementation guide apply?
- Which resources, profiles, search parameters, and operations are supported?
- Which USCDI version and elements are in scope for this program?
- Which SMART launch mode, scopes, token behavior, and context are supported?
- Which roles and organizations may access which patients for which purpose?
- What happens when an optional element is absent?
A server’s CapabilityStatement and the applicable implementation guides belong in the acceptance packet.
Networks add policy to the wire
Cross-organization exchange needs more than an endpoint. Participants need common terms, permitted purposes, directory and identity rules, security expectations, dispute processes, and operating agreements.
The Trusted Exchange Framework and Common Agreement is a US framework for nationwide network-to-network health information exchange. The Recognized Coordinating Entity publishes the Common Agreement, qualified health information network materials, standard operating procedures, and related resources (TEFCA resources).
TEFCA is not a synonym for every interface between two systems. If it is relevant, state which participant, exchange purpose, network path, and operating procedure apply to the use case.
Failure behavior is part of the clinical contract
A result that arrives twice, late, or without an order link can create work even when its values are correct. Write a failure matrix before go-live.
| Failure | Receiver behavior | Owner | Recovery proof |
|---|---|---|---|
| Duplicate event | Detect by stable business identity; do not create a second clinical fact | Interface owner | One final record, duplicate logged |
| Unknown patient | Hold outside the chart; route to reconciliation | Registration or HIM | Authorized match and release trail |
| Invalid code or unit | Reject or quarantine under the contract | Data steward | Corrected value and replay evidence |
| Destination unavailable | Queue or stop according to agreed durability boundary | Operations | Backlog drains without loss or duplication |
| Authorization denied | Return a clear denial; never weaken scope silently | Security owner | Denied test and audit event |
| Late correction | Preserve provenance and update the intended record | Clinical data owner | Old and new states traceable |
Rehearse the matrix. A runbook that nobody has used is a hypothesis.
Acceptance follows the fact
The best acceptance test begins in the source workflow and ends where a user acts.
For a lab result, prove the order identity, specimen, code, value, unit, reference range, status, time, patient, encounter, provenance, and correction behavior. Verify the receiving display and any alert or queue. Then reconcile the source and destination.
Keep the request or message, response or acknowledgment, validation output, logs, destination evidence, and owner decision in one test record. That packet tells a future engineer what “worked” meant.
The Patient Square boundary
Patient Square is an AI clinical platform. Practice Copilot brings the whole practice under one AI copilot: an ambient AI Medical Scribe that hands back a structured SOAP note, ICD-10 suggestions, and a prescription draft minutes after the visit, plus a bundled AI EHR, scheduling, and messaging as you move up the plan. Hospitals get Hospital Copilot.
The public scope includes “EHR-ready export (PDF · HL7 · FHIR).” It does not include a claim of certified interoperability, FHIR conformance, SMART App Launch, TEFCA participation, a named EHR connection, automatic filing, or write-back. Export may be the right handoff for a workflow. If a live exchange is required, it needs its own contract and evidence.
Start the next architecture meeting with one fact, not a diagram of every system. Trace it through all six layers. The missing agreement usually appears before the first connector is built.