CI Build - This specification is a draft continuous integration build and is subject to change. It is not ready for limited roll-out or production level use. For a full list of available versions, see the Directory of published versions
Capability Statements - Server
CA:FeX Server CapabilityStatement
The generic cafex-server CapabilityStatement covers document submission, discovery and retrieval using Binary, Bundle and DocumentReference. The tables below summarize that resource; they do not replace the actor-option requirements in Capability Statements. Option B's $generate-metadata and Option D's $summary are declared in their actor-option artifacts rather than in this generic server artifact.
The CapabilityStatement resource is the source of truth. Published representations are available as XML and JSON; publication of this realignment is a separate release step.
General expectations
The CaFeX Server SHALL:
- Implement the RESTful behavior according to the FHIR specification.
- Follow the requirements documented in the CaFeX specification
- Return the following response classes:
- (Status 400): invalid parameter
- (Status 401/4xx): unauthorized request
- (Status 403): insufficient scopes
- (Status 404): unknown resource
- Support JSON source formats for all CaFeX interactions.
The CaFeX Server SHOULD:
- Support XML source formats for all CaFeX interactions.
See Security for security requirements. A server SHALL reject unauthorized requests with HTTP 401, 403 or 404, as specified in the artifact.
Resource interactions
Resource support is SHOULD for each resource below. Interaction expectations apply within that resource support; claiming an actor option also invokes its specific requirements.
| Resource | SHALL | SHOULD | MAY |
|---|---|---|---|
| Binary | read |
— | create, search-type, vread, update, patch, delete, history-instance, history-type |
| Bundle | read |
create |
search-type, vread, update, patch, delete, history-instance, history-type |
| DocumentReference | search-type, read |
create |
vread, update, patch, delete, history-instance, history-type |
All three resources declare the resolves reference policy. Optional update/delete interactions do not override FHIR document immutability; see Document Exchange.
Search parameters
See Search Parameters for the definitions. The inventory below reports support expectations from the generic server.
| Resource | Parameter | Expectation |
|---|---|---|
| Bundle | bundle-composition-patient |
MAY |
| Bundle | bundle-composition-patient-identifier |
MAY |
| Bundle | timestamp |
MAY |
| Bundle | bundle-composition-type |
MAY |
| Bundle | bundle-composition-author |
MAY |
| Bundle | bundle-composition-status |
MAY |
| Bundle | bundle-composition-date |
MAY |
| Bundle | bundle-composition-category |
MAY |
| DocumentReference | _id |
SHALL |
| DocumentReference | status |
MAY |
| DocumentReference | patient |
SHALL |
| DocumentReference | category |
MAY |
| DocumentReference | type |
MAY |
| DocumentReference | date |
MAY |
| DocumentReference | period |
MAY |
Binary has no named search parameters in this artifact. DocumentReference also declares _revinclude=Provenance:target; this does not add a standalone Provenance endpoint to the retained resource inventory.
DocumentReference search combinations
| Required parameters in combination | Expectation |
|---|---|
patient + category + date |
SHALL |
patient + status |
SHOULD |
patient + category |
SHALL |
patient + type + period |
SHOULD |
patient + type |
SHALL |
Search value requirements
status: The client SHALL provide at least a code value and MAY provide both the system and code values. The server SHALL support both.patient: The client SHALL provide at least a id value and MAY provide both the Type and id values. The server SHALL support both.category: The client SHALL provide at least a code value and MAY provide both the system and code values. The server SHALL support both.type: The client SHALL provide at least a code value and MAY provide both the system and code values. The server SHALL support both.date: A client SHALL provide a value precise to the second + time offset. A server SHALL support a value precise to the second + time offset.period: A client SHALL provide a value precise to the second + time offset. A server SHALL support a value precise to the second + time offset.
Operations
The generic server declares DocumentReference/$docref with a SHOULD expectation and the canonical definition http://hl7.org/fhir/uv/ipa/OperationDefinition/docref. Its operation documentation states:
A server SHOULD be capable of responding to a $docref operation and capable of returning at least a reference to a generated patient-summary document, if available. MAY provide references to other 'on-demand' and 'stable' documents (or 'delayed/deferred assembly') that meet the query parameters as well. If a context date range is supplied the server ** SHOULD** provide references to any document that falls within the date range. If no date range is supplied, then the server SHALL provide references to last or current document(s). SHOULD document what resources, if any, are returned as included resources
GET [base]/DocumentReference/$docref?patient=[id]
See Operations for the operation overview and Document Exchange for Option B and D transactions.
System interactions
The artifact lists transaction, batch, search-system and history-system as MAY. These optional system interactions do not introduce independent clinical-resource exchange requirements.