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 op the Servicedesk.

1 Stakeholders Note - 12 December 2024

This alpha-2 version of the BBS information standard will be further developed as an alpha-3 version with focus on the following:

1) Better alignment with inputs:

1. NvVR "Landelijke beschikbaarheid radiologische beelden voor zorgverlener en patiënt: functionele vereisten"
2. NEN 7541 Beeldbeschikbaarheid
3. TA Beeldbeschikbaarheid
4. eHN Guideline on Medical Imaging Studies and Reports
5. Xt-EHR - D7.2 Medical imaging studies and related imaging reports: EEHRxF, requirements and specifications for EHR systems
6. MyHealth@EU - Medical Imaging Studies (MIS)

Special attention will be paid to avoiding duplication between these inputs and the BBS IS.

2) Continued support for the IHE XDS-I, XCA-I and MHD/WADO-RS approaches to document sharing for the pull scenarios.

3) Simplified approach to metadata definition - prioritize parameter alignment based on an 80-20 approach. Identify parameters that provide 80% search requirement coverage and focus on ways of introducing these in practice.

4) Introduction of document sharing for push scenarios.

The intention is to make BBS IS alpha-3 available for open consultation by the end of Q1 2025

2 Introduction

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

2.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” [3] 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/WIA: Mobile access to Health Documents / Web-based Image Access (1)

This document assumes reader familiarity with these IHE profiles. This document is not an introduction to XDS-I.b, XCA-I, MHD/WIA 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.

2.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.
FAIR	FAIR data refers to data that meet the following principles: Findability: Data should be easy to find and accessible with clear metadata and identifiers. Accessibility: Data should be openly available and retrievable by both humans and machines. Interoperability: Data should be structured in a way that allows integration with other datasets. Reusability: Data should be well-described and licensed for reuse.
FHIR	Fast Healthcare Interoperability Resources
IHE	Integrating the Healthcare Enterprise
Image Availability	The name of this project, in the Netherlands known as Beeldbeschikbaarheid (abbreviated to BBS).
Imaging Report (Report)	An imaging report reflects the observations and interpretations of one or more imaging studies. It usually contains elements such as the reason why the study is requested, relevant contextual medical information, the used modality and its settings, procedures and body localisations that were used, a description of the observations and findings, exposure information, conclusion and advice. An imaging report is signed off/approved by a senior diagnostic consultant and should not be changed thereafter.
Imaging Study (Image)	An imaging study comprises a set of objects, including images and other objects, that were made for a specific purpose and usually in response to a request from a healthcare provider. The Imaging Study does not include the Imaging Report (current scope is unstructured PDF report only).
Imaging Study Manifest (Manifest)	A document listing the key information about the content of an imaging study. It acts as a summary for the actual imaging study that is large (typically megabyte or gigabyte size) and complex (hundreds of data elements). It includes location pointers to its image content and organises this information according to the well-established model of an imaging study made of one or more series and each series made of instances or images.
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.
MCWG	(IHE Europe) Multi-Country Working Group: a group of national (country) representatives sharing deployment experiences and best practices in imaging report and study sharing.
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.
Metadata	Metadata are information parameters that provide contextual information about the actual information within a document (or other information container). Examples are: date of event and/or publication, size in bytes, technical format, template, standard version, document version, author specialty, functional category et cetera.
MHD	IHE Mobile access to Health Documents
NIHEMDS	The NIHEMDS is the National IHE MetaData Set (Dutch: Nationale IHE MetaData Set)
NVvR	Nationale Vereniging van Radiologen: The Dutch Association of Radiologists
Studies	Grouping of images and reports relating to a single patient for a common diagnostic need.
SWF	IHE Scheduled Workflow
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
WIA	IHE Web-based Image Access
XCA-I	IHE Cross-Community Access for Imaging
XDS-I.b	IHE Cross-Enterprise Imaging Document Sharing
XDS	IHE Cross-Enterprise Document Sharing
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

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

This version of the implementation guide only covers the exchange of radiology imaging studies and reports. It is, of course, realized that this is a limited scope. Future versions will include other imaging study and report types (examples: cardiology, pathology, encounter based imaging, etc).

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.

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:

• Identification [NEN-7518] (of client and provider - who are you?)
• Authentication [NEN-7518] (establish that you really are who you say)
• Localization [NEN-7519] (where/what information known about the client and provider?)
• Consent [NEN-7517] (from the patient for the sharing of medical information)
• Authorization (what information are you allowed to access?)
• Addressing (digital address of provider or organization)
• Logging [NEN-7513] (audit trail - who did what, where, when and why?)

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

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

3.2 Radiologist and/or Treating Physician

It is assumed that the radiologist and/or treating physician, as a person who participates in using the document sharing infrastructure, is signed on, authenticated and has authorization & consent to access the necessary (patient) information stored in the document sharing infrastructure (or in other words, an authenticated healthcare professional who has an active treatment relationship with the patient). The way in which the person achieves this state is beyond the scope of this implementation guide but is expected to be facilitated by use of the generic infrastructure.

4 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. These are 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. The metadata available to the Imaging Document Source for document registration, originates during radiology (or in general diagnostic) imaging workflows, and is generated from procedural information in the local EMR/RIS/PACS systems. Standardizing metadata is, therefore, largely a responsibility of the local radiology departments. It is recommended that radiology departments standardized their operating procedures by using the IHE RAD Scheduled Workflow (SWF) profile. 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/selection specific to certain document content. When used for imaging document sharing the event codes represent three types of information about the imaging event:

1. Acquisition Modality used
2. Atomic Region / Body Part affected
3. Imaging Procedure Code (Display Name) - added following MCWG Recommendation

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.

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

Furthermore, in this IG there are several tables regarding the metadata in the different use cases. As we develop a national standard, the “Conformance” column in these tables defines the metadata attribute according to the NIHEMDS.

Code	Meaning	Explanation
R	Required	A value for the attribute shall be supplied by the sending Actor when sending the submission.
R2	Required if Known	A value for the attribute shall be supplied by the sending Actor when sending the submission unless the Actor does not have any value for the attribute.
R3	Required	For Stable DocumentEntries and not allowed for On-Demand DocumentEntries.
O	Optional	The sending Actor may or may not supply a value for this attribute.
X	Prohibited	When sending a submission, a value for the attribute shall not be supplied by the sending Actor.
C	Conditional	The optionality depends on certain conditions.

Table 3.2 NIHEMDS Conformance

4.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 any other DICOM object. The DICOM KOS document is selected as the recommended imaging study manifest in this implementation guide - see also "MCWG Recommendations on Imaging Study Manifest for sharing imaging information at the national/regional level" [5].

The FHIR Imaging Study may become more widely used as and when the MHD profile is more widely supported.

5 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/WIA: Mobile access to Health Documents / Web-based Image Access

Figure 4.1 Image Availability Information Standard

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

• 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 or other).

The Functional Design (FO) defines 7 use cases:

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

Push based use cases

1. Sturen Beeld
2. Sturen Verslag

Note: Only the Pull based use cases are defined in this release. The Push based use case will be addressed in a later release.

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

5.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-I.b 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.

Support for the following XDS-I.b Options is mandated by this implementation guide for the Imaging Document Source (provides the imaging study and imaging reports):

• Set of DICOM Instances - RAD TF-1: 18.2.1
• PDF Report - RAD TF-1: 18.2.2
• Reference ID - RAD TF-1: 18.2.6

Support for the following XDS-I.b Option is strongly recommended by this implementation guide for the Imaging Document Source:

• DICOM Retrieve by WADO-RS - RAD TF-1:18.2.7

Support for the following XDS-I.b Option is strongly recommended by this implementation guide for the Imaging Document Consumer (uses the imaging study and imaging reports):

• DICOM Retrieve by WADO-RS - RAD TF-1:18.2.7

Note: The DICOM Retrieve by WADO-RS option for both Imaging Document Source and Imaging Document Consumer is an emerging XDS-I.b option and is not yet implemented by many systems. It is strongly recommended for implementation when new versions allow.

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.

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

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

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

Note: This implementation guide explicitly states that the RAD-68 Provide & Register Imaging Document Set transaction should be used for Imaging Report registration to ensure that the metadata provided corresponds with any linked Imaging Study registration. The ITI-41 "Provide and Register Document Set-b Request" is therefore not used.

5.1.1.1.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 report and returns the registration status.

Participant	Description	Actors		Transactions
Radiologist	In this role, the radiologist (and/or health organization they work for) is responsible for the quality of the metadata corresponding to a imaging study report and making both metadata and imaging study report available for registration.	Imaging Document Source	Document Repository	XDS-I.b RAD-68 Provide & Register Imaging Document Set

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

See the below table for the metadata used in each DocumentEntry - see https://profiles.ihe.net/ITI/TF/Volume3/ch-4.1.html#4.1.3.2 - also, note that:

• The “ebXML attribute and element values” are included in the table for clarification purposes.
• Conformance is defined in terms of R (Required - value for the attribute will be supplied by the sending actor), R2 (Required if known - value for the attribute will be supplied by the sending actor when the value is known), O (Optional - value may or may not be supplied by the sending actor).
• 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.

Metadata Attribute	ebXML attribute and element values	Conformance	Cardinality	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	R2	0..n	* Onderzoek.Verrichting.Uitvoerder .Zorgverlener.Naamgegevens.Geslachtsnaam.Achternaam Onderzoek.Verrichting.Locatie .Zorgaanbieder.Zorgaanbiederidentificatienummer Onderzoek.Verrichting.Locatie .Zorgaanbieder.Organisatienaam Onderzoek.Verrichting.Uitvoerder .Zorgverlener.ZorgverlenerRol
classCode	classificationScheme: "urn:uuid:41a5887f-8865-4c09-adf7-e362475b143a" Code & DisplayName values taken from XDS classCode Metadata Coding System “1.3.6.1.4.1.19376.1.2.6.1” Code: "REPORTS", DisplayName: "Reports"	R	1..1
confidentialityCode	classificationScheme: "urn:uuid:f4f85eac-e6cb-4883-b524-f2705394840f" Code & DisplayName values taken from HL7 Confidentiality CodingScheme: “2.16.840.1.113883.5.25”. Code "N", DisplayName "normal" Code "R", DisplayName "restricted" Code "V", DisplayName "very restricted"	R	1..n
eventCodeList	classificationScheme: "urn:uuid:2c6b8cb7-8b2a-4051-b291-b1ae6a575ef4" Code & DisplayName values taken from: DICOM Modality (1.2.840.10008.6.1.19): Context Group CID 29 CodingScheme: “DCM” (CodingSchemeDesignator) DICOM Atomic Region/Body Part (4 1.2.840.10008.6.1.2): Context Group CID 4 CodingScheme: “SCT” (CodingSchemeDesignator) with values taken from the coarse-grained list defined in table 3.1 Required Metadata DICOM Imaging Procedure Code - DisplayName (from the Procedure Code Sequence (0008,1032)) At least one Modality eventCode, one Atomic Region/Body Part eventCode and one Imaging Procedure Code eventCode should be registered but more of each type are permitted depending on the actual imaging study contents. Note: It is necessary to register more than one coarse-grained Atomic Region/Body Part eventCode when the codes represent overlapping atomic regions / body parts.	R2	0..n	* 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 Report (XDS-I.b)"	R	1..1
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”	R	1..1	* Verrichting.Uitvoerder.Zorgverlener .Zorgaanbieder.OrganisatieType
practiceSettingCode	classificationScheme: "urn:uuid:cccf5598-8b07-4b77-a05e-ae952c785ead" Codes and DisplayNames taken from MCWG recommended list of 88 SNOMED CT specialty codes. Imaging reports and studies are associated with the Radiology specialty with the following practiceSettingCode value: Code: "394734003", DisplayName: "Radiological specialties"	R	1..1	* Onderzoek.Verrichting.Uitvoerder .Zorgverlener.Zorgaanbieder.Afdelingsspecialisme
typeCode	classificationScheme: "urn:uuid:f0306f51-975f-434e-a61c-c59651d33983" Code System Name SNOMED CT 2.16.840.1.113883.6.96 values Use the SNOMED CT display name of the procedure code sequence in (0008,1032). Closed list of values are provided in the Dutch DHD T-REX https://trex.dhd.nl/ subset (Thesaurus containing all procedures used in The Netherlands).	R	1..1	* Onderzoek.Verrichting.VerrichtingType
creationTime	Slot name = creationTime, Value as DTM: YYYY[MM[DD[hh[mm[ss]]]]]	R	1..1	* Onderzoek.Verslaginformatie.DatumTijd
hash	Slot name = hash, Value as SHA1 hash	O	0..1
languageCode	Slot name = languageCode, Value as String	R	1..1
legalAuthenticator	Slot name = legalAuthenticator, Value as XCN	O	0..1
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 Use the AccessionNumber + AssigningAuthority (AA), StudyUID and OrderNumber + AA (if known)	R	1..n
repositoryUniqueId	Slot name = repositoryUniqueId, Value as OID	O	0..1
serviceStartTime	Slot name = serviceStartTime, Value as DTM	R2	0..1	* Onderzoek.Verrichting.Verrichtingstartdatum
serviceStopTime	Slot name = serviceStopTime, Value as DTM	R2	0..1	* Onderzoek.Verrichting.Verrichtingeinddatum
size	Slot name = size, Value as Integer	O	0..1
sourcePatientId	Slot name = sourcePatientId, Value as CX	R	1..1
sourcePatientInfo	Slot name = sourcePatientInfo, Value as Field Field sourcePatientInfo examples: “PID-x|value”	O	0..1
URI	Slot name = URI, Value = blank (recommended by NIHEMDS)	O	0..1
title	Name.LocalizedString, Value = title (DICOM Imaging Procedure Code - DisplayName (from the Procedure Code Sequence (0008,1032)))	R	1..1
comments	Description.LocalizedString, Value = comments	O	0..1
patientId	identificationScheme: "urn:uuid:58a6f841-87b3-4a3e-92fd-a8ffeff98427" Name.LocalizedString value = XDSDocumentEntry.patientId, Value as CX CX Value example: BSN^^^&2.16.840.1.113883.2.4.6.3&ISO (where "2.16.840.1.113883.2.4.6.3" is the OID of the Assigning Authority)	R	1..1	* Patient.Identificatienummer
document uniqueId	identificationScheme: "urn:uuid:2e82c1f6-a085-4c72-9da3-8640a32e42ab" Name.LocalizedString value = XDSDocumentEntry.uniqueId, Value as Identifier The XDS-I.b Repository will assign the document a uniqueId at the time of initial storage.	O	0..1	* 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.

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

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

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

Participant	Description	Actors		Transactions
Radiologist	In this role, the radiologist (and/or health organization they work for) is responsible for the quality of the metadata corresponding to a imaging study manifest and making both metadata and imaging study manifest available for registration.	Imaging Document Source	Document Repository	XDS-I.b RAD-68 Provide & Register Imaging Document Set

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

See the below table for the metadata used in each DocumentEntry - see https://profiles.ihe.net/ITI/TF/Volume3/ch-4.1.html#4.1.3.2 - also, note that:

• The “ebXML attribute and element values” are included in the table for clarification purposes.
• Conformance is defined in terms of R (Required - value for the attribute will be supplied by the sending actor), R2 (Required if known - value for the attribute will be supplied by the sending actor when the value is known), O (Optional - value may or may not be supplied by the sending actor).

Metadata Attribute	ebXML attribute and element values	Conformance	Cardinality	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	R2	0..n	* Onderzoek.Verrichting.Uitvoerder .Zorgverlener.Naamgegevens.Geslachtsnaam.Achternaam Onderzoek.Verrichting.Locatie .Zorgaanbieder.Zorgaanbiederidentificatienummer Onderzoek.Verrichting.Locatie .Zorgaanbieder.Organisatienaam Onderzoek.Verrichting.Uitvoerder .Zorgverlener.ZorgverlenerRol
classCode	classificationScheme: "urn:uuid:41a5887f-8865-4c09-adf7-e362475b143a" Code & DisplayName values taken from XDS classCode Metadata Coding System “1.3.6.1.4.1.19376.1.2.6.1” Code: "IMAGES", DisplayName: "Images"	R	1..1
confidentialityCode	classificationScheme: "urn:uuid:f4f85eac-e6cb-4883-b524-f2705394840f" Code & DisplayName values taken from HL7 Confidentiality CodingScheme: “2.16.840.1.113883.5.25”. Code "N", DisplayName "normal" Code "R", DisplayName "restricted" Code "V", DisplayName "very restricted"	R	1..n
eventCodeList	classificationScheme: "urn:uuid:2c6b8cb7-8b2a-4051-b291-b1ae6a575ef4" Code & DisplayName values taken from: DICOM Modality (1.2.840.10008.6.1.19): Context Group CID 29 CodingScheme: “DCM” (CodingSchemeDesignator) DICOM Atomic Region/Body Part (4 1.2.840.10008.6.1.2): Context Group CID 4 CodingScheme: “SCT” (CodingSchemeDesignator) with values taken from the coarse-grained list defined in table 3.1 Required Metadata DICOM Imaging Procedure Code - DisplayName (from the Procedure Code Sequence (0008,1032)) At least one Modality eventCode, one Atomic Region/Body Part eventCode and one Imaging Procedure Code eventCode should be registered but more of each type are permitted depending on the actual imaging study contents. Note: It is necessary to register more than one coarse-grained Atomic Region/Body Part eventCode when the codes represent overlapping atomic regions / body parts.	R2	0..n	* Onderzoek.Verrichting.VerrichtingAnatomischeLocatie
formatCode	classificationScheme: "urn:uuid:a09d5840-386c-46f2-b5ad-9c3699a4309d" Code & DisplayName values taken from DICOM UID Registry CodingScheme: “1.2.840.10008.2.6.1” Code: "1.2.840.10008.5.1.4.1.1.88.59", DisplayName: "KOS"	R	1..1
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”	R	1..1	* Verrichting.Uitvoerder.Zorgverlener .Zorgaanbieder.OrganisatieType
practiceSettingCode	classificationScheme: "urn:uuid:cccf5598-8b07-4b77-a05e-ae952c785ead" Codes and DisplayNames taken from MCWG recommended list of 88 SNOMED CT specialty codes. Imaging reports and studies are associated with the Radiology specialty with the following practiceSettingCode value: Code: "394734003", DisplayName: "Radiological specialties"	R	1..1	* Onderzoek.Verrichting.Uitvoerder .Zorgverlener.Zorgaanbieder.Afdelingsspecialisme
typeCode	classificationScheme: "urn:uuid:f0306f51-975f-434e-a61c-c59651d33983" Code System Name SNOMED CT 2.16.840.1.113883.6.96 values Use the SNOMED CT display name of the procedure code sequence in (0008,1032). Closed list of values are provided in the Dutch DHD T-REX https://trex.dhd.nl/ subset (Thesaurus containing all procedures used in The Netherlands).	R	1..1	* Onderzoek.Verrichting.VerrichtingType
creationTime	Slot name = creationTime, Value as DTM - YYYY[MM[DD[hh[mm[ss]]]]]	R	1..1	* Onderzoek.Beeldinformatie.DatumTijd
hash	Slot name = hash, Value as SHA1 hash	O	0..1
languageCode	Slot name = languageCode, Value as String	R	1..1
legalAuthenticator	Slot name = legalAuthenticator, Value as XCN	O	0..1
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 Use the AccessionNumber + AssigningAuthority (AA), StudyUID and OrderNumber + AA (if known)	R	1..n
repositoryUniqueId	Slot name = repositoryUniqueId, Value as OID	O	0..1
serviceStartTime	Slot name = serviceStartTime, Value as DTM	R2	0..1	* Onderzoek.Verrichting.Verrichtingstartdatum
serviceStopTime	Slot name = serviceStopTime, Value as DTM	R2	0..1	* Onderzoek.Verrichting.Verrichtingeinddatum
size	Slot name = size, Value as Integer	O	0..1
sourcePatientId	Slot name = sourcePatientId, Value as CX	R	1..1
sourcePatientInfo	Slot name = sourcePatientInfo, Value as Field Field sourcePatientInfo examples: “PID-x|value”	O	0..1
URI	Slot name = URI, Value = blank (recommended by NIHEMDS)	O	0..1
title	Name.LocalizedString, Value = title (DICOM Imaging Procedure Code - DisplayName (from the Procedure Code Sequence (0008,1032)))	R	1..1
comments	Description.LocalizedString, Value = comments	O	0..1
patientId	identificationScheme: "urn:uuid:58a6f841-87b3-4a3e-92fd-a8ffeff98427" Name.LocalizedString value = XDSDocumentEntry.patientId, Value as CX CX Value example: BSN^^^&2.16.840.1.113883.2.4.6.3&ISO (where "2.16.840.1.113883.2.4.6.3" is the OID of the Assigning Authority)	R	1..1	* Patient.Identificatienummer
document uniqueId	identificationScheme: "urn:uuid:2e82c1f6-a085-4c72-9da3-8640a32e42ab" Name.LocalizedString value = XDSDocumentEntry.uniqueId, Value as Identifier The XDS-I.b Repository will assign the document a uniqueId at the time of initial storage.	O	0..1	* 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.

5.1.1.2.4 DICOM KOS Object Attributes

The imaging study manifest or DICOM KOS object must 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	Value copied from referenced PACS study > patient attributes.
Patient ID​ (0010,0020)​	LO	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).
Issuer of Patient ID (0010,0021)	LO	Value copied from referenced PACS study > patient attributes.
Patient's Birth Date​ (0010,0030)​	DT	Value copied from referenced PACS study > patient attributes.
Patient's Sex​ (0010,0040)​	CS	Value copied from referenced PACS study > patient attributes.
Other Patient IDs Sequence (0010,1002)	SQ
> Patient ID​ (0010,0020)​	LO	Value copied from referenced PACS study > patient attributes.
> Issuer of Patient ID (0010,0021)	LO	Value copied from referenced PACS study > patient attributes.
General Study Module
Study Instance UID​ (0020,000D)	UI	Value copied from referenced PACS study > study attributes. Copying the referenced PACS study Study Instance UID ensures a 1 to 1 relationship between KOS and referenced study (MCWG recommendation).
Study Date​ (0008,0020)	DA	Value copied from referenced PACS study > study attributes.
Study Time​ (0008,0030)​	TM	Value copied from referenced PACS study > study attributes.
Referring Physician's Name​ (0008,0090)​	PN	Value copied from referenced PACS study > study attributes.
Accession Number (0008,0050)	SH	Value copied from referenced PACS study > study attributes.
Issuer of Accession Number Sequence (0008,0051)	SQ	Value copied from referenced PACS study > study attributes.
> Local Namespace Entity ID (0040,0031)	UT	Value copied from referenced PACS study > study attributes.
Study Description (0008,1030)	LO	Value copied from referenced PACS study > study attributes.
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" - recommended value
General Equipment
Manufacturer​ (0008,0070)​	LO	Name of equipment manufacturer
Key Object Document
Instance Number​ (0020,0013)​	IS	"1” - recommended 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	Value copied from General Study > Study Instance UID​ (0020,000D). Note that if this KOS document is shared or exchanged, this same Study Instance UID must be present in the ReferenceIdList (urn:ihe:iti:xds:2016:studyInstanceUID) metadata.
> 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.
>> Local Namespace Entity ID (0040,0031)	UT	Identifies an entity within the local namespace or domain.
> 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.
>> Local Namespace Entity ID (0040,0031)	UT	Identifies an entity within the local namespace or domain.
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). Note that if this KOS document is shared or exchanged, this same Study Instance UID must be present in the ReferenceIdList (urn:ihe:iti:xds:2016:studyInstanceUID) metadata.
> 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 (DICOM UID of Imaging Document Source) that is used as a reference to obtain the actual retrieval end-point (type and address) via the generic Addressing function. Note: The accessibility level of the end-point address (exposure to the Imaging Document Consumer) as being intra-mural (within a document sharing community) or extra-mural (between document sharing communities) is beyond the scope of this KOS specification.
>> Retrieve URL​ (0008,1190)​	UR	The Retrieve URL is the Base URI (end-point address) + Study Instance UID (0020,000D) + Series Instance UID (0020,000E), so that, if left unchanged, can be used to retrieve the instances of the series where the Retrieve URL is placed in the tree of references. It could be changed to perform a retrieve at an instance or entire study level. The end-point type (WADO-URI or WADO-RS) is not conveyed by this attribute. The MCWG recommendation is to define the end-point type as being WADO-RS by default meaning that the value of this Retrieve URL can be used directly for DICOM Series level retrieval using a WADO-RS service. Note: The accessibility level of the end-point address (exposure to the Imaging Document Consumer) as being intra-mural (within a document sharing community) or extra-mural (between document sharing communities) is beyond the scope of this KOS specification.
>> 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 the remaining attribute values
> Code Value (0008,0100)	SH	"113030"
> Coding Scheme Designator (0008,0102)	SH	"DCM"
> Code Meaning (0008,0104)	LO	"Manifest"
Continuity of Content (0040,A050)	CS	"SEPARATE"
Content Template Sequence (0040,A504)	SQ
> Mapping Resource (0008,0105)	CS	"DCMR"
> Template Identifier (0040,DB00)	CS	"2010"
Observation DateTime (0040,A032)	DT
Content Sequence (0040,A730)	SQ	One or more Items shall be included in this Sequence – each item is a reference to one of the instances in referenced study
for each series in referenced PACS study{
for each instance in referenced PACS series{
> Relationship Type (0040,A010)	CS	"CONTAINS"
> Value Type (0040,A040)	CS	"IMAGE" other allowed values are "WAVEFORM" and "COMPOSITE"
> Referenced SOP Sequence (0008,1199)	SQ	Only one item shall be included
>> 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)
}
}
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.

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

5.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), availabilityStatus (Approved)

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.

5.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 as a list of imaging study reports and imaging study manifests.

Participant	Description	Actors		Transactions
Radiologist / Treating Physician	In this role, the radiologist or treating physician requests an overview of previous imaging study reports and and imaging study manifests, for the given patient, from the local community registry.	Imaging Document Consumer	Document Registry	XDS.b ITI-18 Registry Stored Query

5.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 "Intended Use" column specifies the way in which the data elements can be used to define the query request and filter the query responses.

• PF - Primary Filtering: Metadata attribute primarily used for querying documents (Registry Stored Query). This may be a narrowly targeted query (looking for a specific or small set of documents) or a broad query intended to select a manageable set of likely relevant documents.
• SF - Secondary Filtering: Metadata attribute intended to be returned with the matches of a primary query and allow a human (or application) to filter out, amongst the returned candidates, the entries that are not relevant and need not be retrieved.

The patientId and availablityStatus are mandatory.

Metadata Attribute	ebXML query key	Intended Use	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.	PF	* Patient.Identificatienummer
availabilityStatus	Slot name = $XDSDocumentEntryStatus Value = “urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Approved”	PF
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. The DICOM Imaging Procedure Code - DisplayName (from the Procedure Code Sequence (0008,1032)) should be used for secondary filtering (SF). Zero or more query-keys can be defined.	PF	* Onderzoek.Verrichting.VerrichtingAnatomischeLocatie
classCode	Slot name = $XDSDocumentEntryClassCode, Value = IMAGES, REPORTS	PF or SF
typeCode	Slot name = $XDSDocumentEntryTypeCode, Value = typeCodeValue	SF	* Onderzoek.Verrichting.VerrichtingType
practiceSettingCode	Slot name = $XDSDocumentEntryPracticeSettingCode, Value = practiceSettingCodeValue	PF	* Onderzoek.Verrichting.Uitvoerder .Zorgverlener.Zorgaanbieder.Afdelingsspecialisme
creationTime (range)	Slot name = $XDSDocumentEntryCreationTimeFrom, Value = creationTimeFromValue Slot name = $XDSDocumentEntryCreationTimeTo, Value = creationTimeToValue	SF	* Onderzoek.Verslaginformatie.DatumTijd
serviceStartTime (range)	Slot name = $XDSDocumentEntryServiceStartTimeFrom, Value = serviceStartTimeFromValue Slot name = $XDSDocumentEntryServiceStartTimeTo, Value = serviceStartTimeToValue	PF	* Onderzoek.Verrichting.Verrichtingstartdatum
serviceStopTime (range)	Slot name = $XDSDocumentEntryServiceStopTimeFrom, Value = serviceStopTimeFromValue Slot name = $XDSDocumentEntryServiceStopTimeTo, Value = serviceStopTimeToValue	PF	* Onderzoek.Verrichting.Verrichtingeinddatum
healthcareFacilityTypeCode	Slot name = $XDSDocumentEntryHealthcareFacilityTypeCode, Value = healthcareFacilityTypeCodeValue	PF or SF	* Verrichting.Uitvoerder.Zorgverlener .Zorgaanbieder.OrganisatieType
confidentialityCode	Slot name = $XDSDocumentEntryConfidentialityCode, Value = N, R, V	PF
author	Slot name = $XDSDocumentEntryAuthorPerson, Value = authorValue	SF	* Onderzoek.Verrichting.Uitvoerder .Zorgverlener.Naamgegevens.Geslachtsnaam.Achternaam Onderzoek.Verrichting.Locatie .Zorgaanbieder.Zorgaanbiederidentificatienummer Onderzoek.Verrichting.Locatie .Zorgaanbieder.Organisatienaam Onderzoek.Verrichting.Uitvoerder .Zorgverlener.ZorgverlenerRol
entryUUID	Slot name = $uuid, Value = urn:uuid:uuidValue	PF

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.
• Conformance is defined in terms of R (Required - value for the attribute will be supplied by the responding actor when responding to a query), R2 (Required if known - value for the attribute will be supplied by the responding actor when responding to a query if a value is available to the actor. For the Document Registry it must supply the value specified in the submission request), R3 (Required for Stable DocumentEntries and not allowed for On-Demand DocumentEntries), O (Optional - the responding actor may or may not supply a value for this attribute. For the Document Registry it must supply the value specified in the submission request).

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

Metadata Attribute	Query response ebXML attribute and element values	Conformance	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
document uniqueId	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: DICOM Modality (1.2.840.10008.6.1.19) - Context Group CID 29 CodingScheme: “DCM” (CodingSchemeDesignator) DICOM Atomic Region/Body Part (4 1.2.840.10008.6.1.2)​ - Context Group CID 4 CodingScheme: “SCT” (CodingSchemeDesignator), see the coarse-grained list in chapter 3. DICOM Imaging Procedure Code - DisplayName (from the Procedure Code Sequence (0008,1032)) Note: This metadata attribute may contain multiple values for Modality, Atomic Region/Body Part and Imaging Procedure Code when either a multi-modality study or overlapping atomic regions / body parts have been registered for the document entry.	O	* 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	R2	* Onderzoek.Verrichting.Uitvoerder .Zorgverlener.Naamgegevens.Geslachtsnaam.Achternaam Onderzoek.Verrichting.Locatie .Zorgaanbieder.Zorgaanbiederidentificatienummer Onderzoek.Verrichting.Locatie .Zorgaanbieder.Organisatienaam Onderzoek.Verrichting.Uitvoerder .Zorgverlener.ZorgverlenerRol
classCode	classificationScheme: "urn:uuid:41a5887f-8865-4c09-adf7-e362475b143a" Code & DisplayName values taken from XDS classCode Metadata Coding System “1.3.6.1.4.1.19376.1.2.6.1” Code "IMAGES", DisplayName "Images" Code "REPORTS", DisplayName "Reports"	R
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”. Code "N", DisplayName "normal" Code "R", DisplayName "restricted" Code "V", DisplayName "very restricted"	R
formatCode	classificationScheme: "urn:uuid:a09d5840-386c-46f2-b5ad-9c3699a4309d" Report 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 Report (XDS-I.b)" Image Code & DisplayName values taken from CodingScheme: “1.2.840.10008.2.6.1” (DICOM UID Registry) Code "1.2.840.10008.5.1.4.1.1.88.59", DisplayName "KOS"	R
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)	R	* Verrichting.Uitvoerder.Zorgverlener .Zorgaanbieder.OrganisatieType
practiceSettingCode	classificationScheme: "urn:uuid:cccf5598-8b07-4b77-a05e-ae952c785ead" Codes and DisplayNames taken from MCWG recommended list of 88 SNOMED CT specialty codes	R	Onderzoek.Verrichting.Uitvoerder .Zorgverlener.Zorgaanbieder.Afdelingsspecialisme
typeCode	classificationScheme: "urn:uuid:f0306f51-975f-434e-a61c-c59651d33983" Code System Name SNOMED CT 2.16.840.1.113883.6.96 values Use the SNOMED CT display name of the procedure code sequence in (0008,1032). Closed list of values are provided in the Dutch DHD T-REX https://trex.dhd.nl/ subset (Thesaurus containing all procedures used in The Netherlands).	R
creationTime	Slot name = creationTime, Value as DTM - YYYY[MM[DD[hh[mm[ss]]]]]	R3	* Onderzoek.Verslaginformatie.DatumTijd
hash	Slot name = hash, Value as SHA1 hash	R3
languageCode	Slot name = languageCode, Value as String	R
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	R2
serviceStartTime	Slot name = serviceStartTime, Value as DTM	R2	* Onderzoek.Verrichting.Verrichtingstartdatum
serviceStopTime	Slot name = serviceStopTime, Value as DTM	R2	* Onderzoek.Verrichting.Verrichtingeinddatum
size	Slot name = size, Value as Integer	R3
sourcePatientId	Slot name = sourcePatientId, Value as CX	R
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

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

5.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” is supported in this version of the implementation guide.

5.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 imaging study report.

Participant	Description	Actors		Transactions
Radiologist / Treating Physician	In this role, the radiologist or treating physician requests a copy of a specific imaging study report, for the given patient, from a local community repository.	Imaging Document Consumer	Document Repository	XDS.b ITI-43 Retrieve Document Set

5.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 two parts (multipart/related 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/pdf
• binary document: PDF imaging report

5.1.1.5 Use case 5: Retrieve Images (Raadplegen Beeld)

5.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 (approved IHE-TF-RAD CP-257 05/02/2024 - include RAD-107 as additional retrieve option for XDS-I.b) 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.

5.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 imaging study.

Participant	Description	Actors		Transactions
Radiologist / Treating Physician	In this role, the radiologist or treating physician requests a copy of a specific imaging study manifest, for the given patient, from a local community repository and then requests a copy of the actual imaging study (images), from a community imaging document source (PACS/VNA).	Imaging Document Consumer	Document Repository	XDS.b ITI-43 Retrieve Document Set
		Imaging Document Consumer	Imaging Document Source	XDS-I.b RAD-69 Retrieve
		Imaging Document Consumer	Imaging Document Source	XDS-I.b RAD-107 WADO-RS Retrieve

5.1.1.5.3.1 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 (multipart/related 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

5.1.1.5.3.2 RAD-69 Retrieve Imaging Document Set

The RAD-69 Retrieve Imaging Document Set [9] request body is used to define the list of DICOM instances to retrieve and contains the following unique identifiers obtained from the DICOM imaging study manifest KOS object contents:

• study instanceUID: Study Instance UID​ (0020,000D)

for each series in the retrieve study (SeriesRequest in StudyRequest) {

• series instanceUID: Series Instance UID​ (0020,000E)

for each instance in the retrieve series (DocumentRequest in SeriesRequest) {

• 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 a number of parts (multipart/related mime blocks). The first mime block identifies the instances returned and references the binary data of each instance via an XOP include:

Mime Block 1

for each instance in the retrieve series (DocumentResponse) {

• repository uniqueId: (same as request)
• document uniqueId: (same as request)
• mimeType: application/dicom
• document: XOP include reference to Mime Block x

}

The following mime blocks contain the binary instances (one mime block for each instance returned):

Mime Block x

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

5.1.1.5.3.3 RAD-107 WADO-RS Retrieve

The RAD-107 WADO-RS Retrieve request 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}

The required {studyUid}, {seriesUid} and {instanceUid} unique identifier values are obtained from the DICOM imaging study manifest KOS object contents.

The RAD-107 WADO-RS Retrieve response body contains multiple parts (multipart/related mime blocks). The number of parts retrieved depends on the number of DICOM instances present at the retrieve level. Each mime block will have the following format:

Mime Block n

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

Note 1: RAD-107 WADO-RS Retrieve offers URL parameter extensions to further define the retrieved DICOM instance content as, for example, rendered pixel data, DICOM header metadata, etc.

Note 2: The DICOM Retrieve by WADO-RS option for both Imaging Document Source and Imaging Document Consumer is an emerging XDS-I.b option and is not yet implemented by many systems. It is strongly recommended for implementation when new versions allow.

5.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.6 IHE profile and transactions used in the BBS Information standard

5.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-I.b 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.

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

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

XCA-I does not support imaging report registration.

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

XCA-I does not support imaging report registration.

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

5.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), availabilityStatus (Approved)

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.

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

Participant	Description	Actors		Transactions
Radiologist / Treating Physician	In this role, the radiologist or treating physician requests an overview of previous imaging study reports and and imaging study manifests, for the given patient, from the registries of all the federated communities.	Initiating Gateway	Responding Gateway	XCA ITI-38 Cross Gateway Query

5.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 the table for clarification purposes.

The "Intended Use" column specifies the way in which the data elements can be used to define the query request and filter the query responses.

• PF - Primary Filtering: Metadata attribute primarily used for querying documents (Registry Stored Query). This may be a narrowly targeted query (looking for a specific or small set of documents) or a broad query intended to select a manageable set of likely relevant documents.
• SF - Secondary Filtering: Metadata attribute intended to be returned with the matches of a primary query and allow a human (or application) to filter out, amongst the returned candidates, the entries that are not relevant and need not be retrieved.

The patientId and availablityStatus are mandatory.

Metadata Attribute	ebXML query key	Intended Use	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.	PF	* Patient.Identificatienummer
availabilityStatus	Slot name = $XDSDocumentEntryStatus Value = “urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Approved”	PF
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. The DICOM Imaging Procedure Code - DisplayName (from the Procedure Code Sequence (0008,1032)) should be used for secondary filtering (SF). Zero or more query-keys can be defined.	PF	* Onderzoek.Verrichting.VerrichtingAnatomischeLocatie
classCode	Slot name = $XDSDocumentEntryClassCode, Value = IMAGES, REPORTS	PF or SF
typeCode	Slot name = $XDSDocumentEntryTypeCode, Value = typeCodeValue	SF	* Onderzoek.Verrichting.VerrichtingType
practiceSettingCode	Slot name = $XDSDocumentEntryPracticeSettingCode, Value = practiceSettingCodeValue	PF	* Onderzoek.Verrichting.Uitvoerder .Zorgverlener.Zorgaanbieder.Afdelingsspecialisme
creationTime (range)	Slot name = $XDSDocumentEntryCreationTimeFrom, Value = creationTimeFromValue Slot name = $XDSDocumentEntryCreationTimeTo, Value = creationTimeToValue	SF	* Onderzoek.Verslaginformatie.DatumTijd
serviceStartTime (range)	Slot name = $XDSDocumentEntryServiceStartTimeFrom, Value = serviceStartTimeFromValue Slot name = $XDSDocumentEntryServiceStartTimeTo, Value = serviceStartTimeToValue	PF	* Onderzoek.Verrichting.Verrichtingstartdatum
serviceStopTime (range)	Slot name = $XDSDocumentEntryServiceStopTimeFrom, Value = serviceStopTimeFromValue Slot name = $XDSDocumentEntryServiceStopTimeTo, Value = serviceStopTimeToValue	PF	* Onderzoek.Verrichting.Verrichtingeinddatum
healthcareFacilityTypeCode	Slot name = $XDSDocumentEntryHealthcareFacilityTypeCode, Value = healthcareFacilityTypeCodeValue	PF or SF	* Verrichting.Uitvoerder.Zorgverlener .Zorgaanbieder.OrganisatieType
confidentialityCode	Slot name = $XDSDocumentEntryConfidentialityCode, Value = N, R, V	PF
author	Slot name = $XDSDocumentEntryAuthorPerson, Value = authorValue	SF	* Onderzoek.Verrichting.Uitvoerder .Zorgverlener.Naamgegevens.Geslachtsnaam.Achternaam Onderzoek.Verrichting.Locatie .Zorgaanbieder.Zorgaanbiederidentificatienummer Onderzoek.Verrichting.Locatie .Zorgaanbieder.Organisatienaam Onderzoek.Verrichting.Uitvoerder .Zorgverlener.ZorgverlenerRol
entryUUID	Slot name = $uuid, Value = urn:uuid:uuidValue	PF

Table 4.7 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 table below.

• The "Query response ebXML attribute and element values" are included in the table for clarification purposes.
• Conformance is defined in terms of R (Required - value for the attribute will be supplied by the responding actor when responding to a query), R2 (Required if known - value for the attribute will be supplied by the responding actor when responding to a query if a value is available to the actor. For the Document Registry it must supply the value specified in the submission request), R3 (Required for Stable DocumentEntries and not allowed for On-Demand DocumentEntries), O (Optional - the responding actor may or may not supply a value for this attribute. For the Document Registry it must supply the value specified in the submission request).

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

Metadata Attribute	Query response ebXML attribute and element values	Conformance	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
document uniqueId	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: DICOM Modality (1.2.840.10008.6.1.19) - Context Group CID 29 CodingScheme: “DCM” (CodingSchemeDesignator) DICOM Atomic Region/Body Part (4 1.2.840.10008.6.1.2)​ - Context Group CID 4 CodingScheme: “SCT” (CodingSchemeDesignator), see the coarse-grained list in chapter 3. DICOM Imaging Procedure Code - DisplayName (from the Procedure Code Sequence (0008,1032)) Note: This metadata attribute may contain multiple values for Modality, Atomic Region/Body Part and Imaging Procedure Code when either a multi-modality study or overlapping atomic regions / body parts have been registered for the document entry.	O	* 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	R2	* Onderzoek.Verrichting.Uitvoerder .Zorgverlener.Naamgegevens.Geslachtsnaam.Achternaam Onderzoek.Verrichting.Locatie .Zorgaanbieder.Zorgaanbiederidentificatienummer Onderzoek.Verrichting.Locatie .Zorgaanbieder.Organisatienaam Onderzoek.Verrichting.Uitvoerder .Zorgverlener.ZorgverlenerRol
classCode	classificationScheme: "urn:uuid:41a5887f-8865-4c09-adf7-e362475b143a" Code & DisplayName values taken from XDS classCode Metadata Coding System “1.3.6.1.4.1.19376.1.2.6.1” Code "IMAGES", DisplayName "Images" Code "REPORTS", DisplayName "Reports"	R
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”. Code "N", DisplayName "normal" Code "R", DisplayName "restricted" Code "V", DisplayName "very restricted"	R
formatCode	classificationScheme: "urn:uuid:a09d5840-386c-46f2-b5ad-9c3699a4309d" Report 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 Report (XDS-I.b)" Image Code & DisplayName values taken from CodingScheme: “1.2.840.10008.2.6.1” (DICOM UID Registry) Code "1.2.840.10008.5.1.4.1.1.88.59", DisplayName "KOS"	R
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)	R	* Verrichting.Uitvoerder.Zorgverlener .Zorgaanbieder.OrganisatieType
practiceSettingCode	classificationScheme: "urn:uuid:cccf5598-8b07-4b77-a05e-ae952c785ead" Codes and DisplayNames taken from MCWG recommended list of 88 SNOMED CT specialty codes	R	Onderzoek.Verrichting.Uitvoerder .Zorgverlener.Zorgaanbieder.Afdelingsspecialisme
typeCode	classificationScheme: "urn:uuid:f0306f51-975f-434e-a61c-c59651d33983" Code System Name SNOMED CT 2.16.840.1.113883.6.96 values Use the SNOMED CT display name of the procedure code sequence in (0008,1032). Closed list of values are provided in the Dutch DHD T-REX https://trex.dhd.nl/ subset (Thesaurus containing all procedures used in The Netherlands).	R
creationTime	Slot name = creationTime, Value as DTM - YYYY[MM[DD[hh[mm[ss]]]]]	R3	* Onderzoek.Verslaginformatie.DatumTijd
hash	Slot name = hash, Value as SHA1 hash	R3
languageCode	Slot name = languageCode, Value as String	R
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	R2
serviceStartTime	Slot name = serviceStartTime, Value as DTM	R2	* Onderzoek.Verrichting.Verrichtingstartdatum
serviceStopTime	Slot name = serviceStopTime, Value as DTM	R2	* Onderzoek.Verrichting.Verrichtingeinddatum
size	Slot name = size, Value as Integer	R3
sourcePatientId	Slot name = sourcePatientId, Value as CX	R
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.8 XCA-I Metadata Query Response

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

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

5.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 imaging study report.

Participant	Description	Actors		Transactions
Radiologist / Treating Physician	In this role, the radiologist or treating physician requests a copy of a specific imaging study report, for the given patient, from a specifc repository in one of the federated communities.	Initiating Gateway	Reponding Gateway	XCA ITI-39 Cross Gateway Retrieve

5.2.1.4.3 Mapping

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 two parts (multipart/related 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/pdf
• binary document: PDF imaging report

5.2.1.5 Use case 5: Retrieve Images (Raadplegen Beeld)

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

5.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 imaging study.

Participant	Description	Actors		Transactions
Radiologist / Treating Physician	In this role, the radiologist or treating physician requests a copy of a specific imaging study manifest, for the given patient, from a specific repository in one of the federated communities and then requests a copy of the actual imaging study (images), from a specific imaging document source (PACS/VNA) in the same federated community.	Initiating Gateway	Responding Gateway	XCA ITI-39 Cross Gateway Retrieve
		Initiating Gateway	Imaging Responding Gateway	XCA-I RAD-75 Cross Gateway Retrieve Imaging Document Set

5.2.1.5.3.1 ITI-39 Cross Gateway Retrieve

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 response body contains two parts (multipart/related 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

5.2.1.5.3.2 Rad-75 Cross Gateway Retrieve Imaging Document Set

The Rad-75 Cross Gateway Retrieve Imaging Document Set [9] request body is used to define the list of DICOM instances to retrieve and contains the following unique identifiers obtained from the DICOM imaging study manifest KOS object contents:

• study instanceUID: Study Instance UID​ (0020,000D)

for each series in the retrieve study (SeriesRequest in StudyRequest) {

• series instanceUID: Series Instance UID​ (0020,000E)

for each instance in the retrieve series (DocumentRequest in SeriesRequest) {

• homeCommunityId (same as ITI-39)
• 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-75 Cross Gateway Retrieve Imaging Document Set response body contains a number of parts (multipart/related mime blocks). The first mime block identifies the instances returned and references the binary data of each instance via an XOP include:

Mime Block 1

for each instance in the retrieve series (DocumentResponse) {

• repository uniqueId: (same as request)
• document uniqueId: (same as request)
• mimeType: application/dicom
• document: XOP include reference to Mime Block x

}

The following mime blocks contain the binary instances (one mime block for each instance returned):

Mime Block x

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

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

5.3 MHD/WIA: Mobile access to Health Documents / Web-based Image Access

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. The mechanism used to group these actors is beyond the scope of this implementation guide.

Note: The IHE MHD profile has a Trial Implementation status at the time of writing this Implementation Guide meaning that it may be altered/updated from the trial experiences before reaching Final Text status.

The IHE WIA profile supports the RAD transactions for imaging study retrieval.

Figure 4.4 IHE MHD/WIA Affinity Domain

Comments on the notes shown in Figure 4.4:

• Note 1: The MHD Document Registry could be implemented as a MHD facade to an existing XDS infrastructure (XDS-on-FHIR) - see MHD Actor Grouped with XDS Infrastructure.
• Note 2 and 3: The ITI-68 Retrieve Document transaction is not required for retreiving an imaging study manifest if the document sharing infrastructure supports the RAD-129 QIDO-RS Query transaction. This allows the Imaging Document Consumer to query for the imaging study contents (DICOM Study, Series and Instance UIDs) directly from the Imaging Document Responder.

The IHE MHD Profile is FHIR based and so, in addition to the contents of this implementation guide, the reader should be aware of:

1. General FHIR Implementation Guide
2. Use case overarching principles
3. FHIR packages

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.

5.3.1 Use Cases

MHD/WIA 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)

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

5.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 MHD 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). For full details see https://profiles.ihe.net/ITI/MHD/ITI-65.html

The following table identifies the location of the ITI-65 Provide Document Bundle FHIR profile.

FHIR Resource	FHIR Profile
ITI-65 Provide Document Bundle	http://fhir.nl/fhir/StructureDefinition/bbs-iti-65-provide-document-bundle-location-to-be-added

5.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 imaging study report and returns the registration status.

Participant	Description	Actors		Transactions
Radiologist	In this role, the radiologist (and/or health organization they work for) is responsible for the quality of the metadata corresponding to a imaging study report and making both metadata and imaging study report available for registration.	Imaging Document Source	Document Recipient	MHD ITI-65 Provide Document Bundle

5.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 the below table for the metadata used in each DocumentReference. Also, note that:

• The “DocumentReference Element/Value” are included in the table for clarification purposes.
• Conformance is defined in terms of R (Required - value for the attribute will be supplied by the sending actor), R2 (Required if known - value for the attribute will be supplied by the sending actor when the value is known), O (Optional - value may or may not be supplied by the sending actor).

The FHIR Bundle.meta.profile shall reference the “Comprehensive Metadata” option (otherwise known as XDS-on-FHIR ) - see Comprehensive Metadata.

Metadata Attribute	DocumentReference Element	DocumentReference Element Value	Conformance	Cardinality	Art-Decor Element
availabilityStatus	status	CodeableConcept CodingScheme: “http://hl7.org/fhir/ValueSet/document-reference-status” Code: “current” (Current)	R	1..1
author	author	Reference Practitioner | Organization	R2	0..n	* 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 CodingScheme: “http://hl7.org/fhir/ValueSet/document-classcodes” Code: “18726-0” (Radiology studies (set)) Note: Requires better mapping to XDS classCode Metadata Coding System “1.3.6.1.4.1.19376.1.2.6.1” Code: "REPORTS" (Reports)	R	1..1
confidentialityCode	securityLabel	CodeableConcept CodingScheme: "http://terminology.hl7.org/CodeSystem/v3-Confidentiality" (HL7 Confidentiality “urn:oid:2.16.840.1.113883.5.25”) Code: "N" (normal) Code: "R" (restricted) Code: "V" (very restricted)	R	1..n
eventCodeList	context.event	CodeableConcept Code & DisplayName values taken from: DICOM Modality (1.2.840.10008.6.1.19): Context Group CID 29 CodingScheme: “DCM” (CodingSchemeDesignator) DICOM Atomic Region/Body Part (4 1.2.840.10008.6.1.2): Context Group CID 4 CodingScheme: “SCT” (CodingSchemeDesignator) with values taken from the coarse-grained list defined in table 3.1 Required Metadata DICOM Imaging Procedure Code - DisplayName (from the Procedure Code Sequence (0008,1032)) At least one Modality eventCode, one Atomic Region/Body Part eventCode and one Imaging Procedure Code eventCode should be registered but more of each type are permitted depending on the actual imaging study contents. Note: It is necessary to register more than one coarse-grained Atomic Region/Body Part eventCode when the codes represent overlapping atomic regions / body parts.	R2	0..n	* Onderzoek.Verrichting.VerrichtingAnatomischeLocatie
formatCode	content.format	CodeableConcept CodingScheme: "http://hl7.org/fhir/ValueSet/formatcodes" (IHE Format codes “urn:oid:1.3.6.1.4.1.19376.1.2.7.1”) Code "urn.ihe.rad:PDF" (PDF Report (XDS-I.b))	R	1..1
healthcareFacilityTypeCode	context.facilityType	CodeableConcept Code & DisplayName values taken from RoleCodeNLUZIRoleCodeOrganisaties CodingScheme: “2.16.840.1.113883.2.4.15.1060”	R	1..1	* Verrichting.Uitvoerder.Zorgverlener .Zorgaanbieder.OrganisatieType
practiceSettingCode	context.practiceSetting	CodeableConcept Codes and DisplayNames taken from MCWG recommended list of 88 SNOMED CT specialty codes. Imaging reports and studies are associated with the Radiology specialty with the following practiceSettingCode value: Code: "394734003", DisplayName: "Radiological specialties"	R	1..1	* Onderzoek.Verrichting.Uitvoerder .Zorgverlener.Zorgaanbieder.Afdelingsspecialisme
typeCode	type	CodeableConcept Code System Name SNOMED CT 2.16.840.1.113883.6.96 values Use the SNOMED CT display name of the procedure code sequence in (0008,1032). Closed list of values are provided in the Dutch DHD T-REX https://trex.dhd.nl/ subset (Thesaurus containing all procedures used in The Netherlands).	R	1..1	* Onderzoek.Verrichting.VerrichtingType
creationTime	content.attachment.creation	dateTime – YYYY[-MM[-DD[Thh:mm:ss+zz:zz]]]	R	1..1	* Onderzoek.Verslaginformatie.DatumTijd
date	date	dateTime – YYYY[-MM[-DD[Thh:mm:ss+zz:zz]]]	R	1..1	* Onderzoek.Verslaginformatie.DatumTijd
mimeType	content.attachment.contentType	token	R	1..1
hash	content.attachment.hash	Base64Binary (SHA1 hash of the data)	O	0..1
languageCode	content.attachment.language	code: BCP-47	R	1..1
legalAuthenticator	authenticator	Reference – Practitioner | Organization	O	0..1
referenceIdList	context.encounter context.related.identifier	CXi.5 (Identifier Type Codes) = “urn:ihe:iti:xds:2015:encounterId”: Reference - Encounter Other CXi.5 (Identifier Type Codes) values: Identifier mapped from CXi referenceId attributes: urn:ihe:iti:xds:2013:accession urn:ihe:iti:xds:2013:order urn:ihe:iti:xds:2016:studyInstanceUID	R	1..n	Comment: The known values of at least the Accession Number (and Issuer of Accession Number) and the Study UID should be registered as context.related.identifier(s).
serviceStartTime	context.period.start	DateTime	R2	0..1	* Onderzoek.Verrichting.Verrichtingstartdatum
serviceStopTime	context.period.end	DateTime	R2	0..1	* Onderzoek.Verrichting.Verrichtingeinddatum
size	content.attachment.size	unsignedInt	O	0..1
sourcePatientId	context.sourcePatientInfo	Reference - Patient identifier = sourcePatientId	R	1..1
sourcePatientInfo	context.sourcePatientInfo	Reference - Patient Defining “PID-x|value”	O	0..1
title	content.attachment.title	string - (DICOM Imaging Procedure Code - DisplayName (from the Procedure Code Sequence (0008,1032)))	R	1..1
comments	description	string	O	0..1
patientId	subject	Reference - Patient identifier = patientId Identifier example: identifier.system = 2.16.840.1.113883.2.4.6.3 (where "2.16.840.1.113883.2.4.6.3" is the OID of the Assigning Authority) identifier.value = externalPatientIdentifierValue identifier.assigner – Reference Organization = “ISO”	R	1..1	* Patient.Identificatienummer
document uniqueId	masterIdentifier	Identifier	O	0..1	* Onderzoek.Verslaginformatie.Verslagidentificatienummer

Table 4.9 MHD Imaging Report Registration Metadata Attributes

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 for the DocumentReference.content.attachment.data entry.
2. By reference: a reference is included in the DocumentReference as a URI (to the location of the imaging report) for the DocumentReference.content.attachment.url entry.

In both cases the mimeType will be defined by the DocumentReference.content.attachment.contentType = “application/pdf”.

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

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.

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

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

For full details see https://profiles.ihe.net/ITI/MHD/ITI-65.html

The following table identifies the location of the ITI-65 Provide Document Bundle FHIR profile.

FHIR Resource	FHIR Profile
ITI-65 Provide Document Bundle	http://fhir.nl/fhir/StructureDefinition/bbs-iti-65-provide-document-bundle-location-to-be-added

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

Participant	Description	Actors		Transactions
Radiologist	In this role, the radiologist (and/or health organization they work for) is responsible for the quality of the metadata corresponding to a imaging study manifest and making both metadata and imaging study manifest available for registration.	Imaging Document Source	Document Recipient	MHD ITI-65 Provide Document Bundle

5.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 the below table for the metadata used in each DocumentReference. Also, note that:

• The “DocumentReference Element/Value” are included in the table for clarification purposes.
• Conformance is defined in terms of R (Required - value for the attribute will be supplied by the sending actor), R2 (Required if known - value for the attribute will be supplied by the sending actor when the value is known), O (Optional - value may or may not be supplied by the sending actor).

The FHIR Bundle.meta.profile shall reference the “Comprehensive Metadata” option (otherwise known as XDS-on-FHIR ) - see Comprehensive Metadata.

Metadata Attribute	Document-Reference Element	DocumentReference Element Value	Conformance	Cardinality	Art-Decor Element
availabilityStatus	status	CodeableConcept CodingScheme: “http://hl7.org/fhir/ValueSet/document-reference-status” Code: “current” (Current)	R	1..1
author	author	Reference Practitioner | Organization	R2	0..n	* 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 CodingScheme: “http://hl7.org/fhir/ValueSet/document-classcodes” Code: “18726-0” (Radiology studies (set)) Note: Requires better mapping to XDS classCode Metadata Coding System “1.3.6.1.4.1.19376.1.2.6.1” Code: "IMAGES" (Images)	R	1..1
confidentialityCode	securityLabel	CodeableConcept CodingScheme: "http://terminology.hl7.org/CodeSystem/v3-Confidentiality" (HL7 Confidentiality “urn:oid:2.16.840.1.113883.5.25”) Code: "N" (normal) Code: "R" (restricted) Code: "V" (very restricted)	R	1..n
eventCodeList	context.event	CodeableConcept Code & DisplayName values taken from: DICOM Modality (1.2.840.10008.6.1.19): Context Group CID 29 CodingScheme: “DCM” (CodingSchemeDesignator) DICOM Atomic Region/Body Part (4 1.2.840.10008.6.1.2): Context Group CID 4 CodingScheme: “SCT” (CodingSchemeDesignator) with values taken from the coarse-grained list defined in table 3.1 Required Metadata DICOM Imaging Procedure Code - DisplayName (from the Procedure Code Sequence (0008,1032)) At least one Modality eventCode, one Atomic Region/Body Part eventCode and one Imaging Procedure Code eventCode should be registered but more of each type are permitted depending on the actual imaging study contents. Note: It is necessary to register more than one coarse-grained Atomic Region/Body Part eventCode when the codes represent overlapping atomic regions / body parts.	R2	0..n	Onderzoek.Verrichting.VerrichtingAnatomischeLocatie
formatCode	content.format	CodeableConcept CodingScheme: "urn.oid.1.2.840.10008.2.6.1" (DICOM UID Registry) Code: "1.2.840.10008.5.1.4.1.1.88.59" (KOS)	R	1..1
healthcareFacilityTypeCode	context.facilityType	CodeableConcept Code & DisplayName values taken from CodingScheme: “2.16.840.1.113883.2.4.15.1060” (NL Nictiz/HL7 RoleCodeNLUZIRoleCodeOrganisaties)	R	1..1	* Verrichting.Uitvoerder.Zorgverlener .Zorgaanbieder.OrganisatieType
practiceSettingCode	context.practiceSetting	CodeableConcept Codes and DisplayNames taken from MCWG recommended list of 88 SNOMED CT specialty codes. Imaging reports and studies are associated with the Radiology specialty with the following practiceSettingCode value: Code: "394734003", DisplayName: "Radiological specialties"	R	1..1	* Onderzoek.Verrichting.Uitvoerder .Zorgverlener.Zorgaanbieder.Afdelingsspecialisme
typeCode	type	CodeableConcept Code System Name SNOMED CT 2.16.840.1.113883.6.96 values Use the SNOMED CT display name of the procedure code sequence in (0008,1032). Closed list of values are provided in the Dutch DHD T-REX https://trex.dhd.nl/ subset (Thesaurus containing all procedures used in The Netherlands).	R	1..1	* Onderzoek.Verrichting.VerrichtingType
creationTime	content.attachment.creation	dateTime – YYYY[-MM[-DD[Thh:mm:ss+zz:zz]]]	R	1..1	* Onderzoek.Beeldinformatie.DatumTijd
date	date	dateTime – YYYY[-MM[-DD[Thh:mm:ss+zz:zz]]]	R	1..1	* Onderzoek.Verslaginformatie.DatumTijd
mimeType	content.attachment.contentType	token	R	1..1
hash	content.attachment.hash	Base64Binary (SHA1 hash of the data)	O	0..1
languageCode	content.attachment.language	code – BCP-47	R	1..1
legalAuthenticator	authenticator	Reference – Practitioner | Organization	O	0..1
referenceIdList	context.encounter context.related.identifier	CXi.5 (Identifier Type Codes) = “urn:ihe:iti:xds:2015:encounterId”: Reference - Encounter Other CXi.5 (Identifier Type Codes) values: Identifier mapped from CXi referenceId attributes: urn:ihe:iti:xds:2013:accession urn:ihe:iti:xds:2013:order urn:ihe:iti:xds:2016:studyInstanceUID	R	1..n	Comment: The known values of at least the Accession Number (and Issuer of Accession Number) and the Study UID should be registered as context.related.identifier(s).
serviceStartTime	context.period.start	DateTime	R2	0..1	* Onderzoek.Verrichting.Verrichtingstartdatum
serviceStopTime	context.period.end	DateTime	R2	0..1	* Onderzoek.Verrichting.Verrichtingeinddatum
size	content.attachment.size	unsignedInt	O	0..1
sourcePatientId	context.sourcePatientInfo	Reference - Patient identifier = sourcePatientId	R	0..1
sourcePatientInfo	context.sourcePatientInfo	Reference - Patient Defining “PID-x|value”	O	0..1
title	content.attachment.title	string - (DICOM Imaging Procedure Code - DisplayName (from the Procedure Code Sequence (0008,1032)))	R	1..1
comments	description	string	O	0..1
patientId	subject	Reference - Patient identifier = patientId Identifier example: identifier.system = 2.16.840.1.113883.2.4.6.3 (where "2.16.840.1.113883.2.4.6.3" is the OID of the Assigning Authority) identifier.value = externalPatientIdentifierValue identifier.assigner – Reference Organization = “ISO”	R	1..1	* Patient.Identificatienummer
document uniqueId	masterIdentifier	Identifier	O	0..1	* Onderzoek.Beeldinformatie.Beeldinformatieindentificatienummer

Table 4.10 MHD Imaging Study Registration Metadata Attributes

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

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

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

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

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.

5.3.1.2.4 DICOM KOS Object Attributes

The imaging study manifest or DICOM KOS object must 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	Value copied from referenced PACS study > patient attributes.
Patient ID​ (0010,0020)​	LO	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).
Issuer of Patient ID (0010,0021)	LO	Value copied from referenced PACS study > patient attributes.
Patient's Birth Date​ (0010,0030)​	DT	Value copied from referenced PACS study > patient attributes.
Patient's Sex​ (0010,0040)​	CS	Value copied from referenced PACS study > patient attributes.
Other Patient IDs Sequence (0010,1002)	SQ
> Patient ID​ (0010,0020)​	LO	Value copied from referenced PACS study > patient attributes.
> Issuer of Patient ID (0010,0021)	LO	Value copied from referenced PACS study > patient attributes.
General Study Module
Study Instance UID​ (0020,000D)	UI	Value copied from referenced PACS study > study attributes. Copying the referenced PACS study Study Instance UID ensures a 1 to 1 relationship between KOS and referenced study (MCWG recommendation).
Study Date​ (0008,0020)	DA	Value copied from referenced PACS study > study attributes.
Study Time​ (0008,0030)​	TM	Value copied from referenced PACS study > study attributes.
Referring Physician's Name​ (0008,0090)​	PN	Value copied from referenced PACS study > study attributes.
Accession Number (0008,0050)	SH	Value copied from referenced PACS study > study attributes.
Issuer of Accession Number Sequence (0008,0051)	SQ	Value copied from referenced PACS study > study attributes.
> Local Namespace Entity ID (0040,0031)	UT	Value copied from referenced PACS study > study attributes.
Study Description (0008,1030)	LO	Value copied from referenced PACS study > study attributes.
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" - recommended value
General Equipment
Manufacturer​ (0008,0070)​	LO	Name of equipment manufacturer
Key Object Document
Instance Number​ (0020,0013)​	IS	"1” - recommended 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	Value copied from General Study > Study Instance UID​ (0020,000D). Note that if this KOS document is shared or exchanged, this same Study Instance UID must be present in the ReferenceIdList (urn:ihe:iti:xds:2016:studyInstanceUID) metadata.
> 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.
>> Local Namespace Entity ID (0040,0031)	UT	Identifies an entity within the local namespace or domain.
> 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.
>> Local Namespace Entity ID (0040,0031)	UT	Identifies an entity within the local namespace or domain.
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). Note that if this KOS document is shared or exchanged, this same Study Instance UID must be present in the ReferenceIdList (urn:ihe:iti:xds:2016:studyInstanceUID) metadata.
> 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 (DICOM UID of Imaging Document Source) that is used as a reference to obtain the actual retrieval end-point (type and address) via the generic Addressing function. Note: The accessibility level of the end-point address (exposure to the Imaging Document Consumer) as being intra-mural (within a document sharing community) or extra-mural (between document sharing communities) is beyond the scope of this KOS specification.
>> Retrieve URL​ (0008,1190)​	UR	The Retrieve URL is the Base URI (end-point address) + Study Instance UID (0020,000D) + Series Instance UID (0020,000E), so that, if left unchanged, can be used to retrieve the instances of the series where the Retrieve URL is placed in the tree of references. It could be changed to perform a retrieve at an instance or entire study level. The end-point type (WADO-URI or WADO-RS) is not conveyed by this attribute. The MCWG recommendation is to define the end-point type as being WADO-RS by default meaning that the value of this Retrieve URL can be used directly for DICOM Series level retrieval using a WADO-RS service. Note: The accessibility level of the end-point address (exposure to the Imaging Document Consumer) as being intra-mural (within a document sharing community) or extra-mural (between document sharing communities) is beyond the scope of this KOS specification.
>> 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 the remaining attribute values
> Code Value (0008,0100)	SH	"113030"
> Coding Scheme Designator (0008,0102)	SH	"DCM"
> Code Meaning (0008,0104)	LO	"Manifest"
Continuity of Content (0040,A050)	CS	"SEPARATE"
Content Template Sequence (0040,A504)	SQ
> Mapping Resource (0008,0105)	CS	"DCMR"
> Template Identifier (0040,DB00)	CS	"2010"
Observation DateTime (0040,A032)	DT
Content Sequence (0040,A730)	SQ	One or more Items shall be included in this Sequence – each item is a reference to one of the instances in referenced study
for each series in referenced PACS study{
for each instance in referenced PACS series{
> Relationship Type (0040,A010)	CS	"CONTAINS"
> Value Type (0040,A040)	CS	"IMAGE" other allowed values are "WAVEFORM" and "COMPOSITE"
> Referenced SOP Sequence (0008,1199)	SQ	Only one item shall be included
>> 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)
}
}
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.11 DICOM KOS Object Attributes

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

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

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

For full details see https://profiles.ihe.net/ITI/MHD/ITI-67.html

The following table identifies the location of the ITI-67 Find Document References FHIR profile.

FHIR Resource	FHIR Profile
ITI-67 Find Document References	http://fhir.nl/fhir/StructureDefinition/bbs-iti-67-find-document-references-location-to-be-added

5.3.1.3.2 Actors

Participant	Description	Actors		Transactions
Radiologist / Treating Physician	In this role, the radiologist or treating physician requests an overview of previous imaging study reports and and imaging study manifests, for the given patient, from the local community registry.	Imaging Document Consumer	Document Responder	MHD ITI-67 Find Document References

5.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/Query Value” are included in the table for clarification purposes.

The "Intended Use" column specifies the way in which the data elements can be used to define the query request and filter the query responses.

• PF - Primary Filtering: Metadata attribute primarily used for querying documents (Registry Stored Query). This may be a narrowly targeted query (looking for a specific or small set of documents) or a broad query intended to select a manageable set of likely relevant documents.
• SF - Secondary Filtering: Metadata attribute intended to be returned with the matches of a primary query and allow a human (or application) to filter out, amongst the returned candidates, the entries that are not relevant and need not be retrieved.

The patientId (query parameter: patient or patient.identifier) and availabilityStatus (query parameter: status) are mandatory.

Metadata Attribute	Query Parameter	Query Value	Intended Use	Art-Decor Element
patientId	patient or subject Query parameter or subject:Patient.identifier	parameter as Reference(Patient) This is defined by IHE-NL as BSN and will be used in this guide as a 9-digit unique identifier.	PF	* Patient.Identificatienummer
availabilityStatus	status	parameter as token – system|code system = "http://hl7.org/fhir/ValueSet/document-reference-status" code = "current" (Current) Specifies the status of the DocumentReference Resource, or in Document Sharing nomenclature, the availabilityStatus of the Document Entry.	PF
eventCodeList	event	parameter as token – system|code Specifies the main clinical acts documented by the DocumentReference Resource, or in Document Sharing nomenclature, the eventCodeList of the Document Entry. 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. Zero or more query-keys can be defined. The DICOM Imaging Procedure Code - DisplayName (from the Procedure Code Sequence (0008,1032)) should be used for secondary filtering (SF). Zero or more query-keys can be defined.	PF	* Onderzoek.Verrichting.VerrichtingAnatomischeLocatie
classCode	category	parameter as token – system|code system = “http://hl7.org/fhir/ValueSet/document-classcodes” code = “18726-0” (Radiology studies (set)) Note: Requires better mapping to system = “1.3.6.1.4.1.19376.1.2.6.1” (XDS classCode Metadata Coding System) code = "IMAGES"|"REPORTS" Specifies the general classification of the DocumentReference Resource, or in Document Sharing nomenclature, the classCode of the Document Entry.	PF or SF
typeCode	type	parameter as token – system|code Code System Name SNOMED CT 2.16.840.1.113883.6.96 values Use the SNOMED CT display name of the procedure code sequence in (0008,1032). Closed list of values are provided in the Dutch DHD T-REX https://trex.dhd.nl/ subset (Thesaurus containing all procedures used in The Netherlands). Specifies the specific type of the DocumentReference resource or in Document Sharing nomenclature, the typeCode of the Document Entry.	SF	* Onderzoek.Verrichting.VerrichtingType
practiceSettingCode	setting	parameter as token – system|code Specifies the specific practice setting of the DocumentReference Resource, or in Document Sharing nomenclature, the practiceSettingCode of the Document Entry.	PF	* Onderzoek.Verrichting.Uitvoerder .Zorgverlener.Zorgaanbieder.Afdelingsspecialisme
creationTime (range)	creation	parameter as dateTime This IHE defined parameter defined as DocumentReference-Creation, of type dateTime, specifies a search against the DocumentReference.content.attachment.creation.	SF	* Onderzoek.Verslaginformatie.DatumTijd
date	date	parameter as dateTime	SF	* Onderzoek.Verslaginformatie.DatumTijd
mimeType	contenttype	parameter as token	PF
serviceStartTime (range)	period.start	parameter as dateTime Represents the time of service that is being documented by the DocumentReference. The period search parameter specifies an interval which the time of service overlaps. In Document Sharing nomenclature, this query parameter represents from/to parameters for the serviceStartTime and serviceStopTime of the Document Entry.	PF	* Onderzoek.Verrichting.Verrichtingstartdatum
serviceStopTime (range)	period.stop	parameter as dateTime	PF	* Onderzoek.Verrichting.Verrichtingeinddatum
healthcareFacilityTypeCode	facility	parameter as token - system|code system = “2.16.840.1.113883.2.4.15.1060” (NL Nictiz/HL7 RoleCodeNLUZIRoleCodeOrganisaties) Specifies the kind of facility found in DocumentReference.context.facilityType, or in Document Sharing nomenclature, the healthcareFacilityTypeCode of the Document Entry.	PF or SF	* Verrichting.Uitvoerder.Zorgverlener .Zorgaanbieder.OrganisatieType
confidentialityCode	security-label	parameter as token – system|code system = "http://terminology.hl7.org/CodeSystem/v3-Confidentiality" (HL7 Confidentiality “urn:oid:2.16.840.1.113883.5.25”) code = "N"|"R"|"V" Specifies the security labels of the document referenced by DocumentReference Resource, or in Document Sharing nomenclature, the confidentialityCode of the Document Entry.	PF
author	author.given and author.family	parameter as Reference(Practitioner|Organization) Specify the name parts of the author person, which is associated with the DocumentReference Resource, or in Document Sharing nomenclature, the author of the Document Entry.	SF	* Onderzoek.Verrichting.Uitvoerder .Zorgverlener.Naamgegevens.Geslachtsnaam.Achternaam Onderzoek.Verrichting.Locatie .Zorgaanbieder.Zorgaanbiederidentificatienummer Onderzoek.Verrichting.Locatie .Zorgaanbieder.Organisatienaam Onderzoek.Verrichting.Uitvoerder .Zorgverlener.ZorgverlenerRol
referenceIdList	related.identifier	parameter as Identifier The DICOM Accession Number (and Issuer of Accession Number) or the Study UID could be used to provide a targeted query.	PF

Table 4.12 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 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.
• Conformance is defined in terms of R (Required - value for the attribute will be supplied by the responding actor when responding to a query), R2 (Required if known - value for the attribute will be supplied by the responding actor when responding to a query if a value is available to the actor. For the Document Registry it must supply the value specified in the submission request), O (Optional - the responding actor may or may not supply a value for this attribute. For the Document Registry it must supply the value specified in the submission request).

The patientId, availabilityStatus, URI and uniqueId are mandatory.

Metadata Attribute	Document-Reference Element	DocumentReference Element Value	Conformance	Art-Decor Element
patientId	subject	Reference - Patient identifier = patientId Identifier example: identifier.system = 2.16.840.1.113883.2.4.6.3 (where "2.16.840.1.113883.2.4.6.3" is the OID of the Assigning Authority) identifier.value = externalPatientIdentifierValue identifier.assigner – Reference Organization = “ISO”	R	* Patient.Identificatienummer
availabilityStatus	status	CodeableConcept CodingScheme: “http://hl7.org/fhir/ValueSet/document-reference-status” Code: “current” (Current)	R
author	author	Reference Practitioner | Organization	R2	* 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 CodingScheme: “http://hl7.org/fhir/ValueSet/document-classcodes” Code: “18726-0” (Radiology studies (set)) Note: Requires better mapping to XDS classCode Metadata Coding System “1.3.6.1.4.1.19376.1.2.6.1” Code: "IMAGES" (Images) Code: "REPORTS" (Reports)	R
confidentialityCode	securityLabel	CodeableConcept CodingScheme: "http://terminology.hl7.org/CodeSystem/v3-Confidentiality" (HL7 Confidentiality “urn:oid:2.16.840.1.113883.5.25”) Code: "N" (normal) Code: "R" (restricted) Code: "V" (very restricted)	R
eventCodeList	context.event	CodeableConcept Code & DisplayName values taken from: DICOM Modality (1.2.840.10008.6.1.19) - Context Group CID 29 CodingScheme: “DCM” (CodingSchemeDesignator) DICOM Atomic Region/Body Part (4 1.2.840.10008.6.1.2)​ - Context Group CID 4 CodingScheme: “SCT” (CodingSchemeDesignator) See the coarse-grained list in chapter 3. DICOM Imaging Procedure Code - DisplayName (from the Procedure Code Sequence (0008,1032)) Note: This metadata attribute may contain multiple values for Modality, Atomic Region/Body Part and Imaging Procedure Code when either a multi-modality study or overlapping atomic regions / body parts have been registered for the document entry.	O	* Onderzoek.Verrichting.VerrichtingAnatomischeLocatie
formatCode	content.format	CodeableConcept Report CodingScheme: "http://hl7.org/fhir/ValueSet/formatcodes" (IHE Format codes “urn:oid:1.3.6.1.4.1.19376.1.2.7.1”) Code: "urn.ihe.rad:PDF" (PDF Report (XDS-I.b)) Image CodingScheme: "urn:oid:1.2.840.10008.2.6.1" (DICOM UID Registry) Code: "1.2.840.10008.5.1.4.1.1.88.59" (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)	R	* Verrichting.Uitvoerder.Zorgverlener .Zorgaanbieder.OrganisatieType
practiceSettingCode	context.practiceSetting	CodeableConcept Codes and DisplayNames taken from MCWG recommended list of 88 SNOMED CT specialty codes	R	* Onderzoek.Verrichting.Uitvoerder .Zorgverlener.Zorgaanbieder.Afdelingsspecialisme
typeCode	type	CodeableConcept Code System Name SNOMED CT 2.16.840.1.113883.6.96 values Use the SNOMED CT display name of the procedure code sequence in (0008,1032). Closed list of values are provided in the Dutch DHD T-REX https://trex.dhd.nl/ subset (Thesaurus containing all procedures used in The Netherlands).	R
creationTime	content.attachment.creation	dateTime – YYYY[-MM[-DD[Thh:mm:ss+zz:zz]]]	R2	* Onderzoek.Verslaginformatie.VerslagDatumTijd
date	date	dateTime – YYYY[-MM[-DD[Thh:mm:ss+zz:zz]]]	R2	* Onderzoek.Verslaginformatie.VerslagDatumTijd
mimeType	content.attachment.contentType	token	R2
hash	content.attachment.hash	Base64Binary (SHA1 hash of the data)	R2
languageCode	content.attachment.language	code – BCP-47	R
legalAuthenticator	authenticator	Reference – Practitioner | Organization	O
referenceIdList	context.encounter context.related.identifier	CXi.5 (Identifier Type Codes) = “urn:ihe:iti:xds:2015:encounterId”: Reference – Encounter Other CXi.5 (Identifier Type Codes) values: Indentifier CXi referenceId attributes: urn:ihe:iti:xds:2013:accession urn:ihe:iti:xds:2013:order urn:ihe:iti:xds:2016:studyInstanceUID	R2	Comment: The known values of at least the Accession Number (and Issuer of Accession Number) and the Study UID should be returned as context.related.identifier(s).
serviceStartTime	context.period.start	DateTime	R2	* Onderzoek.Verrichting.Verrichtingstartdatum
serviceStopTime	context.period.end	DateTime	R2	* Onderzoek.Verrichting.Verrichtingeinddatum
size	content.attachment.size	unsignedInt	R2
sourcePatientId	context.sourcePatientInfo	Reference - Patient identifier = sourcePatientId	R
sourcePatientInfo	context.sourcePatientInfo	Reference - Patient Defining “PID-x|value”	O
URI	content.attachment.url	url – points to the actual document	R	Comment: The content.attachment.contentType will identify the document mimeType as either "application/pdf" (imaging report) or "application/dicom" (imaging study manifest).
title	content.attachment.title	string	O
comments	description	string	O
document uniqueId	masterIdentifier	Identifier	R	* Onderzoek.Verslaginformatie.Verslagidentificatienummer

Table 4.13 MHD Metadata Query Response

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

5.3.1.4.1 Introduction

The Retrieve Report use case enables an Imaging Document Consumer to retrieve an imaging report for a specific patient. The ITI-68 Retrieve Document request uses the DocumentReference.content.attachment.url and DocumentReference.content.attachment.contentType (mimeType), returned in the ITI-67 Find Document References response, for the selected imaging report to identify/locate it. Only imaging reports with mimeType of “application/pdf” are supported in this version of the implementation guide.

For full details see https://profiles.ihe.net/ITI/MHD/ITI-68.html

5.3.1.4.2 Actors

Participant	Description	Actors		Transactions
Radiologist / Treating Physician	In this role, the radiologist or treating physician requests a copy of a specific imaging study report, for the given patient, from a local community repository.	Imaging Document Consumer	Document Responder	MHD ITI-68 Retrieve Document

5.3.1.4.3 Mapping

The Imaging Document Consumer sends a HTTP GET request to the server. The Imaging Document Consumer request is used to retrieve the document content referenced by a DocumentReference.content.attachment.url. The only MIME type assured to be returned is the MIME type indicated in the DocumentReference.content.attachment.contentType.

5.3.1.5 Use case 5: Retrieve Images (Raadplegen Beeld)

5.3.1.5.1 Introduction

The Retrieve Images use case enables an Imaging Document Consumer to retrieve an imaging study for a specific patient. Two possible scenarios are defined:

1. By using an imaging study manifest - The DocumentReference.content.attachment.url and DocumentReference.content.attachment.contentType (mimeType) returned in the ITI-67 Find Document References response for the selected imaging study manifest (DICOM KOS) identify/locate it. The DICOM KOS has a mimeType of “application/dicom”. The ITI-68 Retrieve Documents transaction is used to retrieve the DICOM KOS. The DICOM KOS contents are parsed to obtain the DICOM UIDs needed to perform the RAD-107 WADO-RS Retrieve. For full details see https://profiles.ihe.net/ITI/MHD/ITI-68.html
2. Without using an imaging study manifest - If the document sharing infrastructure supports the RAD-129 QIDO-RS Query transaction and the WIA Imaging Document Consumer supports the MHD Document Consumer Integration Option (see [11] RAD-TF 1 42.2.2 MHD Document Consumer Integration Option), then the DocumentReference.context.related.identifier.value values returned in the ITI-67 Find Document References response for the selected imaging report identify the DICOM Accession Number (and Issuer of Accession Number) and/or a Study UID. These values can be used by the WIA Imaging Document Consumer to perform RAD-129 QIDO-RS Query transactions to obtain the DICOM UIDs needed to perform the RAD-107 WADO-RS Retrieve.

5.3.1.5.2 Actors

Participant	Description	Actors		Transactions
Radiologist / Treating Physician	In this role, the radiologist or treating physician requests a copy of a specific imaging study manifest, for the given patient, from a local community repository, or queries a community imaging document responder (PACS/VNA) for imaging study details, and then requests a copy of the actual imaging study (images), from a community imaging document responder (PACS/VNA).	Imaging Document Consumer	MHD Document Responder	MHD ITI-68 Retrieve Document
		Imaging Document Consumer	WIA Imaging Document Responder	WIA RAD-129 QIDO-RS Query
		Imaging Document Consumer	WIA Imaging Document Responder	WIA RAD-107 WADO-RS Retrieve

5.3.1.5.3.1 ITI-68 Retrieve Document

The Imaging Document Consumer sends a HTTP GET request to the server. The Imaging Document Consumer request is used to retrieve the document content referenced by a DocumentReference.content.attachment.url. The only MIME type assured to be returned is the MIME type indicated in the DocumentReference.content.attachment.contentType.

5.3.1.5.3.2 RAD-129 QIDO-RS Query

The RAD-129 QIDO-RS Query request is used to query for the complete study, series within a study or individual (image) instance attribute values based on the URL used:

• STUDY: <qidoRsEndpoint>/studies{?search*}
• SERIES: <qidoRsEndPoint>/studies/{studyUid}/series{?search*}
• INSTANCE: <qidoRsEndPoint>/studies/{studyUid}/series/{seriesUid}/instances{?search*}

The required {studyUid} and {seriesUid} unique identifier values are obtained from the iterative QIDO-RQ STUDY and SERIES query responses starting with either the Accession Number (and Issuer of Accession Number) or Study UID. The {search} parameters are defined in [11] - RAD TF-2: 4.129.

The RAD-129 QIDO-RS Query response body when the JSON format is requested contains a single part (mime block). The query responses are encoded as a JSON formatted string. The mime block will have the following format:

Mime Block 1

• mimeType: application/dicom+json
• JSON formatted document: DICOM query responses attributes

The RAD-129 QIDO-RS Query response body when the XML format is requested contains multiple parts (multipart/related mime blocks). The number of parts retrieved depends on the number of matches found by the Imaging Document Responder to the query defined in the request. Each mime block will have the following format:

Mime Block n

• mimeType: application/dicom+xml
• XML formatted document: DICOM query response attributes

For full details of the RAD-129 transaction see [11] - RAD TF-2: 4.129.

5.3.1.5.3.3 RAD-107 WADO-RS Retrieve

The RAD-107 WADO-RS Retrieve request 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}

The required {studyUid}, {seriesUid} and {instanceUid} unique identifier values are obtained from the DICOM imaging study manifest KOS object contents, obtained via the ITI-68 Retrieve Document, or from the query responses of the RAD-129 QIDO-RS Query.

The RAD-107 WADO-RS Retrieve response body contains multiple parts (multipart/related mime blocks). The number of parts retrieved depends on the number of DICOM instances present at the retrieve level. Each mime block will have the following format:

Mime Block n

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

For full details of the RAD-107 transaction see [11] - RAD TF-2: 4.107.

Note: RAD-107 WADO-RS Retrieve offers URL parameter extensions to further define the retrieved DICOM instance content as, for example, rendered pixel data, DICOM header metadata, etc.

5.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.
Web-based Image Access (WIA)	The Web-based Image Access (WIA) Profile, formerly known as Mobile Access to Health Document for Imaging (MHD-I), defines methods for image sharing and interactive viewing of imaging studies using RESTful services such as WADO-RS and QIDO-RS.
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-129 QIDO-RS Query	The QIDO-RS Query [RAD-129] transaction queries for DICOM SOP Instances via an HTTP interface.
RAD-107 WADO-RS Retrieve	The WADO-RS Retrieve [RAD-107] transaction retrieves DICOM SOP Instances via an HTTP interface.

6 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 Recommendations on Standards Positioning for sharing imaging information at the national/regional level.	https://www.ihe-europe.net/sites/default/files/2024-05/1-MCWG-Recommendations-Positioning-Imaging-Standards-Profiles-FinalPublished-V6.pdf
[4]	MCWG Recommendations on Metadata and Linkages for sharing imaging information at the national/regional level.	https://www.ihe-europe.net/sites/default/files/2024-05/2-MCWG-Recommendations-Imaging%20Sharing%20Metadata-Linkages-FinalPublished-V7.pdf
[5]	MCWG Recommendations on Imaging Study Manifest for sharing imaging information at the national/regional level.	https://www.ihe-europe.net/sites/default/files/2024-05/3-MCWG-Recommendations-KOS%20Manifest-FinalPublished-V9.pdf
[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	https://health.ec.europa.eu/publications/ehn-guidelines-medical-imaging-studies-and-reports_en
[8]	https://nictiz.atlassian.net/browse/NICTIZ-9735	2023-12-04, v1.0, Nictiz
[9]	DICOM WADO-WS Specification (RAD-69/RAD-75) - see https://dicom.nema.org/medical/dicom/2017b/output/html/part18.html#sect_6.4	Last version of DICOM Web Services supporting WADO-WS before deprecation
[10]	IHE Infrastructure (ITI) Technical Framework	https://www.ihe.net/resources/technical_frameworks/#IT
[11]	IHE Radiology (RAD) Technical Framework	https://www.ihe.net/resources/technical_frameworks/#radiology

7 Release Notes

Changes compared to previous release.

BITS ticket	Short description
NICTIZ-14008	TO alpha release - updates, corrections and typo fixes
NICTIZ-15823	Advies schrijven over gebruik KOS attributen retrieve URL / retrieve location URI
NICTIZ-17114	NL KOS Spec - Complete SR Document Content
NICTIZ-17686	TO - correctie op Format Coding Scheme voor DICOM KOS in XDS metadata
NICTIZ-17687	TO - toevoegen van Patient ID / Issuer Patient ID in KOS Other Patient Sequence
NICTIZ-17690	TO - Imaging Report en Imaging Study definities in Glossary
NICTIZ-17752	Kardinaliteit toevoegen in Technisch ontwerp voor RAD68
NICTIZ-17753	"Intended Use" toevoegen in Technisch ontwerp voor ITI-18
NICTIZ-18038	TO - MHD ITI-67 Query parameter update
NICTIZ-19111	TO - Breid de MHD/WIA-sectie uit met de QIDO-RQ-queryoptie