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

Home

Official URL: https://fhir.onyxhealth.io/us/arex/ImplementationGuide/onyx.fhir.us.arex				Version: 0.1.0
Draft as of 2026-08-12				Computable Name: AttachmentReferenceExchange

Attachment Reference Exchange (ARex)

ARex defines a common pattern for exchanging large binary and document payloads out-of-band from the FHIR transaction they support.

The transaction carries a manifest reference. The manifest carries an index of individually addressable, individually sized content objects. The receiver retrieves what it needs, under an authorization grant scoped to that one transaction, within a declared availability window.

Why this exists

Every FHIR exchange that carries clinical documentation eventually hits the same wall. Content is base64-encoded into the transaction payload, the payload inflates by roughly a third, and it collides with a size ceiling somewhere in the path — an application gateway, a clearinghouse, an X12 transport, a message broker. The available responses are all poor:

• Inline and hope. Works until it does not, and fails at the recipient rather than at the sender.
• Fragment the transaction. Pushes an unspecified reassembly problem onto intermediaries and produces no interoperable result.
• Fall back to fax or portal upload. Abandons the electronic exchange entirely.

ARex takes the fourth option, which the industry already uses everywhere else: publish the content, describe it, and let the receiver fetch it.

A note on the name

"Attachment" in the title reflects the use case that occasioned this work — supporting documentation for prior authorization and claims — and is not a limit on scope. Nothing in this guide is specific to attachments, to claims, or to prior authorization. Any exchange that needs to move content out of a transaction payload is in scope.

The operative word is Reference. Content-by-reference is the correct pattern at any size: manifest-scoped authorization, declared expiry, and digest verification are as valuable for a 400 KB note as for a 40 MB imaging report. This guide deliberately sets no size threshold, because the only threshold that matters is the smallest ceiling in a given delivery path, and no specification can know it.

What ARex is not

ARex is transaction-agnostic. It does not know what a prior authorization is, and it contains no claims, coverage, or documentation-request semantics. Implementation guides with a large-content problem profile ARex and supply their own reassociation identifiers and availability floors.

ARex is also not a system of record. The manifest endpoint is a transfer mechanism with a declared expiry. Retrieved content becomes the receiver's obligation the moment it is retrieved. See Availability and Retention.

Status

This guide is draft and provisional, published for industry comment ahead of a proposed contribution to HL7. Its canonical URL is provisional and its content is intended to be folded into the Da Vinci HRex implementation guide rather than balloted as a standalone US Realm guide. See HRex Alignment and Fold-In Path.