Appendix A. Overdracht bij gebruik meerdere systemen (by Michiel Bruins, Dutch version)

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

Probleem

In de praktijk worden door de meeste zorginstellingen in een aantal sectoren meer dan één leverancier of systeem actief bij de behandeling. De architectuur voor de Verpleegkundige Overdracht gaat echter wel uit van maar één zender en één ontvanger.

Een voorbeeld hiervan is de ouderenzorg waar vaak de cliëntadministratie, zorgdossier, behandeldossier, Apotheek dossier e.a. naast elkaar worden gebruikt bij de behandeling van een cliënt. Deze systemen wisselen onderling ook gegevens uit, maar het landschap is heel divers en verschilt per zorginstelling.

Een opmerking over terminologie: er worden meerdere begrippen gebruikt afhankelijk van de bron: waar Nictiz het heeft over een XIS, wordt in Nuts gesproken over een Vendor, en in overleg vaak benoemd als Leverancier. In dit stuk volg ik de Nuts terminologie: dus een ‘Vendor’ voor leverancier/XIS, een ‘Customer’ voor Organisatie/zorgaanbieder, etc. De Verpleegkundige Overdracht - ook wel bekend als eOverdracht - kort ik af tot Overdracht.

Oplossingsrichtingen

In de breakout sessie zijn twee mogelijkheden kort besproken maar niet in detail uitgewerkt. Ik beschrijf hier enkele richtingen met voor en nadelen, maar dit is zeker geen compleet beslissingsdocument. Het is bedoeld als startpunt voor verdere discussie over oplossingen.

1) Cliëntadministratie als centrale spil

Het idee is dat de Overdracht altijd gestuurd naar de Vendor waar de administratie wordt gedaan: de cliëntadministratie (of transferverpleegkundige e.a.). Deze Vendor maakt vervolgens een nieuwe Overdracht Task aan voor de overige systemen waarmee de hele ‘nursingHandoff’ set van resources 1-op-1 wordt doorgestuurd. Voor dit ‘intern’ doorsturen kan de shortcut in het proces worden gebruikt waarbij de Task gelijk op status ‘in-progress’ wordt gezet en de negotiate-phase (‘requested’, ‘accepted’ etc.) kan worden overgeslagen.

Voordelen:

Nadelen/vereisten:

2) Stuur de Verpleegkundige overdracht naar alle Vendors

Een aanvulling op de Nuts Bolt proces waarbij als dezelfde Customer bij meerdere Vendors is geregistreerd, er voor elke ‘eOverdracht-Receiver’ service bij elke Vendor een Task wordt gemaakt, dus meerdere taken per customer.

Voordelen:

Nadelen:

Opmerking: een variatie hierop is het idee om één Task te maken en een notificatie te sturen naar de verschillende Vendors. Maar ik denk dat dit problematisch is wat betreft het accepteren en verwerken van het dossier: welk van de Vendors accepteert de Task dan? De Nuts architectuur en de Nuts autorisatie tokens staan dit verder wel toe. Als dit met werkprocessen binnen de Customer kan worden opgelost is dit een richting die ook verder onderzocht kan worden.

3) Stuur de verpleegkundige Overdracht naar één partij

Deze optie is in de breakout sessie niet meer besproken. Los het probleem niet op met Nuts, maar via het huidige werkprocess. Het is een optie om het aan de werkprocessen binnen de zorginstelling over te laten. Omdat de meeste leveranciers van plan zijn de resources zo-ie-zo op te slaan, ook als de data niet past bij het eigen systeem is de data dan wel beschikbaar voor de medewerkers van die zorginstelling. Ook wordt een deel van de gegevens nu al via reguliere datakoppelingen uitgewisseld. Alleen de gegevens die niet door het ontvangende systeem worden verwerkt en doorgestuurd via de reguliere koppelingen, maar wel relevant zijn voor andere systemen zouden dan met de hand moeten worden overgenomen.

Voordeel:

Nadelen:

Dit is niet een echte oplossing, maar zou wel als een eerste pragmatische stap gebruikt: dit is nog altijd een grote besparing op het administratieve proces ten opzichte van het huidige situatie.

Combinaties

Overigens sluiten oplossingsrichting 1, 2 en 3 elkaar niet uit: ze zouden naast elkaar kunnen bestaan zonder elkaar in de weg te zitten: de service configuratie in het adresboek, en configuratie bij de Customer zelf bepaalt welke route wordt gevolgd.

Aanvullend: verzenden van de Verpleegkundige overdracht

Bij de besproken richtingen in de breakout sessie lag de focus bij het ontvangen van Overdrachten. Maar bij het gebruik van meerdere leveranciers is natuurlijk ook het versturen van een Overdracht een uitdaging.

Als een Overdracht centraal vanuit de Cliëntadministratie wordt verstuurd wil je ook resources beschikbaar maken van gegevens die in andere systemen staan geregistreerd. Bijvoorbeeld medicatie uit de apotheek, behandel aanwijzingen uit het behandeldossier of hulpmiddelen uit Infozorg. Hier moet dan ook een oplossing voor worden gezocht.

Overigens is het binnen de huidige architectuur en afspraken stelsel ook mogelijk om vanuit de verschillende Vendors elk een eigen Overdracht te doen. Als de ontvangende partij om kan gaan met het ontvangen van een Overdracht van een dossier dat al bestaat, en dan de ontvangen resources verwerkt heb je uiteindelijk weer een compleet dossier in de verschillende systemen. Dit is mogelijk gedachtengoed voor toekomstig overleg.

Kwalificatie

Optie 1 en 2 zijn niet te realiseren binnen de huidige tijdlijnen van de inzicht regeling en is ook geen onderdeel van de kwalificatie door Nictiz.