Bbs:V1 beta IG MHDWIA

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) unveiled the document “Landelijke beschikbaarheid radiologische beelden voor zorgverlener en patiënt: functionele vereisten” (English: “National availability of radiological images for healthcare professionals and patients: functional requirements”)[1]. This document asserts that the present state of information exchange within Dutch radiology is unsatisfactory. In 2016, nearly one in four radiology patients had a potential necessity for the interchange of studies (images, reports) among multiple healthcare professionals and/or referrers.

Current workaround solutions exist, yet they fall short; transferring pertinent documents from one locale to another is labor-intensive. This situation ensues an undesirable effect: each healthcare professional possesses only a segment of the patient’s file – a scenario not merely unwelcome but also perilous for continuity, safety, and patient-related outcomes. The shared vision, as outlined by the NVvR and VZVZ, is for every radiologist to have the capacity to explore a chronological record of every radiology-associated investigation concerning the patient.

The primary objectives of this joint document include:

1. The establishment of a centralized timeline, representing all radiological encounters of a patient including studies and referrals, within a span of three years.
2. Accessibility of this timeline in every radiologist’s working milieu, irrespective of their location at any given moment.
3. A singular timeline, encompassing all studies and referrals, furnishing the treating radiologist with Invaluable insight and a comprehensive overview regarding each patient.

1.2 About this document

The BBS (Dutch: Beeldbeschikbaarheid, English: Image Availability) implementation guide emanates as a technical extrapolation of the collaborative document between NVvR and VZVZ. This guide aims to counsel on the application of IHE profiles predicated on XDS, XCA, and MHD/WIA, as delineated in volumes 1 through 3 of the IHE IT Infrastructure Technical Framework. It sets forth a suite of guidelines and technical prerequisites for healthcare professionals in the Netherlands, facilitating the provision of radiology images and/or reports.

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 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.
Documents	Encompasses reports and/or images (via an image manifest / DICOM KOS object) inclusive of patient identification, demographic details, author, creation date/time, content type, and additional metadata essential for delineating the source and provenance of the enclosed information.
FHIR	Fast Healthcare Interoperability Resources
IHE	IHE International
Images	Resultant of scanning a patient/specimen utilizing electromagnetic radiation, x-ray, ultrasound or other methodologies to engender visualizations of internal body structures for precise diagnostic purposes.
Image Availability	The name of this project, in the Netherlands known as Beeldbeschikbaarheid (abbreviated to BBS).
MHD	Mobile access to Health Documents
MHDS	Mobile Health Document Sharing
NIHEMDS	The NIHEMDS is the National IHE MetaData Set (Dutch: Nationale IHE MetaData Set)
NVvR	Nationale Vereniging van Radiologen: the Dutch Association of Radiologists
Reports	Summarizes the diagnostic consultant’s findings (radiologist, cardiologist, lab specialist, etc) based on observations derived from an underlying set of images/test results. A report, once endorsed/approved by a senior diagnostic consultant, becomes immutable.
Studies	Grouping of images and reports relating to a single patient for a common diagnostic need.
Timeline	A temporally ordered representation of all radiological encounters a patient has undergone. Each encounter yields radiology information pertinent to the patient in the guise of images and/or reports.
VZVZ	Vereniging van Zorgaanbieders voor Zorgcommunicatie: Dutch Association for Health Providers
WIA	Web image access, also known as DICOMweb
XCA	Cross-Community Access
XCA-I	Cross-Community Access Imaging
XDS	Cross-Enterprise Document Sharing
XDS-I	Cross-Enterprise Document Sharing Imaging
Zib	A zib delineates a clinical concept in such a manner that it serves as a modular unit in various healthcare scenarios and information systems. Zibs underpin the standardization of healthcare information.

2 Actors involved

The table below shows the relevant MHD and WIA actors and transactions with respect to the systems used.

Persons		Systems		MHD/WIA
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 they work for) is the Document Source making them also responsible for the metadata added to the document(s).	PACS	Document Responder	ITI-66 Find Document List
				ITI-67 Find Document References
				ITI-68 Retrieve Document
			Document Recipient	ITI-65 Provide Document Bundle
				ITI-105 Simplified Publish
				ITI-106 Generate Metadata
			Imaging Document Source	RAD-107 WADO-RS Retrieve
Treating physician	This actor is a healthcare professional that requests access to reports and related information from image-generating healthcare professionals.	EHR	Document Consumer	ITI-66 Find Document List
				ITI-67 Find Document References
				ITI-68 Retrieve Document
			Document Source	ITI-65 Provide Document Bundle
				ITI-105 Simplified Publish
				ITI-106 Generate Metadata
		EHR/Mobile Tablet	Imaging Document Consumer	RAD-107 WADO-RS Retrieve

3 Boundaries and relationships

The BBS specification applies to the exchange of documents, images and other related information between radiology healthcare professional 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 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 alfa release 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 addressed in future releases. In consultation with the NVvR, both dictating and authenticating radiologists are not shown in the timeline, it suffices that this information is displayed in the report.

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 Consent

The patient's legal consent 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.

3.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 focuses on achieving cross-gateway interoperability between actors in the Netherlands.

4 Required Metadata

Within BBS we use a combination of data sets, which has 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. Since this document is part of an alfa release, it is very likely that there will be metadata added, adjusted and/or removed in future releases.

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

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

4.2 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 NIHEMDS that have implications on the BBS metadata will be communicated in future releases.

5 Use case 1: Retrieve Timeline Data (Raadplegen Tijdlijn 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 ITI-18 (Registry Stored Query). By using ITI-38, the initiating gateway sends out a query request, and responding gateways send back their query response.

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

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

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

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 they work for) is the Document Source, which is 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 professional that requests access to images and related information from image-generating healthcare professionals.	PACS/EHR	Initiating Gateway	ITI-38 Cross Gateway Query

5.3 Mapping

Certain data is mandatory to send along and is thus minimally expected by the receiving PACS/EHR. Hereby a mapping is made between ART-DECOR and the IHE metadata of these mandatory elements.

IHE metadata	ART-DECOR element
DocumentEntry.sourcePatientInfo.family name	Patient.Naamgegevens.Geslachtsnaam.Achternaam
DocumentEntry.patientId	Patient.Indentificatienummer
DocumentEntry.sourcePatientInfo.date of birth	Patient.Geboortedatum
DocumentEntry.sourcePatientInfo.gender	Patient.Geslacht
DocumentEntry.serviceStartTime	Onderzoek.Verrichting.VerrichtingStartDatum
DocumentEntry.typeCode	Onderzoek.Verrichting.VerrichtingType
DocumentEntry.author.authorInstitution.organization identifier	Onderzoek.Verrichting.Locatie.Zorgaanbieder.Zorgaanbiederidentificatienummer
DocumentEntry.author.authorInstitution.organization name	Onderzoek.Verrichting.Locatie.Zorgaanbieder.Organisatienaam
DocumentEntry.practiceSettingCode(DisplayName)	Onderzoek.Verrichting.Locatie.Zorgaanbieder.AfdelingsSpecialisme
DocumentEntry.author.authorPerson.last name	Onderzoek.Verrichting.Uitvoerder.Zorgverlener.Naamgegevens.Geslachtsnaam.Achternaam
DocumentEntry.author.authorTelecommunication	Onderzoek.Verrichting.Uitvoerder.Zorgverlener.Contactgegevens.Telefoonnummers.Telefoonnummer
DocumentEntry.author.authorSpecialty	Onderzoek.Verrichting.Uitvoerder.Zorgverlener.ZorgverlenerRol

6 Use case 2: Retrieve Images (Raadplegen Beelden)

6.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 Query transaction is therefore not required for this use case. 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 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

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

Persons		Systems		XCA-I
Name	Description	Name	Actors	Transactions
Radiologist	This actor is responsible for generating and transmitting medical images, and related information, and making them available to the responding gateway. In this role, the radiologist (and/or health organization they work for) is the Document Source making them also responsible for the metadata added to the document(s).	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 professional that requests access to images and related information from image-generating healthcare professionals.	PACS/EHR	Initiating Gateway	ITI-39 Cross Gateway Retrieve
			Initiating Imaging Gateway	RAD-75 Cross Gateway Retrieve Imaging Document Set

6.3 Mapping

Certain data is mandatory to send along and is thus minimally expected by the receiving PACS/EHR. Hereby a mapping is made between ART-DECOR and the IHE metadata of these mandatory elements.

IHE metadata	ART-DECOR element
DocumentEntry.sourcePatientInfo.family name	Patient.Naamgegevens.Geslachtsnaam.Achternaam
DocumentEntry.patientId	Patient.Indentificatienummer
DocumentEntry.sourcePatientInfo.date of birth	Patient.Geboortedatum
DocumentEntry.sourcePatientInfo.gender	Patient.Geslacht
DcoumentEntry.creationTime	Onderzoek.Beeldinformatie.DatumTijd

7 Use case 3: Retrieve Reports (Raadplegen Verslagen)

7.1 Introduction

The Retrieve Reports use case 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 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 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 an imaging study report request using the ITI-39 Cross Gateway Retrieve transaction, and the responding gateway, which provides access to and returns the requested report.

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

7.3 Mapping

Certain data is mandatory to send along and is thus minimally expected by the receiving PACS/EHR. Hereby a mapping is made between ART-DECOR and the IHE metadata of these mandatory elements.

IHE metadata	ART-DECOR element
DocumentEntry.sourcePatientInfo.family name	Patient.Naamgegevens.Geslachtsnaam.Achternaam
DocumentEntry.patientId	Patient.Indentificatienummer
DocumentEntry.sourcePatientInfo.date of birth	Patient.Geboortedatum
DocumentEntry.sourcePatientInfo.gender	Patient.Geslacht
Needs to be mentioned in report	Onderzoek.Verslaginformatie.AuthoriserendRadioloog.Zorgverlener.Naamgegevens.Geslachtsnaam.Achternaam
Needs to be mentioned in report	Onderzoek.Verslaginformatie.DicterendRadioloog.Zorgverlener.Naamgegevens.Geslachtsnaam.Achternaam
DocumentEntry.uniqueId	Onderzoek.Verslaginformatie.VerslagIdentificatienummer
DcoumentEntry.creationTime	Onderzoek.Verslaginformatie.DatumTijd

8 Use case 4: Send Images (Sturen Beelden)

This use case is in development!

9 Use case 5: Send Reports (Sturen Verslagen)

This use case is in development!

10 Profiles and transactions

The BBS information standard makes use of the following zibs (from the 2020 release) and IHE transactions.

10.1 HCIMs

Zib NL	HCIM EN
Patient	Patient
Verrichting	Procedure
Zorgverlener	HealthProfessional
Zorgaanbieder	HealthcareProvider

10.2 IHE

IHE Profile	Description
Mobile access to Health Documents	The Mobile access to Health Documents (MHD) Profile defines one pair of actors and a transaction to submit or push new “document entries” from the mobile device to a receiving system. Another set of actors and transactions is used to query a list of “document entries” having specific metadata, and to retrieve a document.
Web Image Access/DICOMweb	WIA offers methodologies for image sharing and interactive viewing of imaging studies via RESTful services, independent of the backend image management infrastructure.
ITI-65 Provide Document Bundle	This transaction facilitates the transmission of a bundle of documents and metadata from a Document Source to a Document Recipient, including patient documents and reports.
ITI-66 Find Document Lists	Utilized to locate List Resources that meet certain parameters. A Document Consumer requests a Bundle, containing a List resource, from the Document Responder.
ITI-67 Find Document References	This transaction enables an initiating gateway to request the retrieval of a patient's health record from a responding gateway. The initiating gateway sends a query request using ITI-38, then uses the retrieved metadata to access the patient's health record from the responding gateway.
ITI-68 Retrieve Document	This transaction lays down the procedure to locate DocumentReference resources with specified parameters. The Document Consumer requests a DocumentReference from the Document Responder, who then responds with a FHIR bundle containing the Document Reference resources aligned with the set parameters.
ITI-105 Simplified Push	This transaction outlines the procedure to transmit a Simplified Publish Request from a Document Source to a Document Recipient.
ITI-106 Generate Metadata	This transaction delineates the method to transmit a Generate Metadata Request from a Document Source to a Document Recipient.
RAD-107 WADO-RS Retrieve	This action retrieves DICOM instances rendered as images, text-based documents, or other representations depending on the target resource. Primarily aimed at providing user agents with a simplified interface for displaying medical images and related documents, without necessitating an extensive understanding of DICOM data structures and encodings. It shares similarities with the Retrieve DICOM service regarding method, resources, header fields, and status codes, with primary distinctions lying in the resource component and the query parameters.