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:

• Een beschrijving van de benodigde rollen en de relaties tussen de rollen (zie artikelen Organisatiebeleid, Informatie, Applicatie)

• Een beschrijving van het zorgproces, de use cases en de scenario’s (zie artikel Zorgproces)

• Een beschrijving van de informatiestandaarden op Informatie- en Applicatie-niveau (zie artikelen Informatie, Applicatie)

• Een beschrijving van de benodigde processen aan de hand van stroomschema’s (zie artikelen Proces Publiceren, Proces Raadplegen)

• Een beschrijving van de implementaties van de benodigde processen aan de hand van sequentiediagrammen (zie artikelen Procesimplementatie Publiceren, Procesimplementatie Raadplegen)

• Een beschrijving van de eisen van de benodigde actoren en transacties (zie artikelen Procesimplementatie Publiceren, Procesimplementatie Raadplegen)

• Een beschrijving van de eisen op het gebied van communicatiebeveiliging (zie artikel Communicatiebeveiliging)

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.

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

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.

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.

• 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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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 laagOrganisatiebeleid worden de juridische rollen die verantwoordelijk zijn voor de invulling van de rollen op de onderliggende lagenbeschreven, 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.

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 laagOrganisatiebeleid 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.

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.

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:

• Een beschrijving van de benodigde rollen en de relaties tussen de rollen (zie artikelen Organisatiebeleid, Informatie, Applicatie)

• Een beschrijving van het zorgproces, de use cases en de scenario’s (zie artikel Zorgproces)

• Een beschrijving van de informatiestandaarden op Informatie- en Applicatie-niveau (zie artikelen Informatie, Applicatie)

• Een beschrijving van de benodigde processen aan de hand van stroomschema’s (zie artikelen Proces Publiceren, Proces Raadplegen)

• Een beschrijving van de implementaties van de benodigde processen aan de hand van sequentiediagrammen (zie artikelen Procesimplementatie Publiceren, Procesimplementatie Raadplegen)

• Een beschrijving van de eisen van de benodigde actoren en transacties (zie artikelen Procesimplementatie Publiceren, Procesimplementatie Raadplegen)

• Een beschrijving van de eisen op het gebied van communicatiebeveiliging (zie artikel Communicatiebeveiliging)

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.

• Voor de verschillende implementatievarianten van het Proces Publiceren zie: Procesimplementatie Publiceren.

• Voor de verschillende implementatievarianten van het Proces Raadplegen zie Procesimplementatie Raadplegen.