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 Imaging Integration Working Group. This is not an authorized publication; it is the continuous build for version 0.1.0). 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 profile is defined. It provides a summary of an irradiation act, related to a performed procedure and a specific equipement. This profile allows to report the radiation data as a structured text following its valueString element. The structure of the text included in valueString is site dependent.
A general Irradiation Event Summary profile is defined. It provides an overview of an irradiation event, related to a perforemd procedure and a specific equipment. Following the analysis of different national and regional recommendations, only a need for CT irradiation events data was found, the details of X-Ray and NM irradiations events were not highlighted as needed during a radiation summary report.
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) actor is responsible on the creation of the Radiation Dose Summary observation, and sharing it with the FHIR Server. The RDSP actor shall consider synchronizing with the FHIR server multiple resources, in order to avoid duplicating resources in the FHIR server. For example, the RDSP actor shall check if the patient already exists in the FHIR server, and if so, only a reference to this patient is created, and the POST bundle from the RDSP actor to the FHIR server shall not contain a Patient resource. Generally, this actor can be implemented within a Dose Management System.
The RDSP actor can implement the following CapabilityStatement: RDSP capability statement.
The RDSP actor SHALL follow the different security considerations mentionned in security section. Sharing PHI SHALL follow the security regulations followed by the deploying facility.
The FHIR Server has two functions:
Thus, the FHIR server can be divided in fact in two sub-actors: one for 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 take the responsibility on alimenting the FHIR server with these resources, by creating them from the RDSRs and images collected from modalities.
The FHIR Server is a logical actor which could be part of an EMR 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 mentionned in security section.
The Radiation Dose Summary Consumer (RDSC) actor is responsible on the collection and interpretation of the Radiation Dose Summary observation. There are many ways to use the Radiation Dose Summary resources, and it depends on the consumer.
Expertise is needed to understand the radiation dose data. The interpretation of the radiation information collected by the Radiation Dose Summary Consumer shall follow the facility regulations and workflows, in order to avoid misuse.
The RDSC actor can implement the following CapabilityStatement: RDSC capability statement.
The RDSC actor SHALL follow the different security considerations mentionned 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. This can happen for example within EMR 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.
During this workflow, a patient arrives to the hospital and performs an exam within an irradiating modality, or including a nuclear medicine administration. The detailed radiation information is shared with the Radiation Dose Summary Producer actor, which may generally be a Dose Management System. During the process of creating the Radiation Dose Summary resources, the RDSP actor performs a list of queries to the FHIR server, in order to collect the right IDs to be referred in the newly created resources. For instance, the RDSP actor shall collect the corresponding IDs for the Patient, the Practitioner, the Modality, and the ImagingStudy resources. Most of these resources can be identified from the DICOM RDSR shared from the modality. Some unique identifiers within the RDSR can be used to query the FHIR server. Here is a mapping between the FHIR resources and the identifiers from DICOM:
| 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 and use them for their own purposes. 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 |
|---|---|---|---|---|
| Irradiation Event Summary | component.code | Components’ Code for Irradiation Event | extensible | to keep the possibility to extend the list of reported components |
| 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 distinguisher 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 Imaging Integration Working Group. Package hl7.fhir.uv.radiation-dose-summary#0.1.0 based on FHIR 4.0.1. Generated 2023-08-14
Links: Table of Contents |
QA Report
| Version History |
|
Propose a change