Referentiearchitectuur

VERSIE: 19-10-2021 STATUS: CONSULTATIE

  • 19-10-2021

    • Hyperlinks geüpdatet

  • 16-09-2021

    • Referentiearchitectuur plaat aangepast:

      • Opgesplitst a.d.h.v. processen;

      • Blok generieke functies toegevoegd;

      • Onder applicatielaag een laag met landelijke tabellen toegevoegd;

      • Rol Gegevensafnemer aangepast naar “Gegevensconsument“ op de informatielaag

      • Rol “Afnemer” toegevoegd op de informatielaag.

    • Structuur artikel aangepast voor een betere leesbaarheid;

    • Verschillende afbeeldingen in het artikel geüpdatet;

    • Inleiding herschreven

    • 1.1 herschreven

  • 21-06-2021

    • Rol “XIS“ onder “Publicerende Zorgaanbieder“ hernoemd naar “Registrator“ (architectuurlaag Applicatie)

    • Rol “Requestor“ onder “Raadplegende Zorgaanbieder“ toegevoegd

    • Rol “Mitz toestemmingsregister” hernoemd naar “Autorisatievoorziening”

    • Rol “Mijn Mitz“ hernoemd naar “Toestemming applicatie“

    • Rol “RLV“ hernoemd naar “Knooppunt“

    • Rol “LLV (Landelijke lokalisatievoorziening)“ hernoemd naar “Lokalisatievoorziening“

  • 07-04-2021

    • Diverse tekstuele aanpassingen doorgevoerd

    • Rol “Extractor“ aan referentiearchitectuur toegevoegd

    • Implementatievarianten toegevoegd aan referentiearchitectuur. Implementatieniveaus zijn hiermee komen te vervallen

  • 16-11-2020

    • Naamswijziging ‘architectuur’ naar ‘referentiearchitectuur’

    • Tekst over zibs in kopje ‘oplossingsrichting' in paragraaf 'modulair ontwerp’ aangepast

  • 15-10-2020 (versie 1.1)

    • Aanpassingen doorgevoerd in paragraaf 'structuur van de referentiearchitectuur';

    • De kleuren in de afbeeldingen van de referentiearchitectuur hebben een generieke invulling gekregen voor de specifieke onderdelen;

    • Rollen op verschillende lagen in het groeimodel van de referentiearchitectuur hebben andere benamingen gekregen, zijn samengevoegd of verwijderd:

      • Gtk is vervangen door RLV (Regionale Lokalisatie Voorziening);

      • Tijdlijnvoorziening is vervangen door LLV (Landelijke Lokalisatie Voorziening)

      • De Resource server uit module B en de DVZA is nu dezelfde;

      • De Gids naar gezondheidsgegevens omvat Module C in zijn geheel. (was uitgesplits in 2 rollen Gids naar gezondheidsgegevens)

      • De rollen zoekmachine, vertaalmachine en standaardiseermachine zijn komen te vervallen.

    • Rollen in de afbeeldingen van de referentiearchitectuur zijn verschoven om een beter overzicht te geven van de processen Publiceren en Raadplegen. Hierbij zijn er op de organisatiebeleidlaag nu publicerende en raadplegende rollen;

    • De processen (in MedMij termen “Use Cases“) Delen en Verzamelen zijn duidelijker neergezet. MedMij benamingen zijn hierin overgenomen;

    • De toelichting in het groeimodel beschrijft nu de mogelijkheden op het gebied van gegevensuitwisseling tussen verschillende implementatieniveaus.

  • 1-7-2020 (versie 1.0)

    • Eerste versie gepubliceerd

Inleiding
Dit artikel beschrijft het lagenmodel van de referentiearchitectuur van het Afsprakenstelsel Interoperabiliteit Geboortezorg. Eerst wordt het modulaire ontwerp en de totstandkoming hiervan toegelicht. Daarna wordt de relatie met andere landelijke ontwikkelingen besproken. Vervolgens komt het lagenmodel van de referentiearchitectuur aan bod waarbij ook wordt ingegaan op de structuur, het gebruik van rollen en de relatie met de andere onderdelen van de referentiearchitectuur. Tot slot wordt toegelicht dat er verschillende varianten van implementatie zijn. Dit artikel is als volgt ingedeeld:

  1. Modulair ontwerp

  2. Relatie met andere landelijke ontwikkelingen

  3. Lagenmodel referentiearchitectuur

  4. Implementatievarianten

Het lagenmodel is de basis waarop de andere onderdelen van de referentiearchitectuur van het Afsprakenstelsel Interoperabiliteit Geboortezorg voortbouwen. Naast het lagenmodel bestaat de referentiearchitectuur uit de volgende onderdelen:

Alle onderdelen van de referentiearchitectuur worden aan de hand van de vijf lagen van interoperabiliteit (zie Nictiz) toegelicht in de artikelen onderliggend aan dit artikel.

1. Modulair ontwerp

Toelichting
De referentiearchitectuur van het Afsprakenstelsel Interoperabiliteit Geboortezorg komt voort uit een modulair ontwerp. Hieronder wordt dit modulair ontwerp en de totstandkoming ervan beschreven.

1.1 Totstandkoming

Het scherm
De zorgverlener, maar ook de cliënt, wil op het juiste moment de juiste gegevens kunnen inzien in één overzichtelijk scherm. Zo’n scherm kan worden gezien als een integrale digitale zwangerschapskaart. Om digitale gegevensuitwisseling mogelijk te maken voor de geboortezorg is er nagedacht over een ontwerp en een aanpak rondom dit idee. De kernpunten hiervan worden hieronder beschreven.

Maak zoveel mogelijk gebruik van wat er al is
‘Hoe kan er een integrale digitale zwangerschapskaart worden gerealiseerd?’ Deze vraag is het vertrekpunt geweest. Vervolgens zijn verschillende mogelijkheden onder de loep genomen, zoals het werken in hetzelfde zorginformatiesysteem, het versturen van gegevens via het LSP (Landelijk Schakelpunt) en het uitwisselen van pdf-bestanden. Echter, al deze ideeën bleken niet toekomstbestendig en niet te voldoen aan de wensen van de gebruikers en aan de eisen voortkomend uit wet- en regelgeving. De volgende stap was te kijken naar wat er dan wel mogelijk is en wat wel voldoet aan alle eisen. Het uitgangspunt hierbij was en is: Maak zoveel mogelijk gebruik van wat er al is. Dit om de kosten te beperken en de doorlooptijd te verkorten.

Zorginformatiebouwstenen
Om ervoor te zorgen dat de juiste informatie op het juiste moment kan worden ingezien en hergebruikt kan worden, is nodig dat een flexibele samenstelling van informatie opvraagbaar is. Om deze flexibele samenstelling te krijgen, moeten gegevens op een eenduidige wijze gestructureerd beschikbaar worden gemaakt. Hiervoor worden zorginformatiebouwstenen (zibs) beschreven en gepubliceerd. Een zorginformatiebouwsteen is een conceptueel datamodel voor een set van zorggegevens die bij elkaar horen, zoals persoonsgegevens, bloeddruk en vorige zwangerschap. Op basis van zibs kunnen FHIR-profielen worden gedefinieerd. Deze FHIR-profielen beschrijven de technische eisen aan de data die worden uitgewisseld, de zgn. FHIR-resources. FHIR-profielen zijn daarmee een essentieel element van de interoperabiliteit van geboortezorg. Wanneer in het Afsprakenstelsel Interoperabiliteit Geboortezorg wordt gesproken over zibs, wordt bedoeld: “FHIR-resources die voldoen aan FHIR-profielen die waar mogelijk zijn gebaseerd op zorginformatiebouwstenen”. De zorginformatiebouwstenen, de FHIR-profielen en de wijze waarop deze toegankelijk moeten worden gemaakt, zijn vastgelegd in de landelijke Informatiestandaard Geboortezorg PWD 3.2. Bij het raadplegen van geboortezorggegevens blijven de gegevens in de bron, een zogenaamde viewer zorgt dat de brongegevens worden getoond.

Versnellingsoplossingen
Zoals in de paragraaf Zorginformatiebouwstenen staat toegelicht, is het voor het realiseren van de wens van de eindgebruikers nodig dat zorgaanbieders zibs gestandaardiseerd kunnen aanleveren. Binnen de geboortezorg wordt een groot aantal verschillende zorginformatiesystemen gebruikt. Het tempo waarin zibs worden ingebouwd, verschilt sterk per zorginformatiesysteem. Daarom zijn door de betrokken partijen in de geboortezorg verschillende versnellingsoplossingen bedacht:

  • Er zijn versnellingsoplossingen ontwikkeld die de beschikbare informatie uit zorginformatiesystemen vertalen naar zibs die voldoen aan de Informatiestandaard Geboortezorg

  • Er zijn versnellingsoplossingen ontwikkeld die de zibs conform de Informatiestandaard Geboortezorg toegankelijk maken

  • Er zijn versnellingsoplossingen ontwikkeld waarin bij de bron(nen) opgehaalde zibs worden samengevoegd tot één actueel en eenduidig scherm. Dit scherm kan zonder opnieuw inloggen worden benaderd vanuit het eigen zorginformatiesysteem.

Lokalisatie
Zorgverleners in de geboortezorg weten vaak niet op welke plekken er informatie over een bepaalde cliënt te vinden is. Om zibs vindbaar te maken voor andere zorgverleners wordt daarom gebruik gemaakt van een lokalisatievoorziening. Hierin staat geregistreerd bij welke zorgaanbieders informatie over een cliënt staat opgeslagen. Met behulp van de lokalisatievoorziening worden vanuit de informatievraag van de zorgverlener de bronnen van de gegevens opgezocht.

1.2 Modules

Toelichting
Het modulair ontwerp dat uit de gekozen aanpak is voortgekomen is weergegeven in de infographic hieronder. Deze beschrijft de verschillende modules, hun onderlinge samenhang en de relatie met de processen Publiceren (in het toegankelijk en vindbaar maken van gegevens, blauw) en Raadplegen (rood) benoemd. De processen worden in deze paragraaf verder toegelicht. Onder de infographic volgt een korte toelichting per module.

Een voorbeeld van een zib

Wat: waar bestaat zib-patiënt uit?
BSN, voornaam, achternaam, tussenvoegsel, geboorte datum.

Hoe wordt zib-patiënt beschreven
BSN: 9 cijfers (moet voldoen aan de 11 proef)
Voornaam: tekst (Eerste letter Hoofdletter)
Achternaam: tekst (Eerste letter Hoofdletter)
Tussenvoegsel: tekst (kleine letters)
Geboortedatum: dag (2 cijfers) maand (tekst, kleine letters) jaar (4 cijfers)

Hoe ziet een ingevulde zib-patiënt er bijvoorbeeld uit?
BSN: 123456789
Voornaam: Ineke
Achternaam: Jansen
Tussenvoegsel: van der
Geboortedatum: 15 mei 1992

  • Module A: Het zorginformatiesysteem waarin geboortezorggegevens worden geregistreerd (Registrator) en van waaruit het raadplegen van geboortezorggegevens wordt geïnitieerd (Requestor).

  • Module B1: Een applicatie die gestructureerde informatie van module A syntactisch converteert naar zorginformatiebouwstenen die voldoen aan Informatiestandaard Geboortezorg PWD 3.2 (Convertor).

  • Module B2: Een applicatie die de zorginformatiebouwstenen afkomstig uit module B1 conform Informatiestandaard Geboortezorg PWD 3.2 toegankelijk maakt. (Resource Server)

  • Module C: Een verzameling van applicaties die invulling geeft aan de generieke functies zoals authenticatie, lokalisatie en autorisatie.

  • Module D1: Een applicatie die een informatiebehoefte vanuit het zorgproces omzet naar een vraag naar specifieke zibs. (Query Builder)

  • Module D2: Een applicatie die de verzamelde zibs vertaalt van code naar leesbare taal. (Translator)

  • Module E: Een applicatie die conform Informatiestandaard Geboortezorg PWD 3.2 toegankelijk gemaakte geboortezorggegevens toont op een scherm. (Viewer)

Op de Applicatie-laag van de referentiearchitectuur van het Afsprakenstelsel Interoperabiliteit Geboortezorg zijn deze modules uitgewerkt door middel van sequentiediagrammen, actoren en transacties.

1.3 Zorginformatiebouwstenen (zibs)

Toelichting
Zorginformatiebouwstenen vormen een belangrijk onderdeel van het modulair ontwerp op basis waarvan de referentiearchitectuur van het Afsprakenstelsel Interoperabiliteit Geboortezorg is opgesteld. Door het gebruik van zibs kunnen datasets flexibel worden samengesteld. Op deze manier kan worden voorzien in de veranderende informatiebehoefte tijdens de verschillende fases van het geboortezorgproces. Daarnaast kan door het gebruik van zibs de cliënt in staat worden gesteld om op een hoog detailniveau te bepalen welke geboortezorggegeven wel of niet tussen zorgverleners mogen worden gedeeld. Het gebruik van zibs maakt het ook mogelijk om analyses op een serie van zibs uit te voeren, bijvoorbeeld door een grafiek te maken van een meting die op meerdere momenten in het geboortezorgproces is uitgevoerd. Op deze manier zorgt het gebruik van zibs ervoor dat relevante informatie op het juiste moment kan worden opgevraagd.

1.4 Processen

Toelichting
Bij het uitwisselen van digitale geboortezorggegevens vormen schrijven en lezen de basis. Wanneer het een zorgverlener betreft, worden deze processen Publiceren en Raadplegen genoemd. Wanneer het een cliënt betreft, worden deze processen Delen en Verzamelen genoemd. Daarnaast kan de cliënt Regie voeren door toestemmingen voor het uitwisselen van eigen geboortezorggegevens vast te leggen en te beheren, behandelrelaties vast te leggen en te beheren en door te bekijken welke zorgverleners haar geboortezorggegevens hebben geraadpleegd.

In de paragrafen hieronder worden de vijf processen en hun relatie met de verschillende modules nader toegelicht.

 

Proces Publiceren

Toelichting
Het proces Publiceren bestaat enerzijds uit het toegankelijk maken van geboortezorggegevens en anderzijds uit het vindbaar maken van geboortezorggegevens.

Om geboortezorggegevens toegankelijk te maken, registreert de zorgverlener allereerst nieuwe gegevens in het eigen systeem, Module A (Registrator). De gegevens worden daarna via Module B1 (Convertor) omgezet naar zibs die voldoen aan de Informatiestandaard Geboortezorg. Module B1 biedt deze zibs vervolgens aan Module B2 (Resource Server) aan, die ervoor zorgt dat deze zibs toegankelijk zijn conform de Informatiestandaard Geboortezorg.

Om geboortezorggegevens vindbaar te maken wordt aan één van de onderdelen van Module C (Lokalisatievoorziening) gemeld dat er een behandelrelatie tussen zorgaanbieder en cliënt is en/of dat er een expliciete toestemming van de cliënt is voor de het delen van de door de zorgaanbieder geregistreerde geboortezorggegevens met één of meer andere zorgaanbieders.

Hieronder is het proces Publiceren schematisch weergegeven.

Proces Raadplegen

Toelichting
Dit proces beschrijft het raadplegen van geboortezorggegevens door een zorgverlener.

Het raadplegen van geboortezorggegevens begint in het zorginformatiesysteem Module A (Requestor) van de zorgverlener. Vanuit Module A opent de zorgverlener Module E (Viewer). Hierbij wordt in Module A aanwezige informatie over de zorgcontext doorgegeven aan Module E.

Module E geeft de informatiebehoefte die voortkomt uit de zorgcontext door aan Module D1 (Query Builder). Module D1 zet deze informatiebehoefte om in een lijst met benodigde zibs. Vervolgens vraagt Module D1 aan Module C (Lokalisatievoorziening) welke zorgaanbieder(s) relevante zibs over de betreffende client hebben geregistreerd.

Vervolgens worden de zibs bij deze zorgaanbieders opgevraagd. Hierbij geldt dat gegevens alleen door een zorgverlener kunnen worden bekeken wanneer daarvoor een grondslag is, zoals een expliciete toestemming of een verwijzing. Dit wordt getoetst door Module C (Grondslagvoorziening). Daarnaast geldt dat de functie en/of rol van de zorgverlener bepaalt welke gegevenselementen een zorgverlener kan zien. Dit filter wordt toegepast door Module C (Autorisatievoorziening).

Module D2 vertaalt de door Module D1 opgehaalde zibs naar leestaal. Daarna zet Module E de informatie van verschillende zorgaanbieders op de juiste plaats in het scherm (de integrale digitale zwangerschapskaart) en toont dit aan de zorgverlener.

Hieronder is het proces Raadplegen schematisch weergegeven.

Voorbeeld van hoe een integrale zwangerschapskaart eruit kan zien.

Toelichting
Module E toont geboortezorggegevens uit één of meerdere bronsystemen waarbij de gegevens in de bron blijven. Op deze manier zijn de eenduidigheid en actualiteit van geboortezorggegevens geborgd. Daarnaast zorgt Module E ervoor dat er minder aanpassingen nodig zijn aan bestaande zorginformatiesystemen.

Proces Regie voeren

Toelichting
Dit proces beschrijft hoe een cliënt Regie kan voeren over haar eigen geboortezorggegevens.

De cliënt kan Regie voeren door toestemmingen voor het uitwisselen van eigen geboortezorggegevens vast te leggen en te beheren, behandelrelaties vast te leggen en te beheren en door te bekijken welke zorgverleners haar geboortezorggegevens hebben geraadpleegd. Zorgverleners kunnen alleen geboortezorggegevens raadplegen wanneer daarvoor een grondslag is. Deze grondslag kan een door de cliënt vastgelegde toestemming of behandelrelatie zijn.

De cliënt kan toestemmingsinformatie doorgeven aan het onderdeel Grondslagvoorziening van Module C. De cliënt kan informatie over behandelrelaties doorgeven aan het onderdeel Lokalisatievoorziening van Module C.

Proces Delen & Proces Verzamelen

Toelichting
Tijdens het Proces Delen en het Proces Verzamelen vindt er gegevensuitwisseling plaats tussen een Zorgaanbieder en een Cliënt. Hieronder staat een korte toelichting van deze processen. Voor meer informatie zie het MedMij Afsprakenstelsel.

Proces Delen

Toelichting
Dit proces beschrijft het delen van geboortezorggegevens door een cliënt.

De cliënt kan gegevens, die zijn opgeslagen in haar PGO, delen met haar zorgverleners. De gegevens worden door Module PGO aangeboden aan Module DVZA. Module DVZA levert de gegevens af bij Module B2. De zorgverlener met wie de cliënt haar gegevens heeft gedeeld, kan deze gegevens nu inzien.

Proces Verzamelen

Toelichting
Dit proces beschrijft het verzamelen van geboortezorggegevens door een cliënt.

De cliënt kan gegevens, die door haar zorgverleners toegankelijk zijn gemaakt in Module B2 verzamelen naar haar PGO. De gegevens worden door Module PGO opgevraagd bij Module DVZA. Module DVZA vraagt de gegevens op bij Module B2. Vervolgens biedt Module DVZA de gegevens aan Module PGO aan.

2. Relatie met andere landelijke ontwikkelingen

Toelichting
Bij de gegevensuitwisseling in de Nederlandse zorg zijn verschillende partijen betrokken die ieder een specifieke rol vervullen. Enkele hiervan worden hieronder schematisch weergegeven en vervolgens toegelicht.

Voor het Afsprakenstelsel Interoperabiliteit Geboortezorg zijn de onderstaande initiatieven het meest van belang:

  • DIZRA: DIZRA is de referentiearchitectuur voor een duurzaam informatiestelsel in de zorg. De principes van DIRZA zijn leidend bij de totstandkoming van het Afsprakenstelsel Interoperabiliteit Geboortezorg.

  • MedMij: MedMij richt zich op het uitwisseling van gezondheidsgegevens tussen het systeem van de Zorgaanbieder en de zelfgekozen persoonlijke gezondheidsomgeving (PGO) van de cliënt. Hierdoor wordt het mogelijk geboortezorggegevens beschikbaar te stellen voor zwangeren. Via een PGO kan de zwangere haar eigen gegevens verzamelen en bekijken. Voor de uitwisseling van geboortezorggegevens tussen cliënten en zorgaanbieders sluit het Afsprakenstelsel Interoperabiliteit Geboortezorg volledig aan bij het MedMij afsprakenstelsel.

  • Twiin: Twiin richt zich op uitwisseling van zorggegevens tussen (regionale) knooppunten. Hierdoor wordt het mogelijk om geboortezorggegevens geregistreerd buiten de eigen regio te raadplegen. Twiin beschrijft verschillende afspraken voor de invulling van de generieke functies in Module C. Het Afsprakenstelsel Interoperabiliteit Geboortezorg sluit hierbij aan in de beschrijving van de actor Knooppunt en de verschillende generieke functies.

  • Registratie aan de bron: richt zich op de ontwikkeling van zorginformatiebouwstenen (zibs) die het fundament vormen van eenduidige registratie. Door de zibs is het mogelijk om schermen naar behoefte samen te stellen (relevante informatie). Het Afsprakenstelsel Interoperabiliteit Geboortezorg sluit hierbij aan door voor de uitwisseling van geboortezorggegevens tussen Zorgaanbieders en tussen Zorgaanbieders en Cliënten de zibs te vereisen die zijn vastgelegd in de Informatiestandaard Geboortezorg PWD 3.2.

  • OTV: OTV richt zich op het ontwikkelen van een landelijke toestemmingsvoorziening (Mitz) waarin cliënten, zorgverleners en zorgaanbieders toestemmingen voor de uitwisseling van zorggegevens kunnen vastleggen, beheren en raadplegen. Mitz biedt een oplossing waarmee de zwangere kan bepalen wie haar gegevens mag zien. Daarnaast biedt Mitz een oplossing waarmee de lokalisatie van geboortezorggegevens kan worden uitgevoerd.

  • Nuts: Nuts richt zich op het realiseren van een decentrale infrastructuur voor gegevensuitwisseling in de zorg. Nuts beschrijft verschillende afspraken en biedt open source software aan voor de invulling van de generieke functies in Module C. Het Afsprakenstelsel Interoperabiliteit Geboortezorg sluit hierbij aan in de beschrijving van de actor Knooppunt en de verschillende generieke functies.

  • Andere VIPP Programma’s: VIPP Babyconnect sluit zo veel mogelijk aan bij de andere VIPP-programma’s. Het VIPP Babyconnect programmabureau maakt waar mogelijk gebruik van wat er binnen andere programma’s is ontwikkeld en vice versa. Door met andere landelijke partijen samen te werken kan er een zo efficiënt mogelijke referentiearchitectuur worden neergezet die invulling geeft aan de wensen van de eindgebruikers en die binnen en buiten de geboortezorg kan worden toegepast.

De aansluiting tussen de referentiearchitectuur van het Afsprakenstelsel Interoperabiliteit Geboortezorg en deze initiatieven wordt nader toegelicht in de paragraaf Afbakening van het artikel Uitgangspunten Afsprakenstelsel.

3. Lagenmodel referentiearchitectuur

Toelichting
In het lagenmodel van de referentiearchitectuur worden de rollen weergegeven die moeten worden ingevuld om digitale gegevensuitwisseling in de geboortezorg mogelijk te maken. De 5 verschillende processen die eerder in dit artikel zijn behandeld, komen hierin terug. De linkerkant bevat de rollen gerelateerd aan de ‘schrijvende' processen ‘Delen' en ‘Publiceren (Bronhouder)’ en de rechterkant bevat de rollen gerelateerd aan de ‘lezende’ processen ‘Raadplegen (Afnemer)’ en 'Verzamelen’. De rollen behorende tot de Generieke functies (Module C), die zowel door Publiceren als door Raadplegen worden gebruikt, worden in het midden weergegeven. Aan de linkerkant zijn daarnaast ook nog de rollen weergegeven die zijn gerelateerd aan het proces 'Regie voeren’.

De benodigde rollen zijn ingedeeld op basis van de lagen van het interoperabiliteitsmodel. Alle rollen staan in verbinding met een of meerdere rollen op andere lagen van interoperabiliteit. Een belangrijk opbrengst hiervan is dat voor iedere rol inzichtelijk is welke juridische rol (op de laag Organisatiebeleid) eindverantwoordelijk is voor de invulling ervan.

Het lagenmodel van de referentiearchitectuur maakt inzichtelijk welke rollen nodig zijn om tot interoperabiliteit van geboortezorg te komen. De wijze waarop de rollen dienen te worden ingevuld, wordt zo concreet mogelijk beschreven in de verschillende artikelen van het afsprakenstelsel.

3.1. Structuur

Toelichting
Het lagenmodel van de referentiearchitectuur van het Afsprakenstelsel Interoperabiliteit Geboortezorg is gestructureerd aan de hand van het door Nictiz beheerde interoperabiliteitsmodel. Hierin worden vijf lagen van interoperabiliteit onderscheiden. Elke laag kent zijn eigen rollen, begrippen en standaarden. Daarnaast zijn er twee randvoorwaardelijke kolommen die op alle lagen van toepassing zijn, te weten Wet- en regelgeving en Informatiebeveiliging. Interoperabiliteit ontstaat als de afspraken op alle lagen op elkaar aansluiten én voldoen aan de randvoorwaarden. De inhoud van de randvoorwaardelijke kolommen is terug te vinden in het artikel Randvoorwaarden en uitgangspunten en is toegepast op de verschillende lagen van de referentiearchitectuur.

Ten opzichte van het interoperabiliteitsmodel gelden voor het lagenmodel van de referentiearchitectuur van het Afsprakenstelsel Interoperabiliteit Geboortezorg de volgende aandachtspunten:

  • De laag Organisatiebeleid bevat juridische rollen
    Een onmisbaar deel van het Afsprakenstelsel Interoperabiliteit Geboortezorg betreft de verantwoordelijkheden die Zorgaanbieders, Personen en andere juridische entiteiten hebben aangaande de interoperabiliteit van geboortezorg. In de laag Organisatiebeleid worden de juridische rollen die verantwoordelijk zijn voor de invulling van de rollen op de onderliggende lagen beschreven, inclusief hun onderlinge relaties.

  • Extra laag landelijke (definitie)tabellen
    Onder de laag Applicatie is een rechthoekige laag toegevoegd. Hierin zijn de benodigde landelijke (definitie)tabellen opgenomen. Actoren op de laag Applicatie die hiermee zijn verbonden, maken gebruik van een dergelijke landelijke tabel.

In de afbeelding hiernaast wordt de structuur van de referentiearchitectuur van het Afsprakenstelsel Interoperabiliteit Geboortezorg weergegeven. De kleuren van de lagen komen overeen met de kleuren van de lagen van het interoperabiliteitsmodel. Voor een gedetailleerde omschrijving per laag wordt verwezen naar de volgende artikelen:

De inhoud van de randvoorwaardelijke kolommen is terug te vinden in het artikel Randvoorwaarden en uitgangspunten en is toegepast op de verschillende lagen van de referentiearchitectuur.

3.2. Rollen

Toelichting
De verantwoordelijkheden die moeten worden ingevuld voor het creëren van interoperabiliteit van geboortezorg vormen een essentieel onderdeel van het Afsprakenstelsel Interoperabiliteit Geboortezorg. Deze verantwoordelijkheden zijn gebundeld in rollen, welke zijn verdeeld over de verschillende lagen van interoperabiliteit. De laag Organisatiebeleid bevat de juridische rollen die eindverantwoordelijk zijn voor de invulling van de rollen op de onderliggende lagen.

De rollen die nodig zijn voor de interoperabiliteit van geboortezorg worden weergegeven als gekleurde rechthoeken. Cilinder vormige blokken geven landelijke (definitie)tabellen weer.

  • Rood: rollen die specifiek zijn voor het Afsprakenstelsel Interoperabiliteit Geboortezorg;

  • Grijs: rollen die zijn gerelateerd aan de generieke functies lokalisatie en adressering;

  • Groen: rollen die zijn gedefinieerd in het MedMij afsprakenstelsel;

  • Blauw: rollen die zijn gerelateerd aan de generieke functies grondslagcontrole en autorisatie en aan het beheren van expliciete toestemmingen;

  • Oranje: rollen die zijn gerelateerd aan de authenticatie van zorgverleners;

  • Bruin: rollen die zijn gerelateerd aan de authenticatie van zorgaanbieders, samenwerkingsverbanden en leveranciers.

3.3 Rolbinding

Toelichting
Rollen op verschillende lagen zijn met elkaar verbonden, dit noemen we rolbinding. De rolbindingen worden per laag toegelicht in de betreffende artikelen, samen met de onderlinge relaties tussen de rollen binnen één laag. Alle rollen uit het lagenmodel van de referentiearchitectuur zijn via rolbinding verbonden met exact één rol op de laag Organisatiebeleid. Op deze manier zorgen rolbindingen ervoor dat voor alle verantwoordelijkheden uit de referentiearchitectuur duidelijk is welke juridische rol eindverantwoordelijk is voor de invulling daarvan. Hieronder is een voorbeeld opgenomen om dit concept toe te lichten.

 

Voorbeeld rolbinding

In de figuur hiernaast zijn de rollen op de verschillende lagen weergegeven als rode rechthoeken. Iedere rol staat voor een verzameling specifieke verantwoordelijkheden. Door middel van verticale lijnen is de rolbinding tussen de rollen weergegeven. De figuur dient als volgt te worden geïnterpreteerd:

De Organisatiebeleid-rol Zorgaanbieder Publicerend is eindverantwoordelijk voor de invulling van alle hiermee verbonden rollen: Zorgverlener, Gegevensproducent, Registrator en Registrator-node.

De Organisatiebeleid-rol Zorgaanbieder Publicerend stelt de Zorgproces-rol Zorgverlener in staat de Informatie-rol Gegevensproducent uit te voeren, door het aanbieden van de Applicatie-rol Registrator.

De Organisatiebeleid-rol Zorgaanbieder Publicerend neemt een dienst af van de Organisatiebeleid-rol Leverancier Registrator voor de invulling van de rol Registrator.

De Applicatie-rol Registrator maakt gebruik van de IT-infrastructuur-rol Registrator node.

3.4 Onderdelen referentiearchitectuur

Het lagenmodel is de basis waarop de andere onderdelen van de referentiearchitectuur van het Afsprakenstelsel Interoperabiliteit Geboortezorg voortbouwen. Naast het lagenmodel bestaat de referentiearchitectuur uit de volgende onderdelen:

4. Implementatievarianten

Toelichting
Het implementeren van de referentiearchitectuur kan op verschillende manieren, deze worden implementatievarianten genoemd. De juiste implementatievariant wordt per zorgaanbieder per proces (Publiceren of Raadplegen) bepaald. De implementatievariant is afhankelijk van de mogelijkheden van het gebruikte XIS en de mate waarin de zorgaanbieder hiervan gebruik wenst te maken. De technische uitwerking van de implementatievarianten is opgenomen in de procesimplementaties die onderdeel zijn van de laag Applicatie.

 

Samen komen we verder
Dit artikel is tot stand gekomen met de kennis en inzichten van professionals, experts, beleidsmakers en bestuurders. Bij VIPP Babyconnect geloven we dat er vele perspectieven nodig zijn om te gaan zien wat voor iedereen werkt. En die afweging kan altijd beter. Zie jij mogelijkheden voor verbetering in dit artikel? Vraag via info@carecodex.org een review-account aan en laat een reactie achter.
Samen weten we meer. Samen komen we verder.