Custom FHIR Resources Deﬁnition of Detailed Radiation Information

for Dose Management Systems

Abderrazek Boufahja

, Steven Nichols

and Vincent Pangon

GE Healthcare, Strasbourg, France

Keywords:

FHIR



, DICOM



, Dose, Radiation, RDSR.

Abstract:

Medical diagnostic imaging dose management systems aggregate and calculate irradiation dose generated

by acquisition modalities, collected through standardized methods such as DICOM



, HL7



or proprietary

interfaces. Irradiation dose information is valuable to multiple stakeholders, such as, general practitioners

(GP), nationalized dose registries, patient facing applications, and information systems, such as, the Radiology

Information System (RIS) or Electronic Health Record (EHR). For Medical Physicists, the radiation data is

used to perform patient cohort and statistical analysis as part of a dose management program. However, there is

no standardized, lightweight method to exchange the collected dose information with third party applications,

through RESTful APIs. In this paper, we deﬁne a methodology to expose the content of the Radiation Dose

DICOM



SR data models as custom HL7



FHIR



resources. This methodology leverages the strength of

FHIR



in deﬁning and exchanging resources, and the strength of the DICOM



SR data models, as their

structure is implemented, maintained, and tested by dozens of modality providers.

1 INTRODUCTION

In recent years, dose management systems have

played an increasingly important role within the ﬂeet

of applications inside hospitals, assisting in compli-

ance with regional and national regulations, and im-

proving the safety of irradiated patients (R. Loose,

2020). Dose management systems gather technical

information from modalities and demographic and

clinical observation data from other various facility

applications. Some dose management systems pro-

vide functionalities for the enhancement of dose in-

formation through calculations and analyzes, such as

effective dose calculation, organ dose, size speciﬁc

dose estimation (SSDE), etc. Where IHE proﬁles

and DICOM



speciﬁcations have been established

to normalize the exchange between modalities and

dose management systems (IHE, 2020b) (IHE, 2016),

there has been no standardization exposing the dose

information from the dose management systems to

third party applications through RESTful APIs. Such

exposure should include both the collected and en-

hanced data. In this paper, we ﬁrst describe the prob-

lem and the need for ”API-zation” of dose informa-

https://orcid.org/0000-0002-6481-2185

https://orcid.org/0000-0002-4873-1676

https://orcid.org/0000-0001-5031-8525

tion exposure. Then, we detail the methodology for

taking advantage of the rising HL7



FHIR



standard

(Fast Healthcare Interoperability Resources) (HL7,

2019). Finally, we perform a comparison between the

described methodology and another possible solution.

2 PROBLEM

The dose irradiation information is collected from

multiple sources. The most standardized structure

is the DICOM



Radiation Dose Structured Report

(RDSR) based structures. There are four RDSR struc-

tures allowing to expose the dose information and de-

ﬁned in PS3.16 of the DICOM



standard (DICOM,

2020c):

• X-Ray Radiation Dose SR

• CT Radiation Dose SR

• Radiopharmaceutical Radiation Dose SR

• Cone-beam CT Radiation Dose SR (WIP)

Each of these structures deﬁne a complete struc-

tured report of irradiation events. Radiation expo-

sure information can be collected from other kinds

of messages, as well. For instance, some modalities

share the dose information through MPPS messages.

Boufahja, A., Nichols, S. and Pangon, V.

Custom FHIR Resources Deﬁnition of Detailed Radiation Information for Dose Management Systems.

DOI: 10.5220/0010251104670474

In Proceedings of the 14th International Joint Conference on Biomedical Engineering Systems and Technologies (BIOSTEC 2021) - Volume 5: HEALTHINF, pages 467-474

ISBN: 978-989-758-490-9

467

Also, some DICOM



images contain relevant dose

information, like nuclear medicine images (R. Loose,

2020). The most structured deﬁnition of radiation ex-

posure information are RDSR DICOM



objects.

The IHE Radiology domain deﬁned two IHE inte-

gration proﬁles: REM (Radiation Exposure Monitor-

ing) (IHE, 2020b), and REM-NM (Radiation Expo-

sure Monitoring for Nuclear Medicine) (IHE, 2016).

The aim of these proﬁles is to deﬁne the actors in-

tervening in patient radiation exposure process, their

roles and the different transactions performed be-

tween them. REM proﬁles the X-Ray Radiation Dose

SR and the CT Radiation Dose SR; and REM-NM

proﬁles the Radiopharmaceutical Radiation Dose SR.

The aim of both integration proﬁles is to describe how

the dose information transits between modalities or

radiopharmaceutical activity suppliers and the dose

registry actors. During the process of sharing the dose

information with the dose registry, the dose consum-

ing actors may enhance the dose content with calcu-

lated information, like the effective dose, the organ

dose, or the size speciﬁc dose estimation methods.

Once the original and the enhanced dose informa-

tion are stored in the dose registry, which could be

a hospital based registry or a regional/national based

registry (IHE, 2020a), there is a need to expose the

radiation information to third parties in a lightweight

manner. Exposing the complete RDSR is useless for

most of the use cases:

• Most of the display applications need only few

parts of the RDSR

• Many third party applications are specialized in

speciﬁc dose information like the effective dose,

the organ dose, or the size speciﬁc dose estima-

tion. However, these applications cannot access

such speciﬁc dose information without retrieving

the entire RDSR.

• Backend applications performing cohort search

and measures need efﬁcient data structures to

query information within the RDSR

Partial exposure of the RDSR contents is needed.

However, there is no lightweight methodology facil-

itating access to the dose information content within

the RDSR from the dose management system to the

third party applications.

Many healthcare systems can beneﬁt from the

exposure of dose details from the dose reg-

istry/repository actors:

• Mobile applications: new dose related mobile

applications may beneﬁt from the exposure of

the information in the dose management systems.

Such applications could follow accumulated pa-

tient dose exposure in a multi-facility enterprise.

Figure 1: IHE REM/REM-NM proﬁles description.

• RIS: Radiology Information Systems may bene-

ﬁt by retrieving dose data for inclusion in the ﬁ-

nal imaging report, as mandated by multiple na-

tional/regional regulations promoting the sharing

of dose information (IHE, 2020a).

• EHR: Electronic Health Record systems can ben-

eﬁt from sharing dose information, as some utilize

manual entry of dose, and many do not support

the ingestion and analysis of DICOM



objects,

especially SR objects. A REST based API allows

simple integration of dose information within the

EHR system. Dose information can be provided

to practitioners for appropriate procedure selec-

tion during a diagnostic encounter.

• CQMS: Clinical Quality Management Systems

can beneﬁt from lightweight exposure of dose in-

formation, in order to provide different metrics for

a multitude of stakeholders. These metrics can

be used to compare facilities, patient cohorts, or

even, regional practices as part of a comprehen-

sive quality control program.

• Third party application backends: some third

party applications may use the exposed dose in-

formation for other uses. For example, technical

exposure factors of previously performed exams

for a speciﬁc patient can be used by the modality

operator to set parameters of the current exam.

• Third party dose registries: API based exposure

can facilitate reconciliation between multiple dose

registries implementing the same API.

The most widely used standard for exposing APIs

and resources in healthcare domain is FHIR



, which

ﬁts our problem well.

HEALTHINF 2021 - 14th International Conference on Health Informatics

468

3 STATE OF THE ART

3.1 Dose Summary on FHIR

An ongoing work item within the DICOM



WG-

20 and the HL7



O&O (Orders and Observations)

group analyses the speciﬁcation and the proﬁling of

the Dose Summary on FHIR



(DICOM, 2020a). The

aim of this working item is to describe the minimal re-

quired dose information within a normative resource

(likely the Observation resource), allowing commu-

nication of the accumulated dose information from

the performed procedure step, to provide a summary

overview of the patient dose exposure. This working

item will involve several activities, like the identiﬁca-

tion of the minimal dose information from various na-

tional regulations and recommendations, and the pro-

ﬁling of the Observation resource in order to integrate

the minimal dose information. The scope of the Dose

Summary on FHIR



is to share a summary of dose in-

formation by exam through FHIR



, which is different

than the scope of this analysis: sharing details of the

radiation administration, and sharing of the enhanced

data like SSDE and effective dose to third party appli-

cations.

3.2 DICOM SR to FHIR Mapping

Another ongoing work item is a mapping be-

tween DICOM



SR and FHIR



resources (DICOM,

2020b). The scope of this work item is to map key

SR templates and content into FHIR



resources. At

the time of this paper, the work item was concentrated

in the mapping of measurement TIDs (Template IDs:

TID1410, TID1411, and TID1420). There are two

explored solutions: Observation based solution, and a

CDA



based solution. The ﬁrst solution is describing

all elements inside the TIDs using the ”hasMember”

and ”component” attributes. The second solution is

to translate the SR into CDA



, following DICOM



PS3.20 (DICOM, 2020d). After CDA



mapping, a

translation between CDA



and FHIR



can be per-

formed using custom resources, following the project

Clinical Document Architecture V2.1 (HL7, 2020a).

The methodology is very interesting, as it allows the

direct mapping from SR templates to custom FHIR



resources. However, this is less relevant for DICOM



Radiation SR templates. In fact, in PS3.20, there is

only one CDA



section deﬁned, summarizing the pa-

tient dose exposure. This section is useful for the

Dose Summary on FHIR



work item; however, it is

not useful for a detailed mapping between DICOM



RDSRs and FHIR



resources.

3.3 DICOM SR and FHIR

Representations for Imaging

Measurements

An analysis was performed within the 30th Project

Week event, in order to convert the TID 1500 - Mea-

surement Report, to FHIR



resources (H. Meine,

2019). The working team concluded that the FHIR



resources should be used to store only the most rele-

vant information, and to keep DICOM



as main stor-

age format. A python based project is shared in a

GitHub repository to describe the different samples

and code used to generate the FHIR



resources. From

the samples provided, the targeted mapping between

TID 1500 and FHIR



is based on combination be-

tween the resources DiagnosticReport, Observation

and ImagingStudy.

4 METHODOLOGY

4.1 Apization of DICOM Radiation SR

The best way to expose detailed radiation informa-

tion through an API is to combine the strength of

FHIR



(HL7, 2019) (T. Benson, 2016), and the sta-

ble structure of the RDSRs coming from PS3.16

(DICOM, 2020c). HL7



FHIR



provides a strong

API model and capabilities for searching and ex-

posing resources, like indexing and searching oper-

ations. The FHIR



community has published nu-

merous open source tools, simplifying any integration

with a FHIR



server, and simplifying the creation

of FHIR



servers. FHIR



also comes with deﬁned

primitive and complex types, ready for use. Compar-

ing to proprietary APIs, FHIR



facilitates conception

of custom resources and the proﬁling of existing re-

sources, which reduces the time to production. In

fact, many open source applications exist, facilitat-

ing the proﬁling of FHIR



resources. Examples in-

clude FHIR



Shorthand / Sushi (HL7, 2020b), SIM-

PLIFIER.NET (K. Gopinathan, 2018), and FHIR



publisher tool (HL7, 2020d). For custom resources,

HL7



provides FHIR



spreadsheet authoring, an Ex-

cel or OpenOfﬁce structure for designing FHIR



data

types, resources, and proﬁles (HL7, 2020c).

DICOM



PS3.16 provides a complete deﬁnition

of each RDSR type, with a clear deﬁnition of con-

tent items, cardinality, data type, format, and con-

straints. The structure of the RDSRs have been de-

ﬁned since 2004 and tested hundreds of times during

testing events like IHE Connectathons, or directly in

production. Their structure has evolved over the years

Custom FHIR Resources Deﬁnition of Detailed Radiation Information for Dose Management Systems

469

but can be considered as having a stable structure and

content.

Our methodology takes advantage of both stan-

dards: we deﬁned FHIR



resources using the ele-

ments and the structures deﬁned in PS3.16 of the

DICOM



standard. For each deﬁned container in the

DICOM



RDSR structure, a custom FHIR



resource

is deﬁned. For each container, a list of rules is fol-

lowed to create the custom resource. A custom re-

source may also be a subset of a container deﬁning a

node with a considerable number of nested levels.

4.2 Mapping between Dose SR and

FHIR Resources

Each Dose SR can be described as a tree of different

TIDs. Each TID can be a container of elements, or a

tree of containers. Each container is described in the

deﬁned API as a custom FHIR



resource. For exam-

ple: TID 10003 (Irradiation Event X-Ray Data) (DI-

COM, 2020c) describes the container with the iden-

tiﬁer EV (113706, DCM, ”Irradiation Event X-Ray

Data”).

For a speciﬁc dose container, a custom resource

is created. A container is not always described by a

TID. In fact, a TID can describe multiple containers as

well as a subset of a container. This nuance is impor-

tant for the deﬁnition of the FHIR



custom resources.

Let’s consider for example the CT Radiation Dose SR

IOD Templates. The ﬁgure 2 describes the TIDs re-

lationship, and the ﬁgure 3 describes the containers

relationship, within the same IOD.

Figure 2: CT Radiation Dose SR IOD TIDs relationship.

Figure 3: CT Radiation Dose SR IOD containers relation-

ship.

We note that the tree of containment is not the

same. Containers relationship is better suited as unit

for FHIR



resources deﬁnition than the DICOM



TIDs. In fact, the containers have a better granular-

ity than TIDs and can be shared independently from

the rest of the structured report. Example: in TID

10013, CT Acquisition parameters may be shared be-

tween multiple RDSRs generated by the same modal-

ity.

The ﬁgure 4 describes the workﬂow used to deﬁne

custom resources based on the identiﬁed container.

Figure 4: Workﬂow to deﬁne custom FHIR



resources

from Radiation DICOM



templates.

The ﬁrst step is to name the custom resource. The

name is based on the code used to identify the con-

tainer. Each custom resource contains two kinds of

elements: contextual elements and standardized ele-

ments. The second step is to deﬁne contextual ele-

ments. They are deﬁned based on the contextual us-

age of the resource. Contextual elements describe the

context of the resource, such as encounter informa-

tion, patient identiﬁcation, performed exam identiﬁ-

cation, exam description, and exam date.

The third step is to identify the standardized ele-

ments, their cardinalities, datatypes, and constraints.

For each content item in the TIDs, an element or a

sub-element in the FHIR



custom resource is created.

We applied the following rules:

• The concept name deﬁnes the name of the FHIR



element, using the name of the attribute in lower

camel case. Example: the content item with the

HEALTHINF 2021 - 14th International Conference on Health Informatics

470

value EV (113764, DCM, ”Acquisition Plane”) is

transformed into element with the name ”acquisi-

tionPlane”.

• The level of the content item is respected, i.e. the

Nesting Level (NL) in the parent container is the

same as in the custom FHIR



resource.

• The relationship with parent is ignored.

• The VT (Value Type) is mapped with its cor-

responding primitive or complex types. Table

1 describes the mapping between VT types and

FHIR



datatypes.

• The Value Multiplicity (VM) and Requirement

Type (Req Type) deﬁne the cardinality of the el-

ement in the deﬁned custom resource. The cardi-

nality of the FHIR



elements is based on the com-

bination of the values of both VM and require-

ment type. The table 2 describes the mapping

to FHIR



cardinalities as identiﬁed by our anal-

ysis. This table was partially described in PS3.16,

paragraph ”6.1.7 - Requirement Type” (DICOM,

2020c).

• The value set constraints can deﬁne:

– The list of supported value sets if the element is

a CodeableConcept

– The unit of the element if it is of type quantity

• The Condition column deﬁnes the constraints re-

lated to the custom resource elements

Table 1: Mapping between VT values and FHIR



Datatypes.

VT values FHIR



Datatypes

CODE CodeableConcept

UIDREF string

TEXT string

DATETIME dateTime

NUM integer k decimal k quantity

IMAGE string

Table 2: Mapping between VM and Req type values, and

FHIR



Cardinalities.

VM Req Type FHIR



Card

1 M 1..1

1 U 0..1

1 MC 0..1

1-n M 1..*

1-n U 0..*

1-n MC 0..*

This methodology can be used to generate custom

resources for any kind of SR template, not only dose

information templates.

5 RESULTS

5.1 Custom Dose Resources Deﬁnition

The described methodology allowed the deﬁnition of

custom resources for the different Dose SRs. The

different custom resources are deﬁned using FHIR



spreadsheet authoring structure, allowing generating

a Dose Implementation Guide (IG) by leveraging the

FHIR



IG publisher tool. The generated IG facili-

tates communication with third parties as it follows

the FHIR



IG publisher style. Let’s take the exam-

ple of the TID 10011: CT Radiation Dose. Figure 5

describes the structure of this TID as described in the

DICOM



standard, PS3.16 (DICOM, 2020c).

Figure 5: TID 10011 - CT Radiation Dose.

This TID contains a parent container item, which

translated then into a custom FHIR



resource. Figure

6 shows the mapping between the TID items and the

FHIR



resource elements.

Figure 6: Custom FHIR



resource for the TID 10011 - CT

Radiation Dose.

Note there are two parts: the contextual elements

and the standardized elements. In this example, the

contextual elements are: identiﬁers of the resource,

serviceRequest, imagingStudy, encounter, and pa-

tient. This information deﬁnes the context on which

the CT radiation dose was deﬁned, and the different

related stakeholders.

The second part of the resource is the standard-

Custom FHIR Resources Deﬁnition of Detailed Radiation Information for Dose Management Systems

471

ized elements as deﬁned in the DICOM



standard and

TID 10011. For example, the sourceOfDoseInforma-

tion is taken from the TID 10011, CT Radiation Dose,

under the content item number 12 (DICOM, 2020c),

and identiﬁed by EV (113854, DCM, ”Source of Dose

Information”). In the DICOM



standard, the related

content item has the Value Multiplicity (VM) of 1-n,

and the Requirement Type to ’M’; this is translated

to a FHIR



cardinality of 1..n in the custom resource,

based on the table 2 of mapping of cardinalities. In the

Content Item, VT is ’CODE’ with a deﬁned value set

CID 10021 ”Source of CT Dose Information”, trans-

lated to the CodeableConcept from FHIR



datatypes.

Note that the nested levels are respected inside the

deﬁned custom resource and the usage of the sum-

mary marker in the deﬁned custom resource. This al-

lows summary of the resource and a lightweight query

to the dose management system when possible. The

identiﬁcation of elements that need to be part of the

summary resource depends on the deﬁned resource.

5.2 Comparison between Custom FHIR

Resources and Observation based

Solution

In this paper, we adopted a custom FHIR



resources

solution; however, there is another possible solution

to describe the different containers inside the RDSRs,

which is the Observation based solution. This solu-

tion is referenced in the DICOM



SR to FHIR



map-

ping working item from Imaging Integration WG (DI-

COM, 2020b). To proﬁle dose SR through Observa-

tion resource, here are the steps that can be followed:

• When a content item is describing a container, or

has nested content items, or has the cardinality 1-

n, it shall be described as an independent observa-

tion.

• This observation shall follow these rules:

– Its code element shall follow the code from

DICOM



content item deﬁnition

– If it does not have nested content items, it shall

have a value element and no components

– If it has nested content items, it may have ”has-

Member” and component elements.

∗ If a nested content item is translated into Ob-

servation, it shall be referenced in the ”has-

Member” element

∗ If the nested content item is not translated

into observation resource, a component ele-

ment needs to be deﬁned, with a slicing using

the code identiﬁer of the content item.

Following these rules, an example of proﬁling the

Observation resource to cover the CT Radiation Dose

is described in the picture 7. We used FHIR



Short-

hand for the proﬁling process (HL7, 2020b).

Figure 7: CT Radiation Dose proﬁled through Observation

resources.

This proﬁling allows description of the CT radi-

ation dose contents inside an Observation resource,

with three additional nested Observation resources.

Even if the same data elements are described in this

structure of resource, the complexity of the structure

is higher in the Observation based solution compared

to the custom resources based solution: four Obser-

vation resources are used instead of one custom re-

source. Also, the use of component instead of custom

elements increases the complexity of searching of the

data inside the resource. For instance, collecting the

endOfXRayIrradiation is less complex in the custom

resource than in the Observation based resources. The

table 3 compares the characteristics of each solution.

The following metrics describes the improve-

ments between custom resource solution and an ob-

servation based solution. A sample of 500 resources

were selected, 250 custom resources and 250 Obser-

vation resources, describing the same CTRadiation-

Dose data. Four metrics were analyzed:

• The number of characters generated (describing

the network footprint)

• The number of lines generated in pretty format

(describing the complexity of the structure)

• The response time from the hosting server

• The laps of time to perform a marshalling from

JSON to Java

We calculate the average of the metrics for each

solution and we divide the value found for custom re-

sources by the value found for Observation resources.

HEALTHINF 2021 - 14th International Conference on Health Informatics

472

Table 3: Custom resources vs Observation based resources.

Custom

resource

solution

Observation

based so-

lution

Small network footprint X X

Ease of interpretation by

tools

X X

Supports ” summary”

option

X X

Lower processing foot-

X X

Human readability X X

Less concepts manage-

ment

X X

Semantic/meaning of the

resource

X X

Ease of EHR integration X X

Ease of speciﬁcation X X

Figure 8: FHIR



custom resources VS Observation based

resources performance.

The metrics analysis demonstrates an average of

20% improvement with custom resources compared

to the Observation resources. The better network

footprint results from a fewer number of exchanged

characters compared to the Observation resources.

The number of lines is also smaller in custom re-

sources versus Observation resources (an improve-

ment of 30%); this explains the better server response

time and marshalling time for custom resources.

Custom resources support the deﬁnition of ele-

ments as summary elements, which also allows im-

provement in the network footprint, in some use

cases. In custom resources, there is no need to main-

tain identifying concepts of components and codes of

observations. Also, as radiation information is not a

typical observation, we estimate that the meaning of

the custom resource is more appropriate than in ob-

servation based resources.

A major advantage of using the observation based

solution is the ease of integration with existing EHRs.

In fact, most EHRs supporting FHIR



already include

FHIR



server, and integrating a proﬁled observation

resource is much easier than integrating a custom re-

source, which may need additional effort by the EHR

providers. For instance, US Core (HL7, 2020e) is us-

ing the Observation resource to proﬁle many health-

care data like patient BMI, heart rate, body temper-

ature, etc.; this proﬁling simpliﬁes the adoption by

EHRs. From speciﬁcation perspective, FHIR



re-

sources proﬁling is easier than deﬁning custom re-

sources, as there are many tools allowing to pro-

ﬁle FHIR



resources like FHIR



Shorthand (HL7,

2020b) or SIMPLIFIER.NET (K. Gopinathan, 2018).

6 CONCLUSION

In this paper, we described our methodology for de-

tailing dose information through custom FHIR



re-

sources. This methodology takes advantages of both

the FHIR



and DICOM



standards: from one, it

takes advantage of the normalization of resources ex-

change, basic datatypes, and existing tooling; from

the other, it takes advantage of the stability of struc-

tures deﬁned within the RDSR templates. This

methodology brings added value to dose management

systems, especially through third party applications.

The deﬁned methodology opens new perspectives for

dose management systems to integrate with hospital

ecosystem, as a provider of enhanced dose data, and

not simply as a consumer of dose information from

modalities. This methodology proves its strengthen

in multiple aspects compared to an Observation based

solution. The exposition of the dose resources im-

proves the communication by normalizing data ex-

change between applications, and simplifying the in-

tegration with patient facing applications, or business

intelligence programs. Although the methodology

proved its strengthen and its multiple possible appli-

cations, an effort to normalize the different custom re-

sources needs to be performed with a greater level of

FHIR



community participation, for standardization

and adoption.

ACKNOWLEDGEMENTS

We acknowledge strong GE Healthcare support dur-

ing this study from Performance Intelligence Analyt-

ics and DoseWatch engineering team.

Custom FHIR Resources Deﬁnition of Detailed Radiation Information for Dose Management Systems

473

REFERENCES

DICOM, I. I. (2020a). Dose Summary on FHIR.

https://conﬂuence.hl7.org/display/IMIN/Dose+

Summary+on+FHIR. Accessed: 2020-11-22.

DICOM, I. I. (2020b). Mapping of DICOM SR

to FHIR. https://conﬂuence.hl7.org/display/IMIN/

Mapping+of+DICOM+SR+to+FHIR. Accessed:

2020-09-28.

DICOM, S. C. (2020c). DICOM Standard PS3.16 2020c -

Content Mapping Resource. NEMA.

DICOM, S. C. (2020d). DICOM Standard PS3.20 2020c,

Imaging Reports using HL7 Clinical Document Archi-

tecture. NEMA.

H. Meine, Oppermann P., e. a. (2019). ProjectWeek:

Roundtrip conversion between DICOM SR and FHIR

representations for imaging measurements. https:

//projectweek.na-mic.org/PW30 2019 GranCanaria/

Projects/DICOMSRTID1500-FHIR/. Accessed:

2020-09-28.

HL7 (2019). FHIR (Fast Healthcare Interoperability Re-

sources) Speciﬁcation. HL7, release 4 edition.

HL7 (2020a). Clinical Document Architecture V2.1.

https://build.fhir.org/ig/HL7/cda-core-2.0/. Accessed:

2020-09-28 - continuous build for version 2.1.0.

HL7 (2020b). FHIR Shorthand. https://build.fhir.org/ig/

HL7/fhir-shorthand/. Accessed: 2020-09-28 - contin-

uous build for version 1.0.0.

HL7 (2020c). FHIR Spreadsheet Authoring.

https://conﬂuence.hl7.org/display/FHIR/FHIR+

Spreadsheet+Authoring. Accessed: 2020-09-28.

HL7 (2020d). IG Publisher documentation.

https://conﬂuence.hl7.org/display/FHIR/IG+

Publisher+Documentation. Accessed: 2020-09-

28.

HL7 (2020e). US Core Implementation Guide STU3, v3.1.1

edition.

IHE, R. (2016). Technical Framework Supplement, Ra-

diation Exposure Monitoring for Nuclear Medicine

(REM-NM). IHE, rev. 1.1 edition.

IHE, R. (2020a). Appendices to Integration Proﬁles, Ap-

pendix I: Deployment of Dose Registries. IHE, rev. 19

edition.

IHE, R. (2020b). Technical Framework Volume 1, Radiation

Exposure Monitoring (REM). IHE, rev. 19 edition.

K. Gopinathan, NA. Kaloumenos, e. a. (2018). FHIR FLI:

An Open Source Platform for Storing, Sharing and

Analysing Lifestyle Data. ICT4AWE.

R. Loose, E. Vano, e. a. (2020). Radiation dose manage-

ment systems - requirements and recommendations

for users from the ESR EuroSafe Imaging initiative.

European Radiology.

T. Benson, G. G. (2016). Principles of Health Interoper-

ability. Springer, Cham.

HEALTHINF 2021 - 14th International Conference on Health Informatics

474