This article or section is in the middle of an expansion or major restructuring and is not yet ready for use.

Processen: \| Verkennen \| Ontwikkelen & Testen \| Publiceren \| Beheren \| Kwalificeren

1 Introduction

An Information Standard (IS) has both a functional and a technical specification, henceforth referred to by their Dutch abbreviations "FO" and "TO", respectively. This template describes both the standard structure and contents of a TO.
The template is annotated by the following:

Goal: What the goal of the section is and what information it should include.
Standard text: Standard sentences to include if appropriate.
Examples: These are taken from multiple Nictiz ISs (BgZ-MSZ 2.0, eOverdracht, etc.).
Placeholders: "<" and ">" are used to denote places that should be filled with IS-specific information, like so: <example>.

Goal:
The Guidance chapter is used to give the reader general guidance regarding the technical implementation of the IS. It should include general disclaimers.

Standard text:
This is the implementation guide (IG) for the information standard (IS) <IS-name>. This IG must be used together with the IS functional specification, see <link to <<IS>> main page>.

Example BgZ-MSZ 2.0 (FHIR STU3):
This is the FHIR implementation guide (IG) for the information standard BgZ-MSZ. This IG must be used together with the functional specification: see BgZ main page.

In addition, the guidelines as specified in general FHIR STU3 Implementation Guide apply. The guide defines how to implement FHIR STU3 and what rules apply (e.g. how to handle empty reponses etc.). In particular, the reader should take note of the use case overarching principles and the use of FHIR packages.

1.1 Support

Standard text:
For questions, feedback, or change requests, please contact our support team at Nictiz Servicemanagement.

1.2 Known issues

Standard text:
The IS described in this document is actively maintained and continuously improved. However, certain limitations may exist due to ongoing development, external dependencies, or the complexity of healthcare interoperability. These known issues are listed in the [Link-to-FO | FO (in Dutch)].

2 Boundaries & relationships

3 Workflows & transactions

Goal: To show the reader which special workflows they should implement.

Information: Most of the information regarding workflows should be available in the FO. The only information relevant here are regarding special implementations of these workflows such as the Notified Pull. This should also include a diagram of the workflow for specific actors.

Long example eOverdracht, FHIR STU3 (click to expand):

4 Workflow and message structure

4.1 Overview

Although the eOverdracht is currently limited to the transfer of the nursing handoff, the ultimate vision is to have a workflow which may include the negotiation of the transfer of the patient. For this reason, a Task resource is used as the entry point for all data exchanges (see #Use of the Composition resource).

4.2 Task

4.2.1 Task requirements

The requirements for the Task resource in the eOverdracht context are specified using the eOverdracht-Task profile. This profile SHALL be used for the eOverdracht workflow.

The Task instance SHALL be hosted on the server of the sending XIS. Both the sending and the receiving XIS need to be able to update the Task. The sending XIS MAY use business rules to reject an update, for example if invalid status change is used.

Both the sending and the receiving XIS SHALL monitor the Task resource for changes. It is expected that the sending XIS will use a notification mechanism to inform the receiving XIS of creation or updates of the Task (see #Notifications), but the receiving XIS could use a polling mechanism as well.

For each combination of sending and receiving XIS, a dedicated instance of the Task resource SHALL be used for each transfer situation.

4.2.2 Task invocations

The receiving XIS can query the Task at the sending XIS by using the Task.id which is communicated in the notification:

 GET base/Task/[Task.id]

Note: It is up to the receiving XIS to determine if this is a new Task or an update to an existing Task, and if it is an update, what the change entails.

The receiving XIS can update a Task hosted by the sending XIS using a PUT operation:

 PUT base/Task/[Task.id]

The body should be the original Task with the needed modifications. The sending XIS SHOULD check the update for errors and inconsistencies. If the update is rejected, the sending XIS SHALL response with a HTTP 422 status code and an OperationOutcome detailing the problem.

4.2.3 Notifications

It is expected that the sending XIS will notify the receiving XIS when a new Task is created or when an existing Task is updated. Although the notification mechanism is out of scope for the eOverdracht information standard, the notification SHALL communicate the Task.id to the receiving XIS.

A straightforward implementation for this notification mechanism is for the notifying party to make an empty POST request combined with an authorization header on a pre-determined endpoint at the party that should be notified, with the Task.id appended as path component:

 POST [base]/[Task.id]

The notified party is expected to respond with HTTP status code 202 Accepted to inform the notifying party that the notification was successfully received.

4.3 Use of the Composition resource

The nursing handoff (Overdrachtsbericht) is mainly built up of individual FHIR resources, selected by the sending organization to form a coherent set of information relevant to the receiving organization. The bulk of these resources are not referenced directly from the Task. Instead, the Task references a Composition resource which in turn assembles the references to all individual FHIR resources. For this purpose, the Composition profiles described in #FHIR profiles SHALL be used.

4.3.1 Composition invocations

The receiving XIS MAY use either of the following mechanism for retrieving the individual FHIR resources referenced in the Compostion resource.

As a Document

The receiving XIS uses the $document operation to retrieve both the Composition and all referenced resources as a single document Bundle.

GET [base]/Composition/[Composition.id]/$document

Note: the Compositions list just the resources that act as the entry point for the various concepts in the eOverdracht transactions, but each of these referenced resources may further refer other resources not listed there. The sending system SHALL produce a complete Bundle containing not only the resources listed directly in the Composition, but all the indirectly referenced resources as well.

Individual requests

The receiving XIS first retrieves the Composition resource

GET [base]/Compositon/[Composition.id]

Then the necessary other resources referenced can be fetched using a GET interaction.

The sending XIS SHALL support both mechanisms.

4.3.2 Exchanging data as unstructured text

The information standard requires that all information described is exchanged in a structured way, according to the FHIR profiles described on this page. However, some systems are not able to support the full extent of the standard yet and may need to send part of the data as formatted text. The following implementation advice provides guidance on how systems with such a need may accomplish this exchange.

All unstructured (textual data) is collected in one single PDF/A document.
This document is added to the Composition resource representing the nursing handoff, in the following way:
- An additional Composition.section is created, with .section.code set to SNOMED CT/703852005 (Narrative comment section).
- In this section, there is a single .section.entry, and it refers to a DocumentReference resource.
- This DocumentReference resource references the PDF/A document containing the unstructured text.

The use of the DocumentReference resource allows the sender to specify additional metadata about the document, if needed. It also prevents that the PDF/A is directly included when the Composition is requested using the $document operation, which could lead to unexpected large data volumes.

4.4 Using Task to manage the workflow

The Task is the main entry point for the eOverdracht transactions. The eOverdracht workflow starts with the retrieval of a new Task instance by the receiving XIS, and all subsequent steps in the workflow are mediated by updates to this Task instance.

The eOverdracht transactions are mapped to FHIR in the following way:

eOverdracht transaction		Task
Confirm transfer		sending XIS updates Task: `Task.status` = in-progress (sending XIS sends notification to receiving XIS)
Send nursing handoff		Sending XIS creates nursing handoff Composition Sending XIS updates Task: `Task.input:nursingHandoff` contains reference to the nursing handoff Composition resource (sending XIS sends notification to receiving XIS)
Send confirmation of nursing handoff		Recieving XIS updates Task: `Task.status` = completed

The following sequence diagrams illustrate the relevant exchanges and state transitions:

Normal flow

The initial eOverdracht 4.0 version has to be carried out without the negotiation phase, the sending XIS will create the Task instance with Task.status already set to in-progress and Task.input:nursingHandoff populated. The full eOverdracht Task workflow will be supported but is out of scope for the 4.0 version.

4.4.1 Brokers

The use of a broker to find an available healthcare provider for the patient transfer fall outside the scope of the eOverdracht information standard. However, it is possible to start the workflow without knowing the receiving organization, which allows for the use of a broker. In this situation, for the sending XIS the broker acts as a receiving XIS, and for the receiving XIS the broker acts as a sending XIS.

When Task.input:nursingHandoff is populated with the nursing handoff Composition, Task.owner MUST be populated with the receiving organization.

4.5 Actors involved

4.6 Use-cases

In dit hoofdstuk wordt vanuit de gekozen techniek (e.g., FHIR) een technische uitwerking gegeven via invocations (e.g., FHIR queries). Een Transactie in ART-DECOR kun je zien als een maximaal bericht (die van toepassing is op meerdere use-cases). Via queries wordt de uitwisseling verder aangescherpt. Via optionele bereik parameters (e.g. lastn) kan voor meerdere use-cases in de gegevensuitwisseling worden voorzien.

FHIR query specificatie kan via een tabel met de volgende kolommen

. Query (inc gekozen resources)
. Code parameters
. Optionele 'bereik' parameters
. Relevante profielen
. toelichting

4.6.1 Example 1

4.6.1.1 Invocations

4.6.2 Example 2

4.6.2.1 Invocations

thema's als NP verdienen een specifiek hoofdstuk. De NP gaat 'horizontaal' door meerdere use cases.

4.7 Data exchange standard

The contents of this chapter change based on the chosen data exchange standard. Supported are HL7 FHIR, HL7 CDA, and HL7 v2.
Information included in this chapter:

Artifacts - which artifacts are exchanged (e.g., FHIR profiles)?
Artifacts - how do the HCIM's link to the artifacts?

4.7.1 HL7 FHIR

Every implementation of the standard will require the availability of the information presented here.

4.7.1.1 Artifacts

This section is to show the link between HCIM and FHIR resources. The table should follow the structure of the FO and refer to the FO (e.g., see FO).
For example, the link to the BgZ-MSZ 2.0 FO would be: [2.0 Chapter 2.1.1] In the BgZ 2.0 FO the data is sectioned off in chapters and sections. Therefore, the table would use the following headers:

Chapter - The relevant chapter from the FO.
HCIM - The name of the HCIM to be exchanged.
Target - The FHIR resource or data element used to exchange the specified HCIM.
Profile - The FHIR profile used in this information standard. Use Sjabloon Simplifier.

Tabel 1. Mapping table between a HCIM and a FHIR resource with a link to the profile specified by this information standard
Chapter	HCIM	Target	Profile
1	Patient	Patient	http://nictiz.nl/fhir/StructureDefinition/BgZ-Patient
1	MaritalStatus	Patient.maritalStatus	http://nictiz.nl/fhir/StructureDefinition/BgZ-Patient
2	BloodPressure	Observation	http://nictiz.nl/fhir/StructureDefinition/zib-BloodPressure
	BodyWeight	Observation	http://nictiz.nl/fhir/StructureDefinition/zib-BodyWeight
	BodyHeight	Observation	http://nictiz.nl/fhir/StructureDefinition/zib-BodyHeight
3	LaboratoryTestResult	Observation	http://nictiz.nl/fhir/StructureDefinition/zib-LaboratoryTestResult-Observation
3	LaboratoryTestResult	Specimen	http://nictiz.nl/fhir/StructureDefinition/zib-LaboratoryTestResult-Specimen
4	Procedure	Procedure	http://nictiz.nl/fhir/StructureDefinition/BgZ-Procedure
5	Encounter	Encounter	http://nictiz.nl/fhir/StructureDefinition/zib-Encounter

4.7.1.2 Examples of FHIR instances

A link to generated FHIR instances in the information standards' Nictiz-testscripts GitHub folder should be included. BgZ-MSZ 2.0 example: Nictiz-testscripts (BgZ-MSZ 2.0)

4.7.2 HL7 CDA

Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.

4.7.3 HL7 v2