FHIRcast, published by HL7 International / Infrastructure And Messaging. This guide is not an authorized publication; it is the continuous build for version 3.0.0-ballot built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/HL7/fhircast-docs/ and changes regularly. See the Directory of published versions
Contents:
This page provides a list of the FHIR artifacts defined as part of this implementation guide.
These define constraints on FHIR resources for systems conforming to this implementation guide.
FHIRcast Content Update Bundle |
Defines the structure of a Bundle that carries content updates that are
communicated in FHIRcast |
FHIRcast Diagnostic Report for Open Events |
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 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 In FHIRcast deployments based on FHIR R5, the attribute Additionally FHIR R5 includes a |
FHIRcast DiagnosticReport for Close Events |
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 In FHIRcast deployments based on FHIR R5, the attribute Additionally FHIR R5 includes a |
FHIRcast Encounter for 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]-close events. |
FHIRcast Encounter for Open 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. |
FHIRcast Get Current Content Bundle |
Defines the structure of a Bundle that carries current content state
resulting from various FHIRcast |
FHIRcast ImagingStudy for Close Events |
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. |
FHIRcast ImagingStudy for Open Events |
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 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 Since this version of FHIRcast promotes the use of FHIR R4 resources, the guidance to provide the accession number in the 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. |
FHIRcast Observation |
Defines the minimum set of attributes which an application wanting to share observation content must support |
FHIRcast Patient for 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]-close events. |
FHIRcast Patient for Open 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. |
FHIRcast context for logout events. |
Contains the rationale behind the userLogout event |
FHIRcast context for userHibernate events. |
Contains the rationale behind the userHibernate event |
FHIRcastCapabilityStatement |
CapabilityStatment stating support for FHIRcast. 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. |
OperationOutcome for Hub generated sync-error events |
Defines the structure of an OperationOutcome to be used in sync-error events created by the Hub. |
OperationOutcome for Subscriber generated sync-error events |
Defines the structure of an OperationOutcome to be used in sync-error events send by a Suscriber indicting refusal to follow context. |
OperationOutcome for sync-error events |
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. |
These define constraints on FHIR data types for systems conforming to this implementation guide.
FHIRcast extension |
Extension in CapabilityStatement stating the location of the FHIRcast hub to be used with this FHIR server. |
These define sets of codes used by systems conforming to this implementation guide.
Reasons for sending a logout event. |
This valueset lists possible reasons a user logs out and send a logout event to other Subscribers. |
Reasons for sending a userHibernate event. |
This valueset lists possible reasons a hibernate event is send to other Subscribers. |
These define new code systems used by systems conforming to this implementation guide.
FHIRcast related Terminology. |
This codesystem defines terminology that is used within the FHIRcast specification. |
These are example instances that show what data produced and consumed by systems conforming with this implementation guide might look like.
FHIRcastCapabilityStatement-Example |
Example instance of a CapabilityStatement with FHIRcast extension. |
FHIRcastContentUpdateBundle-Example |
Example of a content update bundle |
FHIRcastDiagnosticReportClose-Example |
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 |
FHIRcastDiagnosticReportOpen-Example |
Example of a DiagnosticReport which could be used in a [FHIR resource]-open event |
FHIRcastEncounterClose-Example |
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 |
FHIRcastEncounterOpen-Example |
Example of an encounter which could be used in a [FHIR resource]-open event |
FHIRcastGetCurrentContentBundle-Example |
Example response to the get current context. |
FHIRcastHibernateContext-Example |
Example of FHIRcast hibernate event context. |
FHIRcastImagingStudyClose-Example |
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 |
FHIRcastImagingStudyOpen-Example |
Example of an imaging study which could be used in a [FHIR resource]-open event |
FHIRcastLogoutContext-Example |
Example FHIRcast logout event context. |
FHIRcastObservation-Example |
Example of a simple observation which could be exchanged using FHIRcast |
FHIRcastPatientClose-Example |
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 |
FHIRcastPatientOpen-Example |
Example of a patient which could be used in a [FHIR resource]-open event |
FhircastHubSyncErrorOperationOutcome-Example |
Example OperationOutcome as present in sync-error events |
FhircastSubscriberSyncErrorOperationOutcome-Example |
Example OperationOutcome as present in sync-error events |
ImagingStudyExample |
Placeholder resource representing an ImagingStudy |
OrganizationExample |
Placeholder resource representing an Organization. |
PatientExample |
Placeholder resource representing a Patient |
PractitionerExample |
Placeholder resource representing a Practitioner |