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

• Probleem
• Oplossingsrichtingen
• 1) Cliëntadministratie als centrale spil
• 2) Stuur de Verpleegkundige overdracht naar alle Vendors
• 3) Stuur de verpleegkundige Overdracht naar één partij
• Combinaties
• Aanvullend: verzenden van de Verpleegkundige overdracht
• Kwalificatie

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:

• De verzendende partij ziet in het Nuts Adresboek maar 1 ‘eOverdracht-receiver’ Service bij één Vendor per Customer.
• Het verspreiden van de gegevens kan via dezelfde architectuur en software plaatsvinden (gewoon een nuts Overdracht).

Nadelen/vereisten:

• De cliëntadministratie moet alle resources zoals ontvangen als resource weer aanbieden - ook de gegevens die niet zelf ondersteund/gebruikt worden.
• De Vendor die de Overdracht ontvangt moet kennis hebben van de gebruikte systemen binnen de zorgorganisatie en de Overdracht naar de juiste leveranciers doorsturen. Een uitdaging hierbij is hoe deze te vinden in het adresboek zonder dat deze door de gebruikers van de verzender getoond worden: zijn dit een ander type services? ‘eOverdracht-receiver-intern’ bijvoorbeeld?
• Alle cliënten in de zorginstelling moeten dan bekend zijn in één cliëntadministratie. Dit compliceert situaties waar bijvoorbeeld voor revalidatiezorg of wijkverpleging een ander administratief systeem wordt gebruikt: mogelijk moeten er dan toch meerdere services voor Customers worden geconfigureerd. Bijvoorbeeld: ‘<zorgorganizatie>-intramuraal, ‘<zorgorganizatie>-wijkverpleging’, ‘<zorgorganizatie>-revalidatie’. Dit maakt het natuurlijk wel weer lastiger voor de verzender om de juiste Customer te kiezen.
• De aanvullende Vendors - naast de cliëntadministratie - zullen nog wel een gebruiker moeten hebben die inlogt en zich autoriseert via Irma om de gegevens op te kunnen halen. Dus een (minimale) manuele handeling is wel vereist.
• Het gebruik en de werkafspraken binnen de organisatie wordt complexer.
• Data moet meer dan eens worden verwerkt.

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:

• De ontvangende Vendors hebben geen kennis nodig van welke andere systemen gebruikt worden: elk van de Vendors neemt de resources over die voor hun rol in de behandeling relevant zijn: geen Customer specifieke configuratie nodig.
• Er is geen centrale cliëntenadministratie nodig waar alle patiënten bekend zijn, hoewel dan de gebruikers van de verschillende Vendors/systemen dan wel moeten weten of ze de cliënt wel of niet moeten accepteren. Meerdere Customers configureren zoals bij 1) blijft verder ook een optie.
• Het vereist voor zover ik kan zien geen aanpassing aan de Nictiz architectuur, alleen het proces / afspraken binnen Nuts.

Nadelen:

• Dit werkt alleen als alle verzendende partijen dit ondersteunen. Dus het principe dat er meer dan 1 ‘eOverdracht-Receiver’ Service kan zijn voor een Customer in het adresboek, en als dit het geval is dat er voor elke Service een eigen Overdracht gedaan moet worden moet dan wel onderdeel worden van het afsprakenstelsel.
• Voor de verzender voegt het de complexiteit toe als de Task status bij verschillende Vendors niet dezelfde status heeft, bijvoorbeeld dat 1 Vendor het accepteert, en de andere niet.
• Elke ‘Vendor’ in het Nuts adresboek definieert de eigen lijst van ‘Customers’. Er moet dan een label/identifier zijn in het adresboek waardoor de verzender kan zien dat de Customer bij vendor A dezelfde is als de Customer bij Vendor B, en deze Customer in de zoekresultaten voor de gebruiker maar één keer tonen.

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:

• Huidige uitgangssituatie.
• Eén leidend systeem en simpele adressering.

Nadelen:

• Leidende systeem krijgt een regierol in verwerking van data door derden. Dit is niet in lijn met het gedachtengoed van Actiz wat betreft professionele omgeving.
• Zibs die door het leidende systeem niet worden ondersteund kunnen ook niet worden doorgegeven.

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.