Appendix B. Overdracht for multiple vendors (by Michiel Bruins, English version)

Sources
* Nictiz Architectuur https://informatiestandaarden.nictiz.nl/wiki/vpk:V4.0_FHIR_eOverdracht)
* Nuts Bolt: https://nuts-foundation.gitbook.io/bolts/eoverdracht/leveranciersspecificatie

Problem

In practice, most healthcare institutions in a number of sectors have more than one supplier or system active in the treatment. However, the architecture for the Verpleegkundige Overdracht is based on only one sender and one receiver.

An example of this is elderly care, where the client administration, care dossier, treatment dossier, pharmacy dossier, etc. are often used side by side when treating a client. These systems also exchange data with each other, but the landscape is very diverse and differs per healthcare institution.

A note about terminology: several terms are used depending on the source: where Nictiz talks about an XIS, Nuts talks about a Vendor, and is often referred to as a Supplier in consultation. In this piece I follow the Nuts terminology: so a 'Vendor' for supplier/XIS, a 'Customer' for Organisation/care provider, etc. I abbreviate the Verpleegkundige Overdracht - also known as eOverdracht - to Overdracht (Transfer).

Solution directions

In the breakout session, two options were briefly discussed but not elaborated in detail. I describe here some directions with pros and cons, but this is by no means a complete decision document. It is intended as a starting point for further discussion of solutions.

1) Client administration as the central pivot

The idea is that the Overdracht is always sent to the Vendor where the administration is done: the client administration (or transfer nurse and others). This Vendor then creates a new Overdracht Task for the other systems with which the entire 'nursingHandoff' set of resources is forwarded 1-to-1. The shortcut in the process can be used for this 'internal' forwarding, whereby the Task is immediately set to status 'in-progress' and the negotiate phase ('requested', 'accepted', etc.) can be skipped.

Advantages:

Disadvantages/Requirements:

2) Send the Overdracht to all Vendors

An addition to the Nuts Bolt process where if the same Customer is registered with multiple Vendors, a Task is created for each 'eOverdracht-Receiver' service at each Vendor, i.e. multiple tasks per customer.

Advantages:

Disadvantages:

Note: A variation on this is the idea of creating one Task and sending a notification to the different Vendors. But I think this is problematic in terms of accepting and processing the file: which of the Vendors accepts the Task? The Nuts architecture and the Nuts authorization tokens allow this. If this can be solved with work processes within the Customer, this is a direction that can also be further investigated.

3) Send the Overdracht to one party

This option was not discussed again in the breakout session. Do not solve the problem with Nuts, but through the current work process. It is an option to leave it to the work processes within the healthcare institution. Because most suppliers intend to store the resources one way or another, even if the data does not fit their own system, the data will still be available to the employees of that healthcare institution. Also, some of the data is already being exchanged via regular data links. Only the data that is not processed by the receiving system and forwarded via the regular links, but is relevant to other systems, would then have to be transferred manually.

Advantages:

Disadvantages:

This is not a real solution, but should be used as a first pragmatic step: this is still a big saving on the administrative process compared to the current situation.

Combinations

Incidentally, solution directions 1), 2) and 3) are not mutually exclusive: they could co-exist without getting in each other's way: the service configuration in the address book and the configuration at the Customer itself determine which route is followed.

Additionally: sending the Overdracht

The directions discussed in the breakout session focused on receiving Transfers. But when using multiple suppliers, sending an Overdracht is of course also a challenge.

If an Overdracht is sent centrally from the Client Administration, you also want to make resources available from data registered in other systems. For example, medication from the pharmacy, treatment instructions from the treatment dossier or aids from Infozorg. A solution must therefore be found for this.

Incidentally, within the current architecture and system of agreements, it is also possible for each of the various Vendors to make their own Overdracht. If the receiving party can handle receiving an Overdracht of a dossier that already exists, and then process the received resources, you will eventually have a complete file in the different systems. These may be ideas for future consultation.

Qualification

Options 1 and 2 cannot be realized within the current timelines of the Inzicht scheme and are also not part of the qualification by Nictiz.