FHIRcast logo

FHIRcast
3.0.0-ballot - STU 3 Ballot International flag

This page is part of the FHIRcast (v3.0.0-ballot: STU3 (v3.0.0) Ballot 1) based on FHIR (HL7® FHIR® Standard) R4. The current version which supersedes this version is 2.0.0. For a full list of available versions, see the Directory of published versions

Conformance

The FHIRcast specification can be described as a set of capabilities and any specific FHIRcast Hub may implement a subset of these capabilities. A FHIRcast Hub declares support for FHIRcast and specific capabilities by exposing an extension on the FHIR CapabilityStatement resource as described below.

Wellknown Endpoint

To support various architectures, including multiple decentralized FHIRcast hubs, the Hub exposes a .well-known endpoint containing additional information about the capabilities of that Hub. A Hub’s supported events, version, and other capabilities can be exposed as a Well-Known Uniform Resource Identifiers (URIs) (RFC5785) JSON document.

Hubs SHOULD serve a JSON document at the location formed by appending /.well-known/fhircast-configuration to their hub.url. Contrary to RFC5785 Appendix B.4, the .well-known path component may be appended even if the hub.url endpoint already contains a path component.

A simple JSON document is returned using the application/json mime type, with the following key/value pairs:

Field Optionality Type Description
eventsSupported Required array Array of FHIRcast events supported by the Hub.
websocketSupport Required boolean SHALL have the static value: true - indicating support for websockets.
fhircastVersion Optional string STU1, STU2, or STU3 - indicating support for a specific version of FHIRcast. Hubs SHOULD indicate the version of FHIRcast supported.
getCurrentSupport Optional boolean true or false - indicating support for the “Get Current Context” API.
fhirVersion Optional string DSTU1, DSTU2, STU3, R4, R4B, or R5 - indicating the specific version of FHIR for this Hub.

A field of webhookSupport SHALL be ignored.

Wellknown endpoint discovery example

In this example the Hub URL is “www.hub.example.com/”.

Wellknown endpoint discovery Request
GET /.well-known/fhircast-configuration HTTP/1.1
Host: www.hub.example.com

Wellknown endpoint discovery Response

HTTP/1.1 200 OK
Content-Type: application/json

{
  "eventsSupported": ["Patient-open", "Patient-close", "SyncError", "com.example.researchstudy-transmogrify"],
  "websocketSupport": true,
  "fhircastVersion": "STU3"
}

FHIR Capability Statement

To supplement or optionally identify the location of a FHIRcast hub, a FHIR server MAY declare support for FHIRcast using the FHIRcast extension on its FHIR CapabilityStatement’s rest element. The FHIRcast extension has the following internal extensions:

Extension Cardinality Type Description
hub.url 0..1 url The url at which an application can subscribe. This might not be supported by client-side Hubs.

CapabilityStatement Extension Example

{
  "resourceType": "CapabilityStatement",
  ....
  "rest": [{
   ...
        "extension": [
          {
            "url": "http://fhircast.hl7.org/StructureDefinition/fhircast-configuration/fhir-configuration",
            "extension": [
              {
                "url": "hub.url",
                "valueUri": "https://hub.example.com/fhircast/hub/R4"
              }
            ]
          }
        ]      
    ...
    }]
    ...
}

FHIR Resource Structures

FHIRcast defines profiles for various FHIR resource structures used in the specification, see summary of artifacts.

Must Support

In the context of FHIRcast, must support (MS) on any data element SHALL be interpreted to mean FHIR’s MustSupport. Generally, implementations are expected to:

  • if known and possible, populate supported data elements as part of the event notifications as specified by the FHIRcast profiles.
  • interpret missing, supported data elements within resource instances as data not present in the sending systems (or for which the requestor is unauthorized).