Implementation Guide BBS version 1.0.0-alpha.2

This IG is currently under development and can not be considered stable and ready for use. For questions and change requests regarding this IG, please create a ticket in BITS.

1 Introduction

1.1 Background

In 2018, the Dutch Association for Radiologists (NVvR) and the Dutch Association for Health Providers (VZVZ) released the collaborative document “Landelijke beschikbaarheid radiologische beelden voor zorgverlener en patiënt: functionele vereisten” (translates as “National availability of radiological images for the health professional and patient: functional requirements”)[1]. This document states that in 2016, for almost 1 out of 4 radiology patients, there is the potential need to exchange

documents (radiology imaging studies and reports) between multiple healthcare professionals and/or referrers in different locations. It also states that the infrastructure used for information exchange in the Netherlands is currently not acceptable.

The current situation provides some local information exchange between affiliated healthcare providers but is a long way from the goal of a nationwide, fully integrated, document sharing infrastructure. Currently, it takes a lot of effort to transfer the documents of interest from one place to another, often needing manual intervention to do so.

Since the current infrastructure is not nationwide, the available documents might only represent a part of a patient’s complete dossier, meaning that the healthcare professional might be missing relevant and important information about the patient’s total history. This introduces a risk to the continuity of care and to patient safety.

The main objectives mentioned in [1] are:

1. Within 3 years it should be possible to access all the radiology imaging studies and reports belonging to a single patient, no matter where the information is stored, in the form of a timeline: each imaging study and report is an entry in the timeline ordered chronologically.
2. This timeline should be available to every authorized radiologist in their own workspot (work environment) regardless of where they are working at that time.
3. This single timeline should provide much-needed insight and overview to the radiologist treating the patient.
4. Access to any underlying imaging studies and/or reports of interest (retrieval to the radiologist workspot) should be possible by entry section out of the timeline.

1.2 About this document

This BBS (Dutch: Beeldbeschikbaarheid, English: Image Availability) implementation guide is a technical derivation of the aforementioned document between NVvR and VZVZ [1]. Additionally, input is also taken from “eHealth Network guideline on Medical imaging studies and imaging reports”[7] and “Definitief rapport praktijkbeoordeling beeldbeschikbaarheid en toelichting 1.0”[2].

The implementation guide does not define how the NVvR goal of a nationwide, fully integrated, document sharing infrastructure should be achieved from the current situation. It does describe the use of appropriate IHE document sharing profiles to assist in achieving the goal.

Inspiration for the choice of document sharing profiles has been taken from the IHE Multi-country Working Group “Recommendation on Standards Positioning for sharing imaging information at the national/regional level” activities which defines three deployment architectures for document sharing:

1. A country (or a single stand-alone region) with a central document registry both with distributed PACS and or VNAs.
2. A country with federated regional document registries and regions with distributed PACS and or VNAs.
3. A country (or region) with a central document registry and a central VNA.

In all above architectures distributed or centralized Document Repositories should be possible.

The deployment architecture for the Netherlands will be a mixture of the MCWG deployment architectures 1 and 2; recommending the usage of the IHE document sharing profiles based on:

1. XDS-I.b: Cross-enterprise Imaging Document Sharing (1)
2. XCA-I: Cross-community Access of Imaging (2)
3. MHD(S): Mobile access to Health Documents / Mobile Health Document Sharing (1)

This document assumes reader familiarity with these IHE profiles. This document is not an introduction to XDS-I.b, XCA-I, MHD/MHDS and will only focus on requirements from the IHE profiles, combined with the (NIHEMDS) metadata set for BBS, which are relevant for national use in the Netherlands.

This implementation guide is a supplement to the IHE document sharing profile descriptions intended to provide additional information for implementation/deployment needs in the Netherlands. This document is part of an evolving strategy, features will likely be added, adjusted and/or removed in future versions.

1.3 Glossary

Term	Description
Affinity Domain	An administrative structure containing various healthcare entities that have agreed to share clinical documents in the common infrastructure
Beeldbeschikbaarheid (BBS)	The Dutch name of this project, often abbreviated to BBS. Image Availability is the international name for this project.
BSN	The citizen service number (BSN) is a unique 9-digit personal number allocated to everyone registered in the Personal Records Database (BRP). Everyone who registers with the BRP is automatically given a BSN.
DICOM	Digital Imaging and Communications in Medicine is the international standard for medical images and related information. It defines the formats for medical images that can be exchanged with the data and quality necessary for clinical use.
Documents	Describes reports and/or images (via an image manifest / DICOM KOS object) which include patient identification, patient demographic details, author, creation date/time, content type and other metadata needed to define the source and provenance of the contained information.
FHIR	Fast Healthcare Interoperability Resources
IHE	Integrating the Healthcare Enterprise
Images	Result of scanning a patient/specimen using electromagnetic radiation, x-ray, ultrasound or other techniques to produce visualizations of internal structures of the body for the purpose of accurate diagnosis.
Image Availability	The name of this project, in the Netherlands known as Beeldbeschikbaarheid (abbreviated to BBS).
Imaging Report	Summary of the findings of a diagnostic consultant (radiologist, cardiologist, lab specialist, etc.) based on observations taken from an underlying set of images/test results. A report is signed off/approved by a senior diagnostic consultant and should not be changed thereafter.
Imaging Study	Result of scanning a patient/specimen using electromagnetic radiation, x-ray, ultrasound or other techniques to produce visualizations of internal structures of the body for the purpose of accurate diagnosis.
HCIM	Health and Care Information models (HCIM) or Zorginformatiebouwstenen (ZIB's) are used to capture functional, semantic (non-technical) agreements for the standardization of information used in the care process.
MedMij	MedMij is an initiative of the Dutch Patient Federation and was embraced as one of the five focus programs in 2015. The Healthcare Information Council then opted for the MedMij program. To make healthcare better, more affordable and more accessible, the Information Council is working on a sustainable information system for healthcare, in which healthcare data is exchanged securely and reliably. To this end, agreements, standards, and facilities are made, together with the participants of the Information Council.
MHD	Mobile access to Health Documents
MHDS	Mobile Health Document Sharing
NIHEMDS	The NIHEMDS is the National IHE MetaData Set (Dutch: Nationale IHE MetaData Set)
NVvR	Nationale Vereniging van Radiologen: the Dutch Association of Radiologists
Reports	Summary of the findings of a diagnostic consultant (radiologist, cardiologist, lab specialist, etc) based on observations taken from an underlying set of images/test results. A report is signed off/approved by a senior diagnostic consultant and should not be changed thereafter.
Studies	Grouping of images and reports relating to a single patient for a common diagnostic need.
Timeline	A time-ordered representation of all the radiology encounters (visits) a patient has had. Each encounter produces some type of radiology information relating to the patient in the form of images and/or reports.
VZVZ	Vereniging van Zorgaanbieders voor Zorgcommunicatie: Dutch Association for Health Providers
XCA-I	IHE Cross-Community Access for Imaging
XDS-I.b	IHE Cross-Enterprise Imaging Document Sharing
XDS	Cross-Enterprise Document Sharing
XDS-I	Cross-Enterprise Document Sharing Imaging
Zib	A Zib (Zorginformatiebouwstenen) defines a clinical concept in such a way that it can be used as a building block in various healthcare situations and information systems. ZIBs form the basis for the standardization of healthcare information.

Table 1.1 Glossary

2 Boundaries and relationships

This BBS implementation guide applies to the exchange of documents (imaging studies and reports) and other related information between radiology healthcare professionals in the Netherlands. It does not specify how documents and/or images are generated or stored, but rather how they are made available to other healthcare professionals. Therefore, healthcare professionals are not only responsible for the documents that are provided to the community, but also how their infrastructure is connected to the said community to provide cross-community access.

All patients must be identified by a BSN (national patient identifier) with guidance on the use of the BSN in DICOM objects given in [6]. Only national citizens that have a BSN are in scope for this release. Only PDF report document types are in scope for this release, other report document types (including DICOM SR documents) will be addressed in future releases.

In consultation with the NVvR, both dictating and authenticating radiologists’ names are not shown in the timeline. It suffices that this information is displayed in the report. No requirements are defined regarding the performance (bandwidth) of any network implementing the transport infrastructure. It is assumed that there are no network limitations on access (end-point addressing or firewall restrictions) to any actors, defined in the IHE profiles, needing to communicate with each other.

The implementation guideline assumes that a generic infrastructure is available to provide for services like:

• User Authentication: limit access to known/trusted users.
• User Authorization: approval to perform an action.
• Secure transaction exchange: cipher suite / encryption.
• Audit trail: user action logging.
• Discovery (Localization): translation of document sharing system component (registries, repositories, imaging document sources, etc.) unique identifiers to service end-points.

It is assumed that all Imaging Study image instances are stored in the DICOM format version PS3.0 2023d or later.

2.1 MedMij Images (Beelden) information standard

Images (Beelden) is a Dutch national initiative for the exchange of medical images between patients to healthcare organizations. The BBS and the Images standard both aim to improve the exchange of medical images. However, the Images information standard is a specific implementation of medical image exchange from patient to healthcare professional, while BBS provides a framework that can be used between healthcare professionals. They are therefore two different standards that should not be confused with each other during implementation.

2.2 Consent

It is assumed that the radiologist and/or treating physician has consent from the patient to share their information. The way in which the consent is obtained and used for data access is beyond the scope of this implementation guide.

3 Required Metadata

In the context of document sharing, metadata plays a very important role in the classification of document data (during document registration) and in the filtering of document data (during document query and retrieval). It is necessary to ensure that a high level of detail (sufficient choice in value sets) is provided for classification and a lower level of detail (fewer choices in a value list) for query/discovery. This is contradictory but equally important requirements for metadata values. For further details of we refer to the IHE ITI XDS metadata Guideline.

The IHE Imaging Document Source actor is responsible for creating the metadata used when registering a document and, as such, plays a very important part in ensuring the correct use of national code sets and value lists. This ultimately has a huge impact on the overall quality of the metadata available. The success in the using a document sharing infrastructure is down, in a large part, to the metadata originally stored and therefore available for matching query requests from IHE Imaging Document Consumers. Alignment on the use of metadata properties and values (value sets) used is essential for successful document sharing. Inspiration for the metadata requirements and use is taken from the IHE Multi-country Working Group “Recommendation on imaging information sharing metadata strategy for filtering access in queries and linkages of IDs” [4].

The metadata attribute eventCodeList is of special interest. It represents the main clinical keywords for queries specific to certain document content. When used for imaging document sharing the event codes represent two types of information about the imaging event:

1. Acquisition Modality used
2. Atomic Region / Body Part affected

The “MCWG Recommendation on imaging information sharing metadata strategy for filtering access in queries and linkages of IDs” [4] recommends the use of a coarse grained list of Atomic Region/Body Part SNOMED-CT codes as shown below. SNOMED-CT terminology is based on a hierarchical structure with coarse gained code values (higher level) being further defined by fine grained codes (lower level). The coarse grain value list is a subset of the fine-grained value list.

SNOMED CT Code	Code Meaning NL
63337009	Structuur van onderste gedeelte van romp
38266002	Gehele lichaam in totaliteit
53120007	Structuur van bovenste extremiteit
61685007	Structuur van onderste extremiteit
67734004	Structuur van bovenste deel van romp
774007	Structuur van hoofd-halsregio
113257007	Structuur van tractus circulatorius
80891009	Structuur van hart
76752008	Structuur van mamma
737561001	Structuur van wervelkolom en/of ruggenmerg

Table 3.1 Coarse-grained list of Atomic Region/Body Part code values

Also, the metadata creationTime and serviceStartTime/serviceStopTime can be confusing. In this implementation guide they are defined as follows:

• serviceStartTime/serviceStopTime is the moment the first image or report is created
• creationTime is the moment the KOS object is created

It is very likely that there will be metadata added, adjusted and/or removed in future releases of this document.

3.1 NIHEMDS

The NIHEMDS is the National IHE MetaData Set and defines the metadata required when registering documents in the document sharing infrastructure in terms of data meaning, value lists and code sets. It is essential that the same understanding and use is made of this metadata by all imaging document sources that provide imaging study and imaging report content into the document sharing infrastructure.

The NIHEMDS covers for all fields that are not explicitly covered in Beeldbeschikbaarheid. Beeldbeschikbaarheid prescribes additional requirements to the NIHEMDS in semantics and cardinalties.

The NIHEMDS is under constant revision and construction, further adjustments in the NIHEMDS that have implications on the BBS metadata will be communicated in NIHEMDS or future releases of this document.

Please note that the cardinalities from the NIHEMDS are not included in this implementation guide yet and will be added in future releases with more detail when applicable.

3.2 Imaging Study Manifest

An imaging study manifest provides metadata about the identification, description, and location of a set of DICOM images (and other instances), that are grouped by DICOM Series into a DICOM Study for a single patient. Again, it is essential that the same understanding and use is made of this metadata by all imaging document sources that provide imaging study content into the document sharing infrastructure.

The imaging study manifest can be defined in two ways:

1. DICOM KOS (Key Object Selection) document
2. FHIR Imaging Study resource

The DICOM KOS document is currently more widely used and fits better into the imaging archive domain where it is most often used. It can be simply stored in an image archive alongside other DICOM objects and be queried and retrieved like other DICOM objects too.

The FHIR Imaging Study may become more widely used as and when the MHD(S) profiles are more widely supported.

4 Document Sharing IHE Profiles

As mentioned above, in order to support the two required deployment architectures:

1. A country (or a single stand-alone region) with a central document registry both with distributed PACS and or VNAs.
2. A country with federated regional document registries and regions with distributed PACS and or VNAs.

This implementation guide describes support for three different IHE document sharing profiles:

1. XDS-I.b: Cross-enterprise Imaging Document Sharing
2. XCA-I: Cross-community Access for Imaging
3. MHD(S): Mobile access to Health Documents / Mobile Health Document Sharing

Figure 4.1 Image Availability Information Standard

The IHE XDS-I.b and MHD(S) document sharing profiles define support for the following processes applicable to a given patient identified by the national BSN:

NOTE: Usage of the BSN, which is a unique 9-digit identifier, would be ideal. This has yet to be decided and that decision is out of scope for this standard.

• Registration: publish existence of imaging study and/or imaging report.
• Query: discover existence of imaging studies and reports.
• Retrieve: get selected imaging study and/or report.

The XCA-I document sharing profile supports the Query and Retrieve processes only. Registration is assumed to have been done using another document sharing paradigm (XDS-I.b, MHD(S) or other).

The Functional Design (FO) defines 5 use cases:

1. Beschikbaarstellen verslaggegevens t.b.v. tijdlijn
2. Beschikbaarstellen beeldgegevens t.b.v. tijdlijn
3. Raadplegen Tijdlijn Data
4. Raadplegen Verslag
5. Raadplegen Beeld

Possible implementations of these use cases are further detailed below using internationally defined document sharing standards.

4.1 XDS-I.b: Cross-enterprise Imaging Document Sharing

The Cross-Enterprise Imaging Document Sharing (XDS-I.b) IHE Integration Profile facilitates the registration, distribution and access across health enterprises of patient electronic health records. Cross-Enterprise Imaging Document Sharing is focused on providing a standards-based specification for managing the sharing of documents between any healthcare enterprise, ranging from a private physician office to a clinic to an acute care in-patient facility. The XDS-I.b Affinity Domain provides a document sharing infrastructure based on the use of a central document registry actor, 1 or more document repository actors, 1 or more imaging document source actors and 1 or more imaging document consumer actors. All actors in a single affinity domain are accessible to each other over the network infrastructure.

Figure 4.2 IHE XDS-I.b Affinity Domain

The IHE XDS affinity domain is identified by a globally unique identifier known as the homeCommunityId. The interaction (information exchange) between actors within the affinity domain is achieved in terms of the ITI and RAD transactions as shown in the above figure.

The following IHE XDS-I.b profile actor groupings are defined as:

1. The IHE Document Source and Imaging Document Source (providing the imaging study and imaging reports) are grouped together and further referred to as the Imaging Document Source only in this implementation guide. The mechanism used to group these actors is beyond the scope of this implementation guide.
2. The IHE Document Consumer and Imaging Document Consumer (using the imaging study and imaging reports) are grouped together and further referred to as the Imaging Document Consumer only in this implementation guide. The mechanism used to group these actors is beyond the scope of this implementation guide.

The use cases outlined below show how the various transactions are used in practice. Only synchronous web-service support is assumed by participating actors in this version of the implementation guide.

4.1.1 Use Cases

XDS-I.b supports the Registration, Query and Retrieve processes, within a single affinity domain, as illustrated by the following use cases:

1. Register Imaging Report (Beschikbaarstellen verslaggegevens t.b.v. tijdlijn)
2. Register Imaging Study (Beschikbaarstellen beeldgegevens t.b.v. tijdlijn)
3. Query Timeline Data (Raadplegen Tijdlijn Data)
4. Retrieve Imaging Report (Raadplegen Verslag)
5. Retrieve Imaging Study (Raadplegen Beeld)

4.1.1.1 Use case 1: Register Imaging Report (Beschikbaarstellen verslaggegevens t.b.v. tijdlijn)

4.1.1.1.1 Introduction

The Register Imaging Report use case enables a document source to publish the existence of an imaging report to the document sharing infrastructure. This involves creating metadata associated with the report and, in the case of XDS-I.b, using the RAD-68 Provide & Register Imaging Document Set request to send the metadata and a copy of the imaging report to the document repository. The document repository will, in turn, forward the metadata, including a DocumentUniqueId, to the document registry as part of the XDS-I.b registration process.

The document repository RAD-68 Provide & Register Imaging Document Set response indicates whether the registration was successful or not. The document register will only register documents whose metadata meets its quality standards (metadata content correctness).

4.1.1.1.2 Actors

The actors for this use case are the document source, which initiates the document registration request using the RAD-68 Provide & Register Imaging Document Set transaction, and the document repository, which stores the metadata and report and returns the registration status.

Persons		Systems		XDS-I.b
Name	Description	Name	Actors	Transactions
Radiologist	This actor is responsible for creating the metadata corresponding to a radiological imaging report and making both metadata and imaging report available to the Document Repository. In this role, the radiologist (and/or health organization they work for) is the Imaging Document Source making them also responsible for the quality of the metadata added to the document(s).	Document Sharing Infrastructure (Index) NOTE: EPD/PACS are the most common systems	Document Repository / Document Registry	RAD-68 Provide & Register Imaging Document Set

4.1.1.1.3 Mapping

The RAD-68 Provide & Register Imaging Document Set request contains a Submission Request which, in turn, contains exactly one DocumentEntry object for each imaging report (binary attachment “application/pdf”) contained in the request message. Please see the below table for the metadata used in each DocumentEntry. Also, note that:

• The “ebXML attribute and element values” are included in the table for clarification purposes.
• The “Req/Opt” column defines the metadata attribute as being required (R) or optional (O) for this transaction.
• The NIHEMDS is the National IHE MetaData Set and defines the metadata required when registering documents in the document sharing infrastructure in terms of data meaning, value lists and code sets.

Metadata Attribute	ebXML attribute and element values	Req/Opt	Art-Decor Element
author	classificationScheme: "urn:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838d" Slot name = authorPerson, Value as XCN Slot name = authorInstitution, Value as XON Slot name = authorRole, Value as String Slot name = authorSpecialty, Value as CE Slot name = authorTelecommunication, Value as XTN	R	Onderzoek.Verrichting.Uitvoerder.Zorgverlener.Naamgegevens.Geslachtsnaam.Achternaam Onderzoek.Verrichting.Locatie.Zorgaanbieder.Zorgaanbiederidentificatienummer Onderzoek.Verrichting.Locatie.Zorgaanbieder.Organisatienaam Onderzoek.Verrichting.Uitvoerder.Zorgverlener.ZorgverlenerRol
classCode	REPORTS Code & DisplayName values taken from XDS classCode Metadata Coding System “1.3.6.1.4.1.19376.1.2.6.1.1”	R
confidentialityCode	classificationScheme: "urn:uuid:f4f85eac-e6cb-4883-b524-f2705394840f" Code & DisplayName values taken from HL7 Confidentiality CodingScheme: “2.16.840.1.113883.5.25”. The confidentialityCode can carry multiple vocabulary items.	O
eventCodeList	classificationScheme: "urn:uuid:2c6b8cb7-8b2a-4051-b291-b1ae6a575ef4" Code & DisplayName values taken from: DICOM Modality (1.2.840.10008.6.1.1283): Context Group CID 29CodingScheme: “DCM” (CodingSchemeDesignator) DICOM Atomic Region/Body Part (4 1.2.840.10008.6.1.2): Context Group CID 4CodingScheme: “SCT” (CodingSchemeDesignator) with values taken from the coarse-grained list defined in table 3.1 Required Metadata NOTE: It is necessary to register more than one coarse-grained code when the codes represent overlapping atomic regions / body parts. Also, the IHE MCWG wants to restrict to CID 29 and introduces the term "Study level modality"	R	Onderzoek.Verrichting.VerrichtingAnatomischeLocatie
formatCode	classificationScheme: "urn:uuid:a09d5840-386c-46f2-b5ad-9c3699a4309d" Code & DisplayName values taken from IHE Format codes CodingScheme: “1.3.6.1.4.1.19376.1.2.7.1” Code: "urn.ihe.rad:PDF" DisplayName: "PDF"	R
healthcareFacilityTypeCode	classificationScheme: "urn:uuid:f33fb8ac-18af-42cc-ae0e-ed0b0bdb91e1" Code & DisplayName values taken from RoleCodeNLUZIRoleCodeOrganisaties CodingScheme: “2.16.840.1.113883.2.4.15.1060”	O	Verrichting.Uitvoerder.Zorgverlener.Zorgaanbieder.OrganisatieType
practiceSettingCode	classificationScheme: "urn:uuid:cccf5598-8b07-4b77-a05e-ae952c785ead" Code & DisplayName values taken from DICOM Institutional Department/Unit/Service (1.2.840.10008.6.1.817); Context Group CID 7030CodingScheme: “DCM”, “SCT” or “UMLS” (CodingSchemeDesignator) NOTE: The IHE MCWG has proposed a different value for this metadata[8].	O	Onderzoek.Verrichting.Uitvoerder.Zorgverlener.Zorgaanbieder.Afdelingsspecialisme
typeCode	classificationScheme: "urn:uuid:f0306f51-975f-434e-a61c-c59651d33983" Code & DisplayName values taken from DICOM Imaging Procedure (1.2.840.10008.6.1.1436); DCM BCID 101CodingScheme: “LN”, “NICIP”, “SCT” or “I10P” (CodingSchemeDesignator)	R	Onderzoek.Verrichting.VerrichtingType
creationTime	Slot name = creationTime, Value as DTM: YYYY[MM[DD[hh[mm[ss]]]]]	R	Onderzoek.Verslaginformatie.DatumTijd
hash	Slot name = hash, Value as SHA1 hash	O
languageCode	Slot name = languageCode, Value as String	O
legalAuthenticator	Slot name = legalAuthenticator, Value as XCN	O
referenceIdList	Slot name = referenceIdList, Values as CXi CXi referenceId attributes: urn:ihe:iti:xds:2015:encounterId urn:ihe:iti:xds:2013:accession urn:ihe:iti:xds:2013:order urn:ihe:iti:xds:2016:studyInstanceUID	O R R R
repositoryUniqueId	Slot name = repositoryUniqueId, Value as OID	O
serviceStartTime	Slot name = serviceStartTime, Value as DTM	O	Onderzoek.Verrichting.Verrrichtingsstartdatum
serviceStopTime	Slot name = serviceStopTime, Value as DTM	O	Onderzoek.Verrichting.Verrichtingeinddatum
size	Slot name = size, Value as Integer	O
sourcePatientId	Slot name = sourcePatientId, Value as CX	O
sourcePatientInfo	Slot name = sourcePatientInfo, Value as Field Field sourcePatientInfo examples: “PID-x|value”	R
URI	Slot name = URI, Value = blank Recommended by the NIHEMDS	O
title	Name.LocalizedString, Value = title	R
comments	Description.LocalizedString, Value = comments	O
patientId	identificationScheme: "urn:uuid:58a6f841-87b3-4a3e-92fd-a8ffeff98427" Name.LocalizedString value = XDSDocumentEntry.patientId, Value as CX CX Value example: BSN^^^&OIDofAA&ISO (where OIDofAA is the OID of the Assigning Authority)	R	Patient.Identificatienummer
documentuniqueId	identificationScheme: "urn:uuid:2e82c1f6-a085-4c72-9da3-8640a32e42ab" Name.LocalizedString value = XDSDocumentEntry.uniqueId, Value as Identifier	O	Onderzoek.Verslaginformatie.Verslagidentificatienummer

Table 4.1 XDS-I.b Imaging Report Registration Metadata Attributes

When registering an imaging report and corresponding imaging study (i.e. a report and study that are the result of the same radiology event), it is required that the common metadata attributes used in the imaging report Document Entry and imaging study Document Entry will have the same values. This is a requirement to ensure that when querying these registered entries from an Imaging Document Consumer, the same query filters will yield both the imaging report and the imaging study for a connected event.

The RAD-68 Provide & Register Imaging Document Set response indicates the success or otherwise of the registration process.

4.1.1.2 Use case 2: Register Imaging Study (Beschikbaarstellen beeldgegevens t.b.v. tijdlijn)

4.1.1.2.1 Introduction

The Register Imaging Study use case enables an imaging document source to publish the existence of an imaging study to the document sharing infrastructure. This involves creating metadata associated with the imaging study and an imaging study manifest (DICOM KOS object) referring to the imaging study contents (DICOM instances). In the case of XDS-I.b, the RAD-68 Provide & Register Imaging Document Set request is used to send the metadata and a copy of the imaging study manifest to the document repository. The document repository will, in turn, forward the metadata, including a document uniqueId, to the document registry as part of the XDS-I.b registration process.

The document repository RAD-68 Provide & Register Imaging Document Set response indicates whether the registration was successful or not. As in all use cases, the document register will only register documents whose metadata meets its quality standards (metadata content correctness).

4.1.1.2.2 Actors

The actors for this use case are the imaging document source, which initiates the document registration request using the RAD-68 Provide & Register Imaging Document Set transaction, and the document repository, which stores the metadata and imaging study manifest and returns the registration status.

Persons		Systems		XDS-I.b
Name	Description	Name	Actors	Transactions
Radiologist	This actor is responsible for creating the metadata corresponding to a radiological imaging study and the imaging study manifest and making both metadata and imaging study manifest available to the Document Repository.In this role, the radiologist (and/or health organization they work for) is the Imaging Document Source making them also responsible for the metadata added to the document(s).	Document Sharing Infrastructure (Index) NOTE: EPD/PACS are the most common systems	Document Repository / Document Registry	RAD-68 Provide & Register Imaging Document Set

4.1.1.2.3 Mapping

The RAD-68 Provide & Register Imaging Document Set request contains a Submission Request which, in turn, contains exactly one DocumentEntry object for each DICOM KOS object (binary attachment: application/dicom) contained in the request message.

Metadata Attribute	ebXML attribute and element values	Req/Opt	Art-Decor Element
author	classificationScheme: "urn:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838d" Slot name = authorPerson, Value as XCN Slot name = authorInstitution, Value as XON Slot name = authorRole, Value as String Slot name = authorSpecialty, Value as CE Slot name = authorTelecommunication, Value as XTN	O	Onderzoek.Verrichting.Uitvoerder.Zorgverlener.Naamgegevens.Geslachtsnaam.Achternaam Onderzoek.Verrichting.Locatie.Zorgaanbieder.Zorgaanbiederidentificatienummer Onderzoek.Verrichting.Locatie.Zorgaanbieder.Organisatienaam Onderzoek.Verrichting.Uitvoerder.Zorgverlener.ZorgverlenerRol
classCode	IMAGES Code & DisplayName values taken from XDS classCode Metadata Coding System “1.3.6.1.4.1.19376.1.2.6.1.1”	R
confidentialityCode	classificationScheme: "urn:uuid:f4f85eac-e6cb-4883-b524-f2705394840f" Code & DisplayName values taken from HL7 Confidentiality CodingScheme: “2.16.840.1.113883.5.25”. The confidentialityCode can carry multiple vocabulary items.	O
eventCodeList	classificationScheme: "urn:uuid:2c6b8cb7-8b2a-4051-b291-b1ae6a575ef4" Code & DisplayName values taken from: DICOM Modality (1.2.840.10008.6.1.1283): Context Group CID 29CodingScheme: “DCM” (CodingSchemeDesignator) DICOM Atomic Region/Body Part (4 1.2.840.10008.6.1.2): Context Group CID 4CodingScheme: “SCT” (CodingSchemeDesignator) with values taken from the coarse-grained list defined in chapter 3: Required Metadata NOTE: It is necessary to register more than one coarse-grained code when the codes represent overlapping atomic regions / body parts. Also, the IHE MCWG wants to restrict to CID 29 and introduces the term "Study level modality"	R	Onderzoek.Verrichting.VerrichtingAnatomischeLocatie
formatCode	classificationScheme: "urn:uuid:a09d5840-386c-46f2-b5ad-9c3699a4309d" Code & DisplayName values taken from IHE Format codes CodingScheme: “1.3.6.1.4.1.19376.1.2.7.1”, Code "1.2.840.10008.5.1.4.1.1.88.59", DisplayName "DICOM KOS"	R
healthcareFacilityTypeCode	classificationScheme: "urn:uuid:f33fb8ac-18af-42cc-ae0e-ed0b0bdb91e1" Code & DisplayName values taken from RoleCodeNLUZIRoleCodeOrganisaties CodingScheme: “2.16.840.1.113883.2.4.15.1060”	O	Verrichting.Uitvoerder.Zorgverlener.Zorgaanbieder.OrganisatieType
practiceSettingCode	classificationScheme: "urn:uuid:cccf5598-8b07-4b77-a05e-ae952c785ead" Code & DisplayName values taken from DICOM Institutional Department/Unit/Service (1.2.840.10008.6.1.817); Context Group CID 7030CodingScheme: “DCM”, “SCT” or “UMLS” (CodingSchemeDesignator) NOTE: The IHE MCWG has proposed a different value for this metadata[8].	O	Onderzoek.Verrichting.Uitvoerder.Zorgverlener.Zorgaanbieder.Afdelingsspecialisme
typeCode	classificationScheme: "urn:uuid:f0306f51-975f-434e-a61c-c59651d33983" Code & DisplayName values taken from DICOM Imaging Procedure (1.2.840.10008.6.1.1436); DCM BCID 101CodingScheme: “LN”, “NICIP”, “SCT” or “I10P” (CodingSchemeDesignator)	R	Onderzoek.Verrichting.VerrichtingType
creationTime	Slot name = creationTime, Value as DTM - YYYY[MM[DD[hh[mm[ss]]]]]	R	Onderzoek.Beeldinformatie.DatumTijd
hash	Slot name = hash, Value as SHA1 hash	O
languageCode	Slot name = languageCode, Value as String	O
legalAuthenticator	Slot name = legalAuthenticator, Value as XCN	O
referenceIdList	Slot name = referenceIdList, Values as CXi CXi referenceId attributes: urn:ihe:iti:xds:2015:encounterId urn:ihe:iti:xds:2013:accession urn:ihe:iti:xds:2013:order urn:ihe:iti:xds:2016:studyInstanceUID	O R R R
repositoryUniqueId	Slot name = repositoryUniqueId, Value as OID	O
serviceStartTime	Slot name = serviceStartTime, Value as DTM	O	Onderzoek.Verrichting.Verrrichtingsstartdatum
serviceStopTime	Slot name = serviceStopTime, Value as DTM	O	Onderzoek.Verrichting.Verrichtingeinddatum
size	Slot name = size, Value as Integer	O
sourcePatientId	Slot name = sourcePatientId, Value as CX	O
sourcePatientInfo	Slot name = sourcePatientInfo, Value as Field Field sourcePatientInfo examples: “PID-x|value”	R
URI	Slot name = URI, Value = blank Recommended by the NIHEMDS	O
title	Name.LocalizedString, Value = title	R
comments	Description.LocalizedString, Value = comments	O
patientId	identificationScheme: "urn:uuid:58a6f841-87b3-4a3e-92fd-a8ffeff98427" Name.LocalizedString value = XDSDocumentEntry.patientId, Value as CX CX Value example: “BSN^^^&OIDofAA&ISO” - where OIDofAA is the OID of the Assigning Authority	R	Patient.Identificatienummer
documentuniqueId	identificationScheme: "urn:uuid:2e82c1f6-a085-4c72-9da3-8640a32e42ab" Name.LocalizedString value = XDSDocumentEntry.uniqueId, Value as Identifier	O	Onderzoek.Beeldinformatie.Beeldinformatieindentificatienummer

Table 4.2 XDS-I.b Imaging Study Registration Metadata Attributes

When registering an imaging report and corresponding imaging study (i.e. a report and study that are the result of the same radiology event), it is required that the common metadata attributes used in the imaging report Document Entry and imaging study Document Entry will have the same values. This is a requirement to ensure that when querying these registered entries from an Imaging Document Consumer, the same query filters will yield both the imaging report and the imaging study for a connected event.

4.1.1.2.4 DICOM KOS Object Attributes

The imaging study manifest or DICOM KOS object should be created and contain at least the DICOM attributes defined below. Some attributes have been added as private standard extensions to the DICOM KOS IOD definition (based on the MCWG recommendations on the KOS Manifest [5]).The DICOM KOS object should only reference a single imaging study (1 to 1 relationship). Most attribute values can be copied from the referenced imaging study in the imaging document source. Other attributes take values as shown.

DICOM Attribute	DICOM VR (data format)	Value
Patient Module
Patient's Name​ (0010,0010)	PN	Most values copied from referenced PACS study > patient attributes. Patient ID should be updated to use the BSN as primary patient id. The referenced PACS study local Patient ID should be copied as one of the Other Patient IDs Sequence (MCWG recommendations).
Patient ID​ (0010,0020)​	LO
Issuer of Patient ID (0010,0021)	LO
Patient's Birth Date​ (0010,0030)​	DT
Patient's Sex​ (0010,0040)​	CS
Other Patient IDs Sequence (0010,1002)	SQ
General Study Module
Study Instance UID​ (0020,000D)	UI	Values copied from referenced PACS study > study attributes. Copying the referenced PACS study Study Instance UID ensure a 1 to 1 relationship between KOS and referenced study (MCWG recommendation).
Study Date​ (0008,0020)	DA
Study Time​ (0008,0030)​	TM
Referring Physician's Name​ (0008,0090)​	PN
Accession Number (0008,0050)	SH
Issuer of Accession Number Sequence (0008,0051)	SQ
Study Description (0008,1030)	LO
Key Object Document Series
Modality​ (0008,0060)​	CS	“KO”
Series Instance UID​ (0020,000E)​	UI	New DICOM UID for KOS series
Series Number​ (0020,0011)​	IS	"1" - fixed value
General Equipment
Manufacturer​ (0008,0070)​	LO	Name of equipment manufacturer
Key Object Document
Instance Number​ (0020,0013)​	IS	"1” - fixed value
Content Date​ (0008,0023)​	DA	KOS creation date
Content Time​ (0008,0033)​	SQ	KOS creation time
Referenced Request Sequence (0040,A370)	TM	Identifies Requested Procedures that are being fulfilled (completely or partially). This sequence will contain the same number of items as the number of unique combinations of accession numbers and order placer numbers associated with this Study. Each element will have an Accession Number and an Order Placer Number corresponding to and associated with this Study (MCWG recommendation).
> Study Instance UID (0020,000D)	UI	Unique identifier for the Study.
> Referenced Study Sequence (0008,1110)	SQ	Zero length sequence. Nothing should be included in this sequence.
> Accession Number (0008,0050)	SH	A number generated by the RIS that identifies the Imaging Service Request. This value must be one of the values associated with one of the RIS requests for review. Note that if this KOS document is shared or exchanged, this same Accession Number must be present in the ReferenceIdList (urn:ihe:iti:xds:2013:accession) metadata.
> Issuer of Accession Number Sequence (0008,0051)	SQ	Identifier of the Assigning Authority that issued the Accession Number.
> Placer Order Number / Imaging Service Request (0040,2016)	LO	The order number assigned to the Imaging Service Request by the party placing the order. This value must be one of the values associated with one of the imaging requests that resulted in the request for RIS review. Note that if this KOS document is shared or exchanged, this same Placer Order Number will need to be present in the ReferenceIdList (urn:ihe:iti:xds:2013:order) metadata.
> Order Placer Identifier Sequence (0040,0026)	SQ	Identifier of the Assigning Authority that issued the Placer Order Number.
Current Requested Procedure​ Evidence Sequence (0040,A375)​	SQ
> Modalities In Study (0008,0061)	CS	All of the distinct values used for Modality (0008,0060) in the Series of the Study – use only values defined in DICOM 3.0 – Part 16 - Table CID 29 - Acquisition Modality (MCWG recommendation).
> Study Instance UID​ (0020,000D)	UI	Value copied from General Study > Study Instance UID​ (0020,000D)
> Referenced Series Sequence​ (0008,1115)​	SQ
for each series in referenced PACS study {
>> Series Date (0008,0021)	DA	Date the Series started (MCWG recommendation).
>> Series Time (0008,0031)	TM	Time the Series started (MCWG recommendation).
>> Modality (0008,0060)	CS	Type of device, process or method that created the Instances in this Series (MCWG recommendation).
>> Series Description (0008,103E)	LO	Description of the Series (MCWG recommendation).
>> Series Instance UID​ (0020,000E)	UI	Value copied from referenced PACS series > Series Instance UID​ (0020,000E)​
>> Retrieve Location UID​ (0040,E011)​	UI	Unique identifier of the location where the instances are stored on the network. This is an OID that is used as a reference. The URL will be made available through the GF Adressering.
>> Retrieve URL​ (0008,1190)​	UR	Base URI end point of the location from which SOP Instances is retrieved using a DICOM web-based service. This base URI is used together with one or more of Study Instance UID (0020,000D), Series Instance UID (0020,000E) and Referenced SOP Instance UID (0008,1155) values (depending on the level of retrieval required) to create the actual retrieval URL. The end point type (WADO-URL or WADO-RS) is not conveyed by this attribute.
>> Referenced SOP Sequence​ (0008,1199)​	SQ
for each instance in referenced PACS series {
>>> Referenced SOP Class UID​ (0008,1150)​	UI	Value copied from referenced PACS instance > SOP Class UID​ (0008,0016)​
>>> Referenced SOP Instance UID​ (0008,1155)	UI	Value copied from referenced PACS instance > SOP Instance UID​ (0008,0018)​
>>> Instance Number (0020,0013)	IS	A number that identifies this SOP Instance (MCWG recommendation).
>>> Number Of Frames (0028,0008)	IS	Number of frames in a Multi-frame Image. Required if the instance contains multiple frame pixel data (MCWG recommendation).
}
}
SR Document Content
Value Type​ (0040,A040)	CS	“CONTAINER”
Concept Name Code​ Sequence (0040,A043)​	SQ	Use TID 2010 “Key Object Selection” to populate
SOP Common
SOP Class UID​ (0008,0016)​	UI	"1.2.840.10008.5.1.4.1.1.88.59": SOP Class UID of KOS Object
SOP Instance UID​ (0008,0018)​	UI	New DICOM UID for KOS instance itself
Timezone Offset From UTC (0008,0201)​	SH	The UTC time offset of the producer is placed in this field (MCWG recommendation).

Table 4.3 DICOM KOS Object Attributes

The RAD-68 Provide & Register Imaging Document Set response indicates the success or otherwise of the registration process.

4.1.1.3 Use case 3: Query Timeline Data (Raadplegen Tijdlijn Data)

4.1.1.3.1 Introduction

The Query Timeline Data use case enables an imaging document consumer to retrieve a timeline of radiology studies for a specific patient. This use case is implemented using the ITI-18 Registry Stored Query transaction, which allows the imaging document consumer to query for a list of studies (represented in IHE XDS-I.b as Document Entries) based on patient identifiers and other search criteria. The document registry returns a set of Document Entries that match the query criteria, which can then be used to construct a timeline for the patient. By using ITI-18, the imaging document consumer sends out a query request and the document registry sends back the query response.

Creating a timeline for a given patient (with a BSN known beforehand) is best done in two steps by using the ITI-18 query as follows:

Step 1: Find the list of documents that belong to the patient by issuing an ITI-18 with:

1. QueryID = FindDocuments
2. returnType = ObjectRef
3. Query Keys = patientId (BSN), practicesettingCode = 394734003

NOTE: the query keys are conform the Functional Design Art-Decor for "Raadplegen tijdlijn scenario".

This should return a list of matching document UUIDS (unique registry identifiers). As the number of documents belonging to the patient (number of matching query responses) is unknown beforehand this approach provides the “smallest” response in terms of data per document. However, this is not enough detail to create a timeline entry.

Step 2: Using the list of returned document UUIDS from step 1, perform a second query for each document by issuing a new ITI-18:

1. QueryID =GetDocument
2. returnType =LeafClass
3. Query key =document UUID

This will return the registered DocumentEntry details, including all known metadata for the document. This can be used to populate the timeline entry representing the document. The use of two ITI-18 query types to create this timeline is also recommended in the IHE framework Vol2.

4.1.1.3.2 Actors

The actors for this use case are the Imaging Document Consumer, which initiates the timeline data request using the ITI-18 Registry Stored Query transaction, and the Document Registry, which provides access to and returns the timeline data.

Persons		Systems		XDS-I.b
Name	Description	Name	Actors	Transactions
Radiologist/ Treating physician	This Imaging Document Consumer actor is a healthcare professional that requests access to images and related information from image-generating healthcare professionals.	Document Sharing Infrastructure	Document Registry	ITI-18 Registry Stored Query

4.1.1.3.3 Mapping

The metadata query keys that can be used in the ITI-18 Registry Stored Query by use of the Find Documents request (“urn:uuid:14d4debf-8f97-4251-9a74-a90016b0af0d”) are defined in the below table. The “ebXML query key” descriptions are included in the table for clarification purposes. The “Req/Opt” column defines the metadata attribute as being required (R) or optional (O) for this transaction. The patientId and availablityStatus are mandatory.

Metadata Attribute	ebXML query key	Req/Opt	Art-Decor Element
patientId	Slot name = $XDSDocumentEntryPatientId, Value = patientIdValue This is defined by IHE-NL as BSN and will be used in this guide as a 9-digit unique identifier.	R	Patient.Identificatienummer
availabilityStatus	Slot name = $XDSDocumentEntryStatus Value = “urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Approved”	R
eventCodeList	Slot name = $XDSDocumentEntryEventCodeList, Value = eventCodeListValue NOTE: When using the DICOM Atomic Region/Body Part (4 1.2.840.10008.6.1.2)​ as a query-key, the query-key value should be taken from the coarse-grained list in chapter 3: Required Metadata	O	Onderzoek.Verrichting.VerrichtingAnatomischeLocatie
classCode	Slot name = $XDSDocumentEntryClassCode, Value = IMAGES, REPORTS	O
typeCode	Slot name = $XDSDocumentEntryTypeCode, Value = typeCodeValue	O	Onderzoek.Verrichting.VerrichtingType
practiceSettingCode	Slot name = $XDSDocumentEntryPracticeSettingCode, Value = practiceSettingCodeValue	O	Onderzoek.Verrichting.Uitvoerder.Zorgverlener.Zorgaanbieder.Afdelingsspecialisme
creationTime (range)	Slot name = $XDSDocumentEntryCreationTimeFrom, Value = creationTimeFromValue Slot name = $XDSDocumentEntryCreationTimeTo, Value = creationTimeToValue	O O	Onderzoek.Verslaginformatie.DatumTijd
serviceStartTime (range)	Slot name = $XDSDocumentEntryServiceStartTimeFrom, Value = serviceStartTimeFromValue Slot name = $XDSDocumentEntryServiceStartTimeTo, Value = serviceStartTimeToValue	O O	Onderzoek.Verrichting.Verrrichtingsstartdatum
serviceStopTime (range)	Slot name = $XDSDocumentEntryServiceStopTimeFrom, Value = serviceStopTimeFromValue Slot name = $XDSDocumentEntryServiceStopTimeTo, Value = serviceStopTimeToValue	O O	Onderzoek.Verrichting.Verrichtingeinddatum
healthcareFacilityTypeCode	Slot name = $XDSDocumentEntryHealthcareFacilityTypeCode, Value = healthcareFacilityTypeCodeValue	O	Verrichting.Uitvoerder.Zorgverlener.Zorgaanbieder.OrganisatieType
confidentialityCode	Slot name = $XDSDocumentEntryConfidentialityCode,Value = confidentialityCodeValue	O
author	Slot name = $XDSDocumentEntryAuthorPerson, Value = authorValue	O	Onderzoek.Verrichting.Uitvoerder.Zorgverlener.Naamgegevens.Geslachtsnaam.Achternaam Onderzoek.Verrichting.Locatie.Zorgaanbieder.Zorgaanbiederidentificatienummer Onderzoek.Verrichting.Locatie.Zorgaanbieder.Organisatienaam Onderzoek.Verrichting.Uitvoerder.Zorgverlener.ZorgverlenerRol
formatCode	Slot name = $XDSDocumentEntryFormatCode For PDF Imaging report use Value = “^urn.ihe.rad:PDF^1.3.6.1.4.1.19376.1.2.7.1” For KOS Imaging study manifest use Value = "1.2.840.10008.5.1.4.1.1.88.59^^1.3.6.1.4.1.19376.1.2.7.1"	O
objectType	Slot name = $XDSDocumentEntryType, Value = objectTypeValue	O

Table 4.4 XDS-I.b Metadata Query Keys

The ITI-18 Registry Stored Query Find Documents response (“urn:uuid:14d4debf-8f97-4251-9a74-a90016b0af0d”) will contain an entry each for DocumentEntry matching the request query keys that was found in the Document Registry.

The query response metadata is defined in the table below. The “Query response ebXML attribute and element values” are included in the table for clarification purposes. The “Req/Key” column defines the metadata attribute as being required (R), “used as query key” (Q) or optional (O) for this transaction. The “used as query key” means that if the metadata attribute was used in the ITI-18 Registry Stored Query request (as a query key) then a matching metadata value is expected in the ITI-18 Registry Stored Query response, otherwise it is optional.

The patientId, availablityStatus, repositoryUniqueId and document uniqueId are mandatory.

Metadata Attribute	Query response ebXML attribute and element values	Req/Key	Art-Decor Element
patientId	identificationScheme: "urn:uuid:58a6f841-87b3-4a3e-92fd-a8ffeff98427" Name.LocalizedString value = XDSDocumentEntry.patientId, Value as CX	R	Patient.Identificatienummer
availabilityStatus	ExtrinsicObject status Approved: “urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Approved”	R
homeCommunityId	Slot name = homeCommunityId, Value as OID	O
repositoryUniqueId	Slot name = repositoryUniqueId, Value as OID	R
documentuniqueId	identificationScheme: "urn:uuid:2e82c1f6-a085-4c72-9da3-8640a32e42ab" Name.LocalizedString value = XDSDocumentEntry.uniqueId, Value as Identifier	R	Onderzoek.Verslaginformatie.Verslagidentificatienummer
eventCodeList	classificationScheme: "urn:uuid:2c6b8cb7-8b2a-4051-b291-b1ae6a575ef4" Code & DisplayName values taken from: a) DICOM Modality (1.2.840.10008.6.1.1283) - Context Group CID 29CodingScheme: “DCM” (CodingSchemeDesignator) b) DICOM Atomic Region/Body Part (4 1.2.840.10008.6.1.2)​ - Context Group CID 4CodingScheme: “SCT” (CodingSchemeDesignator), see the coarse-grained list in chapter 3. NOTE: It is necessary to register more than one coarse-grained code when the codes represent overlapping atomic regions / body parts. Also, the IHE MCWG wants to restrict to CID 29 and introduces the term "Study level modality"	R	Onderzoek.Verrichting.VerrichtingAnatomischeLocatie
author	classificationScheme: "urn:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838d" Slot name = authorPerson, Value as XCN Slot name = authorInstitution, Value as XON Slot name = authorRole, Value as String Slot name = authorSpecialty, Value as CE Slot name = authorTelecommunication, Value as XTN	Q/O	Onderzoek.Verrichting.Uitvoerder.Zorgverlener.Naamgegevens.Geslachtsnaam.Achternaam Onderzoek.Verrichting.Locatie.Zorgaanbieder.Zorgaanbiederidentificatienummer Onderzoek.Verrichting.Locatie.Zorgaanbieder.Organisatienaam Onderzoek.Verrichting.Uitvoerder.Zorgverlener.ZorgverlenerRol
classCode	IMAGES, REPORTS Code & DisplayName values taken from XDS classCode Metadata Coding System “1.3.6.1.4.1.19376.1.2.6.1.1”	Q/O
confidentialityCode	classificationScheme: "urn:uuid:f4f85eac-e6cb-4883-b524-f2705394840f" Code & DisplayName values taken from the HL7 Confidentiality CodingScheme: “2.16.840.1.113883.5.25”. The confidentialityCode can carry multiple vocabulary items.	Q/O
formatCode	classificationScheme: "urn:uuid:a09d5840-386c-46f2-b5ad-9c3699a4309d" Code & DisplayName values taken from CodingScheme: “1.3.6.1.4.1.19376.1.2.7.1” (IHE Format codes) Code "urn.ihe.rad:PDF", DisplayName "PDF" Code "1.2.840.10008.5.1.4.1.1.88.59", DisplayName "DICOM KOS"	Q/O
healthcareFacility-TypeCode	classificationScheme: "urn:uuid:f33fb8ac-18af-42cc-ae0e-ed0b0bdb91e1" Code & DisplayName values taken from CodingScheme: “2.16.840.1.113883.2.4.15.1060” (NL Nictiz/HL7 RoleCodeNLUZIRoleCodeOrganisaties)	Q/O	Verrichting.Uitvoerder.Zorgverlener.Zorgaanbieder.OrganisatieType
practiceSettingCode	classificationScheme: "urn:uuid:cccf5598-8b07-4b77-a05e-ae952c785ead" Code & DisplayName values taken from: DICOM Institutional Department/Unit/Service (1.2.840.10008.6.1.817); Context Group CID 7030CodingScheme: “DCM”, “SCT” or “UMLS” (CodingSchemeDesignator) NOTE: The IHE MCWG has proposed a different value for this metadata[8].	Q/O	Onderzoek.Verrichting.Uitvoerder.Zorgverlener.Zorgaanbieder.Afdelingsspecialisme
typeCode	classificationScheme: "urn:uuid:f0306f51-975f-434e-a61c-c59651d33983" Code & DisplayName values taken from: DICOM Imaging Procedure (1.2.840.10008.6.1.1436); DCM BCID 101CodingScheme: “LN”, “NICIP”, “SCT” or “I10P” (CodingSchemeDesignator)	Q/O
creationTime	Slot name = creationTime, Value as DTM - YYYY[MM[DD[hh[mm[ss]]]]]	Q/O	Onderzoek.Verslaginformatie.DatumTijd
hash	Slot name = hash, Value as SHA1 hash	O
languageCode	Slot name = languageCode, Value as String	O
legalAuthenticator	Slot name = legalAuthenticator, Value as XCN	O
referenceIdList	Slot name = referenceIdList, Values as CXi, CXi referenceId attributes: urn:ihe:iti:xds:2015:encounterId urn:ihe:iti:xds:2013:accession urn:ihe:iti:xds:2013:order urn:ihe:iti:xds:2016:studyInstanceUID	O
serviceStartTime	Slot name = serviceStartTime, Value as DTM	Q/O	Onderzoek.Verrichting.Verrrichtingsstartdatum
serviceStopTime	Slot name = serviceStopTime, Value as DTM	Q/O	Onderzoek.Verrichting.Verrichtingeinddatum
size	Slot name = size, Value as Integer	O
sourcePatientId	Slot name = sourcePatientId, Value as CX	O
sourcePatientInfo	Slot name = sourcePatientInfo, Value as Field Field sourcePatientInfo examples: “PID-x|value”	O
URI	Slot name = URI, Value = blank Recommended by the NIHEMDS	O
title	Name.LocalizedString, Value = title	O
comments	Description.LocalizedString, Value = comments	O

Table 4.5 XDS-I.b Metadata Query Response

4.1.1.4 Use case 4: Retrieve Imaging Report (Raadplegen Verslag)

4.1.1.4.1 Introduction

The Retrieve Report use case enables a document consumer to retrieve an imaging study report for a specific patient, with two possible scenarios as mentioned in the functional design.

1. The radiologist/ treating physician used use case 3 (Retrieve Timeline Data) to create a timeline belonging to a single patient via the ITI-18 Registry Stored Query transaction of which they wish to consult a report. Selecting the specific timeline entry will contain the displayed (meta)data details but also define the document uniqueId.
2. The radiologist / attending physician is aware of a previous examination of which they wish to consult the report and the document uniqueId of this examination is known (how this is known is beyond the scope of this use case).

Via one of the two options mentioned above, we assume that the use case begins with a known document uniqueId. The document retrieval will make use of the ITI-43 Retrieve Document Set transaction and thus include the document uniqueId. The mimeType in the retrieve response will indicate the document type retrieved. Only mimeType of “application/pdf” are supported in this version of the implementation guide.

4.1.1.4.2 Actors

The actors for this use case are the Imaging Document Consumer, which initiates an imaging study request using the ITI-43 Retrieve Document Set transaction, and the Document Repository, which provides access to and returns the requested report.

Persons		Systems		XDS-I.b
Name	Description	Name	Actors	Transactions
Radiologist/ Treating physician	This Imaging Document Consumer actor is a healthcare professional that requests access to images and related information from image-generating healthcare professionals.	Document Sharing Infrastructure	Document Repository	ITI-43 Retrieve Document Set

4.1.1.4.3 Mapping

The ITI-43 Retrieve Document Set request body contains the following unique identifiers obtained from the ITI-18 Stored Registry Query response details for a specific document:

• repository uniqueId
• document uniqueId

The ITI-43 Retrieve Document Set response body contains:

• repository uniqueId: same as request
• document uniqueId: same as request
• document mimeType: application/pdf
• the document itself, which can be two options:
  • either in-line base64 encoded (single-part) document
  • or XOP include reference to separate (multi-part) binary document = PDF imaging report.

4.1.1.5 Use case 5: Retrieve Images (Raadplegen Beeld)

4.1.1.5.1 Introduction

The Retrieve Images use case describes how the radiologist and/or treating physician can retrieve (an) imaging document set(s), with two possible scenarios as mentioned in the functional design.

1. The radiologist/treating physician used use case 3 (Retrieve Timeline Data) to create a timeline belonging to a single patient via the ITI-18 Stored Registry Query transaction of which they wish to consult (a) specific imaging document set(s). Selecting the specific timeline entry will contain the displayed (meta)data details and define the document's uniqueId.
2. The radiologist/attending physician is aware of a previous examination of which they wish to consult the imaging document set(s) and the document uniqueId of this examination is known (how this is known is beyond the scope of this use case).

We assume this use case begins with a known DocumentUniqueId, obtained by one of the two options mentioned above. Note that the ITI-18 Stored Registry Query transaction is therefore not required for this use case. Issue an ITI-43 Retrieve Document Set request by using the DocumentUniqueId. The ITI-43 response will contain the matching document content, where the mimeType property will identify the document type (e.g. application/pdf or application/dicom).

Note: This use case defines image retrieval which can only be done if the mimeType of the document retrieved above is application/dicom, in which case the retrieved document represents a DICOM imaging manifest KOS (Key Object Selection) document. This retrieved document contains the identifiers (UIDs) or links to the DICOM objects (images, presentation states, structured reports) of interest. The actual DICOM objects will then be retrieved using the RAD-69 Retrieve Imaging Document Set (or RAD-107 WADO-RS Retrieve as recommended bij the IHE MCWG) transaction by including each of the DICOM object UIDs in the retrieve request.

Secondly, although this use case is image retrieval, it is possible having retrieved the DICOM KOS document, that the KOS document references DICOM structured reports SR too. This can only be determined by inspecting the type of DICOM objects referenced by the KOS document. DICOM SR objects are out of scope in the current version of this implementation guide.

4.1.1.5.2 Actors

The actors for this use case are the Imaging Document Consumer, which initiates an imaging study request using the ITI-43 Retrieve Document Set and RAD-69 Retrieve Imaging Document Set / RAD-107 WADO-RS Retrieve transactions, and the Document Repository / Imaging Document Source, which provides access to and returns the requested image.

Persons		Systems		XDS-I.b
Name	Description	Name	Actors	Transactions
			Document Repository	ITI-43 Retrieve Document Set
Radiologist/ Treating physician	This Imaging Document Consumer actor is a healthcare professional that requests access to images and related information from image-generating healthcare professionals.	Document Sharing Infrastructure	Imaging Document Source	RAD-69 Retrieve
			Imaging Document Source	RAD-107 WADO-RS Retrieve (as recommended by the IHE MCWG)

4.1.1.5.4 ITI-43 Retrieve Document Set

The ITI-43 Retrieve Document Set request body contains the following unique identifiers obtained from the ITI-18 Stored Registry Query response details for a specific document:

• repository uniqueId
• document uniqueId

The ITI-43 Retrieve Document Set response body contains two parts (mime blocks):

Mime Block 1

• repository uniqueId (same as request)
• document uniqueId (same as request)
• mimeType: application/xop+xml
• document: XOP include reference to Mime Block 2

Mime Block 2

• mimeType: application/dicom
• binary document: DICOM imaging study manifest as KOS object

4.1.1.5.5 Rad-69 Retrieve Imaging Document Set

The RAD-69 Retrieve Imaging Document Set request body contains the following unique identifiers obtained from the DICOM imaging study manifest KOS object contents:

• study instanceUID: Study Instance UID​ (0020,000D)
• series instanceUID: Series Instance UID​ (0020,000E)
• repository uniqueId: Retrieve Location UID​ (0040,E011) (Imaging Document Source)
• document uniqueId: SOP Instance UID​ (0008,0018)​
• transfer syntax UID list: list of acceptable transfer syntax UIDs as returned image format

The RAD-69 Retrieve Imaging Document Set response body contains two parts (mime blocks):

Mime Block 1

• study instanceUID: (same as request)
• series instanceUID: (same as request)
• repository uniqueId: (same as request)
• document uniqueId: (same as request)
• transfer syntax UID: transfer syntax UID of retrieved image
• mimeType: application/xop+xml
• document: XOP include reference to Mime Block 2

Mime Block 2

• mimeType: application/dicom
• binary document: DICOM image instance as DICOM Part-10 (.dcm) file

The RAD-107 WADO-RS Retrieve is used to retrieve a complete study, series within a study or individual (image) instances based on the URL used:

• STUDY: <wadoRsEndpoint>/studies/{studyUid}
• SERIES: <wadoRsEndPoint>/studies/{studyUid}/series/{seriesUid}
• INSTANCE: <wadoRsEndPoint>/studies/{studyUid}/series/{seriesUid}/instances/{instanceUid}

4.1.2 Profiles and Transactions

The BBS information standard makes use of the following IHE profile and transactions.

IHE Profile/Transactions	Description
Cross-enterprise Imaging Document Sharing	The Cross-Enterprise Imaging Document Sharing (XDS-I.b) IHE Integration Profile facilitates the registration, distribution and access across health enterprises of patient electronic health records. Cross-Enterprise Imaging Document Sharing is focused on providing a standards-based specification for managing the sharing of documents between any healthcare enterprise, ranging from a private physician office to a clinic to an acute care in-patient facility
RAD-68 Provide & Register Imaging Document Set	The Provide and Register Imaging Document Set MTOM/XOP transaction passes a Repository Submission Request from an XDS-I.b Imaging Document Source to an XDS Document Repository.
ITI-18 Registry Stored Query	This is a query request to the Document Registry from a Document Consumer. The query request contains: A reference to a pre-defined query stored on the Document Registry Actor. Parameters for the query.
ITI-43 Retrieve Document Set	The Retrieve Document Set Request shall carry the following information: A required repository uniqueId that identifies the repository from which the document is to be retrieved. This value corresponds to XDSDocumentEntry.repositoryUniqueId. A required document uniqueId that identifies the document within the repository. This value corresponds to the XDSDocumentEntry.uniqueId.
RAD-69 Retrieve Imaging Document Set	This transaction is used to retrieve DICOM instances that are referenced within and XDS-I.b DICOM imaging study manifest.
RAD-107 WADO-RS Retrieve	The WADO-RS Retrieve (RAD-107) transaction accesses DICOM SOP Instances via an HTTP interface.

Table 4.5 IHE profile and transactions used in the BBS Information standard

4.2 XCA-I: Cross-community Access for Imaging

The Cross-Community Access for Imaging Profile supports the means to query and retrieve patient relevant medical data held by other communities. This provides a mechanism to connect regional communities together to create a national wide document sharing infrastructure.

A community is defined as a coupling of facilities/enterprises that have agreed to work together using a common set of policies for the purpose of sharing clinical information via an established mechanism. Facilities/enterprises may host any type of healthcare application such as EHR, PHR, etc. A community is identifiable by a globally unique id called the homeCommunityId. Membership of a facility/enterprise in one community does not preclude it from being a member in another community.

Figure 4.3 IHE Cross Community Access for Imaging

A community may be implemented as an XDS Affinity Domain, but this is not mandatory for the successful use of the XCA-I document sharing profile. If both initiating and responding gateways within any community implement the XCA-I transactions correctly no further requirements on the internal infrastructure of a community are assumed by using XCA-I. XCA-I does not support any kind of document registration process but assumes that any community supporting XCA-I has a local registration process in place that will support the information exchange needed between communities as defined by XCA-I.

A generic infrastructure service is assumed to be available that maps community homeCommuntyIds to service endpoints for transaction exchange between communities. It is also assumed that all community gateways are accessible to each other over the network infrastructure. The NVvR requires that all patients known within the (XCA-I) document sharing infrastructure have the national BSN as the primary patient identifier to be used in all patient-based transactions. This has the advantage that no patient identification translation is needed between local and national identifiers.

Only synchronous web-service support is assumed by participating actors in this version of the implementation guide.

4.2.1 Use Cases

XCA-I supports the Query and Retrieve processes, across connected communities (multiple affinity domains), as illustrated by the following use cases:

1. Register Imaging Report (Beschikbaarstellen verslaggegevens t.b.v. tijdlijn) – not supported
2. Register Imaging Study (Beschikbaarstellen beeldgegevens t.b.v. tijdlijn) – not supported
3. Query Timeline Data (Raadplegen Tijdlijn Data)
4. Retrieve Imaging Report (Raadplegen Verslag)
5. Retrieve Imaging Study (Raadplegen Beeld)

4.2.1.1 Use case 1: Register Imaging Report (Beschikbaarstellen verslaggegevens t.b.v. tijdlijn)

XCA-I does not support imaging report registration.

4.2.1.2 Use case 2: Register Imaging Study (Beschikbaarstellen beeldgegevens t.b.v. tijdlijn)

XCA-I does not support imaging report registration.

4.2.1.3 Use case 3: Query Timeline Data (Raadplegen Tijdlijn Data)

4.2.1.3.1 Introduction

The Query Timeline Data use case enables a radiologist/treating physician, acting as the (imaging) document consumer, in the community initiating the request (initiating gateway) to retrieve a timeline of radiology encounters (imaging studies and reports) from other communities, containing (imaging) document sources (responding gateways), for a specific patient.

This use case is implemented using the ITI-38 Cross Gateway Query transaction, which allows the initiating gateway to query for a list of imaging studies and reports (document entries) based on the patient identifier and other search criteria. There is a 1 to n relationship between initiating gateway and responding gateways meaning that the initiating gateway query may be broadcast to more than one responding gateway. The initiating gateway is responsible for collecting all the query responses (from the responding gateways) into a single response to be returned to the local (imaging) document consumer.

Each responding gateway returns a set of document entries that match the query criteria, which can then be used to construct a timeline for the patient. ITI-38 is the Cross Gateway Query with essentially the same semantics as ITI-18 (Registry Stored Query). By using ITI-38, the initiating gateway sends out a query request, and responding gateways send back their query responses.

Creating a timeline for a given patient (with a BSN known beforehand) is best done in two steps by using the ITI-38 query as follows:

Step 1: Find the list of documents that belong to the patient by issuing an ITI-38 with

• QueryID = FindDocuments
• returnType = ObjectRef

1. Query Keys = patientId (BSN), practicesettingCode = 394734003

NOTE: the query keys are conform the Functional Design Art-Decor for "Raadplegen tijdlijn scenario".

This should return a list of matching document UUID's (unique registry identifiers). As the number of documents belonging to the patient (number of matching query responses) is unknown beforehand this approach provides the “smallest” response in terms of data per document. However, this is not enough detail to create a timeline entry.

Step 2:Using the list of returned document UUID's from step 1, perform a second query for each document by issuing a new ITI-38:

• QueryID = GetDocument
• returnType = LeafClass
• Query key = document UUID

This will return the registered DocumentEntry details, including all known metadata for the document. This can be used to populate the timeline entry representing the document. The use of two ITI-38 query types to create this timeline is also recommended in IHE framework Vol. 2.

NOTE: The use of XCA-I initiating and responding gateways to connect communities does not scale well. The addition of a new community to an existing document sharing infrastructure adds n - 1 new query paths when implementing the ITI-38 Cross Gateway Query. The issue at hand is knowing which of the communities supporting a responding gateway contains information belonging to the patient of interest in the initiating gateway query. Rather than continually querying all responding gateways, use can be made of the IHE XCPD Cross-community Patient Discovery profile which supports patient existence discovery (i.e., a discovery message can be sent to each responding gateway to see if the patient is known or not). A cache can be maintained by the initiating gateway of patient id versus containing responding gateways (homeCommunityIds) and only the responding gateways known to contain corresponding patient data queried by ITI-38 Cross Gateway Query.

4.2.1.3.2 Actors

The actors for this use case are the requesting gateway, which initiates the timeline data request using the ITI-38 Cross Gateway Query transaction, and the responding gateway, which provides access to and returns the timeline data. The actors for this use case are the requesting gateway, which initiates the timeline data request using the ITI-38 Cross Gateway Query transaction, and the responding gateway, which provides access to and returns the timeline data.

Persons		Systems		XCA-I
Name	Description	Name	Actors	Transactions
Radiologist/ Treating physician	This actor is a healthcare professional that requests access to images and related information from image-generating healthcare professionals. In this role, the radiologist/treating physician is the Document Consumer.	Document Sharing Infrastructure	Initiating Gateway	ITI-38 Cross Gateway Query
Radiologist	This actor is responsible for generating and transmitting medical images, and related information, and making them available to the responding gateway. In this role, the radiologist (and/or health organization they work for) is the Document Source, which is responsible for the metadata added to the document(s).	Document Sharing Infrastructure	Responding Gateway	ITI-38 Cross Gateway Query

4.2.1.3.3 Mapping

The metadata query keys that can be used in the ITI-38 Cross Gateway Query via Find Documents request (“urn:uuid:14d4debf-8f97-4251-9a74-a90016b0af0d”) are defined in the table below. The “ebXML query key” descriptions are included in this table for clarification purposes. The “Req/Opt” column defines the metadata attribute as being required (R) or optional (O) for this transaction.

The patientId and availablityStatus are mandatory.

Metadata Attribute	ebXML query key	Req/Opt	Art-Decor Element
patientId	Slot name = $XDSDocumentEntryPatientId, Value = patientIdValue This is defined by IHE-NL as BSN and will be used in this guide as a 9-digit unique identifier.	R	Patient.Identificatienummer
availabilityStatus	Slot name = $XDSDocumentEntryStatus Approved: “urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Approved”	R
eventCodeList	Slot name = $XDSDocumentEntryEventCodeList, Value = eventCodeListValue NOTE: When using the DICOM Atomic Region/Body Part (4 1.2.840.10008.6.1.2)​ as a query-key, the query-key value should be taken from the coarse-grained list as mentiond in Table 3.1	O	Onderzoek.Verrichting.VerrichtingAnatomischeLocatie
classCode	Slot name = $XDSDocumentEntryClassCode, Value = IMAGES or REPORTS	O
typeCode	Slot name = $XDSDocumentEntryTypeCode, Value = typeCodeValue	O	Onderzoek.Verrichting.VerrichtingType
practiceSettingCode	Slot name = $XDSDocumentEntryPracticeSettingCode, Value = practiceSettingCodeValue	O	Onderzoek.Verrichting.Uitvoerder.Zorgverlener.Zorgaanbieder.Afdelingsspecialisme
creationTime (range)	Slot name = $XDSDocumentEntryCreationTimeFrom, Value = creationTimeFromValue Slot name = $XDSDocumentEntryCreationTimeTo, Value = creationTimeToValue	O O	Onderzoek.Verslaginformatie.DatumTijd
serviceStartTime (range)	Slot name = $XDSDocumentEntryServiceStartTimeFrom, Value = serviceStartTimeFromValue Slot name = $XDSDocumentEntryServiceStartTimeTo, Value = serviceStartTimeToValue	O O	Onderzoek.Verrichting.Verrrichtingsstartdatum
serviceStopTime (range)	Slot name = $XDSDocumentEntryServiceStopTimeFrom, Value = serviceStopTimeFromValue Slot name = $XDSDocumentEntryServiceStopTimeTo, Value = serviceStopTimeToValue	O O	Onderzoek.Verrichting.Verrichtingeinddatum
healthcareFacilityTypeCode	Slot name = $XDSDocumentEntryHealthcareFacilityTypeCode, Value = healthcareFacilityTypeCodeValue	O	Verrichting.Uitvoerder.Zorgverlener.Zorgaanbieder.OrganisatieType
confidentialityCode	Slot name = $XDSDocumentEntryConfidentialityCode, Value = confidentialityCodeValue	O
author	Slot name = $XDSDocumentEntryAuthorPerson, Value = authorValue	O	Onderzoek.Verrichting.Uitvoerder.Zorgverlener.Naamgegevens.Geslachtsnaam.Achternaam Onderzoek.Verrichting.Locatie.Zorgaanbieder.Zorgaanbiederidentificatienummer Onderzoek.Verrichting.Locatie.Zorgaanbieder.Organisatienaam Onderzoek.Verrichting.Uitvoerder.Zorgverlener.ZorgverlenerRol
formatCode	Slot name = "$XDSDocumentEntryFormatCode” For PDF imaging report use value “^urn.ihe.rad:PDF^1.3.6.1.4.1.19376.1.2.7.1” For KOS imaging study manifest use value = "1.2.840.10008.5.1.4.1.1.88.59^^1.3.6.1.4.1.19376.1.2.7.1"	O
objectType	Slot name = $XDSDocumentEntryType, Value = objectTypeValue	O

Table 4.6 XCA-I Metadata Query Keys

The ITI-38 Cross Gateway Query Find Documents response (“urn:uuid:14d4debf-8f97-4251-9a74-a90016b0af0d”) will contain an entry each for DocumentEntry matching the request query keys that was found in the Document Registry.

The query response metadata is defined in the below table. The “Query response ebXML attribute and element values” are included in the table for clarification purposes. The “Req/Key” column defines the metadata attribute as being required (R), “used as query key” (Q) or optional (O) for this transaction. The “used as query key” means that if the metadata attribute was used in the ITI-38 Cross Gateway Query request (as a query key) then a matching metadata value is expected in the ITI-38 Cross Gateway Query response, otherwise it is optional.

The patientId, availablityStatus, homeCommunityId, repositoryUniqueId and documentuniqueId are mandatory.

Metadata Attribute	Query response ebXML attribute and element values	Req/Key	Art-Decor Element
patientId	identificationScheme: "urn:uuid:58a6f841-87b3-4a3e-92fd-a8ffeff98427" Name.LocalizedString value = XDSDocumentEntry.patientId, Value as CX	R	Patient.Identificatienummer
availabilityStatus	ExtrinsicObject status Approved: “urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Approved”	R
homeCommunityId	Slot name = homeCommunityId, Value as OID	R
repositoryUniqueId	Slot name = repositoryUniqueId, Value as OID	R
documentuniqueId	identificationScheme: "urn:uuid:2e82c1f6-a085-4c72-9da3-8640a32e42ab" Name.LocalizedString value = XDSDocumentEntry.uniqueId, Value as Identifier	R	Onderzoek.Verslaginformatie.Verslagidentificatienummer
eventCodeList	classificationScheme: "urn:uuid:2c6b8cb7-8b2a-4051-b291-b1ae6a575ef4" Code & DisplayName values taken from: a) DICOM Modality (1.2.840.10008.6.1.1283) - Context Group CID 29CodingScheme: “DCM” (CodingSchemeDesignator) b) DICOM Atomic Region/Body Part (4 1.2.840.10008.6.1.2)​ - Context Group CID 4CodingScheme: “SCT” (CodingSchemeDesignator) with values from the coarse-grained list returned (see Table 3.1) NOTE: It is necessary to register more than one coarse-grained code when the codes represent overlapping atomic regions / body parts. Also, the IHE MCWG wants to restrict to CID 29 and introduces the term "Study level modality"	R	Onderzoek.Verrichting.VerrichtingAnatomischeLocatie
author	classificationScheme: "urn:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838d" Slot name = authorPerson, Value as XCN Slot name = authorInstitution, Value as XON Slot name = authorRole, Value as String Slot name = authorSpecialty, Value as CE Slot name = authorTelecommunication, Value as XTN	Q/O	Onderzoek.Verrichting.Uitvoerder.Zorgverlener.Naamgegevens.Geslachtsnaam.Achternaam Onderzoek.Verrichting.Locatie.Zorgaanbieder.Zorgaanbiederidentificatienummer Onderzoek.Verrichting.Locatie.Zorgaanbieder.Organisatienaam Onderzoek.Verrichting.Uitvoerder.Zorgverlener.ZorgverlenerRol
classCode	IMAGES, REPORTS Code & DisplayName values taken from XDS classCode Metadata Coding System “1.3.6.1.4.1.19376.1.2.6.1.1”	Q/O
confidentialityCode	classificationScheme: "urn:uuid:f4f85eac-e6cb-4883-b524-f2705394840f" Code & DisplayName values taken from HL7 Confidentiality CodingScheme: “2.16.840.1.113883.5.25”. The confidentialityCode can carry multiple vocabulary items.	Q/O
formatCode	classificationScheme: "urn:uuid:a09d5840-386c-46f2-b5ad-9c3699a4309d" Code & DisplayName values taken from the IHE Format codes CodingScheme: “1.3.6.1.4.1.19376.1.2.7.1” (IHE Format codes) a) Code "urn.ihe.rad:PDF", DisplayName "PDF" b) Code "1.2.840.10008.5.1.4.1.1.88.59", DisplayName "DICOM KOS"	Q/O
healthcareFacilityTypeCode	classificationScheme: "urn:uuid:f33fb8ac-18af-42cc-ae0e-ed0b0bdb91e1" Code & DisplayName values taken from the HL7 RoleCodeNLUZIRoleCodeOrganisaties CodingScheme: “2.16.840.1.113883.2.4.15.1060”	Q/O	Verrichting.Uitvoerder.Zorgverlener.Zorgaanbieder.OrganisatieType
practiceSettingCode	classificationScheme: "urn:uuid:cccf5598-8b07-4b77-a05e-ae952c785ead" Code & DisplayName values taken from: DICOM Institutional Department/Unit/Service (1.2.840.10008.6.1.817): Context Group CID 7030CodingScheme: “DCM”, “SCT” or “UMLS” (CodingSchemeDesignator) NOTE: The IHE MCWG has proposed a different value for this metadata[8].	Q/O	Onderzoek.Verrichting.Uitvoerder.Zorgverlener.Zorgaanbieder.Afdelingsspecialisme
typeCode	classificationScheme: "urn:uuid:f0306f51-975f-434e-a61c-c59651d33983" Code & DisplayName values taken from DICOM Imaging Procedure (1.2.840.10008.6.1.1436); DCM BCID 101CodingScheme: “LN”, “NICIP”, “SCT” or “I10P” (CodingSchemeDesignator)	Q/O	Onderzoek.Verrichting.VerrichtingType
creationTime	Slot name = creationTime, Value as DTM - YYYY[MM[DD[hh[mm[ss]]]]]	Q/O	Onderzoek.Verslaginformatie.DatumTijd
hash	Slot name = hash, Value as SHA1 hash	O
languageCode	Slot name = languageCode, Value as String	O
legalAuthenticator	Slot name = legalAuthenticator, Value as XCN	O
referenceIdList	Slot name = referenceIdList, Values as CXi CXi referenceId attributes: urn:ihe:iti:xds:2015:encounterId urn:ihe:iti:xds:2013:accession urn:ihe:iti:xds:2013:order urn:ihe:iti:xds:2016:studyInstanceUID	O
serviceStartTime	Slot name = serviceStartTime, Value as DTM	Q/O	Onderzoek.Verrichting.Verrrichtingsstartdatum
serviceStopTime	Slot name = serviceStopTime, Value as DTM	Q/O	Onderzoek.Verrichting.Verrichtingeinddatum
size	Slot name = size, Value as Integer	O
sourcePatientId	Slot name = sourcePatientId, Value as CX	O
sourcePatientInfo	Slot name = sourcePatientInfo, Value as Field Field sourcePatientInfo examples: “PID-x|value”	O
URI	Slot name = URI, Value = blank Recommended by the NIHEMDS	O
title	Name.LocalizedString value = title	O
comments	Description.LocalizedString value = comments	O

Table 4.7 XCA-I Metadata Query Response

4.2.1.4 Use case 4: Retrieve Imaging Report (Raadplegen Verslag)

4.2.1.4.1 Introduction

The Retrieve Report use case enables a document consumer to retrieve an imaging study report for a specific patient, with two possible scenarios as mentioned in the functional design.

1. The radiologist/ treating physician used use case 1 (Retrieve Timeline Data) to create a timeline belonging to a single patient via the ITI-38 Cross Gateway Query transaction of which they wish to consult a report. Selecting the specific timeline entry will contain the displayed (meta)data details but also define the document uniqueId.
2. The radiologist / attending physician is aware of a previous examination of which they wish to consult the report and the document uniqueId of this examination is known (how this is known is beyond the scope of this use case).

Via one of the two options mentioned above, we assume that the use case begins with a known documentuniqueId. The document retrieval will make use of the ITI-39 Cross Gateway Retrieve transaction and thus include the documentuniqueId. The mimeType in the retrieve response will indicate the document type retrieved. Only mimeType of “application/pdf” are supported in this version of the implementation guide.

4.2.1.4.2 Actors

The actors for this use case are the requesting gateway, which initiates an imaging study report request using the ITI-39 Cross Gateway Retrieve transaction, and the responding gateway, which provides access to and returns the requested report.

Persons		Systems		XCA-I
Name	Description	Name	Actors	Transactions
Radiologist/ Treating physician	This actor is a healthcare professional that requests access to images and related information from image-generating healthcare professionals. In this role, the radiologist/treating physician is the Document Consumer.	Document Sharing Infrastructure	Initiating Gateway	ITI-39 Cross Gateway Retrieve
Radiologist	This actor is responsible for generating and transmitting medical images, and related information, and making them available to the responding gateway. In this role, the radiologist (and/or health organization they work for) is the Document Source making them also responsible for the metadata added to the document(s).	Document Sharing Infrastructure	Responding Gateway	ITI-39 Cross Gateway Retrieve

4.2.1.4.3 Mapping

There are no ART-DECOR mappings that apply to the ITI-39 Cross Gateway Retrieve transaction.

The ITI-39 Cross Gateway Retrieve request body contains the following unique identifiers obtained from the ITI-38 Cross Gateway Query response details for a specific document:

• homeCommunityId
• repository uniqueId
• document uniqueId

A generic infrastructure service is assumed to be available that maps the homeCommuntyId to the service end-point of the responding gateway that contains the imaging report being retrieved.

The ITI-39 Cross Gateway Retrieve response body contains:

• homeCommunityId
• repository uniqueId (same as request)
• document uniqueId (same as request)
• document mimeType “application/pdf”
• document:
  • either in-line base64 encoded (single-part) document or
  • XOP include reference to separate (multi-part) binary document for PDF imaging report.

4.2.1.5 Use case 5: Retrieve Images (Raadplegen Beeld)

4.2.1.5.1 Introduction

The Retrieve Images use case describes how the radiologist and/or treating physician can retrieve (an) imaging document set(s), with two possible scenarios as mentioned in the functional design.

1. The radiologist/treating physician used use case 1 (Retrieve Timeline Data) to create a timeline belonging to a single patient via the ITI-38 Cross Gateway Query transaction of which they wish to consult (a) specific imaging document set(s). Selecting the specific timeline entry will contain the displayed (meta)data details and define the document's uniqueId.
2. The radiologist/attending physician is aware of a previous examination of which they wish to consult the imaging document set(s) and the document uniqueId of this examination is known (how this is known is beyond the scope of this use case).

We assume this use case begins with a known document uniqueId, obtained by one of the two options mentioned above. Note that the ITI-38 Cross Gateway transaction is therefore not required for this use case. Issue an ITI-39 Cross Gateway Retrieve request by using the document uniqueId. The ITI-39 response will contain the matching document content, where the mimeType property will identify the document type.

Note: This use case defines image retrieval which can only be done if the mimeType of the document retrieved above is application/dicom, in which case the retrieved document represents a DICOM imaging manifest Key Object Selection - KOS) document. This retrieved document contains the identifiers (UIDs) or links to the DICOM objects (images, presentation states, structured reports) of interest. The actual DICOM objects will then be retrieved using the RAD-75 Cross Gateway Retrieve Imaging Document Set transaction by including each of the DICOM object UIDs in the retrieve request. Secondly, although this use case is image retrieval, it is possible having retrieved the DICOM KOS document, that the KOS document references DICOM structured reports SR too. This can only be determined by inspecting the type of DICOM objects referenced by the KOS document. DICOM SR objects are out of scope in the current version of this implementation guide.

4.2.1.5.2 Actors

The actors for this use case are the requesting gateway, which initiates an imaging study request using the ITI-39 Cross Gateway Retrieve and RAD-75 Cross Gateway Retrieve Imaging Document Set transactions, and the responding gateway, which provides access to and returns the requested image.

Persons		Systems		XCA-I
Name	Description	Name	Actors	Transactions
Radiologist/ Treating physician	This actor is a healthcare professional that requests access to images and related information from image-generating healthcare professionals. In this role, the radiologist/treating physician is the (Imaging) Document Consumer.	Document Sharing Infrastructure	Initiating Gateway	ITI-39 Cross Gateway Retrieve
			Initiating Imaging Gateway	RAD-75 Cross Gateway Retrieve Imaging Document Set or RAD-107 WADO-RS Retrieve (as recommended by the IHE MCWG)
Radiologist	This actor is responsible for generating and transmitting medical images, and related information, and making them available to the responding gateway. In this role, the radiologist (and/or health organization they work for) is the (Imaging) Document Source making them also responsible for the metadata added to the document(s).	Document Sharing Infrastructure	Responding Gateway	ITI-39 Cross Gateway Retrieve
			Responding Imaging Gateway	RAD-75 Cross Gateway Retrieve Imaging Document Set or RAD-107 WADO-RS Retrieve (as recommended by the IHE MCWG)

4.2.1.5.3 Mapping

There are no ART-DECOR mappings that apply to the ITI-39 Cross Gateway Retrieve or RAD-75 Cross Gateway Retrieve Imaging Document Set transactions.

The ITI-39 Cross Gateway Retrieve request body contains the following unique identifiers obtained from the ITI-38 Cross Gateway Query response details for a specific document:

• homeCommunityId
• repository uniqueId
• document uniqueId

The ITI-39 Cross Gateway Retrieve Document Set response body contains two parts (mime blocks):

Mime Block 1

• homeCommunityId same as request
• repository uniqueId same as request
• document uniqueId same as request
• mimeType “application/xop+xml”
• document XOP include reference to Mime Block 2

Mime Block 2

• mimeType “application/dicom”
• binary document DICOM imaging study manifest as KOS object

The RAD-75 Cross Gateway Retrieve Imaging Document Set request body contains the following unique identifiers obtained from the DICOM imaging study manifest KOS object contents:

• study instanceUID Study Instance UID​ (0020,000D)
• series instanceUID Series Instance UID​ (0020,000E)
• homeCommunityId (same as ITI-39)
• repository uniqueId Retrieve Location UID​ (0040,E011)​ (i.e. the Imaging Document Source)
• document uniqueId SOP Instance UID​ (0008,0018)​
• transfer syntax UID list list of acceptable transfer syntax UIDs as returned image format

The RAD-75 Cross Gateway Retrieve Imaging Document Set response body contains two parts (mime blocks):

Mime Block 1

• study instanceUID same as request
• series instanceUID same as request
• homeCommunityId same as request
• repository uniqueId same as request
• document uniqueId same as request
• transfer syntax UID transfer syntax UID of retrieved image
• mimeType “application/xop+xml”
• document XOP include reference to Mime Block 2

Mime Block 2

• mimeType “application/dicom”
• binary document DICOM image instance as DICOM Part-10 (.dcm) file

The RAD-107 WADO-RS Retrieve is used to retrieve a complete study, series within a study or individual (image) instances based on the URL used:

• STUDY: <wadoRsEndpoint>/studies/{studyUid}
• SERIES: <wadoRsEndPoint>/studies/{studyUid}/series/{seriesUid}
• INSTANCE: <wadoRsEndPoint>/studies/{studyUid}/series/{seriesUid}/instances/{instanceUid}

4.2.2 Profiles and Transactions

The BBS information standard makes use of the following IHE profile and transactions.

IHE Profile/Transactions	Description
Cross-Community Access for Imaging (XCA-I)	The Cross-Community Access for Imaging Profile supports the means to query and retrieve patient-relevant medical data held by other communities. A community is defined as a coupling of facilities/enterprises that have agreed to work together using a common set of policies for the purpose of sharing clinical information via an established mechanism.
ITI-38 Cross Gateway Query	This transaction defines a way for a source gateway to send a query request to a destination gateway to retrieve metadata about patients and their health records. The query can be based on a variety of parameters such as patient name, ID, birth date, and diagnosis.
ITI-39 Cross Gateway Retrieve	This transaction defines a way for a source gateway to request the retrieval of a patient's health record from a destination gateway. The source gateway sends a query request using ITI-38 and then uses the retrieved metadata to retrieve the patient's health record from the destination gateway.
RAD-75 Cross Gateway Retrieve Imaging Document Set	This transaction allows a source gateway to request the retrieval of a patient's imaging documents from a destination gateway. The source gateway sends a query request using ITI-38 to retrieve metadata about the patient and their imaging studies and then uses RAD-75 to retrieve the actual imaging documents from the destination gateway.
RAD-107 WADO-RS Retrieve	The WADO-RS Retrieve [RAD-107] transaction accesses DICOM SOP Instances via an HTTP interface.

4.3 MHD(S): Mobile access to Health Documents / Mobile Health Document Sharing

The IHE MHD profile, unlike XDS-I.b and XCA-I, does not support any RAD transactions for imaging study registration and retrieval. In this implementation guide the following extensions to MHD are defined:

1. Definition of the MHD Imaging Document Source as an actor, grouped with the MHD Document Source, extending the ITI-65 “Provide Document Bundle” transaction DocumentReference to include the DICOM KOS manifest as an attachment with contentType “application/dicom”. This extension allows for the registration of the imaging study. The mechanism used to group these actors is beyond the scope of this implementation guide.
2. Definition of the MHD Imaging Document Consumer as an actor, grouped with the MHD Document Consumer, extending the ITI-67 “Find Document References” transaction to include DocumentReference attachments to DICOM KOS manifests. This extension allows for the retrieval of the DICOM KOS manifests. In addition, the RAD-107 “WADO-RS” transaction is included for the retrieval of imaging study content as referenced by the DICOM KOS manifest. The mechanism used to group these actors is beyond the scope of this implementation guide.

Figure 4.4 IHE MHD Affinity Domain

The use cases outlined below show how the various transactions are used in practice. Only synchronous web-service support is assumed by participating actors in this version of the implementation guide.

4.3.1 Use Cases

MHD(S) supports the Registration, Query and Retrieve processes as illustrated by the following use cases:

1. Register Imaging Report (Beschikbaarstellen verslaggegevens t.b.v. tijdlijn)
2. Register Imaging Study (Beschikbaarstellen beeldgegevens t.b.v. tijdlijn)
3. Query Timeline Data (Raadplegen Tijdlijn Data)
4. Retrieve Imaging Report (Raadplegen Verslag)
5. Retrieve Imaging Study (Raadplegen Beeld)

4.3.1.1 Use case 1: Register Imaging Report (Beschikbaarstellen verslaggegevens t.b.v. tijdlijn)

4.3.1.1.1 Introduction

The Register Imaging Report use case enables a document source to publish the existence of an imaging report to the document sharing infrastructure. This involves creating metadata associated with the report and, in the case of MHD, using the ITI-65 Provide Document Bundle request to send the metadata and a copy of the imaging report to the document recipient as part of the MHDS registration process.

The document recipient ITI-65 Provide Document Bundle response indicates whether the registration was successful or not. The document recipient will only register documents whose metadata meets its quality standards (metadata content correctness).

4.3.1.1.2 Actors

The actors for this use case are the document source, which initiates the document registration request using the ITI-65 Provide Document Bundle transaction, and the document recipient, which stores the metadata and report and returns the registration status.

Persons		Systems		MHD(S)
Name	Description	Name	Actors	Transactions
Radiologist	This actor is responsible for creating the metadata corresponding to a radiological imaging report and making both metadata and imaging report available to the Document Recipient. In this role, the radiologist (and/or health organization they work for) is the Imaging Document Source making them also responsible for the quality of the metadata added to the document(s).	Document Sharing Infrastructure (Index)	Document Recipient	ITI-65 Provide Document Bundle

4.3.1.1.3 Mapping

The ITI-65 Provide Document Bundle request contains a SubmissionSet type List Resource instance and exactly one DocumentReference instance for each imaging report (binary attachment: “application/pdf”) contained in the request message. See below table for the metadata used in each DocumentReference. The “DocumentReference Element/Value” are included in the table for clarification purposes. The “Req/Opt” column defines the metadata attribute as being required (R) or optional (O) for this transaction.

The “UnContained Comprehensive Metadata” option is used as reference, for more information we refer you to the IHE profile.

Metadata Attribute	DocumentReference Element	DocumentReference Element Value	Req/Opt	Art-Decor Element
availabilityStatus	status	CodeableConcept: Code: “current”, DisplayName: “Current” CodingScheme: “http://hl7.org/fhir/ValueSet/document-reference-status”	R
author	author	Reference Practitioner | Organization	R	Onderzoek.Verrichting.Uitvoerder.Zorgverlener.Naamgegevens.Geslachtsnaam.Achternaam Onderzoek.Verrichting.Locatie.Zorgaanbieder.Zorgaanbiederidentificatienummer Onderzoek.Verrichting.Locatie.Zorgaanbieder.Organisatienaam Onderzoek.Verrichting.Uitvoerder.Zorgverlener.ZorgverlenerRol
classCode	category	CodeableConcept: REPORTS Code & DisplayName values taken from XDS classCode Metadata Coding System “1.3.6.1.4.1.19376.1.2.6.1.1”	R
confidentialityCode	securityLabel	CodeableConcept: Code & DisplayName values taken from CodingScheme: “2.16.840.1.113883.5.25” (HL7 Confidentiality). The confidentialityCode can carry multiple vocabulary items.	O
eventCodeList	context.event	CodeableConcept: Code & DisplayName values taken from: DICOM Modality (1.2.840.10008.6.1.1283): Context Group CID 29CodingScheme: “DCM” (CodingSchemeDesignator) DICOM Atomic Region/Body Part (4 1.2.840.10008.6.1.2): Context Group CID 4CodingScheme: “SCT” (CodingSchemeDesignator) NOTE: The full list of values supported by SNOMED-CT should be used for a fine-grained definition of the Atomic Region/Body Part during the registration process.	R	Onderzoek.Verrichting.VerrichtingAnatomischeLocatie
formatCode	content.format	CodeableConcept: Code & DisplayName values taken from CodingScheme: “1.3.6.1.4.1.19376.1.2.7.1” (IHE Format codes) Code "urn.ihe.rad:PDF", DisplayName "PDF"	R
healthcareFacilityTypeCode	context.facilityType	CodeableConcept: Code & DisplayName values taken from CodingScheme: “2.16.840.1.113883.2.4.15.1060” (NL Nictiz/HL7 RoleCodeNLUZIRoleCodeOrganisaties)	O	Verrichting.Uitvoerder.Zorgverlener.Zorgaanbieder.OrganisatieType
practiceSettingCode	context.practiceSetting	CodeableConcept: Code & DisplayName values taken from: DICOM Institutional Department/Unit/Service (1.2.840.10008.6.1.817) Context Group CID 7030CodingScheme: “DCM”, “SCT” or “UMLS” (CodingSchemeDesignator) NOTE: The IHE MCWG has proposed a different value for this metadata[8].	O	Onderzoek.Verrichting.Uitvoerder.Zorgverlener.Zorgaanbieder.Afdelingsspecialisme
typeCode	type	CodeableConcept: Code & DisplayName values taken from: DICOM Imaging Procedure (1.2.840.10008.6.1.1436) DCM BCID 101CodingScheme: “LN”, “NICIP”, “SCT” or “I10P” (CodingSchemeDesignator)	R	Onderzoek.Verrichting.VerrichtingType
creationTime	content.attachment.creation	dateTime – YYYY[-MM[-DD[Thh:mm:ss+zz:zz]]]	R	Onderzoek.Verslaginformatie.DatumTijd
hash	content.attachment.hash	Base64Binary (SHA1 hash of the data)	O
languageCode	content.attachment.language	code: BCP-47	O
legalAuthenticator	authenticator	Reference – Practitioner | Organization	O
referenceIdList	context.encounter context.related	CXi.5 (Identifier Type Codes) = “urn:ihe:iti:xds:2015:encounterId”: Reference - Encounter Other CXi.5 (Identifier Type Codes) values (when possible): Reference - Any CXi referenceId attributes: urn:ihe:iti:xds:2015:encounterId urn:ihe:iti:xds:2013:accession urn:ihe:iti:xds:2013:order urn:ihe:iti:xds:2016:studyInstanceUID	O R R R
repositoryUniqueId	content.attachement.url	url – repositoryUniqueId as url (OID) See also: URI	O
serviceStartTime	context.period.start	DateTime	O	Onderzoek.Verrichting.Verrrichtingsstartdatum
serviceStopTime	context.period.end	DateTime	O	Onderzoek.Verrichting.Verrichtingeinddatum
size	content.attachment.size	unsignedInt	O
sourcePatientId	context.sourcePatientInfo	Reference - Patient identifier = sourcePatientId	R
sourcePatientInfo	context.sourcePatientInfo	Reference - Patient Defining “PID-x|value”	R
URI	content.attachement.url	url – repositoryUniqueId as url (URI) See also: repositoryUniqueId	O
title	content.attachment.title	string	R
comments	description	string	O
patientId	subject	Reference - Patient identifier = patientId Identifier example: identifier.system = OIDofAA - where OIDofAA is the OID of the Assigning Authority identifier.value = externalPatientIdentifierValue identifier.assigner – Reference Organization = “ISO”	R	Patient.Identificatienummer
documentuniqueId	masterIdentifier	Identifier	R	Onderzoek.Verslaginformatie.Verslagidentificatienummer

NOTE: When registering an imaging report and corresponding imaging study (i.e. a report and study that are the result of the same radiology event), it is required that the common metadata attributes used in the imaging report DocumentReference and imaging study DocumentReference will have the same values. This is a requirement to ensure that when querying these registered entries from a Document Consumer, the same query filters will yield both the imaging report and the imaging study for a connected event.

There are two ways in which the actual PDF imaging report can be published:

1. Inline: imaging report is included in the DocumentReference as a base64Binary string using the DocumentReference.attachment.data entry.
2. By reference: a reference is included in the DocumentReference as a URI (to the location of the imaging report) using the DocumentReference.attachment.url entry.

In both cases the mimeType will be defined by the DocumentReference.attachment.type = “application/pdf”. The ITI-65 Provide Document Bundle response indicates the success or otherwise of the registration process.

4.3.1.2 Use case 2: Register Imaging Study (Beschikbaarstellen beeldgegevens t.b.v. tijdlijn)

4.3.1.2.1 Introduction

The Register Imaging Study use case enables a document source to publish the existence of an imaging study to the document sharing infrastructure. This involves creating metadata associated with the imaging study and an imaging study manifest (DICOM KOS object) referring to the imaging study contents (DICOM instances). In the case of MHD, the ITI-65 Provide Document Bundle request is used to send the metadata and a copy of the imaging study manifest to the document recipient as part of the MHDS registration process. Please note that the use of the DICOM KOS as an image study manifest in MHD (instead of the FHIR Imaging Study resource) is recommended by the IHE MCWG (with rationale)[5].

The document recipient ITI-65 Provide Document Bundle response indicates whether the registration was successful or not. The document recipient will only register documents whose metadata meets its quality standards (metadata content correctness).

4.3.1.2.2 Actors

The actors for this use case are the document source, which initiates the document registration request using the ITI-65 Provide Document Bundle transaction, and the document recipient, which stores the metadata and imaging study manifest and returns the registration status.

Persons		Systems		MHD(S)
Name	Description	Name	Actors	Transactions
Radiologist	This actor is responsible for creating the metadata corresponding to a radiological imaging study and the imaging study manifest and making both metadata and imaging study manifest available to the Document Recipient.In this role, the radiologist (and/or health organization they work for) is the Imaging Document Source making them also responsible for the metadata added to the document(s).	Document Sharing Infrastructure (Index)	Document Recipient	ITI-65 Provide Document Bundle

4.3.1.2.3 Mapping

The ITI-65 Provide Document Bundle request contains a SubmissionSet type List Resource instance and exactly one DocumentReference instance for each imaging study (binary attachment – “application/dicom”) contained in the request message.

See below table for the metadata used in each DocumentReference. The “DocumentReference Element/Value” are included in the table for clarification purposes. The “Req/Opt” column defines the metadata attribute as being required (R) or optional (O) for this transaction.

The “UnContained Comprehensive Metadata” option is used as reference, for more information we refer you to the IHE profile.

Metadata Attribute	Document-Reference Element	DocumentReference Element Value	Req/Opt	Art-Decor Element
availabilityStatus	status	CodeableConcept Code: “current” DisplayName: “Current” CodingScheme: “http://hl7.org/fhir/ValueSet/document-reference-status”	R
author	author	Reference – Practitioner | Organization	O	Onderzoek.Verrichting.Uitvoerder.Zorgverlener.Naamgegevens.Geslachtsnaam.Achternaam Onderzoek.Verrichting.Locatie.Zorgaanbieder.Zorgaanbiederidentificatienummer Onderzoek.Verrichting.Locatie.Zorgaanbieder.Organisatienaam Onderzoek.Verrichting.Uitvoerder.Zorgverlener.ZorgverlenerRol
classCode	category	CodeableConcept IMAGES Code & DisplayName values taken from XDS classCode Metadata Coding System “1.3.6.1.4.1.19376.1.2.6.1.1”	R
confidentialityCode	securityLabel	CodeableConcept Code & DisplayName values taken from CodingScheme: “2.16.840.1.113883.5.25” (HL7 Confidentiality)The confidentialityCode can carry multiple vocabulary items.	O
eventCodeList	context.event	CodeableConcept Code & DisplayName values taken from: DICOM Modality (1.2.840.10008.6.1.1283) - Context Group CID 29CodingScheme: “DCM” (CodingSchemeDesignator) DICOM Atomic Region/Body Part (4 1.2.840.10008.6.1.2)​ - Context Group CID 4CodingScheme: “SCT” (CodingSchemeDesignator) with values taken from the coarse-grained list defined in Table 3.1 niet gevonden. NOTE: It is necessary to register more than one coarse-grained code when the codes represent overlapping atomic regions / body parts.	R	Onderzoek.Verrichting.VerrichtingAnatomischeLocatie
formatCode	content.format	CodeableConcept Code & DisplayName values taken from CodingScheme: “1.3.6.1.4.1.19376.1.2.7.1” (IHE Format codes)Code "1.2.840.10008.5.1.4.1.1.88.59" DisplayName "DICOM KOS"	R
healthcareFacilityTypeCode	context.facilityType	CodeableConcept Code & DisplayName values taken from CodingScheme: “2.16.840.1.113883.2.4.15.1060” (NL Nictiz/HL7 RoleCodeNLUZIRoleCodeOrganisaties)	O	Verrichting.Uitvoerder.Zorgverlener.Zorgaanbieder.OrganisatieType
practiceSettingCode	context.practiceSetting	CodeableConcept Code & DisplayName values taken from: DICOM Institutional Department/Unit/Service (1.2.840.10008.6.1.817) Context Group CID 7030CodingScheme: “DCM”, “SCT” or “UMLS” (CodingSchemeDesignator) NOTE: The IHE MCWG has proposed a different value for this metadata[8].	O	Onderzoek.Verrichting.Uitvoerder.Zorgverlener.Zorgaanbieder.Afdelingsspecialisme
typeCode	type	CodeableConcept Code & DisplayName values taken from: DICOM Imaging Procedure (1.2.840.10008.6.1.1436) DCM BCID 101CodingScheme: “LN”, “NICIP”, “SCT” or “I10P” (CodingSchemeDesignator)	R	Onderzoek.Verrichting.VerrichtingType
creationTime	content.attachment.creation	dateTime – YYYY[-MM[-DD[Thh:mm:ss+zz:zz]]]	R	Onderzoek.Beeldinformatie.DatumTijd
hash	content.attachment.hash	Base64Binary (SHA1 hash of the data)	O
languageCode	content.attachment.language	code – BCP-47	O
legalAuthenticator	authenticator	Reference – Practitioner | Organization	O
referenceIdList	context.encounter context.related	CXi.5 (Identifier Type Codes) = “urn:ihe:iti:xds:2015:encounterId”: Reference – Encounter Other CXi.5 (Identifier Type Codes) values (when possible): Reference - Any CXi referenceId attributes: urn:ihe:iti:xds:2015:encounterId urn:ihe:iti:xds:2013:accession urn:ihe:iti:xds:2013:order urn:ihe:iti:xds:2016:studyInstanceUID	O R R R
repositoryUniqueId	content.attachement.url	url – repositoryUniqueId as url (OID) See also: URI	O
serviceStartTime	context.period.start	DateTime	O	Onderzoek.Verrichting.Verrrichtingsstartdatum
serviceStopTime	context.period.end	DateTime	O	Onderzoek.Verrichting.Verrichtingeinddatum
size	content.attachment.size	unsignedInt	O
sourcePatientId	context.sourcePatientInfo	Reference - Patient identifier = sourcePatientId	R
sourcePatientInfo	context.sourcePatientInfo	Reference - Patient Defining “PID-x|value”	R
URI	content.attachement.url	url – repositoryUniqueId as url (URI) See also: repositoryUniqueId	O
title	content.attachment.title	string	R
comments	description	string	O
patientId	subject	Reference - Patient identifier = patientId Identifier example: identifier.system = OIDofAA - where OIDofAA is the OID of the Assigning Authority identifier.value = externalPatientIdentifierValue identifier.assigner – Reference Organization = “ISO”	R	Patient.Identificatienummer
documentuniqueId	masterIdentifier	Identifier	R	Onderzoek.Beeldinformatie.Beeldinformatieindentificatienummer

NOTE: When registering an imaging report and corresponding imaging study (i.e. a report and study that are the result of the same radiology event), it is required that the common metadata attributes used in the imaging report DocumentReference and imaging study DocumentReference will have the same values. This is a requirement to ensure that when querying these registered entries from a Document Consumer, the same query filters will yield both the imaging report and the imaging study for a connected event.

There are two ways in which the actual imaging study manifest (DICOM KOS) can be published:

1. Inline: imaging study manifest is included in the DocumentReference as a base64Binary string using the DocumentReference.attachment.data entry.
2. By reference: a reference is included in the DocumentReference as a URI (to the location of the imaging study manifest) using the DocumentReference.attachment.url entry.

In both cases the mimeType will be defined by the DocumentReference.attachment.type = “application/dicom”.

The imaging study manifest or DICOM KOS object should be created and contain at least the DICOM attributes defined below. The DICOM KOS object should only reference a single imaging study (1 to 1 relationship). Most attribute values can be copied from the referenced imaging study in the document source. Other attributes take values as shown.

The ITI-65 Provide Document Bundle response indicates the success or otherwise of the registration process.

4.3.1.3 Use case 3: Query Timeline Data (Raadplegen Tijdlijn Data)

4.3.1.3.1 Introduction

The Query Timeline Data use case enables an imaging document consumer to retrieve a timeline of radiology studies for a specific patient. This use case is implemented using the ITI-67 Find Document References transaction, which allows the imaging document consumer to query for a list of studies (represented in IHE MHD as DocumentReferences) based on patient identifiers and other search criteria. The document registry returns a set of DocumentReferences that match the query criteria, which can then be used to construct a timeline for the patient. By using ITI-67, the imaging document consumer sends out a query request and the document registry sends back the query response.

This will return the registered DocumentReference details, including all known metadata for the document. This can be used to populate the timeline entry representing the document.

4.3.1.3.2 Actors

Persons		Systems		MHD(S)(-I)
Name	Description	Name	Actors	Transactions
Radiologist/ Treating physician	This actor is a healthcare professional that requests access to images and related information from image-generating healthcare professionals. In this role, the radiologist (and/or health organization they work for) is the Imaging Document Consumer.	Document Sharing Infrastructure	Document Responder	ITI-67 Find Document References

4.3.1.3.3 Mapping

The ITI-67 query is issued using the following URL: [base]/DocumentReference?<query>

The query represents a series of encoded name-value pairs (parameters) representing the filter for the query. The query parameters are defined in the below table. The “DocumentReference Query parameter/Value” are included in the table for clarification purposes. The “Req/Opt” column defines the metadata attribute as being required (R) or optional (O) for this transaction.

The patientId and availabilityStatus are mandatory.

Metadata Attribute	DocumentReference	DocumentReference Query Value	Req/Opt	Art-Decor Element
patientId	subject Query parameter or subject:Patient.identifier	parameter as Reference(Patient) parameter as token This is defined by IHE-NL as BSN and will be used in this guide as a 9-digit unique identifier.	R	Patient.Identificatienummer
availabilityStatus	status	parameter as token http://hl7.org/fhir/ValueSet/document-reference-status%7Ccurrent	R
eventCodeList	context.event	parameter as token – system|code NOTE: When using the DICOM Atomic Region/Body Part (4 1.2.840.10008.6.1.2)​ as a query-key, the query-key value should be taken from the coarse-grained list in chapter 3: Requiered Metadata'.	O	Onderzoek.Verrichting.VerrichtingAnatomischeLocatie
classCode	category	parameter as token – category system|code system = “1.3.6.1.4.1.19376.1.2.6.1.1” (XDS classCode Metadata Coding System)	O
typeCode	type	parameter as token – type system|code DICOM Imaging Procedure (1.2.840.10008.6.1.1436) - DCM BCID 101CodingScheme: “LN”, “NICIP”, “SCT” or “I10P” (CodingSchemeDesignator)	O	Onderzoek.Verrichting.VerrichtingType
practiceSettingCode	practiceSetting	parameter as token – system|code DICOM Institutional Department/Unit/Service (1.2.840.10008.6.1.817) Context Group CID 7030CodingScheme: “DCM”, “SCT” or “UMLS” (CodingSchemeDesignator) NOTE: The IHE MCWG has proposed a different value for this metadata[8].	O	Onderzoek.Verrichting.Uitvoerder.Zorgverlener.Zorgaanbieder.Afdelingsspecialisme
creationTime (range)	content.attachment.creation	parameter as dateTime	O	Onderzoek.Verslaginformatie.Verslagidentificatienummer
serviceStartTime (range)	context.period.start	parameter as dateTime	O	Onderzoek.Verrichting.Verrrichtingsstartdatum
serviceStopTime (range)	context.period.stop	parameter as dateTime	O	Onderzoek.Verrichting.Verrichtingeinddatum
healthcareFacilityTypeCode	facilityType	parameter as token - system|code system = “2.16.840.1.113883.2.4.15.1060” (NL Nictiz/HL7 RoleCodeNLUZIRoleCodeOrganisaties)	O	Verrichting.Uitvoerder.Zorgverlener.Zorgaanbieder.OrganisatieType
confidentialityCode	securityLabel	parameter as token – system|code system = “2.16.840.1.113883.5.25” (HL7 Confidentiality)	O
author	author	Reference – Practitioner | Organization	O	Onderzoek.Verrichting.Uitvoerder.Zorgverlener.Naamgegevens.Geslachtsnaam.Achternaam Onderzoek.Verrichting.Locatie.Zorgaanbieder.Zorgaanbiederidentificatienummer Onderzoek.Verrichting.Locatie.Zorgaanbieder.Organisatienaam Onderzoek.Verrichting.Uitvoerder.Zorgverlener.ZorgverlenerRol
formatCode	content.format	parameter as token – system|code 1.3.6.1.4.1.19376.1.2.7.1|urn.ihe.rad: PDF for PDF imaging report 1.3.6.1.4.1.19376.1.2.7.1|1.2.840.10008.5.1.4.1.1.88.59: for KOS imaging study manifest	O

Table 4.9 MHD Metadata Query

The ITI-67 Find Document References response will contain a DocumentReference for each entry matching the request query keys in the Document Registry.

The query response metadata is defined in the table below. The “DocumentReference Element/Values” are included in the table for clarification purposes. The “Req/Key” column defines the metadata attribute as being required (R), “used as query key” (Q) or optional (O) for this transaction. The “used as query key” means that if the metadata attribute was used in the ITI-67 Find Document References request (as a query key) then a matching metadata value is expected in the ITI-67 Find Document References response, otherwise it is optional.

The patientId, availabilityStatus, URI and uniqueId are mandatory.

Metadata Attribute	Document-Reference Element	DocumentReference Element Value	Req/Key	Art-Decor Element
patientId	subject	Reference - Patient identifier = patientId Identifier example: identifier.system = OIDofAA - where OIDofAA is the OID of the Assigning Authority identifier.value = externalPatientIdentifierValue identifier.assigner – Reference Organization = “ISO”	R	Patient.Identificatienummer
availabilityStatus	status	CodeableConcept Code: “current” DisplayName: “Current” CodingScheme: “http://hl7.org/fhir/ValueSet/document-reference-status”	R
author	author	Reference – Practitioner | Organization	Q/O	Onderzoek.Verrichting.Uitvoerder.Zorgverlener.Naamgegevens.Geslachtsnaam.Achternaam Onderzoek.Verrichting.Locatie.Zorgaanbieder.Zorgaanbiederidentificatienummer Onderzoek.Verrichting.Locatie.Zorgaanbieder.Organisatienaam Onderzoek.Verrichting.Uitvoerder.Zorgverlener.ZorgverlenerRol
classCode	category	CodeableConcept IMAGES, REPORTS Code & DisplayName values taken from XDS classCode Metadata Coding System “1.3.6.1.4.1.19376.1.2.6.1.1”	Q/O
confidentialityCode	securityLabel	CodeableConcept Code & DisplayName values taken from CodingScheme: “2.16.840.1.113883.5.25” (HL7 Confidentiality)The confidentialityCode can carry multiple vocabulary items.	Q/O
eventCodeList	context.event	CodeableConcept Code & DisplayName values taken from: DICOM Modality (1.2.840.10008.6.1.1283) - Context Group CID 29CodingScheme: “DCM” (CodingSchemeDesignator) DICOM Atomic Region/Body Part (4 1.2.840.10008.6.1.2)​ - Context Group CID 4CodingScheme: “SCT” (CodingSchemeDesignator) with values taken from the coarse-grained list defined in chapter 3.	Q/O	Onderzoek.Verrichting.VerrichtingAnatomischeLocatie
formatCode	content.format	CodeableConcept Code & DisplayName values taken from CodingScheme: “1.3.6.1.4.1.19376.1.2.7.1” (IHE Format codes) Code "1.2.840.10008.5.1.4.1.1.88.59", DisplayName "DICOM KOS"	Q/O
healthcareFacilityTypeCode	context.facilityType	CodeableConcept Code & DisplayName values taken from CodingScheme: “2.16.840.1.113883.2.4.15.1060” (NL Nictiz/HL7 RoleCodeNLUZIRoleCodeOrganisaties)	Q/O	Verrichting.Uitvoerder.Zorgverlener.Zorgaanbieder.OrganisatieType
practiceSettingCode	context.practiceSetting	CodeableConcept Code & DisplayName values taken from: DICOM Institutional Department/Unit/Service (1.2.840.10008.6.1.817) Context Group CID 7030CodingScheme: “DCM”, “SCT” or “UMLS” (CodingSchemeDesignator) NOTE: The IHE MCWG has proposed a different value for this metadata[8].	Q/O	Onderzoek.Verrichting.Uitvoerder.Zorgverlener.Zorgaanbieder.Afdelingsspecialisme
typeCode	type	CodeableConcept Code & DisplayName values taken from: DICOM Imaging Procedure (1.2.840.10008.6.1.1436) DCM BCID 101CodingScheme: “LN”, “NICIP”, “SCT” or “I10P” (CodingSchemeDesignator)	Q/O
creationTime	content.attachment.creation	dateTime – YYYY[-MM[-DD[Thh:mm:ss+zz:zz]]]	Q/O	Onderzoek.Verslaginformatie.Verslagidentificatienummer
hash	content.attachment.hash	Base64Binary (SHA1 hash of the data)	O
languageCode	content.attachment.language	code – BCP-47	O
legalAuthenticator	authenticator	Reference – Practitioner | Organization	O
referenceIdList	context.encounter context.related	CXi.5 (Identifier Type Codes) = “urn:ihe:iti:xds:2015:encounterId”: Reference – Encounter Other CXi.5 (Identifier Type Codes) values (when possible): Reference - Any CXi referenceId attributes: urn:ihe:iti:xds:2015:encounterId urn:ihe:iti:xds:2013:accession urn:ihe:iti:xds:2013:order urn:ihe:iti:xds:2016:studyInstanceUID	Q/O
repositoryUniqueId	content.attachement.url	url – repositoryUniqueId as url (OID) See also: URI	O
serviceStartTime	context.period.start	DateTime	Q/O	Onderzoek.Verrichting.Verrrichtingsstartdatum
serviceStopTime	context.period.end	DateTime	Q/O	Onderzoek.Verrichting.Verrichtingeinddatum
size	content.attachment.size	unsignedInt	O
sourcePatientId	context.sourcePatientInfo	Reference - Patient identifier = sourcePatientId	O
sourcePatientInfo	context.sourcePatientInfo	Reference - Patient Defining “PID-x|value”	O
URI	content.attachement.url	url – repositoryUniqueId as url (URI) See also: repositoryUniqueId	R
title	content.attachment.title	string	O
comments	description	string	O
documentuniqueId	masterIdentifier	Identifier	R	Onderzoek.Verslaginformatie.Verslagidentificatienummer

Table 4.10 MHD Metadata Query Response

4.3.1.4 Use case 4: Retrieve Imaging Report (Raadplegen Verslag)

4.3.1.4.1 Introduction

The Retrieve Report use case enables an imaging document consumer to retrieve an imaging report for a specific patient, with two possible scenarios as mentioned in the functional design.

1. The radiologist/ treating physician used use case 1 (Retrieve Timeline Data) to create a timeline belonging to a single patient via the ITI-65 Provide Document bundle. Selecting the specific timeline entry will contain the displayed (meta)data details but also define the document uniqueId.
2. The radiologist / attending physician is aware of a previous examination of which they wish to consult the report and the document uniqueId of this examination is known (how this is known is beyond the scope of this use case).

Via one of the two options mentioned above, we assume that the use case begins with a known document uniqueId. The document retrieval will make use of the ITI-68 Retrieve Document and thus include the document uniqueId. The mimeType in the retrieve response will indicate the document type retrieved. Only mimeType of “application/pdf” is supported in this version of the implementation guide.

4.3.1.4.2 Actors

Persons		Systems		MHD(S)(-I)
Name	Description	Name	Actors	Transactions
Radiologist/ Treating physician	This actor is a healthcare professional that requests access to images and related information from image-generating healthcare professionals representing the Imaging Document Consumer.	Document Sharing infrastructure	Document Responder	ITI-68 Retrieve Document

4.3.1.4.3 Mapping

The ITI-68 Retrieve Document response body contains:

• uniqueId .id for the DocumentReference (same as request)
• document mimeType in context.attachtment.contentType = “application/pdf”
• document
  • either in-line base64 encoded (single-part) document in the element content.attachtment.hash or
  • include reference to separate (multi-part) binary document in content.attachment.url for PDF imaging report.

4.3.1.5 Use case 5: Retrieve Images (Raadplegen Beeld)

4.3.1.5.1 Introduction

The Retrieve Images use case enables a imaging document consumer to retrieve an imaging study for a specific patient, with two possible scenarios as mentioned in the functional design.

1. The radiologist/ treating physician used use case 1 (Retrieve Timeline Data) to create a timeline belonging to a single patient via the ITI-65 Provide Document bundle. Selecting the specific timeline entry will contain the displayed (meta)data details but also define the document uniqueId.
2. The radiologist / attending physician is aware of a previous examination of which they wish to consult the report and the document uniqueId of this examination is known (how this is known is beyond the scope of this use case).

Via one of the two options mentioned above, we assume that the use case begins with a known document uniqueId. The document retrieval will make use of the ITI-68 Retrieve Document and thus include the document uniqueId. The mimeType in the retrieve response will indicate the document type retrieved. Only mimeType of “application/dicom” is supported in this version of the implementation guide.

The DICOM KOS object contents defines the DICOM UIDs needed to perform the RAD-107 WADO-RS Retrieve.

4.3.1.5.2 Actors

Persons		Systems		MHD(S)(-I)
Name	Description	Name	Actors	Transactions
Radiologist/ Treating physician	This actor is a healthcare professional that requests access to images and related information from image-generating healthcare professionals representing the Imaging Document Consumer.	Document Sharing Infrastructure	DocumentResponder	ITI-68 Retrieve Document
Imaging Document Source	RAD-107 WADO-RS

4.3.1.5.3 Mapping

The ITI-68 Retrieve Document response body contains:

• uniqueId .id for the DocumentReference (same as request)
• document mimeType in context.attachtment.contentType = “application/dicom”

• document;
  • either in-line base64 encoded (single-part) document in the element content.attachtment.hash
  • or include reference to separate (multi-part) binary document in content.attachment.url for DICOM imaging study manifest as KOS object

The RAD-107 WADO-RS Retrieve is used to retrieve a complete study, series within a study or individual (image) instances based on the URL used:

• STUDY – <wadoRsEndpoint>/studies/{studyUid}
• SERIES – <wadoRsEndPoint>/studies/{studyUid}/series/{seriesUid}
• INSTANCE –<wadoRsEndPoint>/studies/{studyUid}/series/{seriesUid}/instances/{instanceUid}

4.3.2 Profiles and Transactions

The BBS information standard makes use of the following IHE profiles and transactions.

IHE Profile/Transactions	Description
Mobile access to Health Documents (MHD)	The Mobile access to Health Documents (MHD) Profile defines one standardized interface to health document sharing (a.k.a. an Application Programming Interface (API)) for use by mobile devices so that deployment of mobile applications is more consistent and reusable. In this context, mobile devices include tablets, smart-phones, and embedded devices including home-health devices.
Mobile Health Document Sharing	The Mobile Health Document Sharing (MHDS) Profile defines Document Sharing Exchange using IHE-profiled FHIR® standard, rather than the legacy IHE profiles that are dominated by XDS and HL7® v2.
ITI-65 Provide Document Bundle	The Provide Document Bundle [ITI-65] transaction passes a Provide Document Bundle Request from a Document Source to a Document Recipient.
ITI-67 Find Document References	The Find Document References transaction is used to find DocumentReference Resources that satisfy a set of parameters. It is equivalent to the FindDocuments and FindDocumentsByReferenceId queries from the Registry Stored Query [ITI-18] transaction. The result of the query is a FHIR Bundle containing DocumentReference Resources that match the query parameters.
ITI-68 Retrieve Document	The Retrieve Document [ITI-68] transaction is used by the Document Consumer to retrieve a document from the Document Responder.
RAD-107 WADO-RS Retrieve	The WADO-RS Retrieve [RAD-107] transaction accesses DICOM SOP Instances via an HTTP interface.

5 References

Reference	Document Title	Date, Version, Source
[1]	Landelijke beschikbaarheid radiologische beelden voor zorgverlener en patiënt: functionele vereisten Translates as “National availability of radiological images for the health professional and patient: functional requirements”	2018-11-15, V1.0, NVvR
[2]	Definitief rapport praktijkbeoordeling beeldbeschikbaarheid en toelichting 1.0	2023-07-28, 3030060023 V1.0, NVvR
[3]	MCWG Recommendation on Standards Positioning for sharing imaging information at the national/regional level. Positioning HL7 FHIR and DICOM along with the related IHE profiles such as MHD(FHIR), XDS-I, XCA-I, WIA (DICOMweb).	MCWG-Issue-Positioning--Imaging-Standards-Profiles-V5
[4]	MCWG Recommendation on Metadata and Linkages for sharing imaging information at the national/regional level. Effective sharing with linkage between imaging requests (clinician, imaging production), imaging reports, imaging examinations. Setting an imaging metadata strategy for key filtering elements in queries.	MCWG-Recommendation-Imaging Sharing Metadata-Linkages-V7-Approved
[5]	MCWG Recommendation on Imaging Study Manifest for sharing imaging information at the national/regional level.	IHE MCWG
[6]	Richtlijn_BSN_in_Dicom - DUTCH NATIONAL PATIENT ID (BSN) & DICOM OBJECTS	2010-04-15, V1.0, Nictiz
[7]	eHealth Network guideline on medical imaging studies and imaging reports	2023-10-23, Release 1.0
[8]	https://nictiz.atlassian.net/browse/NICTIZ-9735	2023-12-04, v1.0, Nictiz

6 Release Notes

Changes compared to previous release.

BITS ticket	Short description
BBS-81 BBS-83 BBS-85	Small adjustments
BBS-76	Mapping in UC1 changed from Onderzoek.Verrichting.Locatie.Zorgaanbieder.AfdelingSpecialisme = practiceSettingCode to Onderzoek.Verrichting.Uitvoerder.Zorgverlener.Specialisme = authorSpecialty
BBS-82	Added information about Radiology query parameters
BBS-84	Changed DICOM SR to PDF in chapter 7.1