Attachment Reference Exchange (ARex)
0.1.0 - ci-build
Attachment Reference Exchange (ARex)
0.1.0 - ci-build
Attachment Reference Exchange (ARex) - Local Development build (v0.1.0) built by the FHIR (HL7® FHIR® Standard) Build Tools. See the Directory of published versions
| Page standards status: Informative |
ARex borrows its shape from the Bulk Data Access manifest and deliberately leaves the rest behind.
Borrowed: the separation of a FHIR server that describes content from a content server that serves octets; per-object typing, sizing, and addressing; an explicit access-token requirement flag; a declared transaction time.
Not borrowed: the kickoff / 202 Accepted / poll ceremony. In Bulk Data the manifest does not exist until an asynchronous job completes. In ARex the content set is known at publication time, so there is nothing to poll for. Implementers should not reach for $export semantics here.
Inverted: direction of pull. Bulk Data manifests are produced by the party that holds the data and consumed by a client that already has a relationship with it. ARex content typically originates at a provider organization and is consumed by a payer or its intermediary — which means the publisher may be a party that has never operated an authorization server.
This inversion is the central adoption risk, and ARex addresses it by specifying two conformant topologies rather than one.
Escrow-hosted. The originating organization pushes content to an intermediary, clearinghouse, or neutral escrow, which publishes the manifest and serves the content. This preserves the existing trust, contracting, and connectivity model. It requires no new externally reachable infrastructure at the source organization, and it puts per-object sizing enforcement at the party that already knows the downstream size ceilings.
Source-hosted. The receiving organization retrieves directly from the originating organization, discovered through directory infrastructure. This is the better end state and the one that generalizes beyond any single intermediary relationship.
A guide that specified only the source-hosted topology would be technically sound and would go unimplemented, in the same way and for the same reasons as the X12 275. Escrow-hosted is the on-ramp; source-hosted is the destination.
Binary for content. It is the one FHIR resource with native raw-octet semantics: retrieval with a non-FHIR Accept header returns the actual bytes with the actual content type and no encoding inflation. Note that Binary is not a DomainResource and therefore cannot carry extensions — all per-object ARex metadata lives on the corresponding ARex Content Entry.
DocumentReference for per-object metadata. It already carries content type, size, title, creation date, and format, which is exactly the set a receiver needs in order to decide what to fetch and in what order before committing to a transfer.
List for the manifest. DocumentManifest is the intuitive choice and is a trap: it was removed in FHIR R5, so building on it would guarantee a rewrite at the R5 migration. List survives, carries snapshot mode semantics, and — importantly — has a retracted status, which gives revocation a first-class representation rather than an invented extension.
Provenance for the signature. List has no signature element, and adding one by extension would duplicate a resource that already exists for exactly this purpose.