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

• Problem
• Solution directions
• 1) Client administration as the central pivot
• 2) Send the Overdracht to all Vendors
• 3) Send the Overdracht to one party
• Combinations
• Additionally: sending the Overdracht
• Qualification

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:

• The sending party only sees one 'eOverdracht-receiver' Service at one Vendor per Customer in the Nuts Address Book.
• The distribution of the data can be done through the same architecture and software (Nuts eOverdracht).

Disadvantages/Requirements:

• The client administration Vendor must again provide all resources to other systems as received - also the data that is not supported/used itself by the client administration.
• The client administration Vendor must have knowledge of the systems used within the healthcare organization and route the Overdracht to the appropriate suppliers. A challenge here is how to find them in the address book without being shown to the sender's users: are these a different type of service? ‘eOverdracht-receiver-internal’ for example?
• All clients in the healthcare institution must be known in one client administration. This complicates situations where, for example, a different administrative system is used for rehabilitation care or district nursing: multiple services may still have to be configured for Customers. For example: \‘-intramuraal’, \‘-wijkverpleging’, \‘-revalidatie’. This of course makes it more difficult for the sender to choose the right Customer.
• The additional Vendors - in addition to the client administration one - will still need a user who logs in and authorizes himself via Irma in order to retrieve the data. So a (minimal) manual action is required.
• The use and working arrangements within the organization are becoming more complex.
• Data needs to be processed more than once.

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:

• The receiving Vendors do not need knowledge of which other systems are used: each of the Vendors takes over the resources relevant to their role in the treatment: no Customer specific configuration required.
• There is no need for a central client administration where all patients are known, although the users of the various Vendors/systems then have to know whether or not to accept the client. Configuring multiple Customers as in 1) also remains an option.
• It doesn't require any modification to the Nictiz architecture as far as I can tell, just the process/agreements within Nuts.

Disadvantages:

• This only works if all sending parties support it. So the principle that there can be more than one 'eOverdracht-Receiver' Service for a Customer in the address book, and if this is the case that a separate Overdracht must be made for each Service, must then become part of the agreement system.
• For the sender it adds complexity if the Task status does not have the same status at different Vendors, for example one Vendor accepts it and the other does not.
• Each 'Vendor' in the Nuts address book defines its own list of 'Customers'. There must then be a label/identifier in the address book through which the sender can see that the Customer at Vendor A is the same as the Customer at Vendor B, and only show this Customer once in the search results for the user.

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:

• Current baseline.
• One leading system and simple addressing.

Disadvantages:

• Leading system is given a coordinating role in the processing of data by third parties. This is not in line with Actiz's ideas regarding a professional environment.
• Zibs that are not supported by the leading system cannot be passed on either.

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.