Onderstaande beschrijving is een samenvatting van de referentiearchitectuur.
De architectuur voor interoperabiliteit Geboortezorg is gericht op het zorgproces rondom een contactmoment.
Een contactmoment kan elke vorm van contact tussen een zorggebruiker en een zorgverlener zijn, waarbij de zorgverlener gebruik maakt van gegevens van de zorggebruiker. (bijvoorbeeld: telefoon, chat, e-mail, bezoek van de zorggebruiker aan de zorgverlener, bezoek van de zorgverlener aan de zorggebruiker, etc)
Het proces “boven de motorkap” bestaat uit drie delen: Raadplegen, contactmoment, Vastleggen.
Raadplegen van relevante gegevens van de zorggebruiker (door de zorgverlener), ook als die door andere zorgverleners zijn vastgelegd. “Raadplegen bij de bron”
Essentiel is hier dat de zorgverlener in het eigen zorgverlener systeem (XIS) naar het scherm van de cliënt/patiënt gaat (behandelrelatie)
Vervolgens moet de zorgverlener vaststellen dat het om de juiste persoon gaat (wettelijke plicht)
Vanuit het eigen XIS wordt dan de viewer gestart via een Single Sign On (SSO) routine.
“onder de motorkap” worden gegevens gezocht, gevonden, opgehaald, verzameld, vertaald en uiteindelijk gepresenteerd in de viewer.
De zorgverlener kan dan de relevante gegevens van de cliënt/patiënt raadplegen
Het contactmoment tussen zorgverlener en zorggebruiker
Hierin wordt door de zorgverlener nieuwe informatie uitgevraagd en, wanneer nodig, worden metingen gedaan.
Vastleggen van nieuwe gegevens, en die beschikbaar stellen voor hergebruik
Nieuwe informatie wordt door de zorgverlener vastgelegd in het eigen zorgverlener systeem.
De nieuwe informatie wordt beschikbaar gesteld in de “eenheid van taal” zodat die door andere eindgebruikers geraadpleegd kan worden.
Om dit proces “onder de motorkap” te kunnen realiseren is de volgende architectuur ontwikkeld. (voor meer informatie: zie de referentiearchitectuur)
Binnen de architectuur wordt gebruik gemaakt van verschillende modulen.
Sommige modulen worden niet alleen in interoperabiliteit geboortezorg toegepast, maar worden nu ook ingezet voor alle vormen van interoperabiliteit in de zorg. Deze modulen hebben de naam “Generieke functies” gekregen.
De belangrijkste generieke functies zijn
Identificatie
Authenticatie
Autorisatie
Lokalisatie
Toestemming
Adressering
De functies worden landelijk beschreven in normen, en die normen zijn onderdeel van de Wet elektronische gegevensuitwisseling in de zorg (Wegiz).
Deze functies zijn geen onderdeel van dit testplan (technisch buiten scope), dit is omdat de normen voor de Wegiz nog niet gereed zijn. Status 2024 is dat alle regio’s gekozen hebben voor HINQ, en HINQ de generieke functies op eigen wijze faciliteert. HINQ heeft daarbij aangegeven dat haar generieke functies de stand van de afspraken volgt, en dat de HINQ functies direct vervangen kunnen worden als het door anderen gefaciliteerd wordt. Wel is het noodzakelijk dat de functies “boven de motorkap” getest worden.
Kan ik als raadplegende zorgverlener erop vertrouwen dat gegevens aangemaakt zijn door de juiste zorgverlener? (identificatie / authenticatie)
Kan ik als schrijvende zorgverlener erop vertrouwen dat alleen de juiste zorgverlener de gegevens kan raaplegen? (identificatie / authenticatie / autorisatie / toestemming)
Kan ik de relevante gegevens vinden en raadplegen? (lokalisatie / adressering)
Zijn de gegevens goed beschermd? (nodes)
Een node is een middel om de toegang tot gegevens te beschermen, “nodes praten met nodes”. Een zorgaanbieder krijgt alleen een node als de zorgaanbieder voldoet aan de eisen van het vertrouwensmodel. Als de eigen zorgaanbieder, en de zorgaanbieders van het persoonlijk zorgnetwerk van de cliënt/patiënt, een gecertificeerde node hebben, kunnen veilig gegevens uitgewisseld worden. (TWIIN, NUTS)
Kijk ik alleen naar gegevens die ik mag zien? (autorisatie / toestemming)
Add Comment