This page is part of the Radiation Dose Summary for Diagnostic Procedures on FHIR (v0.1.0: STU 1 Ballot 1) based on FHIR R4. . For a full list of available versions, see the Directory of published versions

Architecture and Implementation

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. Must Support - A focus on Must Support usage in 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 base for the Radiation Dose Summary reporting.
  • CT Radiation Dose Summary profiles the Observation resource by extending the Radiation Dose Summary profile with minimal dose information related to CT procedures.
  • X-Ray Radiation Dose Summary profiles the Observation resource by extending the Radiation Dose Summary profile with minimal dose information related to X-Ray procedures (XA, RF, MG, etc.).
  • Radiopharmaceutical Radiation Dose Summary profiles the Observation resource by extending the Radiation Dose Summary profile with minimal dose information related to nuclear medicine imaging procedures.
• Irradiation Event Summary profiles the Observation resource in order to describe minimal dose information related to irradiation events.
  • CT Irradiation Event Summary profiles the Observation resource by extending Irradiation Event Summary profile, and adding minimal dose information related to CT Irradiation Events.
• 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 specificities 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 profiles: these profiles allow describing a performed radiation act, as seen from modality perspective. They summarize the radiation report generated by the modality. These radiation observation profiles are Radiation Dose Summary, CT Radiation Dose Summary, X-Ray Radiation Dose Summary, Radiopharmaceutical Radiation Dose Summary, Irradiation Event Summary, and CT Irradiation Event Summary (they are presented in green 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, with relationship to the patient conditions and the procedure indications. These reporting profiles are Radiation Summary Report, Indication Observation, and Pregnancy Status (IPS). The two latter profiles contain information collected before patient imaging procedure, which explain the two levels of profiles.

A general Dose Summary profile is defined, and extended by three different Profiles:

• CT Dose Summary Profile
• X-Ray Dose Summary Profile
• NM Dose Summary Profile

These extensions follow DICOM standard, which had already defined three types of structured report templates, related to each one of these profiles:

• CT Radiation Dose SR IOD Templates
• X-Ray Radiation Dose SR IOD Templates
• Radiopharmaceutical Radiation Dose SR IOD Templates

A general Irradiation Event profile is defined, and extended by on profile: CT Irradiation Event. Following the analysis of different national and regional recommendations, only a need for CT Irradiation event profiling was found, the details of X-Ray and NM irradiations events were not highlighted as needed during a radiation summary report. Thus, no Profiles related to X-Ray and NM irradiation events were created.

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

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 sharing performed from the Producer actor

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:

1. The Patient resources: the patients having exams.
2. The Device resources: the modalities participating in the irradiation of the patients.
3. The Practitioner resources: the irradiation authorizing persons responsible on the performed exams.
4. The ImagingStudy resources: resources describing the performed exams.

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

Radiation Dose Summary Consumer

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.

• RIS systems can act as consumer actor, in order to enhance the final radiology report with radiation information.
• Clinical Decision Support tools can use these radiation resources to feed their algorithms.
• Clinical Quality Information tools can use these radiation resources to perform analyzes on radiations information, and provide metrics related to patients cohorts, or devices comparison, or limit values calculations, etc.
• Other consumers may act as a light Dose registry, by collecting the radiation summary information for a patient or a group of patients in a regional or national infrastructure. Such registries can create valuable data for regulations purpose, or for population radiation estimations.

The RDSC actor can implement the following CapabilityStatement: RDSC capability statement.

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

Actors communication

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.

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
5. Irradiation Event 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
CT Irradiation Event Summary	bodySite	CID 4030 CT, MR and PET Anatomy Imaged	extensible	Following DICOM TID 10013
CT Irradiation Event Summary	component:ctdiPhantomType	CID 4052 Phantom Devices	extensible	Following DICOM TID 10013
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
Radiopharmaceutical Radiation Dose Summary	component:radiopharmaceutical	Radiopharmaceuticals Value Set	extensible	Following DICOM TID 10022
Radiopharmaceutical Radiation Dose Summary	component:radioisotope	Isotopes Value Set	extensible	Following DICOM TID 10022
Radiopharmaceutical Radiation Dose Summary	component:routeOfAdministration	CID 11 Route of Administration	preferred	Following DICOM TID 10022
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

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
Irradiation Event Summary	identifier:irradiationEventUID	urn:dicom:uid	irradiation-event-uid	DICOM Identifier Type	Irradiation Event UID	(0008,3010) Irradiation Event UID
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"
    }
]

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.