Brontekst bekijken van Bbs:V1 IG

{{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 patiënt: ''functionele vereisten''”  (translates as “National availability of radiological images for the health professional 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 healthcare professionals 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 healthcare professional only has a part of the patient’s dossier – not only unwanted but also a risk for continuity, safety and results related to the patient. The document released by NVvR and VZVZ explains that the vision is that every radiologist should be able to view a timeline of ''every'' radiology-related research concerning the patient.

The main objectives of the mentioned collaborative document are:
# Within 3 years a central timeline representing all the radiology encounters of a patient, including studies and referrals, should exist.
# This timeline should be available in the work environment of every radiologist regardless of where the radiologist is working at that time.
# 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: Beeldbeschikbaarheid, 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 professionals can provide radiology images and/or reports in the Netherlands using cross gateway interoperability.

Since this document is part of an alfa release, features will likely be 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 ([https://www.rijksoverheid.nl/onderwerpen/privacy-en-persoonsgegevens/basisregistratie-personen-brp BRP]). Everyone who registers with the BRP is automatically given a BSN.
|-
| Documents || Describes reports and/or images (via an image manifest / DICOM KOS object) which include patient identification, patient demographic details, author, creation date/time, content type and other metadata needed to define the source and provenance of the contained information.
|-
| IHE || [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). 
|-
| 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 they work 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 professional that requests access to images and related information from image-generating healthcare professionals. 
| rowspan="3" | PACS/EHR
| 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 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.

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

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

== 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: Retrieve Timeline Data (Raadplegen Tijdlijn 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 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 

# QueryID = ''FindDocuments''
# returnType = ''ObjectRef''
# A simple set of query keys (maybe a date range or clinic type)

This should return a list of matching document UUIDS (unique registry identifiers). As we don’t know the number of documents belonging to the patient (number of matching query responses) beforehand this approach provides the “smallest” response in terms of data per document. However, this is not enough detail to create a timeline entry. 

'''Step 2: ''' Using the list of returned document UUIDS from step 1, perform a second query for each document by issuing a new ITI-38:

# QueryID = ''GetDocument''
# returnType = ''LeafClass''
# query key 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 [https://profiles.ihe.net/ITI/TF/Volume2/ITI-18.html#3.18.4.1.2.3.1 the IHE framework Vol2].

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

== Mapping ==
Certain data is mandatory to send along and is thus minimally expected by the receiving PACS/EHR. 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.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
|-
|}

= Use case 2: Retrieve Images (Raadplegen Beelden) =
== 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 [https://informatiestandaarden.nictiz.nl/wiki/Bbs:V0.4.0_Concept_Ontwerp_Beeldbeschikbaarheid functional design].

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

== 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. 
{| 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 they work 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 professional that requests access to images and related information from image-generating healthcare professionals. 
| rowspan="2" | PACS/EHR
| 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/EHR. 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.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
|-
|}

= Use case 3: Retrieve Reports (Raadplegen Verslagen) =
== 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 [https://informatiestandaarden.nictiz.nl/wiki/Bbs:V0.4.0_Concept_Ontwerp_Beeldbeschikbaarheid functional design]: 

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

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

== Mapping ==
Certain data is mandatory to send along and is thus minimally expected by the receiving PACS/EHR. 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.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
|-
|}

= Use case 4: Send Images (Sturen Beelden) =
{{IssueBox|This use case is in development!}}

= Use case 5: Send Reports (Sturen Verslagen) =
{{IssueBox|This use case is in development!}}

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

== HCIMs ==
{| class="wikitable"
! style="font-weight: bold;text-align:left;" | Zib NL
! 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/Volume1/ch-18.html#18  Cross-Community Access (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.
|-
| [https://profiles.ihe.net/ITI/TF/Volume2/ITI-38.html  ITI-38 Cross Gateway Query]
| This transaction defines a way for a source gateway to send a query request to a destination gateway to retrieve metadata about patients and their health records. The query can be based on a variety of parameters such as patient name, ID, birth date, and diagnosis. 
|-
| [https://profiles.ihe.net/ITI/TF/Volume2/ITI-39.html  ITI-39 Cross Gateway Retrieve]
| This transaction defines a way for a source gateway to request the retrieval of a patient's health record from a destination gateway. The source gateway sends a query request using ITI-38 and then uses the retrieved metadata to retrieve the patient's health record from the destination gateway. 
|-
| [https://www.ihe.net/uploadedFiles/Documents/Radiology/IHE_RAD_TF_Vol2.pdf  RAD-75 Cross Gateway Retrieve Imaging Document Set]
| This transaction allows a source gateway to request the retrieval of a patient's imaging documents from a destination gateway. The source gateway sends a query request using ITI-38 to retrieve metadata about the patient and their imaging studies and then uses RAD-75 to retrieve the actual imaging documents from the destination gateway. 
|}