Bbs:V1 IG

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

1 Introduction

1.1 Background

In 2018 the Dutch Association for Radiologists (NVVR) and the Dutch Association for Health Providers (VZVZ) released the document “Landelijke beschikbaarheid radiologische beelden voor zorgverlener en patient: functionele vereisten"[1]. This document describes that the current radiology situation in the Netherlands is not acceptable. In 2016, for almost 1 out of 4 radiology patients, there is the potential need to exchange images, studies and reports across multiple health providers and/or referrers.

The current situation is that there are short-term solutions in place, but these are not satisfying; it asks a lot of effort to get the documents of interest from one place to another. This has another unwanted effect: each health provider has a part of the patient’s dossier – not only unwanted, but also a risk for continuity, safety and results related to the patient. The released document explains that the vision is that every radiologist should be able to view a timeline of every radiology-related research concerning the patient.

The main objectives of the mentioned collaborative document are:

1. Within 3 years a timeline with all radiology-related studies of a patient, including referrals.
2. This timeline is available in the work environment of every radiologist regardless of where the radiologist is working at that time.
3. By using 1 timeline where all research and referrals are included, this will provide the treating radiologist with much-needed insight and overview regarding one patient.

1.2 About this document

This implementation guide is a technical derivation of the aforementioned, collabrative document between NVVR and VZVZ. This guide advises the usage of the IHE profiles based on XCA, as provided in volumes 1 through 3 of the IHE IT Infrastructure Technical Framework and will provide a set of guidelines and technical requirements how healthcare providers can provide radiology images and/or reports in the Netherlands using cross gateway interoperability.

Furthermore, this document is solely regarding the Alpha release. It is very likely that there will be features added, adjusted and/or removed in future releases.

1.3 Glossary

Term	Description
Image Availability	The name of this project, in the Netherlands known as "Beeldbeschikbaarheid" (frequently abbreviated to "BBS").
BSN	The citizen service number (BSN) is a unique personal number allocated to everyone registered in the Personal Records Database (BRP). Everyone who registers with the BRP is automatically given a BSN.
Documents	Describes reports and/or images (via an image manifest / DICOM KOS object) and include patient identification and demographic details, author, creation date/time, content type and other metadata needed to define the source and provenance of the contained information.
Images	Result of scanning a patient/specimen using electromagnetic radiation, x-ray, ultrasound or other techniques to produce visualizations of internal structures of the body for the purpose of accurate diagnosis.
Studies	Grouping of images and reports relating to a single patient for a common diagnostic need.
Reports	Summary of the findings of a diagnostic consultant (radiologist, cardiologist, lab specialist, etc) based on observations taken from an underlying set of images / test results. A report is signed off/approved by a senior diagnostic consultant and should not be changed thereafter.
NVVR	Nationale Vereniging van Radiologen: the Dutch Association of Radiologists
VZVZ	Vereniging van Zorgaanbieders voor Zorgcommunicatie: Dutch Association for Health Providers
Nictiz	The Dutch knowledge organization for digital information provision in healthcare.
IHE	IHE International
XCA	Cross Community Access
XDS	Cross Enterprise Document Sharing
NIHEMDS	The NIHEMDS is the National IHE MetaData Set (Dutch: Nationale IHE MetaData Set)

2 Actors involved

The table below shows the relevant XCA-I actors and transactions in perspective of the systems used.

Persons		Systems		XCA-I
Name	Description	Name	Actors	Transactions
Radiologist	This actor is responsible for generating and transmitting medical images and making them available to the responding gateway. In this role, the radiologist (and/or health organisation he/she works for) is the Document Source ie they are responsible for the metadata added to the document(s).	PACS	Responding Gateway	ITI-38 Cross Gateway Query
				ITI-39 Cross Gateway Retrieve
			Responding Imaging Gateway	RAD-75 Cross Gateway Retrieve Imaging Document Set
Radiologist/ Treating physician	This actor is a healthcare provider that requests access to images and related information from image-generating healthcare providers.	PACS/EPD	Initiating Gateway	ITI-38 Cross Gateway Query
				ITI-39 Cross Gateway Retrieve
			Initiating Imaging Gateway	RAD-75 Cross Gateway Retrieve Imaging Document Set

3 Boundaries and relationships

The Image Availability specification applies to the exchange of documents, images and other related information between radiology healthcare providers 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 providers. Therefore, healthcare providers are not only responsible for the documents that are provided to the community, but also how their infrastructure is connected to said community to provide cross-community access. Also note that only national citizens that have a BSN are in scope for this release.

For the current release, Alpha, only the cross-community access via synchronous XCA-I is in scope. Future releases of this information standard will address non-XCA exchange.

3.1 Beelden information standard MedMij

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

3.2 NIHEMDS

The NIHEMDS is the National IHE MetaData Set (Dutch: Nationale IHE MetaData Set). This might be helpful for implementing the Image Availability information standard. The NIHEMDS is published on ART-DECOR.

3.3 Consent

Consent in not in scope for this Implementation Guide: for this release we assume that the radiologist and/or treating physician has consent from the patient to share their information.

3.4 IHE

For “Image Availability”, we assume that the reader is familiar with the mentioned IHE IT Infrastructure Domains. This document is not an introduction to XCA and/or XDS and will only focus on requirements from the IHE profiles, combined with the metadata set for "Image Availability”, which is relevant for national use in the Netherlands. This implementation guide also only focusses on achieving cross gateway interoperability between actors in the Netherlands.

4 Use case 1: Raadplegen Tijdlijn Data / Retrieve timeline data

4.1 Introduction

The Retrieve Timeline Data use case enables a requesting gateway to retrieve a timeline of imaging documents for a specific patient. This use case is implemented using the ITI-38 Cross Gateway Query transaction, which allows the requesting gateway to query for a list of documents based on patient identifiers and other search criteria. The responding gateway returns a set of documents that match the query criteria, which can then be used to construct a timeline of imaging studies for the patient.

ITI-38 is the Cross Gateway Query with essentially the same semantics as the ITI-18 (Registry Stored Query). By using ITI-38, the initiating Gateway sends out a query request, responding gateways send back their query response.

A timeline in this use case is an ordered sequence of items belonging to a single patient (as stated in chapter 3, BSN is used as an unique identifier) where the items in the timeline represent documents stored in the registry that match the query keys used to create it. In IHE terms these documents are defined by XDSDocumentEntries in the registry.

Creating a timeline for a given patient (with a known BSN 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

1. QueryID = “FindDocuments”
2. returnType = “ObjectRef”
3. A simple set of query keys (maybe a date range or clinic type)

This should return a list of matching document UUIDS (unique registry identifiers). As we don’t know the number of documents belonging to the patient (number of matching query responses) 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-38:

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-38 query types to create this timeline is also recommended in the IHE framework Vol2: 3.18.4.1.2.3.1 Parameter returnType.Actors

4.2 Actors

Persons		Systems		XCA-I
Name	Description	Name	Actors	Transactions
Radiologist	This actor is responsible for generating and transmitting medical images and making them available to the responding gateway. In this role, the radiologist (and/or health organisation he/she works for) is the Document Source ie they are responsible for the metadata added to the document(s).	PACS	Responding Gateway	ITI-38 Cross Gateway Query
Radiologist/ Treating physician	This actor is a healthcare provider that requests access to images and related information from image-generating healthcare providers.	PACS/EPD	Initiating Gateway	ITI-38 Cross Gateway Query

4.3 Required Metadata

As stated above, our advice is to use the ITI-38 transaction for a Cross Gateway Query. However, to be able to query these studies (and get appropriate responses), the uploader of these studies (ie the Document source) is required to add metadata to these studies.

Based on the National IHE Metadata Set, we have derived specific metadata which is obligated for all documents within the scope of project Image Availability. We have listed only the required metadata below; for the content within the required element use ART-DECOR.

4.3.1 Required request Metadata

Element	IHE Parameter
Patient.Naamgegevens.Geslachtsnaam.Achternaam	not yet defined
Patient.Indentificatienummer	XDSDocumentEntry.patientId
Patient.Geboortedatum	not yet defined
Patient.Geslacht	not yet defined
Onderzoek.Verrichting.Locatie.Zorgaanbieder.AfdelingsSpecialisme	XDSDocumentEntry.practiceSettingCode

4.3.2 Required response Metadata

Element	IHE Parameter
Patient.Naamgegevens.Geslachtsnaam.Achternaam	SourcePatientInfo
Patient.Indentificatienummer	SourcePatientInfo
Patient.Geboortedatum	SourcePatientInfo
Patient.Geslacht	SourcePatientInfo
Onderzoek.Verrichting.StatusVerrichting	availabilityStatus
Onderzoek.Verrichting.VerrichtingStartDatum	serviceStartTime
Onderzoek.Verrichting.Locatie.Zorgaanbieder.Zorgaanbiederidentificatienummer	author
Onderzoek.Verrichting.Locatie.Zorgaanbieder.Organistatienaam	author
Onderzoek.Verrichting.Locatie.Zorgaanbieder.AfdelingsSpecialisme	author

4.4 Invocations

Sample messages have been generated as guides for developing the standard. For the sample messages, see GitHub.

5 Use case 2: Raadplegen Beelden / Retrieve images

5.1 Introduction

Use case 2 (Retrieve Images) describes how the radiologist and/or treating physician can retrieve (an) imaging document set(s), with two possible scenarios as mentioned in Functioneel Ontwerp.

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 he/she wishes to consult (an) specific imaging document set(s). Selecting the specific timeline entry will contain the displayed (meta)data details but also define the document uniqueId.

The radiologist / attending physician is aware of a previous examination of which he wishes to consult the imaging document set(s) and is known with the document uniqueID of the(se) imaging document set(s).

With the two preconditions mentioned above, we assume this use case begins with a timeline entry has been selected and the document uniqueId for that entry is known. Note that the ITI-38 Cross Gateway Query transaction is therefore not required by use case 2. Issue an ITI-39 request by using the document uniqueID that is selected previously. The ITI-39 response will contain the matching document content, whereas the mimeType property will identify the document type: for example, text/xml, application/pdf or application/dicom.

Please note that 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 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 (let’s assume mainly images) will then be retrieved using the RAD-75 Cross Gateway Retrieve Imaging Document Set 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, and that the KOS document references DICOM structured reports too. This can only be determined by inspecting the type of DICOM objects referenced by the KOS document and is further discussed in chapter 6.

5.2 Actors

Persons		Systems		XCA-I
Name	Description	Name	Actors	Transactions
Radiologist	This actor is responsible for generating and transmitting medical images and making them available to the responding gateway. In this role, the radiologist (and/or health organisation he/she works for) is the Document Source ie they are responsible for the metadata added to the document(s).	PACS	Responding Gateway	ITI-39 Cross Gateway Retrieve
			Responding Imaging Gateway	RAD-75 Cross Gateway Retrieve Imaging Document Set
Radiologist/ Treating physician	This actor is a healthcare provider that requests access to images and related information from image-generating healthcare providers.	PACS/EPD	Initiating Gateway	ITI-39 Cross Gateway Retrieve
			Initiating Imaging Gateway	RAD-75 Cross Gateway Retrieve Imaging Document Set

5.3 Requiered metadata

Based on the National IHE Metadata Set, we have derived specific metadata which are obligated for all documents within the scope of project Image Availability. We have listed only the required metadata below; for the content within the required element, use ART-DECOR. Optional metadata is a shared responsibility. To guarantee consistent operability between gateways (and any underlying infrastructures) consistent use of metadata is needed and should be discussed between all parties involved. Future adjustment of required metadata is therefore plausible and will be included in future versions of this document.

5.3.1 Requiered request Metadata

Element	IHE Parameter
Onderzoek.Beeldinformatie	?

5.3.2 Required response Metadata

Element	IHE Parameter
Patient.Naamgegevens.Geslachtsnaam.Achternaam	SourcePatientInfo
Patient.Indentificatienummer	SourcePatientInfo
Patient.Geboortedatum	SourcePatientInfo
Patient.Geslacht	SourcePatientInfo
Onderzoek.Beeldinformatie.DatumTijd	creationTime
Onderzoek.Beeldinformatie.Beelden	-

5.4 Invocations

Sample messages have been generated as guides for developing the standard. For the sample messages, see GitHub.

6 Use case 3: Raadplegen Verslagen / Retrieve report

6.1 Introduction

Use Case 3, Retrieve Report, enables a requesting gateway to retrieve an imaging study report for a specific patient. Similar to use case 2, this use case describes how the radiologist and/or treating physician can retrieve (an) imaging document set(s), with two possible scenarios as mentioned in Functioneel Ontwerp:

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 he/she wishes to consult (an) specific imaging document set(s). 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 he wishes to consult the imaging document set(s) and is known with the document uniqueID of the(se) imaging document set(s).

Making the same precondition assumptions as in use case 2 (the document uniqueID is known); the document retrieval will make use of ITI-39 and thus include the preferred document uniqueId. The mimeType in the retrieve response will indicate the document type retrieved:

• If the mimeType in the retrieve response is not application/dicom then the actual document retrieved represents the report content.
• If the mimeType in the retrieve response is application/dicom then the KOS document retrieved needs to be inspected to see if any DICOM structured reports are referenced by it. RAD-75 (Cross Gateway Retrieve Imaging Document Set) would then be needed to retrieve the DICOM structured report.

6.2 Actors

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

Persons		Systems		XCA-I
Name	Description	Name	Actors	Transactions
Radiologist	This actor is responsible for generating and transmitting medical images and making them available to the responding gateway. In this role, the radiologist (and/or health organisation he/she works for) is the Document Source ie they are responsible for the metadata added to the document(s).	PACS	Responding Gateway	ITI-39 Cross Gateway Retrieve
			Responding Imaging Gateway	RAD-75 Cross Gateway Retrieve Imaging Document Set
Radiologist/ Treating physician	This actor is a healthcare provider that requests access to images and related information from image-generating healthcare providers.	PACS/EPD	Initiating Gateway	ITI-39 Cross Gateway Retrieve

6.3 Required mappings

There are several required parameters. See the table below. For the content within the required element, use ART-DECOR.

6.3.1 Required request Metadata

Element	IHE Parameter
Onderzoek.Verslaginformatie	?

6.3.2 Required response Metadata

Element	IHE Parameter
Patient.Naamgegevens.Geslachtsnaam.Achternaam	SourcePatientInfo
Patient.Indentificatienummer	SourcePatientInfo
Patient.Geboortedatum	SourcePatientInfo
Patient.Geslacht	SourcePatientInfo
Onderzoek.Verslaginformatie.AuthoriserendRadioloog.Zorgvelener.Naamgegevens.Geslachtsnaam.Achternaam	?
Onderzoek.Verslaginformatie.DicterendRadioloog.Zorgvelener.Naamgegevens.Geslachtsnaam.Achternaam	Author
Onderzoek.Verslaginformatie.VerslagIdentificatienummer	uniqueId
Onderzoek.Verslaginformatie.DatumTijd	creationTime
Onderzoek.Verslaginformatie.StatusVerslag	?
Onderzoek.Verslaginformatie.Verslag	-

6.4 Invocations

Sample messages have been generated as guides for developing the standard. For the sample messages, see GitHub.

7 Use case 4: Sturen Beelden / Send images

This use case is in development!

8 Use case 5: Sturen Verslagen / Send report

This use case is in development!

9 Profiles

The Image Availability specification defines ZIB and IHE profiles.

9.1 Zib

Zib NL (2020)	HCIM EN
Patient	Patient
Verrichting	Procedure
Zorgvelener	HealthProfessional
Zorgaanbieder	HealthcareProvider

9.2 IHE

IHE Profile	Description
ITI-38 Cross Gateway Query	This profile 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 profile 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 profile 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.