2023-06-28T08:29:28Z

Yvette van der Haas: /* Background */

{{Vdraft/InformationBox|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 [{{VersieInfo|BITS|release=V1.0.0|namespace=bbs}} BITS].}}

__NUMBEREDHEADINGS__
{{DISPLAYTITLE:Implementation Guide BBS version {{VersieInfo|BBS|release=V1.0.0|namespace=bbs}}}}

[[Bestand:Icoon_Nictiz_Cirkel_Informatiestandaard_Beeld_en_Verslagen.svg|link=Landingspagina_Beeldbeschikbaarheid|Beeldbeschikbaarheid|100px|BBS|rechts]]

<div class="toclimit-3">__TOC__</div>

= Introduction =

== Background ==

In 2018 the Dutch Association for Radiologists ([https://radiologen.nl/ NVVR]) and the Dutch Association for Health Providers ([https://www.vzvz.nl/ VZVZ]) released the document “Landelijke beschikbaarheid radiologische beelden voor zorgverlener en patient: ''functionele vereisten''" (translates as “National availability of radiological images for the healthcare provider and patient: functional requirements”)[https://radiologen.nl/system/files/bestanden/documenten/functionele-eisen-radiologische-beelden-v1.0.pdf]. This document states that the information exchange in radiology in the Netherlands is currently 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 [https://radiologen.nl/ NVVR] and [https://www.vzvz.nl/ 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.
# A single timeline, including all studies and referrals, will provide much-needed insight and overview regarding one patient to the treating radiologist.

== About this document ==
This BBS (Dutch: Beeldbeschikbarheid, English: Image Availability) implementation guide is a technical derivation of the aforementioned, collaborative 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 [https://profiles.ihe.net/ITI/TF/index.html 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 Alfa release. It is very likely that there will be features added, adjusted and/or removed in future releases.

== Glossary ==
{| class="wikitable"
|-
! 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 ([https://www.government.nl/topics/personal-data/citizen-service-number-bsn BSN]) is a unique 9-digit personal number allocated to everyone registered in the Personal Records Database (BRP). Everyone who registers with the ([https://www.rijksoverheid.nl/onderwerpen/privacy-en-persoonsgegevens/basisregistratie-personen-brp 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 || [https://profiles.ihe.net/index.html 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 [https://decor.nictiz.nl/ad/#/ihexds-/datasets/dataset/2.16.840.1.113883.2.4.3.11.60.106.1.1/2013-12-04T12:24:19 NIHEMDS] is the National IHE MetaData Set (Dutch: Nationale IHE MetaData Set)
|-
| NVVR || [https://radiologen.nl/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 || [https://www.vzvz.nl/veelgestelde-vragen/wie-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 the standardization of healthcare information.
|-
|}

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

{| class="wikitable"
! colspan="2" style="text-align:left; font-weight: bold;" | Persons
! colspan="2" style="text-align:left; font-weight: bold;" | Systems
! colspan="2" style="text-align:left; font-weight: bold;" | XCA-I
|-
! style="text-align:left;" |Name
! style="text-align:left;" |Description
! style="text-align:left;" |Name
! style="text-align:left;" |Actors
! style="text-align:left;" |Transactions
|-
| rowspan="3" | Radiologist
| rowspan="3" | 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).
| rowspan="3" | PACS
| rowspan="2" | Responding Gateway
| ITI-38 Cross Gateway Query
|-
| ITI-39 Cross Gateway Retrieve
|-
| Responding Imaging Gateway
| RAD-75 Cross Gateway Retrieve Imaging Document Set
|-
| rowspan="3" | Radiologist/ Treating physician
| rowspan="3" | This actor is a healthcare provider that requests access to images and related information from image-generating healthcare providers.
| rowspan="3" | PACS/EPD
| rowspan="2" | Initiating Gateway
| ITI-38 Cross Gateway Query
|-
| ITI-39 Cross Gateway Retrieve
|-
| Initiating Imaging Gateway
| RAD-75 Cross Gateway Retrieve Imaging Document Set
|}

= Boundaries and relationships =
The BBS 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, Alfa, 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.

== MedMij Images (Beelden) information standard ==
[https://informatiestandaarden.nictiz.nl/wiki/MedMij:V2020.01 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, Images are a specific implementation of medical image exchange from patient to healthcare provider, while BBS 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.

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

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

= Required Metadata =
Withing BBS 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 Alfa release. It is very likely that there will be metadata added, adjusted and/or removed in future releases.

== 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:
# <code>DocumentEntry.patientId</code> <code>($XDSDocumentEntryPatientId)</code>. This is defined by IHE-NL as BSN and will be used in this guide as a 9-digit unique identifier.
# <code>DocumentEntry.availabilityStatus</code> <code>($XDSDocumentEntryStatus)</code>. This defines the lifecycle status of the DocumentEntry: Approved or Deprecated.

== NIHEMDS ==
The NIHEMDS is the National IHE MetaData Set (Dutch: Nationale IHE MetaData Set) and is published on [https://decor.nictiz.nl/ad/#/ihexds-/datasets/dataset/2.16.840.1.113883.2.4.3.11.60.106.1.1/2013-12-04T12:24:19 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.

= Use case 1: Raadplegen Tijdlijn Data / Retrieve Timeline Data =
== 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, and 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 = <code>FindDocuments</code>
# returnType = <code>ObjectRef</code>
# 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 = <code>GetDocument</code>
# returnType = <code>LeafClass</code>
# 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 [https://profiles.ihe.net/ITI/TF/Volume2/ITI-18.html the IHE framework Vol2: 3.18.4.1.2.3.1 Parameter returnType.Actors]

== Actors ==

{| class="wikitable"
! colspan="2" style="text-align:left; font-weight: bold;" | Persons
! colspan="2" style="text-align:left; font-weight: bold;" | Systems
! colspan="2" style="text-align:left; font-weight: bold;" | XCA-I
|-
! style="text-align:left;" |Name
! style="text-align:left;" |Description
! style="text-align:left;" |Name
! style="text-align:left;" |Actors
! style="text-align:left;" |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
|}

== Mapping ==
Certain data is mandatory to send along and is thus minimally expected by the receiving PACS/EPD. Hereby a mapping is made between [https://decor.nictiz.nl/ad/#/bbs-/scenarios/scenarios ART-DECOR] and the IHE metadata of these mandatory elements.

{| class="wikitable"
|-
! IHE metadata !! ART-DECOR element
|-
| DocumentEntry.sourcePatientInfo.FamilyName || Patient.Naamgegevens.Geslachtsnaam.Achternaam
|-
| DocumentEntry.patientId || Patient.Indentificatienummer
|-
| DocumentEntry.sourcePatientInfo.DateOfBirth || Patient.Geboortedatum
|-
| DocumentEntry.sourcePatientInfo.Gender|| Patient.Geslacht
|-
| DocumentEntry.serviceStartTime || Onderzoek.Verrichting.VerrichtingStartDatum
|-
| DocumentEntry.Type|| Onderzoek.Verrichting.VerrichtingType
|-
| DocumentEntry.authorInstitution.organization identifier || Onderzoek.Verrichting.Locatie.Zorgaanbieder.Zorgaanbiederidentificatienummer
|-
| DocumentEntry.authorInstitution.organization name || Onderzoek.Verrichting.Locatie.Zorgaanbieder.Organistatienaam
|-
| DocumentEntry.practiceSettingCode(.DisplayName) || Onderzoek.Verrichting.Locatie.Zorgaanbieder.AfdelingsSpecialisme
|-
| DocumentEntry.authorPerson.last name || Onderzoek.Verrichting.Uitvoerder.Zorgverlener.Naamgegevens.Geslachtsnaam.Achternaam
|-
| DocumentEntry.authorTelecommunication || Onderzoek.Verrichting.Uitvoerder.Zorgverlener.Contactgegevens.Telefoonnummers.Telefoonnummer
|-
| DocumentEntry.authorSpecialty || Onderzoek.Verrichting.Uitvoerder.Zorgverlener.ZorgverlenerRol
|-
|}

= Use case 2: Raadplegen Beelden / Retrieve images =
== 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 [https://informatiestandaarden.nictiz.nl/wiki/Bbs:V0.4.0_Concept_Ontwerp_Beeldbeschikbaarheid 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 and define the document's 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 the 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.

== Actors ==
{| class="wikitable"
! colspan="2" style="text-align:left; font-weight: bold;" | Persons
! colspan="2" style="text-align:left; font-weight: bold;" | Systems
! colspan="2" style="text-align:left; font-weight: bold;" | XCA-I
|-
! style="text-align:left;" |Name
! style="text-align:left;" |Description
! style="text-align:left;" |Name
! style="text-align:left;" |Actors
! style="text-align:left;" |Transactions
|-
| rowspan="2" | Radiologist
| rowspan="2" | 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).
| rowspan="2" | PACS
| Responding Gateway
| ITI-39 Cross Gateway Retrieve
|-
| Responding Imaging Gateway
| RAD-75 Cross Gateway Retrieve Imaging Document Set
|-
| rowspan="2" | Radiologist/ Treating physician
| rowspan="2" | This actor is a healthcare provider that requests access to images and related information from image-generating healthcare providers.
| rowspan="2" | PACS/EPD
| Initiating Gateway
| ITI-39 Cross Gateway Retrieve
|-
| Initiating Imaging Gateway
| RAD-75 Cross Gateway Retrieve Imaging Document Set
|}

== Mapping ==
Certain data is mandatory to send along and is thus minimally expected by the receiving PACS/EPD. Hereby a mapping is made between [https://decor.nictiz.nl/ad/#/bbs-/scenarios/scenarios ART-DECOR] and the IHE metadata of these mandatory elements.

{| class="wikitable"
|-
! IHE metadata !! ART-DECOR element
|-
| DocumentEntry.sourcePatientInfo.FamilyName || Patient.Naamgegevens.Geslachtsnaam.Achternaam
|-
| DocumentEntry.patientId || Patient.Indentificatienummer
|-
| DocumentEntry.sourcePatientInfo.DateOfBirth || Patient.Geboortedatum
|-
| DocumentEntry.sourcePatientInfo.Gender|| Patient.Geslacht
|-
| DcoumentEntry.creationTime || Onderzoek.Beeldinformatie.DatumTijd
|-
|}

= Use case 3: Raadplegen Verslagen / Retrieve report =
== 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 [https://informatiestandaarden.nictiz.nl/wiki/Bbs:V0.4.0_Concept_Ontwerp_Beeldbeschikbaarheid 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 a report. 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 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.

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

{| class="wikitable"
! colspan="2" style="text-align:left; font-weight: bold;" | Persons
! colspan="2" style="text-align:left; font-weight: bold;" | Systems
! colspan="2" style="text-align:left; font-weight: bold;" | XCA-I
|-
! style="text-align:left;" |Name
! style="text-align:left;" |Description
! style="text-align:left;" |Name
! style="text-align:left;" |Actors
! style="text-align:left;" |Transactions
|-
| rowspan="2" | Radiologist
| rowspan="2" | 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).
| rowspan="2" | 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
|}

== Mapping ==
Certain data is mandatory to send along and is thus minimally expected by the receiving PACS/EPD. Hereby a mapping is made between [https://decor.nictiz.nl/ad/#/bbs-/scenarios/scenarios ART-DECOR] and the IHE metadata of these mandatory elements.

{| class="wikitable"
|-
! IHE metadata !! ART-DECOR element
|-
| DocumentEntry.sourcePatientInfo.FamilyName || Patient.Naamgegevens.Geslachtsnaam.Achternaam
|-
| DocumentEntry.patientId || Patient.Indentificatienummer
|-
| DocumentEntry.sourcePatientInfo.DateOfBirth || Patient.Geboortedatum
|-
| DocumentEntry.sourcePatientInfo.Gender|| Patient.Geslacht
|-
| Needs to be mentioned in report || Onderzoek.Verslaginformatie.AuthoriserendRadioloog.Zorgvelener.Naamgegevens.Geslachtsnaam.Achternaam
|-
| Needs to be mentioned in report || Onderzoek.Verslaginformatie.DicterendRadioloog.Zorgvelener.Naamgegevens.Geslachtsnaam.Achternaam
|-
| DocumentEntry.uniqueId || Onderzoek.Verslaginformatie.VerslagIdentificatienummer
|-
| DcoumentEntry.creationTime || Onderzoek.Verslaginformatie.DatumTijd
|-
|}

= Use case 4: Sturen Beelden / Send images =
{{IssueBox|This use case is in development!}}

= Use case 5: Sturen Verslagen / Send report =
{{IssueBox|This use case is in development!}}

= Profiles =
The BBS specification defines ZIB and IHE profiles.

== Zib ==
{| class="wikitable"
! style="font-weight: bold;text-align:left;" | Zib NL (2020)
! style="font-weight: bold;text-align:left;" | HCIM EN
|-
| [https://zibs.nl/wiki/Patient-v3.2(2020NL) Patient]
| Patient
|-
| [https://zibs.nl/wiki/Verrichting-v5.2(2020NL) Verrichting]
| Procedure
|-
| [https://zibs.nl/wiki/Zorgverlener-v3.5(2020NL) Zorgverlener]
| HealthProfessional
|-
| [https://zibs.nl/wiki/Zorgaanbieder-v3.4(2020NL) Zorgaanbieder]
| HealthcareProvider
|}

== IHE ==
{| class="wikitable"
! style="font-weight: bold;text-align:left;" | IHE Profile
! style="font-weight: bold;text-align:left;" | Description
|-
| [https://profiles.ihe.net/ITI/TF/Volume2/ITI-38.html 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.
|-
| [https://profiles.ihe.net/ITI/TF/Volume2/ITI-39.html 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.
|-
| [https://www.ihe.net/uploadedFiles/Documents/Radiology/IHE_RAD_TF_Vol2.pdf 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.
|-
| [https://profiles.ihe.net/ITI/TF/Volume1/ch-18.html#18 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.
|}

Bbs:V1 IG

2023-06-26T13:59:09Z

Yvette van der Haas: /* Introduction */

{{Vdraft/InformationBox|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 [{{VersieInfo|BITS|release=V1.0.0|namespace=bbs}} BITS].}}

__NUMBEREDHEADINGS__
{{DISPLAYTITLE:Implementation Guide BBS version {{VersieInfo|BBS|release=V1.0.0|namespace=bbs}}}}

[[Bestand:Icoon_Nictiz_Cirkel_Informatiestandaard_Beeld_en_Verslagen.svg|link=Landingspagina_Beeldbeschikbaarheid|Beeldbeschikbaarheid|100px|BBS|rechts]]

<div class="toclimit-3">__TOC__</div>

= Introduction =

== Background ==

In 2018 the Dutch Association for Radiologists ([https://radiologen.nl/ NVVR]) and the Dutch Association for Health Providers ([https://www.vzvz.nl/ VZVZ]) released the document “Landelijke beschikbaarheid radiologische beelden voor zorgverlener en patient: ''functionele vereisten''" (translates as “National availability of radiological images for the healthcare provider and patient: functional requirements”)[https://radiologen.nl/system/files/bestanden/documenten/functionele-eisen-radiologische-beelden-v1.0.pdf]. 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 [https://radiologen.nl/ NVVR] and [https://www.vzvz.nl/ 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.
# A single timeline, including all studies and referrals, will provide much-needed insight and overview regarding one patient to the treating radiologist.

== About this document ==
This BBS (Dutch: Beeldbeschikbarheid, English: Image Availability) implementation guide is a technical derivation of the aforementioned, collaborative 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 [https://profiles.ihe.net/ITI/TF/index.html 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 Alfa release. It is very likely that there will be features added, adjusted and/or removed in future releases.

== Glossary ==
{| class="wikitable"
|-
! 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 ([https://www.government.nl/topics/personal-data/citizen-service-number-bsn BSN]) is a unique 9-digit personal number allocated to everyone registered in the Personal Records Database (BRP). Everyone who registers with the ([https://www.rijksoverheid.nl/onderwerpen/privacy-en-persoonsgegevens/basisregistratie-personen-brp 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 || [https://profiles.ihe.net/index.html 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 [https://decor.nictiz.nl/ad/#/ihexds-/datasets/dataset/2.16.840.1.113883.2.4.3.11.60.106.1.1/2013-12-04T12:24:19 NIHEMDS] is the National IHE MetaData Set (Dutch: Nationale IHE MetaData Set)
|-
| NVVR || [https://radiologen.nl/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 || [https://www.vzvz.nl/veelgestelde-vragen/wie-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 the standardization of healthcare information.
|-
|}

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

{| class="wikitable"
! colspan="2" style="text-align:left; font-weight: bold;" | Persons
! colspan="2" style="text-align:left; font-weight: bold;" | Systems
! colspan="2" style="text-align:left; font-weight: bold;" | XCA-I
|-
! style="text-align:left;" |Name
! style="text-align:left;" |Description
! style="text-align:left;" |Name
! style="text-align:left;" |Actors
! style="text-align:left;" |Transactions
|-
| rowspan="3" | Radiologist
| rowspan="3" | 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).
| rowspan="3" | PACS
| rowspan="2" | Responding Gateway
| ITI-38 Cross Gateway Query
|-
| ITI-39 Cross Gateway Retrieve
|-
| Responding Imaging Gateway
| RAD-75 Cross Gateway Retrieve Imaging Document Set
|-
| rowspan="3" | Radiologist/ Treating physician
| rowspan="3" | This actor is a healthcare provider that requests access to images and related information from image-generating healthcare providers.
| rowspan="3" | PACS/EPD
| rowspan="2" | Initiating Gateway
| ITI-38 Cross Gateway Query
|-
| ITI-39 Cross Gateway Retrieve
|-
| Initiating Imaging Gateway
| RAD-75 Cross Gateway Retrieve Imaging Document Set
|}

= Boundaries and relationships =
The BBS 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, Alfa, 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.

== MedMij Images (Beelden) information standard ==
[https://informatiestandaarden.nictiz.nl/wiki/MedMij:V2020.01 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, Images are a specific implementation of medical image exchange from patient to healthcare provider, while BBS 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.

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

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

= Required Metadata =
Withing BBS 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 Alfa release. It is very likely that there will be metadata added, adjusted and/or removed in future releases.

== 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:
# <code>DocumentEntry.patientId</code> <code>($XDSDocumentEntryPatientId)</code>. This is defined by IHE-NL as BSN and will be used in this guide as a 9-digit unique identifier.
# <code>DocumentEntry.availabilityStatus</code> <code>($XDSDocumentEntryStatus)</code>. This defines the lifecycle status of the DocumentEntry: Approved or Deprecated.

== NIHEMDS ==
The NIHEMDS is the National IHE MetaData Set (Dutch: Nationale IHE MetaData Set) and is published on [https://decor.nictiz.nl/ad/#/ihexds-/datasets/dataset/2.16.840.1.113883.2.4.3.11.60.106.1.1/2013-12-04T12:24:19 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.

= Use case 1: Raadplegen Tijdlijn Data / Retrieve Timeline Data =
== 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, and 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 = <code>FindDocuments</code>
# returnType = <code>ObjectRef</code>
# 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 = <code>GetDocument</code>
# returnType = <code>LeafClass</code>
# 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 [https://profiles.ihe.net/ITI/TF/Volume2/ITI-18.html the IHE framework Vol2: 3.18.4.1.2.3.1 Parameter returnType.Actors]

== Actors ==

{| class="wikitable"
! colspan="2" style="text-align:left; font-weight: bold;" | Persons
! colspan="2" style="text-align:left; font-weight: bold;" | Systems
! colspan="2" style="text-align:left; font-weight: bold;" | XCA-I
|-
! style="text-align:left;" |Name
! style="text-align:left;" |Description
! style="text-align:left;" |Name
! style="text-align:left;" |Actors
! style="text-align:left;" |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
|}

== Mapping ==
Certain data is mandatory to send along and is thus minimally expected by the receiving PACS/EPD. Hereby a mapping is made between [https://decor.nictiz.nl/ad/#/bbs-/scenarios/scenarios ART-DECOR] and the IHE metadata of these mandatory elements.

{| class="wikitable"
|-
! IHE metadata !! ART-DECOR element
|-
| DocumentEntry.sourcePatientInfo.FamilyName || Patient.Naamgegevens.Geslachtsnaam.Achternaam
|-
| DocumentEntry.patientId || Patient.Indentificatienummer
|-
| DocumentEntry.sourcePatientInfo.DateOfBirth || Patient.Geboortedatum
|-
| DocumentEntry.sourcePatientInfo.Gender|| Patient.Geslacht
|-
| DocumentEntry.serviceStartTime || Onderzoek.Verrichting.VerrichtingStartDatum
|-
| DocumentEntry.Type|| Onderzoek.Verrichting.VerrichtingType
|-
| DocumentEntry.authorInstitution.organization identifier || Onderzoek.Verrichting.Locatie.Zorgaanbieder.Zorgaanbiederidentificatienummer
|-
| DocumentEntry.authorInstitution.organization name || Onderzoek.Verrichting.Locatie.Zorgaanbieder.Organistatienaam
|-
| DocumentEntry.practiceSettingCode(.DisplayName) || Onderzoek.Verrichting.Locatie.Zorgaanbieder.AfdelingsSpecialisme
|-
| DocumentEntry.authorPerson.last name || Onderzoek.Verrichting.Uitvoerder.Zorgverlener.Naamgegevens.Geslachtsnaam.Achternaam
|-
| DocumentEntry.authorTelecommunication || Onderzoek.Verrichting.Uitvoerder.Zorgverlener.Contactgegevens.Telefoonnummers.Telefoonnummer
|-
| DocumentEntry.authorSpecialty || Onderzoek.Verrichting.Uitvoerder.Zorgverlener.ZorgverlenerRol
|-
|}

= Use case 2: Raadplegen Beelden / Retrieve images =
== 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 [https://informatiestandaarden.nictiz.nl/wiki/Bbs:V0.4.0_Concept_Ontwerp_Beeldbeschikbaarheid 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 and define the document's 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 the 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.

== Actors ==
{| class="wikitable"
! colspan="2" style="text-align:left; font-weight: bold;" | Persons
! colspan="2" style="text-align:left; font-weight: bold;" | Systems
! colspan="2" style="text-align:left; font-weight: bold;" | XCA-I
|-
! style="text-align:left;" |Name
! style="text-align:left;" |Description
! style="text-align:left;" |Name
! style="text-align:left;" |Actors
! style="text-align:left;" |Transactions
|-
| rowspan="2" | Radiologist
| rowspan="2" | 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).
| rowspan="2" | PACS
| Responding Gateway
| ITI-39 Cross Gateway Retrieve
|-
| Responding Imaging Gateway
| RAD-75 Cross Gateway Retrieve Imaging Document Set
|-
| rowspan="2" | Radiologist/ Treating physician
| rowspan="2" | This actor is a healthcare provider that requests access to images and related information from image-generating healthcare providers.
| rowspan="2" | PACS/EPD
| Initiating Gateway
| ITI-39 Cross Gateway Retrieve
|-
| Initiating Imaging Gateway
| RAD-75 Cross Gateway Retrieve Imaging Document Set
|}

== Mapping ==
Certain data is mandatory to send along and is thus minimally expected by the receiving PACS/EPD. Hereby a mapping is made between [https://decor.nictiz.nl/ad/#/bbs-/scenarios/scenarios ART-DECOR] and the IHE metadata of these mandatory elements.

{| class="wikitable"
|-
! IHE metadata !! ART-DECOR element
|-
| DocumentEntry.sourcePatientInfo.FamilyName || Patient.Naamgegevens.Geslachtsnaam.Achternaam
|-
| DocumentEntry.patientId || Patient.Indentificatienummer
|-
| DocumentEntry.sourcePatientInfo.DateOfBirth || Patient.Geboortedatum
|-
| DocumentEntry.sourcePatientInfo.Gender|| Patient.Geslacht
|-
| DcoumentEntry.creationTime || Onderzoek.Beeldinformatie.DatumTijd
|-
|}

= Use case 3: Raadplegen Verslagen / Retrieve report =
== 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 [https://informatiestandaarden.nictiz.nl/wiki/Bbs:V0.4.0_Concept_Ontwerp_Beeldbeschikbaarheid 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 a report. 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 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.

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

{| class="wikitable"
! colspan="2" style="text-align:left; font-weight: bold;" | Persons
! colspan="2" style="text-align:left; font-weight: bold;" | Systems
! colspan="2" style="text-align:left; font-weight: bold;" | XCA-I
|-
! style="text-align:left;" |Name
! style="text-align:left;" |Description
! style="text-align:left;" |Name
! style="text-align:left;" |Actors
! style="text-align:left;" |Transactions
|-
| rowspan="2" | Radiologist
| rowspan="2" | 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).
| rowspan="2" | 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
|}

== Mapping ==
Certain data is mandatory to send along and is thus minimally expected by the receiving PACS/EPD. Hereby a mapping is made between [https://decor.nictiz.nl/ad/#/bbs-/scenarios/scenarios ART-DECOR] and the IHE metadata of these mandatory elements.

{| class="wikitable"
|-
! IHE metadata !! ART-DECOR element
|-
| DocumentEntry.sourcePatientInfo.FamilyName || Patient.Naamgegevens.Geslachtsnaam.Achternaam
|-
| DocumentEntry.patientId || Patient.Indentificatienummer
|-
| DocumentEntry.sourcePatientInfo.DateOfBirth || Patient.Geboortedatum
|-
| DocumentEntry.sourcePatientInfo.Gender|| Patient.Geslacht
|-
| Needs to be mentioned in report || Onderzoek.Verslaginformatie.AuthoriserendRadioloog.Zorgvelener.Naamgegevens.Geslachtsnaam.Achternaam
|-
| Needs to be mentioned in report || Onderzoek.Verslaginformatie.DicterendRadioloog.Zorgvelener.Naamgegevens.Geslachtsnaam.Achternaam
|-
| DocumentEntry.uniqueId || Onderzoek.Verslaginformatie.VerslagIdentificatienummer
|-
| DcoumentEntry.creationTime || Onderzoek.Verslaginformatie.DatumTijd
|-
|}

= Use case 4: Sturen Beelden / Send images =
{{IssueBox|This use case is in development!}}

= Use case 5: Sturen Verslagen / Send report =
{{IssueBox|This use case is in development!}}

= Profiles =
The BBS specification defines ZIB and IHE profiles.

== Zib ==
{| class="wikitable"
! style="font-weight: bold;text-align:left;" | Zib NL (2020)
! style="font-weight: bold;text-align:left;" | HCIM EN
|-
| [https://zibs.nl/wiki/Patient-v3.2(2020NL) Patient]
| Patient
|-
| [https://zibs.nl/wiki/Verrichting-v5.2(2020NL) Verrichting]
| Procedure
|-
| [https://zibs.nl/wiki/Zorgverlener-v3.5(2020NL) Zorgverlener]
| HealthProfessional
|-
| [https://zibs.nl/wiki/Zorgaanbieder-v3.4(2020NL) Zorgaanbieder]
| HealthcareProvider
|}

== IHE ==
{| class="wikitable"
! style="font-weight: bold;text-align:left;" | IHE Profile
! style="font-weight: bold;text-align:left;" | Description
|-
| [https://profiles.ihe.net/ITI/TF/Volume2/ITI-38.html 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.
|-
| [https://profiles.ihe.net/ITI/TF/Volume2/ITI-39.html 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.
|-
| [https://www.ihe.net/uploadedFiles/Documents/Radiology/IHE_RAD_TF_Vol2.pdf 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.
|-
| [https://profiles.ihe.net/ITI/TF/Volume1/ch-18.html#18 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.
|}

Bbs:V1 IG

2023-06-26T13:58:19Z

Yvette van der Haas: /* Introduction */

{{Vdraft/InformationBox|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 [{{VersieInfo|BITS|release=V1.0.0|namespace=bbs}} BITS].}}

__NUMBEREDHEADINGS__
{{DISPLAYTITLE:Implementation Guide BBS version {{VersieInfo|BBS|release=V1.0.0|namespace=bbs}}}}

[[Bestand:Icoon_Nictiz_Cirkel_Informatiestandaard_Beeld_en_Verslagen.svg|link=Landingspagina_Beeldbeschikbaarheid|Beeldbeschikbaarheid|100px|BBS|rechts]]

<div class="toclimit-3">__TOC__</div>

= Introduction =

== Background ==

In 2018 the Dutch Association for Radiologists ([https://radiologen.nl/ NVVR]) and the Dutch Association for Health Providers ([https://www.vzvz.nl/ VZVZ]) released the document “Landelijke beschikbaarheid radiologische beelden voor zorgverlener en patient: ''functionele vereisten''" (translates as “National availability of radiological images for the healthcare provider and patient: functional requirements”)[https://radiologen.nl/system/files/bestanden/documenten/functionele-eisen-radiologische-beelden-v1.0.pdf]. 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 [https://radiologen.nl/ NVVR] and [https://www.vzvz.nl/ 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.
# A single timeline, including all studies and referrals, will provide much-needed insight and overview regarding one patient to the treating radiologist.

== About this document ==
This BBS (Dutch: Beeldbeschikbarheid, English: Image Availability) implementation guide is a technical derivation of the aforementioned, collaborative 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 [https://profiles.ihe.net/ITI/TF/index.html 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 Alfa release. It is very likely that there will be features added, adjusted and/or removed in future releases.

== Glossary ==
{| class="wikitable"
|-
! 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 ([https://www.government.nl/topics/personal-data/citizen-service-number-bsn BSN]) is a unique 9-digit personal number allocated to everyone registered in the Personal Records Database (BRP). Everyone who registers with the ([https://www.rijksoverheid.nl/onderwerpen/privacy-en-persoonsgegevens/basisregistratie-personen-brp 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 || [https://profiles.ihe.net/index.html 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 [https://decor.nictiz.nl/ad/#/ihexds-/datasets/dataset/2.16.840.1.113883.2.4.3.11.60.106.1.1/2013-12-04T12:24:19 NIHEMDS] is the National IHE MetaData Set (Dutch: Nationale IHE MetaData Set)
|-
| NVVR || [https://radiologen.nl/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 || [https://www.vzvz.nl/veelgestelde-vragen/wie-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 the standardization of healthcare information.
|-
|}

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

{| class="wikitable"
! colspan="2" style="text-align:left; font-weight: bold;" | Persons
! colspan="2" style="text-align:left; font-weight: bold;" | Systems
! colspan="2" style="text-align:left; font-weight: bold;" | XCA-I
|-
! style="text-align:left;" |Name
! style="text-align:left;" |Description
! style="text-align:left;" |Name
! style="text-align:left;" |Actors
! style="text-align:left;" |Transactions
|-
| rowspan="3" | Radiologist
| rowspan="3" | 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).
| rowspan="3" | PACS
| rowspan="2" | Responding Gateway
| ITI-38 Cross Gateway Query
|-
| ITI-39 Cross Gateway Retrieve
|-
| Responding Imaging Gateway
| RAD-75 Cross Gateway Retrieve Imaging Document Set
|-
| rowspan="3" | Radiologist/ Treating physician
| rowspan="3" | This actor is a healthcare provider that requests access to images and related information from image-generating healthcare providers.
| rowspan="3" | PACS/EPD
| rowspan="2" | Initiating Gateway
| ITI-38 Cross Gateway Query
|-
| ITI-39 Cross Gateway Retrieve
|-
| Initiating Imaging Gateway
| RAD-75 Cross Gateway Retrieve Imaging Document Set
|}

= Boundaries and relationships =
The BBS 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, Alfa, 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.

== MedMij Images (Beelden) information standard ==
[https://informatiestandaarden.nictiz.nl/wiki/MedMij:V2020.01 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, Images are a specific implementation of medical image exchange from patient to healthcare provider, while BBS 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.

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

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

= Required Metadata =
Withing BBS 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 Alfa release. It is very likely that there will be metadata added, adjusted and/or removed in future releases.

== 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:
# <code>DocumentEntry.patientId</code> <code>($XDSDocumentEntryPatientId)</code>. This is defined by IHE-NL as BSN and will be used in this guide as a 9-digit unique identifier.
# <code>DocumentEntry.availabilityStatus</code> <code>($XDSDocumentEntryStatus)</code>. This defines the lifecycle status of the DocumentEntry: Approved or Deprecated.

== NIHEMDS ==
The NIHEMDS is the National IHE MetaData Set (Dutch: Nationale IHE MetaData Set) and is published on [https://decor.nictiz.nl/ad/#/ihexds-/datasets/dataset/2.16.840.1.113883.2.4.3.11.60.106.1.1/2013-12-04T12:24:19 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.

= Use case 1: Raadplegen Tijdlijn Data / Retrieve Timeline Data =
== 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, and 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 = <code>FindDocuments</code>
# returnType = <code>ObjectRef</code>
# 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 = <code>GetDocument</code>
# returnType = <code>LeafClass</code>
# 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 [https://profiles.ihe.net/ITI/TF/Volume2/ITI-18.html the IHE framework Vol2: 3.18.4.1.2.3.1 Parameter returnType.Actors]

== Actors ==

{| class="wikitable"
! colspan="2" style="text-align:left; font-weight: bold;" | Persons
! colspan="2" style="text-align:left; font-weight: bold;" | Systems
! colspan="2" style="text-align:left; font-weight: bold;" | XCA-I
|-
! style="text-align:left;" |Name
! style="text-align:left;" |Description
! style="text-align:left;" |Name
! style="text-align:left;" |Actors
! style="text-align:left;" |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
|}

== Mapping ==
Certain data is mandatory to send along and is thus minimally expected by the receiving PACS/EPD. Hereby a mapping is made between [https://decor.nictiz.nl/ad/#/bbs-/scenarios/scenarios ART-DECOR] and the IHE metadata of these mandatory elements.

{| class="wikitable"
|-
! IHE metadata !! ART-DECOR element
|-
| DocumentEntry.sourcePatientInfo.FamilyName || Patient.Naamgegevens.Geslachtsnaam.Achternaam
|-
| DocumentEntry.patientId || Patient.Indentificatienummer
|-
| DocumentEntry.sourcePatientInfo.DateOfBirth || Patient.Geboortedatum
|-
| DocumentEntry.sourcePatientInfo.Gender|| Patient.Geslacht
|-
| DocumentEntry.serviceStartTime || Onderzoek.Verrichting.VerrichtingStartDatum
|-
| DocumentEntry.Type|| Onderzoek.Verrichting.VerrichtingType
|-
| DocumentEntry.authorInstitution.organization identifier || Onderzoek.Verrichting.Locatie.Zorgaanbieder.Zorgaanbiederidentificatienummer
|-
| DocumentEntry.authorInstitution.organization name || Onderzoek.Verrichting.Locatie.Zorgaanbieder.Organistatienaam
|-
| DocumentEntry.practiceSettingCode(.DisplayName) || Onderzoek.Verrichting.Locatie.Zorgaanbieder.AfdelingsSpecialisme
|-
| DocumentEntry.authorPerson.last name || Onderzoek.Verrichting.Uitvoerder.Zorgverlener.Naamgegevens.Geslachtsnaam.Achternaam
|-
| DocumentEntry.authorTelecommunication || Onderzoek.Verrichting.Uitvoerder.Zorgverlener.Contactgegevens.Telefoonnummers.Telefoonnummer
|-
| DocumentEntry.authorSpecialty || Onderzoek.Verrichting.Uitvoerder.Zorgverlener.ZorgverlenerRol
|-
|}

= Use case 2: Raadplegen Beelden / Retrieve images =
== 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 [https://informatiestandaarden.nictiz.nl/wiki/Bbs:V0.4.0_Concept_Ontwerp_Beeldbeschikbaarheid 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 and define the document's 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 the 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.

== Actors ==
{| class="wikitable"
! colspan="2" style="text-align:left; font-weight: bold;" | Persons
! colspan="2" style="text-align:left; font-weight: bold;" | Systems
! colspan="2" style="text-align:left; font-weight: bold;" | XCA-I
|-
! style="text-align:left;" |Name
! style="text-align:left;" |Description
! style="text-align:left;" |Name
! style="text-align:left;" |Actors
! style="text-align:left;" |Transactions
|-
| rowspan="2" | Radiologist
| rowspan="2" | 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).
| rowspan="2" | PACS
| Responding Gateway
| ITI-39 Cross Gateway Retrieve
|-
| Responding Imaging Gateway
| RAD-75 Cross Gateway Retrieve Imaging Document Set
|-
| rowspan="2" | Radiologist/ Treating physician
| rowspan="2" | This actor is a healthcare provider that requests access to images and related information from image-generating healthcare providers.
| rowspan="2" | PACS/EPD
| Initiating Gateway
| ITI-39 Cross Gateway Retrieve
|-
| Initiating Imaging Gateway
| RAD-75 Cross Gateway Retrieve Imaging Document Set
|}

== Mapping ==
Certain data is mandatory to send along and is thus minimally expected by the receiving PACS/EPD. Hereby a mapping is made between [https://decor.nictiz.nl/ad/#/bbs-/scenarios/scenarios ART-DECOR] and the IHE metadata of these mandatory elements.

{| class="wikitable"
|-
! IHE metadata !! ART-DECOR element
|-
| DocumentEntry.sourcePatientInfo.FamilyName || Patient.Naamgegevens.Geslachtsnaam.Achternaam
|-
| DocumentEntry.patientId || Patient.Indentificatienummer
|-
| DocumentEntry.sourcePatientInfo.DateOfBirth || Patient.Geboortedatum
|-
| DocumentEntry.sourcePatientInfo.Gender|| Patient.Geslacht
|-
| DcoumentEntry.creationTime || Onderzoek.Beeldinformatie.DatumTijd
|-
|}

= Use case 3: Raadplegen Verslagen / Retrieve report =
== 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 [https://informatiestandaarden.nictiz.nl/wiki/Bbs:V0.4.0_Concept_Ontwerp_Beeldbeschikbaarheid 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 a report. 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 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.

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

{| class="wikitable"
! colspan="2" style="text-align:left; font-weight: bold;" | Persons
! colspan="2" style="text-align:left; font-weight: bold;" | Systems
! colspan="2" style="text-align:left; font-weight: bold;" | XCA-I
|-
! style="text-align:left;" |Name
! style="text-align:left;" |Description
! style="text-align:left;" |Name
! style="text-align:left;" |Actors
! style="text-align:left;" |Transactions
|-
| rowspan="2" | Radiologist
| rowspan="2" | 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).
| rowspan="2" | 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
|}

== Mapping ==
Certain data is mandatory to send along and is thus minimally expected by the receiving PACS/EPD. Hereby a mapping is made between [https://decor.nictiz.nl/ad/#/bbs-/scenarios/scenarios ART-DECOR] and the IHE metadata of these mandatory elements.

{| class="wikitable"
|-
! IHE metadata !! ART-DECOR element
|-
| DocumentEntry.sourcePatientInfo.FamilyName || Patient.Naamgegevens.Geslachtsnaam.Achternaam
|-
| DocumentEntry.patientId || Patient.Indentificatienummer
|-
| DocumentEntry.sourcePatientInfo.DateOfBirth || Patient.Geboortedatum
|-
| DocumentEntry.sourcePatientInfo.Gender|| Patient.Geslacht
|-
| Needs to be mentioned in report || Onderzoek.Verslaginformatie.AuthoriserendRadioloog.Zorgvelener.Naamgegevens.Geslachtsnaam.Achternaam
|-
| Needs to be mentioned in report || Onderzoek.Verslaginformatie.DicterendRadioloog.Zorgvelener.Naamgegevens.Geslachtsnaam.Achternaam
|-
| DocumentEntry.uniqueId || Onderzoek.Verslaginformatie.VerslagIdentificatienummer
|-
| DcoumentEntry.creationTime || Onderzoek.Verslaginformatie.DatumTijd
|-
|}

= Use case 4: Sturen Beelden / Send images =
{{IssueBox|This use case is in development!}}

= Use case 5: Sturen Verslagen / Send report =
{{IssueBox|This use case is in development!}}

= Profiles =
The BBS specification defines ZIB and IHE profiles.

== Zib ==
{| class="wikitable"
! style="font-weight: bold;text-align:left;" | Zib NL (2020)
! style="font-weight: bold;text-align:left;" | HCIM EN
|-
| [https://zibs.nl/wiki/Patient-v3.2(2020NL) Patient]
| Patient
|-
| [https://zibs.nl/wiki/Verrichting-v5.2(2020NL) Verrichting]
| Procedure
|-
| [https://zibs.nl/wiki/Zorgverlener-v3.5(2020NL) Zorgverlener]
| HealthProfessional
|-
| [https://zibs.nl/wiki/Zorgaanbieder-v3.4(2020NL) Zorgaanbieder]
| HealthcareProvider
|}

== IHE ==
{| class="wikitable"
! style="font-weight: bold;text-align:left;" | IHE Profile
! style="font-weight: bold;text-align:left;" | Description
|-
| [https://profiles.ihe.net/ITI/TF/Volume2/ITI-38.html 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.
|-
| [https://profiles.ihe.net/ITI/TF/Volume2/ITI-39.html 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.
|-
| [https://www.ihe.net/uploadedFiles/Documents/Radiology/IHE_RAD_TF_Vol2.pdf 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.
|-
| [https://profiles.ihe.net/ITI/TF/Volume1/ch-18.html#18 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.
|}