2. FHIR IG

2.1. Introduction

This IG describes a patient use case in the context of the information standard "Image Availability" (Dutch: Beeldbeschikbaarheid or BBS), version 1.0.0-alpha.2. The information standard Image Availability as published by Nictiz does not yet include a patient use case, this may change in the future. Up until then, the patient use case will be published by MedMij.

This IG is a technical counterpart of the functional design. The FHIR version used for this IG is R4 (4.0.1).

2.2. Actors involved

Actor		System		FHIR CapabilityStatement
Name	Description	Name	Description	Name	Description
Patient	The user of a personal healthcare environment	PHR (Document Consumer)	Personal health record	[TO DO]	FHIR client requirements
Healthcare provider	The user of a XIS	XIS (Document Responder)	Healthcare information system	[TO DO]	FHIR server requirements

Table 1: Actors

2.3. Boundaries and relationships

This FHIR IG includes use cases for the exchange of images and reports between healthcare providers (e.g. hospitals) and patients (e.g. in a PHR setting).

This IG assumes that a PHR is able to make a connection to the right XIS that contains the patient's information. It does not provide information on finding the right source system nor does it provide information about security. These infrastructure and interface specifications are described in the MedMij Afsprakenstelsel. In particular, each transaction is performed in the context of a specific authenticated patient, which has been established using the authentication mechanisms outlined in the MedMij Afsprakenstelsel (also see the MedMij FHIR IG by Nictiz), i.e. via an OAuth2 token. Each XIS gateway is required to perform filtering based on the patient associated with the context for the request, so only the records associated with the authenticated patient are returned. For this reason, search parameters should not be included for patient identification.

2.4. Relating FHIR (profiles) to its functional counterpart

The BBS FHIR IG, section 5.3 describes the (intended) mapping between metadata, FHIR (DocumentReference) and the datasets in ART-DECOR. In this FHIR IG, we incorporate the aforementioned functional mapping provided by Nictiz BBS. This mapping has resulted in the bbs-DocumentReference profile.

2.5. Identifiers

There are several identifiers that play a role in the exchange of images and reports. The following table gives an overview of all these identifiers, and how they are related to each other.

Identifier	Source	Definition	FHIR DocumentReference element
Document Unique ID	National IHE MetaData Set (2024), ihexds-dataelement-29	The globally unique identifier of a document in XDS, assigned by the document source. This identifier is stable during data exchange and is not generated by the XDS document repository. It is used for identification, version control and deduplication.	`.masterIdentifier`
Report Information Identification Number	Nictiz BBS dataset (1.0.0-alpha.2), bbs-dataelement-100	The globally unique id of a report of the imaging study in a XIS, used for synchronization and identification of the report. In an XDS context, this identifier could be equal to the Document Unique ID of the report. In DICOM, the Study Instance UID MAY be used as Report Information Identification Number.	`.masterIdentifier`
Image Information Identification Number	Nictiz BBS dataset (1.0.0-alpha.2), bbs-dataelement-784	The globally unique id of an imaging study manifest in a PACS (Picture Archiving and Communication System) or VNA (Vendor Neutral Archive). In an XDS context, this identifier refers to the KOS document that describes the set of images within the study. The KOS document is a representation of the image study manifest, and is a separate document with its own Document Unique ID. In DICOM, the Study Instance UID MAY be used as Image Information Identification Number.	`.masterIdentifier`
Study Instance UID	DICOM (0020,000D); National IHE MetaData Set (2024), ihexds-dataelement-117; MedMij dataset, bbs-medmij-dataelement-4	The globally unique DICOM identifier of the imaging study upon which the imaging report is based, assigned by the modality or PACS. All images within an imaging study are implicitly linked to each other with this identifier. Each KOS document contains exactly one Study Instance UID according to IHE WIA. Note that if a KOS document is shared or exchanged, the same Study Instance UID SHOULD be present in the metadata attribute ReferenceIdList, as well as the corresponding FHIR DocumentReference resource.	`.context.related`
Accession Number	DICOM (0008,0050); National IHE MetaData Set (2024), ihexds-dataelement-117; MedMij dataset, bbs-medmij-dataelement-3	A locally unique record number generated by the RIS that identifies an imaging procedure request created by the RIS in response to a clinical order. It links together the imaging study with its corresponding reports, images, and KOS documents. Moreover, it makes searching on imaging study level possible. Note that if a KOS document is shared or exchanged, the same Accession Number SHALL be present in the metadata attribute ReferenceIdList, as well as the corresponding FHIR DocumentReference resource.	`.context.related`

Table 2: Identifiers relevant in the context of images and reports

Note:

The cardinality of DocumentReference.masterIdentifier is 1..1. If a XIS wants to provide additional identifiers (e.g. a report identifier assigned in the EHR), the DocumentReference.identifier can be used.
If the Accession Number is known, it SHALL be conveyed in all DocumentReference resources that refer to the corresponding images and reports. In particular, this ensures that images and reports that belong to the same imaging study, are linked together.

2.6. Use cases

The use cases in this IG are based as much as possible on the specifications described in the BBS FHIR IG, section 5.3. In short: IHE MHD and WIA.

2.6.1. Use case: Retrieve Image and Report in personal health environment

The Nictiz BBS FHIR IG splits the transactions in different use cases, for reasons of convenience. Seen from the perspective of a patient using a PHR, retrieval of images and reports from a healthcare provider is a related activity performed in one action. Therefore, this IG bundles the BBS use cases as one.

2.6.1.1. Query Timeline Data (MHD ITI-67)

Based on Use case 3: Query Timeline Data (Raadplegen Tijdlijn Data) in the Nictiz BBS FHIR IG, see ITI-67 for further details.

The ITI-67 transaction is used to find available documents for a patient, based on a search on DocumentReference.

Transaction group	Transaction	Actor	System role	FHIR CapabilityStatement
Image and report timeline (PULL)	Retrieve image and report timeline	Patient (using a PHR)	MM-1.0-TDR-FHIR	[TO DO]
Image and report timeline (PULL)	Serve image and report timeline	Healthcare provider (using a XIS)	MM-1.0-TDB-FHIR	[TO DO]

Table 3: Transactions

2.6.1.1.1. PHR: request message

The PHR executes an HTTP search against the DocumentReference endpoint of the XIS using the following URL:

GET [base]/DocumentReference{?<query>}

The <query> represents a series of encoded name-value pairs representing the filter for the query. The search parameters listed in the table below SHALL be supported by both PHR and XIS. Note that the PHR SHALL always include the search parameter status in their request.

Image Availability search parameter	Description	FHIR search parameter	Examples
availabilityStatus	Search on the status of the DocumentReference.	`status`	Retrieve all DocumentReference resources that refer to an approved document. `GET [base]/DocumentReference?status=current` Retrieve all DocumentReference resources that refer to a deprecated document. `GET [base]/DocumentReference?status=superseded`
mimeType	Search on the MIME type of the document.	`contenttype`	Retrieve all DocumentReference resources that refer to a report in PDF format. `GET [base]/DocumentReference?contenttype=application/pdf` Retrieve all DocumentReference resources that refer to an imaging study available as DICOM KOS document. `GET [base]/DocumentReference?contenttype=application/dicom`

Table 4: Search parameters

Other search parameters can be found in the ITI-67 Request Message specification. The PHR MAY supply, and the XIS SHALL be capable of processing all query parameters listed there, with the exception of the patient and patient.identifier search parameters, as patient identification is done differently in the MedMij context (i.e. via an OAuth2 token).

See ITI-67 Request Message for further details.

2.6.1.1.2. XIS: response message

The XIS returns an HTTP Status code appropriate to the processing as well as a Bundle of the matching DocumentReference resources. Based on the values of DocumentReference.content.attachment.contentType and DocumentReference.content.format it can be derived whether each respective DocumentReference refers to a report or an image.

See ITI-67 Response Message for further details.

2.6.1.2. Retrieve Imaging Report (MHD ITI-68)

Based on Use case 4: Retrieve Imaging Report (Raadplegen Verslag) in the Nictiz BBS FHIR IG, see ITI-68 for further details.

Transaction group	Transaction	Actor	System role	FHIR CapabilityStatement
Image and report (PULL)	Retrieve image and report	Patient (using a PHR)	MM-1.0-BR-FHIR	[TO DO]
Image and report (PULL)	Serve image and report	Healthcare provider (using a XIS)	MM-1.0-BB-FHIR	[TO DO]

Table 5: Transactions

2.6.1.2.1. PHR: request message

The PHR sends an HTTP GET request to the XIS server to retrieve the imaging report content referenced by a DocumentReference in DocumentReference.content.attachment.url.

The PHR SHALL provide an HTTP Accept header to indicate the preferred MIME type, such that the XIS can provide the imaging report requested in an encoding other than the encoding indicated in the DocumentReference.content.attachment.contentType. The XIS SHALL support the Accept header application/pdf, irrespective of the value of .contentType.

The PHR MAY supply a MIME type in the Accept header other than application/pdf or the MIME type indicated in DocumentReference.content.attachment.contentType. Support for such headers by the XIS is optional.

See ITI-68 Request Message for further details.

2.6.1.2.2. XIS: response message

The XIS returns an HTTP Status code appropriate to the processing. When the requested imaging report is returned, the XIS SHALL respond with HTTP Status Code 200, and the imaging report SHOULD use a correct content type based on the Accept header supplied in the request by the PHR. This MAY include CDA, PDF, or other structured or unstructured formats originating from an EHR.

If the XIS is unable to format the imaging report in a content type listed in the Accept header, it SHALL respond with HTTP Status Code 406.

See ITI-68 Response Message for further details.

2.6.1.3. Retrieve Images (MHD ITI-68 and WADO-RS RAD-107)

Based on Use case 5: Retrieve Images (Raadplegen Beeld) in the Nictiz BBS FHIR IG, see ITI-68 for further details.

Transaction group	Transaction	Actor	System role	FHIR CapabilityStatement
Image and report (PULL)	Retrieve image and report	Patient (using a PHR)	MM-1.0-BR-FHIR	[TO DO]
Image and report (PULL)	Serve image and report	Healthcare provider (using a XIS)	MM-1.0-BB-FHIR	[TO DO]

Table 6: Transactions

2.6.1.3.1. PHR: request message (MHD ITI-68)

The PHR sends an HTTP GET request to the XIS server to retrieve the imaging study manifest content referenced by a DocumentReference in DocumentReference.content.attachment.url.

The PHR SHALL provide an HTTP Accept header to indicate the preferred MIME type, such that the XIS can provide the imaging study manifest requested in an encoding other than the encoding indicated in the DocumentReference.content.attachment.contentType. The table below indicates which MIME types as value of the Accept header SHALL be supported by the XIS relative to the .contentType present in the DocumentReference for which the PHR requests the content. In particular, the XIS has to support reformatting a DICOM KOS document (with .contentType equal to application/dicom) into the DICOM JSON Model (with .contentType equal to application/dicom+json).

The PHR MAY supply a MIME type in the Accept header other than those indicated by the table below or the MIME type indicated in DocumentReference.content.attachment.contentType. Support for such headers by the XIS is optional.

`.contentType` (ITI-67 Response)	Accept header (ITI-68 Request)
application/dicom	application/dicom
application/dicom	application/dicom+json
application/dicom+json	application/dicom+json

Table 7: Mapping between content type and supported Accept headers

See ITI-68 Request Message for further details.

2.6.1.3.2. XIS: response message (MHD ITI-68)

The XIS returns an HTTP Status code appropriate to the processing. When the requested imaging study manifest is returned, the XIS SHALL respond with HTTP Status Code 200, and the imaging study manifest SHOULD use a correct content type based on the Accept header supplied in the request by the PHR. The imaging study manifest SHOULD contain references to the relevant images following the WADO-RS format.

If the XIS is unable to format the imaging study manifest in a content type listed in the Accept header, it SHALL respond with HTTP Status Code 406.

See ITI-68 Response Message for further details.

2.6.1.3.3. PHR: request message (WADO-RS RAD-107)

The WADO-RS Retrieve request (RAD-107) is used to retrieve individual (image) instances. For each (image) instance the PHR wants to retrieve, it executes an HTTP GET against the WADO-RS endpoint of the XIS using the following URL:

GET [WadoRsEndpoint]/studies/{StudyInstanceUID}/series/{SeriesInstanceUID}/instances/{SOPInstanceUID}

The required {StudyInstanceUID}, {SeriesInstanceUID} and {SOPInstanceUID} unique identifier values can be found in the DICOM KOS document, which is obtained via the ITI-68 Retrieve Document transaction.

Instead of constructing the above URL from scratch by searching all these identifier values from various locations within the KOS document, the DICOM tag (0008,1115) (Referenced Series Sequence) provides a structured way to access this information. This sequence contains one or more referenced image series. Each item in the sequence corresponds to a specific series and contains:

Retrieve URL (0008,1190)
A sequence of referenced instances (Referenced SOP Sequence (0008,1199)), each containing:
- Referenced SOP Instance UID (0008,1155)

To simplify the construction of the WADO-RS request, the Retrieve URL (0008,1190) can be used, as it attains the value [WadoRsEndpoint]/studies/{StudyInstanceUID}/series/{SeriesInstanceUID} (for each series). To create the WADO-RS request with which the image is retrieved, the PHR would then only need to add the value of the Referenced SOP Instance UID (0008,1155). This approach allows the PHR to iterate over all items in the KOS document in the Referenced Series Sequence (0008,1115):

For each series in the Referenced Series Sequence (0008,1115), retrieve the corresponding Retrieve URL (0008,1190);
For each SOP instance in the series, retrieve the corresponding Referenced SOP Instance UID (0008,1155);
Compose the WADO-RS URL by using the data retrieved in the previous steps: {RetrieveURL}/instances/{SOPInstanceUID}.

The PHR SHALL provide an HTTP Accept header to indicate the preferred MIME type, such that the XIS can provide the (image) instance in the preferred format. The table below indicates which MIME types as value of the Accept header SHALL be supported by the XIS, as well as the corresponding WADO-RS request that needs to be executed by the PHR.

WADO-RS request	Accept header
`GET {RetrieveURL}/instances/{SOPInstanceUID}`	application/dicom
`GET {RetrieveURL}/instances/{SOPInstanceUID}/rendered`	image/jpeg

See WADO-RS Retrieve (RAD-107), section 4.107, for further details.

Table 8: Supported WADO-RS requests

2.6.1.3.4. XIS: response message (WADO-RS RAD-107)

The XIS returns an HTTP Status code appropriate to the processing. When the requested (image) instance is returned, the XIS SHALL respond with HTTP Status Code 200, and the (image) instance SHOULD use a correct content type based on the Accept header supplied in the request by the PHR.

See WADO-RS Retrieve (RAD-107), section 4.107, for further details.