Radiation Dose Summary for Diagnostic Procedures on FHIR
0.1.0 - ci-build
Radiation Dose Summary for Diagnostic Procedures on FHIR
0.1.0 - ci-build
Radiation Dose Summary for Diagnostic Procedures on FHIR, published by HL7 International / Imaging Integration. This guide is not an authorized publication; it is the continuous build for version 0.1.0 built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/HL7/fhir-radiation-dose-summary-ig/ and changes regularly. See the Directory of published versions
This chapter describes the different architecture aspects of the resources, profiles and actors identified within the IG.
There is no special supporting DataType profiles defined by this IG.
There is no special supporting extensions defined by this IG.
There are two levels or profiles:
A general Radiation Dose Summary provides a summary of an irradiation act related to a performed procedure and specific equipment. This profile allows the reporting of radiation data as structured text within its valueString element. The structure of the text included in valueString is site-dependent.
Radiation Dose Summary profiles are using the component element to describe the different parameters of the radiation procedure. We consider that the attributes of the components in the radiation summary resources are part of the resource itself when provided, which cannot be understood without reading the complete different components. Having different Observations referenced in multiple hasMember elements is not useful, as the interpretation of the radiation dose summary resource needs to access to all the different parameters of the radiation procedure.
A list of actors are identified within this IG:
The Radiation Dose Summary Producer (RDSP) is responsible for creating the Radiation Dose Summary observation and sharing it with the FHIR Server. The RDSP should synchronize multiple resources with the FHIR Server to avoid duplicating resources. For example, the RDSP should verify if the patient already exists in the FHIR Server; if the patient does exist, only a reference to the patient should be created. In this case, the POST bundle to the FHIR Server should not contain a Patient resource.
Generally, this actor can be implemented within a Dose Management System.
The RDSP should implement the following CapabilityStatement: RDSP capability statement.
The RDSP actor SHALL adhere to the security considerations in the security section. Sharing PHI shall comply with the local security requirements of the deploying facility.
The FHIR Server has two functions:
Thus, the FHIR Server can be divided in fact in two sub-actors: one to provide the contextual resources, and one for the Radiation Dose resources.
The contextual resources are resources managed by the FHIR Server and related to the imaging procedure, and works as a source of truth for these resources:
When these resources are not present in the FHIR Server, the Radiation Dose Summary Producer can complement the FHIR Server by creating observations from the RDSRs and images collected from modalities.
The FHIR Server is a logical actor which could be part of an EHR related to the patient care. Also, it can be part of the Dose Management System, used to expose radiation summary to third party consumers.
The FHIR Server can implement the following CapabilityStatements:
The FHIR Server SHALL follow the different security considerations mentioned in security section.
The Radiation Dose Summary Consumer (RDSC) actor is responsible for retrieving the Radiation Dose Summary observation (e.g., a RIS or EHR may enhance the final radiology report with radiation information).
Specialized expertise is required to understand radiation dose data. The interpretation of the radiation information collected by the Radiation Dose Summary Consumer shall follow the local policies and jurisdictional requirements to avoid misuse.
The RDSC actor can implement the following CapabilityStatement: RDSC capability statement.
The RDSC actor SHALL follow the different security considerations mentioned in security section. Collection of Data from the FHIR Server SHALL follow consent requirements used within the deploying facility, as described in security section.
The FHIR Server can be grouped with the Radiation Dose Summary Producer actor within the Dose Management System. Thus, the Dose Management System is managing all the resources and references between resources. Another possible grouping is between the FHIR Server and the Radiation Dose Summary Consumer actor (e.g., within EHR systems or RIS/EHR systems). In this case, the source of truth for contextual resources are independent from the Radiation Dose Summary Producer.
The following sequence diagram describes the typical workflow between the RDSP actor, the FHIR Server, and the RDSC actor.
In this workflow, a patient undergoes an irradiating study (including a nuclear medicine administration). The detailed radiation information is shared with the Radiation Dose Summary Producer actor, which may be a Dose Management System. During the process of creating the Radiation Dose Summary resources, the RDSP actor makes queries to the FHIR Server in order to collect the correct IDs to be referred in the newly created resources (i.e., Patient, Practitioner, Modality, and ImagingStudy resources). Many of these resources can be found within the DICOM RDSR provided by the modality. Some identifiers within the RDSR can be used for querying the FHIR Server. Below is a mapping illustrating the relationship between the FHIR resources and the DICOM identifiers:
| FHIR Resource | Identifier from DICOM |
|---|---|
| Patient | tag(0010,0020) Patient ID |
| Practitioner | TID 1020(Person Participant).EV (113871, DCM, Person ID) |
| ImagingStudy | tag(0020,000D) Study Instance UID |
| Device | tag(0018,1000) Device Serial Number |
The IDs collected are used to construct the Radiation Dose Summary resources and their related Irradiation Event resources. Then, these resources are shared with the FHIR Server through a POST of a bundle. The bundle may contain temporary resources related to Patient, ImagingStudy, and other contextual resources, if the FHIR Server has no reference of them.
Once the resources are shared with the FHIR Server, the Radiation Dose Summary Consumer can search and retrieve the resources from the FHIR Server. The RDSC actor can optionally enrich the FHIR Server resources by posting a Composition document as profiled by the Radiation Summary Report profile.
These Value Sets have been defined for this implementation guide.
DICOM ValueSet links:
One new code system is defined under this IG:
This implementation guide draws on a number of formal code systems.
The following table presents the external code systems (and naming conventions) adopted in this implementation guide:
| Code System Key | Code System Name | Code System | Application |
|---|---|---|---|
| LOINC | Logical Observation Identifiers Names and Codes | http://loinc.org | Observation and laboratory codes |
| SNOMED CT | Systematized Nomenclature of Medicine Clinical Terms | http://snomed.info/sct | Procedures, anatomy, products, isotopes |
| DCM | DICOM | http://dicom.nema.org/resources/ontology/DCM | Devices, products, radiation information |
The following table summarizes the mapping between defined profiles and Value sets strength:
| Profile | Element path | Value Set | Strength | Strength Justification |
|---|---|---|---|---|
| Modality Device | type | CID 33 Modality | required | VS contains the exhaustive list of modality types |
| Radiation Dose Summary | component.code | Components’ Code for Radiation Dose Summary | extensible | to keep the possibility to extend the list of reported components |
| Radiation Dose Summary | component:procedureReported | Procedure Reported Type Value Set | required | procedure reported component is the differentiator of irradiation type |
Many profiles defined in this IG are using DICOM IDs and UIDs as identifiers for the resources. In this paragraph, we summarize the different IDs and UIDs used, and the way they should be exposed in FHIR resources:
| Profile | Identifier | Identifier.system | Identifier.type.code | Identifier.type.system | Identifier.type.display | DICOM Tag Mapping |
|---|---|---|---|---|---|---|
| Modality Device | identifier:deviceSerialNumber | SNO | HL7 IdentifierType | Serial Number | (0018,1000) Device Serial Number | |
| Modality Device | identifier:aeTitle | application-entity | DICOM Identifier Type | Application Entity | N/A | |
| Modality Device | identifier:deviceUID | urn:dicom:uid | device-uid | DICOM Identifier Type | Device UID | (0018,1002) Device UID |
| Modality Device | identifier:deviceID | device-id | DICOM Identifier Type | Device ID | (0018,1003) Device ID | |
| Radiation Dose Summary | identifier:radiationSRUID | urn:dicom:uid | sop-instance-uid | DICOM Identifier Type | SOP Instance UID | (0008,0018) SOP Instance UID |
| Radiation Dose Summary | partOf.identifier | urn:dicom:uid | study-instance-uid | DICOM Identifier Type | Study Instance UID | (0020,000D) Study Instance UID |
| Radiation Dose Summary | basedOn.identifier | ACSN | HL7 IdentifierType | Accession ID | (0008,0050) Accession Number |
Following the notes within the ImagingStudy resource - When encoding a DICOM UID in an Identifier datatype, use the Identifier system of “urn:dicom:uid” - the identifiers related to DICOM tags having the Value Representation (VR) of type UID, shall have the type.system=urn:dicom:uid.
Here some examples :
"identifier": [
{
"type": {
"coding": [
{
"system": "http://hl7.org/fhir/uv/radiation-dose-summary/CodeSystem/dicom-identifier-type",
"code": "irradiation-event-uid",
"display": "Irradiation Event UID"
}
]
},
"system": "urn:dicom:uid",
"value": "urn:oid:1.2.840.121.3.32.0.1.1323423.2"
}
]
"identifier": [
{
"type": {
"coding": [
{
"system": "http://hl7.org/fhir/uv/radiation-dose-summary/CodeSystem/dicom-identifier-type",
"code": "application-entity",
"display": "Application Entity"
}
]
},
"value": "XA01"
}
]
This implementation guide uses specific terminology to flag statements that have relevance for the evaluation of conformance with the guide:
Actors and Systems asserting conformance to this implementation guide have to implement the requirements outlined in the corresponding capability statements. The following definition of MUST SUPPORT is to be used in the implementation of the requirements.
In the context of this IG, mustSupport on any data element SHALL be interpreted as follows:
Exchanging Radiation summary resources makes use of patient-specific information which could be exploited by malicious actors resulting in exposure of patient data. For these reasons, all data exchange between the different actors must be secured appropriately with access to limited authorized individuals, data protected in transit, and appropriate audit measures taken.
Implementers SHOULD be aware of these security considerations associated with FHIR transactions, particularly those related to:
These security requirements are highlighted in the context of this IG:
IG © 2020+ HL7 International / Imaging Integration. Package hl7.fhir.uv.radiation-dose-summary#0.1.0 based on FHIR 4.0.1. Generated 2024-07-10
Links: Table of Contents |
QA Report
| Version History |
|
Propose a change