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
| Official URL: https://fhir.onyxhealth.io/us/arex/CapabilityStatement/ARexContentServer | Version: 0.1.0 | |||
| Draft as of 2026-08-10 | Computable Name: ARexContentServer | |||
The party that publishes a manifest and serves the content it references. In an escrow-hosted deployment this is an intermediary or neutral escrow; in a source-hosted deployment it is the originating organization.
Raw OpenAPI-Swagger Definition file | Download
json, xmlNote to Implementers: FHIR Capabilities
Any FHIR capability may be 'allowed' by the system unless explicitly marked as 'SHALL NOT'. A few items are marked as MAY in the Implementation Guide to highlight their potential relevance to the use case.
serverServers SHALL require an OAuth 2.0 access token for all interactions unless a capability-URL downgrade has been agreed under a trading partner agreement. Servers SHALL verify that the authenticated client corresponds to the requesting organization named in the manifest transaction context.
SMART Backend Services or UDAP B2B. No new mutual-TLS trust relationships are established for ARex purposes.
The summary table lists the resources that are part of this configuration, and for each resource it lists:
_include_revinclude| Resource Type | Profile | R | S | U | C | Searches | _include | _revinclude | Operations |
|---|---|---|---|---|---|---|---|---|---|
| List | https://fhir.onyxhealth.io/us/arex/StructureDefinition/arex-manifest | y | y | transaction-identifier | |||||
| DocumentReference | https://fhir.onyxhealth.io/us/arex/StructureDefinition/arex-content-entry | y | |||||||
| Binary | https://fhir.onyxhealth.io/us/arex/StructureDefinition/arex-binary | y | |||||||
| Provenance | https://fhir.onyxhealth.io/us/arex/StructureDefinition/arex-provenance | y | y |
read, search-type.| Conformance | Parameter | Type | Documentation |
|---|---|---|---|
| SHALL | transaction-identifier | token |
read.read.Servers SHALL honour a non-FHIR Accept header on Binary read and return the native octets with the native content type.
read, search-type.