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

HRex Alignment and Fold-In Path

Page standards status: Informative

HRex Alignment and Fold-In Path

ARex is written to be absorbed, not to persist as a standalone guide.

Why HRex

The large-content problem is not specific to any one exchange. Prior authorization supporting documentation, claims attachments, and clinical data requests all hit it, and the guides that cover them already overlap in this area. A pattern that lives inside one of them will be re-invented, incompatibly, by the others. HRex is where Da Vinci puts cross-cutting infrastructure, and this is cross-cutting infrastructure.

A practical consequence for anyone filing against this proposal: a change request that spans multiple Da Vinci guides tends to be bounced when it is filed against just one of them. The pattern should be socialized across the affected work before a formal submission.

Canonical rebase

Every canonical URL in this guide is provisional. On adoption, artifacts rebase from https://fhir.onyxhealth.io/us/arex to the HRex canonical. This is a breaking change and there is no way to avoid it, so the design minimizes its blast radius:

• All artifact IDs carry an arex- prefix, so they can be dropped into HRex without collision.
• No artifact ID encodes the publisher, the version, or the word "Onyx."
• Dependencies are limited to US Core and HRex itself. There is no dependency on any guide that would have to be inverted.

Implementers piloting this content should expect to re-point canonicals once and should not build tooling that assumes the provisional canonical is durable.

Version coupling

ARex declares a US Core dependency but does not derive any profile from a US Core profile. This is deliberate. Deriving ARex Content Entry from the US Core DocumentReference profile would bind the pattern to a specific US Core version and, through it, to a specific USCDI version — a coupling that would force an ARex revision on every US Core release for no design benefit.

Instead: US Realm deployments SHALL ensure that instances conforming to ARex Content Entry also conform to the applicable US Core DocumentReference profile. The obligation is stated as a deployment requirement rather than baked into the derivation chain, which keeps ARex stable across US Core versions and keeps it reusable outside the US Realm if that ever becomes relevant.

Terminology

Two CodeSystems are defined, which is two more than ideal. Both are candidates for terminology.hl7.org migration on adoption.

ARexDigestAlgorithm should be retired outright if an external registry binding is acceptable — the IANA Named Information Hash Algorithm Registry covers the same ground and avoids HL7 maintaining a list of hash functions. Retaining a locally defined code system for cryptographic algorithms is a maintenance commitment that outlasts the people who make it.

ARexManifestType is small and stable and is a reasonable THO candidate as-is.

Open items for HL7 discussion

1. Signature type code. The examples use Author's Signature (1.2.840.10065.1.12.1.1). Verification Signature may be the better fit depending on whether the publisher is asserting authorship of the content or attestation of the index. This should be settled before ballot.
2. List.source cannot reference Organization in R4. Publisher organization identity is consequently carried in ARex Provenance rather than on the manifest itself. This is a workaround, not a design; R5 migration may permit a cleaner model.
3. Whether the manifest belongs in the transaction at all. ARex assumes a pointer is carried in the governing transaction but does not specify where. An alternative is discovery purely by transaction identifier search, with no pointer. The first is more robust; the second requires no change to existing transaction profiles.
4. Escrow liability. The escrow-hosted topology makes an intermediary a custodian of clinical content for the duration of the availability window. The business-associate implications are real and are not addressed here.