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: Trial-use |
Conformance statements are numbered §arex-NN for citation.
§arex-1 A publisher SHALL make available, for each content set, exactly one ARex Manifest instance conforming to the ARex Manifest profile.
§arex-2 A manifest SHALL index each content object as a separate entry. A publisher SHALL NOT aggregate multiple logical documents into a single content object solely to reduce entry count.
§arex-3 Each content entry SHALL declare content.attachment.size in octets as served, and SHALL declare a digest using the ARex Digest extension.
§arex-4 Content SHALL be referenced by absolute URL. Inline content.attachment.data is prohibited.
§arex-5 A publisher SHALL accompany each manifest with an ARex Provenance instance carrying a detached JWS over the canonical serialization of the manifest.
§arex-6 A publisher SHALL populate the transaction context with sufficient business identifiers to reassociate the content set with the transaction it supports. Profiling implementation guides SHALL specify which identifiers are required in their context.
§arex-7 A content server SHALL honour a non-FHIR Accept header on Binary read and return the native octets with the native content type.
§arex-8 A consumer SHALL verify the manifest signature before acting on its contents.
§arex-9 A consumer SHALL verify the declared digest of each object it retrieves, and SHALL NOT process an object whose computed digest does not match.
§arex-10 A consumer SHALL NOT infer that a manifest is complete or current from a prior retrieval. A consumer that re-enters a workflow SHALL re-read the manifest and check status.
§arex-11 A publisher SHOULD size individual content objects with regard to the smallest known ceiling in the delivery path, where such a ceiling is known.
§arex-12 A content server SHALL support HTTP range requests on Binary retrieval.
§arex-13 Neither publisher nor consumer SHALL fragment a single content object across manifest entries. Where an object exceeds a consumer's transfer capacity, the consumer uses range requests; the object remains one addressable resource with one digest.
The distinction in §arex-13 is the point of the whole pattern. Splitting a set across transfers is a routine transport concern. Splitting an object creates a reassembly contract that no receiver is obligated to honour and that breaks integrity verification.
§arex-14 A publisher SHALL be able to revoke a manifest prior to its declared expiry by setting status to retracted.
§arex-15 On revocation a publisher SHALL cease serving the referenced content and SHALL revoke or allow the immediate expiry of any outstanding grants scoped to that manifest.
§arex-16 A publisher SHALL retain the manifest identifier and a retracted manifest instance after revocation, so that a consumer holding a stale reference receives an authoritative retraction rather than a 404.
Wrong-patient disclosure is the case that makes revocation non-optional, and it is the case that constrains the authorization design: see Security and Authorization.
§arex-17 A publisher SHALL record an ARex Audit Event for each manifest publication, manifest retrieval, content retrieval, and revocation.
§arex-18 A publisher SHALL retain audit records for a period not shorter than its applicable accounting-of-disclosures obligation, independent of the manifest expiry.