Defines the structure of a Bundle that carries content updates that are communicated in FHIRcast -update messages. The bundle can only contain requests of type PUT and DELETE.
POST is not allowed as the content sharing mechanism cannot indicate the id of the created resource using a POST operation.

Provides guidance as to which DiagnosticReport attributes should be present and considerations as to how each attribute should be valued in all [FHIR resource]-open events.

At least one business identifier of the DiagnosticReport SHALL be provided in a [FHIR resource]-open request.

Typically the report is associated with an order from an information system. In this case the accession number of the order is provided in the DiagnosticReport’s basedOn array attribute as a reference using a ServiceRequest reference type and the “ACSN” identifier type. The accession number SHALL be included as a business identifier if it is known.

A reporting system may also include its own identifier and should use an appropriate identifier type and system when supplying such a business identifier.

In radiology reports or other image related uses of FHIRcast, at least one imaging study would likely be the subject of the report and included in the event’s context. In this case, the reference to one or more ImagingStudy resources would be provided.

FHIR R4 versus FHIR R5 In the FHIR R4 DiagnosticReport resource image study references would be placed in the imagingStudy attribute. In a FHIR R5 (or above) DiagnosticReport this attribute has been renamed study since the allowed reference types has been expanded to include references to GenomicStudy resources. This is obviously a breaking change.

In FHIRcast deployments based on FHIR R5, the attribute study SHALL be used rather than the imagingStudy attribute.

Additionally FHIR R5 includes a supportingInfo attribute. While not yet formally provided for in FHIR R5, it has been recommended that the next release of FHIR allow an ImagingStudy reference be included in this attribute so that the DiagnosticReport could indicate one or more image studies were consulted during the creation of the report. As such in FHIR R5 deployments, this field is considered labeled as must support.

Provides guidance as to which DiagnosticReport attributes should be present and considerations as to how each attribute should be valued in DiagnosticReport-select events.

The DiagnosticReport in DiagnosticReport-select events enables verification that the selected content in the DiagnosticReport-select event belongs to the DiagnosticReport which is the current anchor context.

Hence, the only required attributes of DiagnosticReport in the DiagnosticReport-select event is the resources’ id, as well as its status and code since these attributes are required by FHIR. Other attributes of the DiagnosticReport MAY be valued but would serve no purpose in the DiagnosticReport-select event.

Provides guidance as to which DiagnosticReport attributes should be present and considerations as to how each attribute should be valued in DiagnosticReport-update events.

The DiagnosticReport in DiagnosticReport-update events serves two purposes. First its presence enables verification that the content in the DiagnosticReport-update event’s Bundle attribute belongs to the DiagnosticReport which is the current anchor context. Additionally, attributes of the DiagnosticReport which is the current anchor context may be updated in a DiagnosticReport-update event.

Hence, the only required attributes of DiagnosticReport in the DiagnosticReport-update event is the resources’ id, as well as its status since this attribute is required by FHIR. Other attributes of the DiagnosticReport MAY be valued if they have changed from their original values or no value had been provided in the DiagnosticReport-open event.

Provides guidance as to which DiagnosticReport attributes should be present and considerations as to how each attribute should be valued in all [FHIR resource]-close events.

FHIR R4 versus FHIR R5 In the FHIR R4 DiagnosticReport resource image study references would be placed in the imagingStudy attribute. In a FHIR R5 (or above) DiagnosticReport this attribute has been renamed study since the allowed reference types has been expanded to include references to GenomicStudy resources. This is obviously a breaking change.

In FHIRcast deployments based on FHIR R5, the attribute study SHALL be used rather than the imagingStudy attribute.

Additionally FHIR R5 includes a supportingInfo attribute. While not yet formally provided for in FHIR R5, it has been recommended that the next release of FHIR allow an ImagingStudy reference be included in this attribute so that the DiagnosticReport could indicate one or more image studies were consulted during the creation of the report. As such in FHIR R5 deployments, this field is considered labeled as must support.

Provides guidance as to which Encounter attributes should be present and considerations as to how each attribute should be valued in all [FHIR resource]-close events.

Provides guidance as to which Encounter attributes should be present and considerations as to how each attribute should be valued in all [FHIR resource]-open events.

Defines the structure of a Bundle that carries current content state resulting from various FHIRcast -update messages.

Provides guidance as to which ImagingStudy attributes should be present and considerations as to how each attribute should be valued in all [FHIR resource]-close events.

It is recommended that the image study business identifiers provided in the corresponding [FHIR resource]-open event are provided in the [FHIR resource]-close event. Providing these business identifiers enables Subscribers to perform identity verification according to their requirements. See FHIRcast ImagingStudy for Open Events for details on the business identifiers of an ImagingStudy.

Provides guidance as to which ImagingStudy attributes should be present and considerations as to how each attribute should be valued in all [FHIR resource]-open events.

At least one business identifier of the ImagingStudy SHALL be provided in a [FHIR resource]-open request. Two business identifiers are typically associated with an image study. Imaging systems such as a PACS viewer, advanced visualization workstation, etc. typically identify an image study by its DICOM Study Instance UID (which in DICOM is identified with a (0020,000D) tag). Likewise, information systems often identify an image study through the accession number of the order which triggered the image procedure to be performed.

The Study Instance UID SHALL be included as a business identifier if it is known. In FHIR, the Study Instance UID of an ImagingStudy is provided in the identifier array using the identifier system of urn:dicom:uid and prefixing the UID value with urn:oid:.

The accession number SHALL be included as a business identifier if it is known.

FHIR R4 versus FHIR R5

Relative to FHIR R4, the ImagingStudy resource’s change relevant to FHIRcast is the guidance FHIR R5 provides in specifying the accession number. In FHIR R4, the guidance is to provide the accession number in the identifier array. In FHIR R5, the accession number is provided in the ImagingStudy’s basedOn array as a reference using a ServiceRequest reference type.

Since this version of FHIRcast promotes the use of FHIR R4 resources, the guidance to provide the accession number in the identifier array SHOULD be used and this approach is shown in all ImagingStudy examples in the FHIRcast specification. However, if Subscribers agree to use FHIR R5 resources, the FHIR R5 recommendation MAY be used.

For a more detailed explanation of these business identifiers, see the FHIR R4 implementation notes of the FHIR ImagingStudy resource (and the FHIR R5 implementation notes of the FHIR ImagingStudy resource). Ideally both the accession number and Study Instance UID are available and present in an ImagingStudy resource used in FHIRcast. The presence of both business identifiers ensures that all Subscribers will be able to be able to identify the appropriate imaging study.

Defines the minimum set of attributes which an application wanting to share observation content must support

Provides guidance as to which Patient attributes should be present and considerations as to how each attribute should be valued in all [FHIR resource]-close events.

Provides guidance as to which Patient attributes should be present and considerations as to how each attribute should be valued in all [FHIR resource]-open events.

Contains the rationale behind the userLogout event

Contains the rationale behind the userHibernate event

CapabilityStatment stating support for FHIRcast.

Defines the structure of an OperationOutcome to be used in sync-error events created by the Hub.

Defines the structure of an OperationOutcome to be used in sync-error events send by a Suscriber indicting refusal to follow context.

Defines the structure of OperationOutcomes to be used in sync-error events. The content of the OperationOutcomes contains information that is used to determine the cause of the sync-error.

Extension in CapabilityStatement stating the location of the FHIRcast hub to be used with this FHIR server.

This valueset lists possible reasons a user logs out and send a logout event to other Subscribers.

This valueset lists possible reasons a hibernate event is send to other Subscribers.

This codesystem defines terminology that is used within the FHIRcast specification.

Example instance of a CapabilityStatement with FHIRcast extension.

Example of a content update bundle

Example of a DiagnosticReport which could be used in a [FHIR resource]-close event. Note that due to limitation of tools used to publishing the specification the below resource id is appended with ‘-close’. The specification requires that the resource id in the [FHIR resource]-close be identical to the resource id provided in the corresponding [FHIR resource]-open; hence in the real world the ‘-close’ suffix would not be present.

Example of a DiagnosticReport which could be used in a [FHIR resource]-open event

Example of a DiagnosticReport which could be used in a DiagnosticReport-select event. Note that due to limitation of tools used to publishing the specification the below resource id is appended with ‘-select’. The specification requires that the resource id in the [FHIR resource]-select be identical to the resource id provided in the corresponding [FHIR resource]-open; hence in the real world the ‘-select’ suffix would not be present.

Example of a DiagnosticReport which could be used in a DiagnosticReport-update event. Note that due to limitation of tools used to publishing the specification the below resource id is appended with ‘-update’. The specification requires that the resource id in the [FHIR resource]-update be identical to the resource id provided in the corresponding [FHIR resource]-open; hence in the real world the ‘-update’ suffix would not be present.

Example of an encounter which could be used in a [FHIR resource]-close event. Note that due to limitation of tools used to publishing the specification the below resource id is appended with ‘-close’. The specification requires that the resource id in the -close be identical to the resource id provided in the corresponding -open; hence in the real world the ‘-close’ suffix would not be present.

Example of an encounter which could be used in a [FHIR resource]-open event

Example response to the get current context.

Example of FHIRcast hibernate event context.

Example of an imaging study which could be used in a [FHIR resource]-close event. Note that due to limitation of tools used to publishing the specification, the below resource id is appended with ‘-close’. The specification requires that the resource id in the [FHIR resource]-close be identical to the resource id provided in the corresponding [FHIR resource -open; hence in the real world the ‘-close’ suffix would not be present.

Example of an imaging study which could be used in a [FHIR resource]-open event

Example FHIRcast logout event context.

Example of a simple observation which could be exchanged using FHIRcast

Example of a patient which could be used in a [FHIR resource]-close event. Note that due to limitation of tools used to publishing the specification, the below resource id is appended with ‘-close’. The specification requires that the resource id in the [FHIR resource]-close be identical to the resource id provided in the corresponding [FHIR resource]-open; hence in the real world the ‘-close’ suffix would not be present.

Example of a patient which could be used in a [FHIR resource]-open event

Example OperationOutcome as present in sync-error events

Example OperationOutcome as present in sync-error events

Placeholder resource representing an ImagingStudy

Placeholder resource representing an Organization.

Placeholder resource representing a Patient

Placeholder resource representing a Practitioner