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" (translates as “National availability of radiological images for healthcare provider and patient: functional requirements”)[1]. This document states 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 studies (images, 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 takes a lot of effort to transfer the documents of interest from one place to another. This has another unwanted effect: each health provider only 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 document released by NVVR and VZVZ 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:

Within 3 years a central timeline representing all the radiology encounters of a patient, including studies and referrals, should exist.
This timeline should be available in the work environment of every radiologist regardless of where the radiologist is working at that time.
By using a single timeline, including all studies and referrals, a much-needed insight and overview regarding one patient will be provided to the treating radiologist.

1.2 About this document

This Image Availability (English: Image Availability) implementation guide is a technical derivation of the aforementioned, collabrative document between NVVR and VZVZ. The goal of this implementation guide is to advise on 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
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 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) 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.
IHE	IHE International
Images	Result of scanning a patient/specimen using electromagnetic radiation, x-ray, ultrasound or other techniques to produce visualizations of internal structures of the body for the purpose of accurate diagnosis.
Image Availability	The name of this project, in the Netherlands known as Beeldbeschikbaarheid (abbreviated to BBS).
Nictiz	The Dutch knowledge organization for digital information provision in healthcare.
NIHEMDS	The NIHEMDS is the National IHE MetaData Set (Dutch: Nationale IHE MetaData Set)
NVVR	Nationale Vereniging van Radiologen: the Dutch Association of Radiologists
Reports	Summary of the findings of a diagnostic consultant (radiologist, cardiologist, lab specialist, etc) based on observations taken from an underlying set of images / test results. A report is signed off/approved by a senior diagnostic consultant and should not be changed thereafter.
Studies	Grouping of images and reports relating to a single patient for a common diagnostic need.
Timeline	A time-ordered representation of all the radiology encounters (visits) a patient has had. Each encounter produces some type of radiology information relating to the patient in the form of images and/or reports.
VZVZ	Vereniging van Zorgaanbieders voor Zorgcommunicatie: Dutch Association for Health Providers
XCA	Cross-Community Access
XDS	Cross Enterprise Document Sharing
Zib	A zib 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 standardization of healthcare information.

2 Actors involved

The table below shows the relevant XCA-I actors and transactions with respect to the systems used.

Persons		Systems		XCA-I
Name	Description	Name	Actors	Transactions
Radiologist	This actor is responsible for generating and transmitting medical images, and related information, and making them available to the responding gateway. In this role, the radiologist (and/or health organization he/she works for) is the Document Source making them also responsible for the metadata added to the document(s).	PACS	Responding Gateway	ITI-38 Cross Gateway Query
			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-38 Cross Gateway Query
			Initiating Gateway	ITI-39 Cross Gateway Retrieve
			Initiating Imaging Gateway	RAD-75 Cross Gateway Retrieve Imaging Document Set

3 Required Metadata

Withing Image Availability we use a combination of datasets, which have implications on the required metadata. Optional metadata is advised, as this could provide the consumer with more information. Responsibility for the quality of metadata lies with the Document Source. Furthermore, this is solely regarding the Alpha release. It is very likely that there will be metadata added, adjusted and/or removed in future releases.

3.1 IHE

Starting from chapter 5, we introduce the various use cases. In these use cases we advise the usage of various IHE transactions which include the following required metadata:

DocumentEntry.patientId ($XDSDocumentEntryPatientId). This is defined by IHE-NL as BSN and will be used in this guide as an unique identifier
DocumentEntry.availabilityStatus ($XDSDocumentEntryStatus). This defines the lifecycle status of the DocumentEntry: Approved or Deprecated.

3.1.1 NIHEMDS

The NIHEMDS is the National IHE MetaData Set (Dutch: Nationale IHE MetaData Set) and is published on ART-DECOR. The NIHEMDS is under constant revision and construction, further adjustments in the metadata will be communicated in future releases.

3.2 Zib

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

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

The Documents in scope for this release are pdf only. Other documents will be adressed in future releases.

4.1 MedMij Images (Beelden) information standard

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.

4.2 Consent

The patient's consent, e.g., is not in scope for this Implementation Guide: we assume that the radiologist and/or treating physician has consent from the patient to share their information.

4.3 IHE

For BBS, 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 BBS, 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.

5 Use case 1: Raadplegen Tijdlijn Data / Retrieve Timeline Data

5.1 Introduction

The Retrieve Timeline Data use case enables a requesting gateway to retrieve a timeline of radiology encounters 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 encounters (represented in IHE XDS as Document Entries) based on patient identifiers and other search criteria. The 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 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.

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

QueryID = FindDocuments
returnType = ObjectRef
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:

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 the IHE framework Vol2: 3.18.4.1.2.3.1 Parameter returnType.Actors

5.2 Actors

Persons		Systems		XCA-I
Name	Description	Name	Actors	Transactions
Radiologist	This actor is responsible for generating and transmitting medical images, and related information, and making them available to the responding gateway. In this role, the radiologist (and/or health organization he/she works for) is the Document Source making them also 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

6 Use case 2: Raadplegen Beelden / Retrieve images

6.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/she wishes 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).

Via one of the two options mentioned above, we assume this use case begins with a known document uniqueId. 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. The ITI-39 response will contain the matching document content, where 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.

6.2 Actors

Persons		Systems		XCA-I
Name	Description	Name	Actors	Transactions
Radiologist	This actor is responsible for generating and transmitting medical images, and related information, and making them available to the responding gateway. In this role, the radiologist (and/or health organization he/she works for) is the Document Source making them also responsible for the metadata added to the document(s).	PACS	Responding Gateway	ITI-39 Cross Gateway Retrieve
Radiologist		PACS	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
Radiologist/ Treating physician		PACS/EPD	Initiating Imaging Gateway	RAD-75 Cross Gateway Retrieve Imaging Document Set

6.3 Invocations

Some metadata is still under review and not yet defined, so example messages will be added in a later stadium.

7 Use case 3: Raadplegen Verslagen / Retrieve report

7.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 report(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 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 he/she wishes 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 ITI-39 and thus include the 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.

7.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 related information, and making them available to the responding gateway. In this role, the radiologist (and/or health organization he/she works for) is the Document Source making them also responsible for the metadata added to the document(s).	PACS	Responding Gateway	ITI-39 Cross Gateway Retrieve
Radiologist		PACS	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

8 Use case 4: Sturen Beelden / Send images

This use case is in development!

9 Use case 5: Sturen Verslagen / Send report

This use case is in development!

10 Profiles

The BBS specification defines ZIB and IHE profiles.

10.1 Zib

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

10.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.
Cross-Community Acces (XCA)	The Cross-Community Access 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.

Implementation Guide BBS version

Inhoud