Usecase versturen medische gegevens

van

Een zorgverlener die medische gegevens wil versturen naar een andere zorgverlener dient eerst de juiste adresseringsgegevens op te zoeken. Hiervoor wordt vanuit het informatiesysteem ZORG-AB geraadpleegd. Vervolgens wordt gecontroleerd of het bericht geautomatiseerd verstuurd kan worden. Dit kan indien de benodigde waarborgen aanwezig zijn; een geldig inschrijftoken en mandaattoken. Indien het mandaattoken het systeem het recht geeft te versturen en het inschrijftoken voor de betreffende patiënt is geldig dan wordt het bericht verstuurd zonder extra handeling van de zorgverlener. Zo niet, dan zal de zorgverlener zich dienen te authentiseren met UZI-pas alvorens het bericht verstuurd kan worden. De ontvangstbevestiging die wordt teruggestuurd geeft aan dat het bericht technisch is ontvangen door de geadresseerde applicatie.

Uitleg gebruik mandaattokens

Het kan zijn dat er meerdere geldige mandaten bestaan voor het systeem. Voor de goede werking is het van belang dat het systeem het mandaattoken selecteert waaraan de juiste rechten (via de UZI-rolcode) gekoppeld zijn om het betreffende bericht te mogen versturen.

Daarnaast hangt de keuze van het mandaattoken af van hoe de verantwoordelijkheden binnen de zorgaanbieder zijn ingericht, zie ook de use case (initieel) aanmaken mandaattoken. Zo kan het bijvoorbeeld zijn dat per polikliniek, SEH of andere afdeling een mandaattoken wordt aangemaakt dat rechten geeft aan het systeem. Het systeem zal in dit geval het mandaattoken selecteren dat hoort bij de werkcontext (bijv. polikliniek) van waaruit het bericht verstuurd wordt. Op deze manier weerspiegelt het gebruikte mandaattoken de verantwoordelijkheden zoals deze in de organisatie van de zorgaanbieder zijn ingericht.

Uitleg gebruik inschrijftokens

Dit is onderdeel van het ‘Vereenvoudigd Gebruik UZI-pas’ (VGU):

Voor verzending van medische gegevens van patiënten is beveiliging op het hoogste niveau vereist. Er is hiervoor een ‘algemeen’ geldend principe van de tokens geïntroduceerd met ieder een eigen ondertekeningsvereiste:

• Alleen een transactietoken moet met een UZI-pas op het moment van verzenden

• Een transactietoken met een mandaattoken moet met een UZI-pas ondertekend op het moment van verzenden

• Een transactietoken (UZI-servercertificaat), mandaattoken (UZI-pas van zorgverlener) én inschrijftoken (UZI-pas door zorgmedewerker/zorgverlener).

In het proces van medicatie voorschriften was/is een uitzondering gemaakt, waarvan we geen gebruik willen maken. Het alleen ondertekenen van het transactietoken door het UZI-servercertificaat.
Waarom dan het meesturen van een inschrijftoken?

• Een Inschrijftoken borgt de koppeling (op een goed betrouwbaar niveau) dat het BSN gekoppeld is met de zorgaanbieder (risico mitigatie).

• Zonder inschrijftoken zouden ‘ongeborgde’ berichten gegenereerd kunnen worden die niet door zorgmedewerkers bevestigd zijn.

Wanneer het inschrijftoken niet gegenereerd zou kunnen zijn voor verzending, zou een uitgestelde verzending nodig zijn óf direct ondertekend met een UZI-pas. Dit is een ‘tijdelijke’ situatie totdat de UZI-gegevebs in zijn geheel is opgenomen in ZORG-ID Smart (of ander authenticatiemiddel).

Alternatieve workflows

• Verwerken bericht wordt niet ondersteund in de geadresseerde applicatie: in de bovenstaande use case is er vanuit gegaan dat de geadresseerde applicatie het bericht dat het LSP verstuurd kan verwerken. Dit is lang niet altijd het geval, omdat Medicatieoverdracht gefaseerd wordt ingevoerd. De informatie uit het ZORG-AB (de zogenoemde conformances) wordt gebruikt om vast te stellen of de geadresseerde applicatie het bericht kan verwerken. Zo niet, dan wordt teruggevallen op een andere wijze van (digitale) gegevensuitwisseling.

• Verlopen inschrijftoken: in uitzonderlijke situaties kan het voorkomen dat geconstateerd wordt dat er geen geldig inschrijftoken is. Normaalgesproken kan in dit geval de UZI-pas gebruikt worden. Als dit niet mogelijk is, dan dient het bericht op een later moment verstuurd te worden. Zie hiervoor de use case ‘uitgesteld versturen'. Hierdoor ontstaat tijdelijk een verschil tussen het lokale medicatieprofiel en het medicatieprofiel bij andere medebehandelaars. Denk bijvoorbeeld aan het doorvoeren van een stop-MA die verstuurd wordt naar de oorspronkelijke voorschrijver. Daarom zal dit proces regelmatig doorlopen moeten worden.

• Onbeschikbaarheid van communicatieserver of LSP: indien het versturen van het bericht niet mogelijk is als gevolg van onbeschikbaarheid, dan dient - gelijk aan de situatie in het punt hierboven - het bericht op een later moment verstuurd te worden. Zie wederom de use case ‘uitgesteld versturen’.