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

Availability and Retention

Page standards status: Trial-use

Availability and Retention

There are two clocks here and conflating them is how this pattern fails in production. ARex governs one of them and explicitly disclaims the other.

Transfer availability

How long the manifest and its content remain retrievable from the publisher.

§arex-30 A publisher SHALL declare an explicit expiry instant in the manifest using the ARex Expires extension.

§arex-31 The declared expiry SHALL NOT be earlier than the anticipated completion of the business transaction the content supports, including any request-for-additional-information cycle that transaction permits.

§arex-32 Profiling implementation guides SHALL specify a minimum availability floor appropriate to their business context. In the absence of such a floor, a publisher SHOULD declare an expiry not less than 30 days after publication.

§arex-33 A publisher SHALL NOT rely on an HTTP Expires header alone to convey availability. The expiry SHALL be carried in the manifest body.

§arex-33 matters because a manifest may be relayed, cached, or re-served by an intermediary in the escrow-hosted topology. Transport headers do not survive that journey; the manifest must be self-describing.

Evidentiary retention

What the receiver owes once it has retrieved the content. This is outside ARex's scope, and saying so is a normative act rather than an omission.

§arex-34 A consumer SHALL persist retrieved content in accordance with its own record-retention and evidentiary obligations, and SHALL NOT rely on the publisher's endpoint as a system of record.

§arex-35 A consumer SHALL NOT treat manifest expiry as terminating any obligation of its own with respect to content it has already retrieved.

Without §arex-34, the predictable outcome is that receivers treat publisher endpoints as durable archives. That creates an unbounded and unfunded storage liability at the publishing organization, and it produces a broken evidence trail when a dispute surfaces long after the manifest has expired. The party that made a determination on the basis of a document is the party that must be able to produce that document.

Interaction with existing availability requirements

Availability requirements elsewhere in an implementer's stack generally attach to the transaction record, not to attachment binaries. Implementers should not read a transaction-record availability period across to ARex content, in either direction: the record obligation does not oblige the publisher to keep serving octets, and a short ARex expiry does not relieve the record obligation.

Where a profiling guide intends the two to align, it must say so explicitly under §arex-32.