Radiation Dose Summary for Diagnostic Procedures on FHIR
1.0.0 - STU 1

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 1.0.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

## Architecture and Implementation

Page standards status: Informative

This chapter describes the different architecture aspects of the resources, profiles and actors identified within the IG.

1. Profiles & Extensions - FHIR Profiles and extensions defined in the IG
2. Actors - Actors participating in the IG
3. Terminology - Value Sets defined
4. Resources Identifiers - A focus on DICOM identifiers types
5. Conformance - A focus on the conformance with this IG
6. Security Consideration - Security aspects to be taken in consideration

### Profiles & Extensions

#### Resource Profiles

- Radiation Dose Summary profiles the Observation resource to provide the structure for the Radiation Dose Summary reporting.
- Radiation Summary Report profiles Composition resource and defines a report document describing the irradiation act.
- Indication Observation profiles Observation resource to provide the indications related to the performed procedure.
- Pregnancy Status (IPS) profiles Observation resource to provide the pregnancy status of the patient. The Pregnancy Status profile is defined within the International Patient Summary IG (IPS).
- Modality Device profiles Device resource to provide the specificity of a modality as a Device resource.

#### Supporting DataType Profiles

There is no special supporting DataType profiles defined by this IG.

#### Supporting Extensions

There is no special supporting extensions defined by this IG.

#### Profiles relationship

There are two levels or profiles:

- Radiation Observation profile: This profile allows for the description of a performed radiation act, summarizing the radiation report generated by the modality. See Radiation Dose Summary in the class diagram above.
- Radiation Report profiles: These profiles reference the radiation observation resources and enhance the collected information in a general radiation report by relating it to the patient's conditions and the procedure indications. See Radiation Summary Report, Indication Observation, and Pregnancy Status (IPS) in the class diagram above. The latter two profiles contain information collected before the patient's imaging procedure, explaining the two levels of 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.

### Actors

A list of actors are identified within this IG:

- Radiation Dose Summary Producer
- FHIR Server
- Radiation Dose Summary Consumer

#### Radiation Dose Summary Producer

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.

#### FHIR Server

The FHIR Server has two functions:

1. Provide the diagnostic procedure context to both the Radiation Dose Summary Producer and Consumer actors
2. Store the Radiation Dose Summary resources and Irradiation Event resources from the Radiation Dose Summary Producer actor

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:

1. Patient: the subject of the imaging study.
2. Device: the modality.
3. Practitioner: the irradiation authorizing persons responsible on the performed exams.
4. ImagingStudy: resources describing the performed exams.

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:

- FHIRServer-RDSP - Requirements for FHIR Server interacting with RDSP actor
- FHIRServer-RDSC - Requirements for FHIR Server interacting with RDSC actor
- FHIRServer - Requirements for FHIR Server actor

The FHIR Server SHALL follow the different security considerations mentioned in security section.

#### Radiation Dose Summary Consumer

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.

#### Actor grouping

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.

#### Actor communication

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.

### Terminology

#### Value Sets Defined

These Value Sets have been defined for this implementation guide.

1. Isotopes Value Set
2. Procedure Reported Type Value Set
3. Radiopharmaceuticals Value Set
4. Radiation Dose Summary component type

#### Value Sets Used

DICOM ValueSet links:

1. CID 4030 CT, MR and PET Anatomy Imaged
2. CID 4052 Phantom Devices
3. CID 33 Modality
4. CID 11 Route of Administration
5. CID 25 Radiopharmaceuticals
6. CID 4021 PET Radiopharmaceutical
7. CID 18 Isotopes in Radiopharmaceuticals
8. CID 4020 PET Radionuclide

#### Code Systems Defined

One new code system is defined under this IG:

1. DICOM Identifier Type

#### Code Systems Used

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

#### Value Sets strength

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

### Resources Identifiers

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 :

- Irradiation Event UID :

    "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"
        }
    ]

- Application Entity :

    "identifier": [
        {
            "type": {
                "coding": [
                    {
                        "system": "http://hl7.org/fhir/uv/radiation-dose-summary/CodeSystem/dicom-identifier-type",
                        "code": "application-entity",
                        "display": "Application Entity"
                    }
                ]
            },
            "value": "XA01"
        }
    ]

### Conformance

#### Conventions

This implementation guide uses specific terminology to flag statements that have relevance for the evaluation of conformance with the guide:

- SHALL indicates requirements that must be met to be conformant with the specification.
- SHOULD indicates behaviors that are strongly recommended (and which may result in interoperability issues or sub-optimal behavior if not adhered to), but which do not, for this version of the specification, affect the determination of specification conformance.
- MAY describes optional behaviors that are free to consider but where the is no recommendation for or against adoption.

#### Claiming Conformance

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.

#### Must Support

In the context of this IG, mustSupport on any data element SHALL be interpreted as follows:

- When creating Radiation Dose Summary content, implementers SHALL be capable of including mustSupport data elements.
- When receiving Radiation Dose Summary content, implementers:
  - SHALL be capable of processing resource instances containing mustSupport data elements without generating an error or causing the application to fail.
  - SHOULD be capable of displaying mustSupport data elements for human use, or processing (e.g., storing) them for other purposes.

### Security Consideration

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:

- Communications
- Authentication
- Authorization/Access Control
- Audit Logging
- Digital Signatures
- Security Labels
- Narrative

These security requirements are highlighted in the context of this IG:

- Systems SHALL keep audit logs of the various transactions. Some auditing workflows can be used like IHE ATNA or RESTful ATNA.
- Systems SHALL use TLS version 1.2 or higher for all transmissions not taking place over a secure network connection. IHE ATNA may be followed for the TLS usage.
- Systems SHALL conform to FHIR Communications Security requirements.
- Systems SHALL implement consent requirements per their country, state, local, and institutional policies.