HL7 FHIR Lacks Architectural N-Party Coordination Substrate

FHIR Reality

HL7 FHIR operates as the dominant healthcare-interoperability standard across U.S. and emerging international deployments. ONC certification under the 21st Century Cures Act mandates FHIR support, the HTI-1 final rule operationalized the USCDI v3 data classes against FHIR R4, and HTI-2 — progressing through the regulatory pipeline — extends mandated exchange into prior authorization, payer-to-payer coordination, and public-health reporting. US Core profiles constrain FHIR resources into a baseline set of elements that every certified EHR must support; SMART on FHIR provides the application-launch substrate; Bulk Data and SMART App Launch round out the developer-facing exchange surface.

The market position is decisive. Epic, Oracle Cerner, MEDITECH, athenahealth, Veradigm, and effectively every certified EHR expose FHIR R4 endpoints. Payers expose Patient Access, Provider Directory, and Drug Formulary FHIR APIs under CMS-9115. Digital-health vendors — from remote-monitoring platforms to AI-augmented clinical documentation — assume FHIR as the integration substrate. International adoption through Argonaut, IPS (International Patient Summary), and country-specific implementation guides extends the same exchange model into NHS, Canada Health Infoway, and EU MyHealth@EU contexts.

What FHIR provides, definitively, is a data-exchange wire format with constrained semantics and a regulatory mandate to support it. What FHIR does not provide — and was not designed to provide — is architectural substrate for credentialed multi-party coordination grounded in physical proximity.

Coordination Substrate Above FHIR

N-party-coordination is the architectural primitive for physical-proximity-grounded multi-party settlement. The clinical reality FHIR is asked to support is structurally multi-party: a patient encounter routinely involves the admitting hospital, a referring physician practice, a specialty consultant, an imaging center, a reference laboratory, a specialty pharmacy, a payer, a pharmacy-benefit manager, a public-health registry, and — increasingly — an at-home device manufacturer and a remote-monitoring service. Each party operates under its own credential, its own consent envelope, and its own regulatory regime, and the coordination among them is grounded in physical proximity events: the patient is physically present at the imaging center, the specimen is physically transported to the lab, the device is physically affixed to the patient at home.

FHIR exchanges resources between two endpoints at a time. It does not settle a multi-party coordination event. There is no FHIR resource that says: "these seven credentialed parties, grounded in this physical-proximity event, settled this coordination outcome under this composite consent envelope." Bundles are aggregations, not settlements; Provenance attests origin, not multi-party agreement; Consent is a single-axis policy artifact, not a composite credential. The architectural gap is not a missing resource — it is a missing layer.

Physical proximity is the load-bearing element that distinguishes healthcare coordination from generic distributed-systems coordination. The patient is at the imaging center; the specimen is in the courier's hand; the device is on the patient's wrist. Each of these is an irreducibly physical event, and the credential trail that settles the multi-party coordination must be grounded in those events rather than in the message exchanges that report them after the fact. FHIR transports the report; the substrate above settles the event.

Layered Composition

FHIR provides data-exchange substrate; n-party-coordination provides handoff-and-coordination substrate; the layers compose. The coordination layer reads the same FHIR resources every certified EHR already exposes, treats each FHIR transaction as a credentialed observation grounded in a physical-proximity event, and emits a settled multi-party coordination artifact that survives across the encounter. US Core profiles continue to constrain the resource shape; SMART on FHIR continues to handle application launch; Bulk Data continues to handle population-level export. None of that changes.

What changes is that the seven-party encounter — admitting hospital, referrer, consultant, imaging, lab, pharmacy, payer — settles into a single credentialed coordination artifact whose audit trail is grounded in the physical-proximity events that actually carried the patient through the encounter. ONC's HTI-2 trajectory toward prior-authorization, payer-to-payer, and public-health coordination is exactly the surface that demands this layer. FHIR alone cannot settle prior authorization across plan, provider, and PBM; it can only exchange the resources those parties need to coordinate. The settlement is the missing primitive.

Regulatory Trajectory

ONC HTI-1 operationalized FHIR-based data exchange; HTI-2 operationalizes coordination workflows that FHIR alone cannot settle. CMS Interoperability and Prior Authorization (CMS-0057-F) requires payer-to-payer FHIR exchange and prior-authorization APIs; TEFCA's QHIN framework moves cross-network exchange into a federated-trust posture; public-health reporting under eCR and ELR is migrating onto FHIR rails. Each of these surfaces is structurally multi-party, structurally credentialed, and structurally grounded in physical-proximity events the exchange must reflect rather than abstract away.

The FHIR community's response has been working groups and implementation guides — Da Vinci for payer-provider coordination, CodeX for oncology, Vulcan for research. Each is valuable, none provides architectural substrate for n-party settlement. The coordination layer above FHIR is the substrate those working groups assume but do not themselves define.

HL7 Ecosystem Position

The HL7 community gains architectural coordination direction; FHIR-based deployments gain a coordination substrate that complements rather than displaces the existing standard. EHR vendors continue to expose FHIR R4 and R5 endpoints under ONC certification; payers continue to operate CMS-9115 and CMS-0057-F APIs; the substrate above absorbs the multi-party settlement that FHIR was never asked to perform. The architectural separation — FHIR as data-exchange substrate, n-party-coordination as physical-proximity-grounded settlement substrate — is the layered composition the HTI-2 trajectory ultimately requires.

Implementation guides such as Da Vinci, CodeX, and Vulcan continue to constrain resource shape and exchange semantics for their respective verticals; SMART on FHIR continues to handle launch and authorization; Bulk Data continues to handle population export. None of those investments are displaced. The coordination substrate composes above them, treating each FHIR transaction as a credentialed physical-proximity observation and emitting the multi-party settlement artifact that prior-authorization, payer-to-payer, and public-health workflows actually require to operate accountably across the seven-or-more parties any nontrivial encounter touches.