Technisch ontwerp technische basisstructuur

Transcriptie

1 Technisch ontwerp technische basisstructuur Versie: 0.95 Versiedatum: Status: Auteur: REVIEW (Intern) Hilko Jacobse (ZIN)

2 Inhoudsopgave Inleiding 2 Doel van dit document 2 Uitgangspunten 2 Actoren & Rollen 3 Onboarding 4 Componenten 5 5 Applicatie componenten en functies 7 Gedeelde voorzieningen 9 Station Directory 9 Autorisatie voorziening 11 Verwijsindex 12 Indexatie functie 13 Applicatie Services 14 Interactiepatronen 15 Raadplegen Station Directory 15 Raadplegen 15 Procesverloop raadplegen (wettelijke grondslag) 16 Procesverloop raadplegen (handmatige consent) 16 Abonneren 17 Procesverloop abonneren 18 Notificeren op abonnement 19 Procesverloop Notificeren 19 (Terug)Melden 20 Procesverloop melden 20 Statuscodes 20 Overzicht koppelvlakken 21 1

3 Inleiding Doel van dit document Dit document beschrijft de technische opzet van technische basisinfrastructuur voortkomend uit het actieprogramma iwlz. Deze basisinfrastructuur bestaat uit onderling samenwerkende datastations en de ondersteunde functies die zijn ondergebracht in de netwerkvoorziening. De conversie voorziening Silvester is ook onderdeel van de basisinfrastructuur, maar valt buiten de scope van dit document. De diensten die die partijen in het netwerk elkaar aanbieden, de wijze waarop deze in het netwerkproces een rol spelen en de wijze waarop partijen deze intern (in hun eigen applicaties) verwerken staat beschreven in het functioneel ontwerp. In dit document wordt de technische invulling van deze principes uitgewerkt. Uitgangspunten Het uitgangspunt van dit ontwerp is dat de applicatie waar mogelijk decentraal wordt opgezet. Dit betekent dat applicatie functies zoveel mogelijk gepositioneerd worden in de datastations, de gedeelde voorzieningen bevatten enkel de functies die minimaal nodig zijn om de datastations elkaar te laten vinden en te voorzien van de benodigde autorisatie profielen. De daadwerkelijke gegevensuitwisseling vindt dus enkel tussen de datastations plaats ( point-to-point ). De gegevens die via het datastation worden ontsloten moeten voldoen aan de FAIR principes. Het datastation fungeert derhalve als een FAIR datapoint. 2

4 Actoren & Rollen Op diverse plaatsen in dit ontwerp wordt verwezen naar de rol die een partij (Actor) speelt in het netwerk. Afhankelijk van zijn/haar rol krijgt een partij toegang tot bepaalde services en of gegevens sets. De relevante rollen worden hier kort beschreven, voor een uitgebreide beschrijving zie het Functioneel Ontwerp. Referentie: # Actor Rol Afkorting Toelichting 1 CIZ Indicatieorgaan IND Verantwoordelijk voor het beslissen over het toekennen van Wlz-zorg aan een cliënt. 2 CAK Administratie ADM Verantwoordelijk voor het voeren van een administratie om bedragen in de zorg te kunnen betalen en incasseren. 3 SVB Administratie ADM Verantwoordelijk voor het voeren van een administratie om bedragen in de zorg te kunnen betalen en incasseren. 4 Zorgkantoor Uitvoerder UIT Verantwoordelijk voor inkopen van zorg binnen een toegekend budget en het toeleiden van cliënten naar de juiste zorg. 5 Zorgaanbieder Zorgaanbieder ZA * de natuurlijke persoon of rechtspersoon die beroeps- of bedrijfsmatig zorg verleent; de natuurlijke persoon of rechtspersoon voor zover deze tarieven in rekening brengt namens, ten behoeve van of in verband met het verlenen van zorg door een zorgaanbieder als bedoeld in het vorige punt. bron:wmg Artikel 1. 6 Cliënt Cliënt C Cliënt heeft een zorgbehoefte. 3

5 Onboarding Voordat een partij gegevens uit kan wisselen via de basisstructuur moet de zogenaamde Onboarding procedure worden doorlopen. De partij dient hier minimaal één wettelijke grondslag voor te hebben. Tijdens deze procedure wordt de partij toegevoegd aan de Station Directory. Hierdoor worden gegevens die de partij ondersteunt vindbaar voor de overige deelnemers aan het netwerk. Daarnaast krijgt de betreffende partij hiermee een autorisatieprofiel in de autorisatie voorziening op basis van haar wettelijke taak, waardoor de partij toegang krijgt tot de gegevens van de andere netwerk deelnemers. Alle partijen identificeren zichzelf (via het datastation) met hulp van een PKI server certificaat. Hiermee kan eenduidig en onweerlegbaar worden vastgesteld met welk datastation en dus met welke partij een connectie wordt opgezet. Op basis van de subject name in het certificaat kan tevens worden afgeleid welke rol(len) een partij vervult in het netwerk en welke autorisatieprofielen van toepassing zijn. De subject name uit het certificaat wordt meegegeven als custom header in het request. Op basis van de informatie in deze header kan het ontvangende datastation bepalen of de vragende partij recht heeft op de gevraagde gegevens. De gebeurt door de subject name te matchen met de gegevens uit de Station Directory, hieruit kan worden afgeleid welke rollen een partij vervult in het netwerk. In de Station Directory worden in elk geval de volgende gegevens over de partij vastgelegd: - De identiteit van de nieuwe deelnemer - De subject name uit het PKIO certificaat van de deelnemer - De rol(len) die de deelnemer vervult in het netwerk - Het endpoint van het van de deelnemer - De metadata van de gegevensverzamelingen die de deelnemer ontsluit Nadat de registratie succesvol is afgerond zijn de gegevens over de deelnemer beschikbaar voor de overige deelnemers van het netwerk. 4

6 Componenten De componenten van de technische basisstructuur kunnen worden onderverdeeld in twee categorieën. Het datastation waarvan voor elke aangesloten partij een instantie bestaat en gedeelde voorzieningen welke gebruikt worden door de diverse datastations om informatie met elkaar uit te wisselen. Het datastation ontkoppelt de interne organisatie van het (iwlz) netwerk. Het datastation routeert verzoeken van interne organisatie naar het juiste externe datastation, routeert verzoeken van externe datastations naar de juiste interne bron, zorgt voor een veilige uitwisseling van informatie tussen de datastations en logt alle verzoeken op een uniforme wijze. 5

7 Het DataStation communiceert via diverse koppelvlakken met de backoffice applicatie van de aangesloten partij zodat informatie uit andere DataStations geconsumeerd kan worden. Tevens heeft het DataStation toegang nodig tot de gegevens van de partij welke zijn vastgelegd in een DataStorage, waardoor deze gegevens beschikbaar komen voor andere netwerk partijen. Deze integratie is hieronder weergegeven. 6

8 Applicatie componenten en functies Een is een aggregatie van diversie applicatie componenten en functies. Deze worden hieronder nader toegelicht. Dispatcher De Dispatcher is verantwoordelijk voor het het verwerken van alle interne informatie verzoeken die synchroon worden afgehandeld in het netwerk. De Dispatcher maakt gebruik van de Station Directory om het verzoek naar het juiste te routeren. De Dispatcher kan gebruik maken van een dat de functie van verwijsindex uitvoert om te achterhalen waar informatie over een specifieke cliënt gevonden kan worden. Via de Dispatcher worden twee type requests gedaan - Raadplegingen: Het ophalen van gegevens bij een externe bron - Abonnementen: Het zetten van een abonnement op wijzigingen van een entiteit in een externe bron. Een abonnement 7

9 bestaat uit een onderwerp waarover men geïnformeerd wenst te worden, zoals een BSN of een Indicatienummer, een identificatie van de abonnerende partij en een geldigheidsperiode. De inhoudelijke specificatie van de gegevenssets en abonnement typen die bij een kunnen worden geraadpleegd of ingesteld zijn nader omschreven in de Dienstencatalogus iwlz-netwerk en Procesmodel. Message Access Point Het Message Access Point is verantwoordelijk het verzenden en ontvangen van berichten naar een andere partij in het netwerk. Deze berichten worden reliable verstuurd zodat men zich ervan kan verzekeren dat deze worden afgeleverd. - Melden: Het doen van een verzoek aan een andere partij om een bepaald proces in werking te zetten - Terugmelden: Het melden van een mogelijke incorrectheid in een gegevensverzameling van een andere partij - Notificeren: Het melden dat een wijziging is opgetreden in een entiteit waar een partij op is geabonneerd - Verwerken melding: - Verwerken terugmelding: - Verwerken notificatie: Subscription Handler De Subscription Handler verwerkt de inkomende abonneer verzoeken uit het netwerk. De Subscription Handler stuurt een abonnementid retour als response en persisteert het abonnement. Tevens wordt het abonnementid inclusief relevante parameters doorgezet naar de backoffice applicatie. Metadata Publisher De Metadata Publisher stelt metadata beschikbaar over de gegevensverzamelingen die ontsloten worden via het. Voor elke gegevensverzameling wordt een aparte set metadata gepubliceerd. Data Access Point Via het Data Access Point kunnen de diverse gegevensverzamelingen worden benaderd. Het Data Access Point kent zowel een API voor het afhandelen van REST operaties als een Query API voor het afhandelen van bijvoorbeeld SPARQL queries. Verzoeken die via één van beide interfaces binnenkomen worden door het Data Access Point gerouteerd naar de juiste achterliggende gegevensbron. Het resultaat van de bevraging van de gegevensbron wordt door het Data Access Point synchroon teruggestuurd naar het vragende (Dispatcher). configuratie Het kent een beheerinterface waarmee de gegevensverzamelingen die via het worden ontsloten gedefinieerd kunnen worden. Bij elke gegevensverzameling 8

10 wordt vastgelegd via welke interne dataservice deze benaderd kan worden. Tevens wordt bij elke gegevensverzameling de relevante metadata vastgelegd zodat deze door de Metadata Publisher kan worden ontsloten. Logging De logging functie legt vast wie, namens welke organisatie, op welk moment, welke informatie heeft opgevraagd via het datastation. De volgende gegevens moeten minimaal worden opgeslagen Gegeven ID Timestamp Richting Organisatie ID Gegevensverzameling RequestID ResponseID Toelichting Unieke, betekenisloze sleutel Aanduiding van het moment waarop de logregel is toegevoegd Inkomend of Uitgaand verzoek Unieke identificatie van de organisatie die het verzoek doet (afkomstig uit request header) Gegevensverzameling waar het request betrekking op had Unieke identificatie van het request Unieke identificatie van de response De logging functie wordt aangeroepen door alle andere applicatie componenten. Logging informatie kan bij een datastation worden opgevraagd via de Logging service, deze service is niet toegankelijk voor andere datastations en wordt alleen gebruikt ten behoeve van audits. Gedeelde voorzieningen Het netwerk kent een aantal gedeelde voorzieningen die de datastations voorzien van de informatie die noodzakelijk is om gegevensuitwisseling mogelijk te maken. Hierin onderkennen we de Station Directory en de Autorisatie voorziening. Station Directory De Station Directory is in feite een doorzoekbare bron met de metadata van alle datastations. Van elk datastation worden minimaal de volgende gegevens vastgelegd. Gegeven ID Toelichting Unieke, betekenisloze sleutel 9

11 Naam Identificatienummer Identificatienummer soort Subject name certificaat Endpoint datastation Gegevensverzamelingen Datum aangemaakt Datum bijgewerkt Aanduiding van de partij Betekenisvolle sleutel waarmee de partij kan worden geïdentificeerd Duidt aan welk type identificatienummer is vastgelegd, bijvoorbeeld AGB code, KvK nummer enz. Subject name zoals opgenomen in het PKI certificaat URL waarop het datastation van de partij kan worden aangeroepen Welke gegevensverzamelingen de partij via het datastation ontsluit Datum waarop de gegevens voor het eerst zijn vastgelegd Datum waarop de gegevens voor het laatst zijn bijgewerkt De Station Directory kan worden aangeroepen door het om op basis van een kenmerk, zoals een partijid of gegevenstype, te bepalen naar welk endpoint een request moet worden verzonden. De Station Directory kan ook worden gebruikt om te toetsen welke gegevens via welk datastation ontsloten worden en onder welke voorwaarden deze gebruikt kunnen worden. Deze informatie volgt uit de metadata die wordt gepubliceerd door de individuele 10

12 datastations via de Metadata Publisher. De Station Directory indexeert deze metadata en stelt deze beschikbaar aan het netwerk. Autorisatie voorziening De autorisatie voorziening vervult een poortwachter functie binnen het iwlz netwerkmodel en bewaakt de relatie tussen individuen en uitvoerders in de Wlz. Op basis van een machtiging structuur, die gebaseerd is op consent (instemming), tussen partijen wordt toegang tot gegevens verleend. De consent die wordt doorgevoerd is gebaseerd op de AVG-grondslag: Wetgeving/ wettelijke verplichting; Pre- en contractuele verplichtingen (overeenkomst, algemene en aanvullende voorwaarden, etc.); Uitvoering van taken van algemeen belang/uitvoering van openbaar gezag; Vitaal belang (alleen bij levensbedreigende zaken); Gerechtvaardigd belang (van de betrokkene of derden); Toestemming (is aan eisen gebonden en last resort). De autorisatie voorziening toetst of een vragende partij toegang mag krijgen tot de gegevens van de leverende partij. Uitgangspunt hierbij is dat per bevraging wordt bepaald of deze wel of niet mag plaatsvinden en overeenkomstig AVG-grondslag is. De autorisatie voorziening is verantwoordelijk voor het daadwerkelijk doorvoeren van de machtigingen in de vorm van policies op het dataverkeer. Aangesloten partijen zijn hierdoor zelf maar gedeeltelijk verantwoordelijk voor de autorisatiestructuur die betrekking heeft op hun gegevens- en informatiediensten. Dit levert een complexiteitsreductie op voor wat betreft interne autorisatieregels en, op het berichtenverkeer van toepassing zijnde, technische en operationele regels. De van toepassing zijnde machtigingen structuur zal op voorhand door het Zorginstituut worden gedefinieerd door de huidige wetgeving en overeenkomsten te raadplegen en afgeleid hieraan de bijbehorende machtigingen structuur op te stellen. De autorisatie voorziening wordt door ieder data-station per bevraging aangeroepen. Hierbij wordt per bevraging gecontroleerd of er een zogenaamde consent aanwezig is (AVG-grondslag). Op basis van de aanwezige consent wordt automatisch bepaald of de bevragende partij een grondslag heeft voor de bevraging/raadpleging en of deze mag worden doorgezet (autorisatie). Bij een succesvolle autorisatie op de bevraging zal deze zichtbaar zijn voor de desbetreffende persoon. Een consent kan ontstaan doordat deze door de cliënt zelf is verstrekt of doordat de partij een wettelijke grondslag heeft voor het opvragen van de gegevens. In dit laatste geval wordt er automatisch een consent aangemaakt op het moment dat de rechthebbende partij gegevens over een cliënt opvraagt, dit is een zogenaamde automated consent. Er bestaat dus alleen een consent in de autorisatie voorziening als er daadwerkelijk een juridische grondslag aanwezig is voor de 11

13 gegevensuitwisseling tussen cliënt en iwlz partij OF wanneer de cliënt zelf een consent heeft afgegeven door middel van toestemming. Indien er geen consent aanwezig is zal de bevragen worden geblokkeerd door de gatekeeper. De bevragende partij zal in dit geval direct een foutmelding ontvangen waaruit blijkt waarom geen toegang is verstrekt tot de gevraagde gegevens. Verwijsindex Om het mogelijk te maken dat partijen informatie over cliënten uit te wisselen, zonder van elkaar te weten wie diensten levert aan welke cliënt, is een verwijsindex nodig. Door de Index functie te raadplegen kan een partij uitvragen bij welke partijen informatie over een cliënt beschikbaar is. De Verwijsindex is een speciale gegevensverzameling die door een zogenaamde Trusted Third Party wordt aangeboden via een. De Verwijsindex kan dus op dezelfde manier worden geraadpleegd als alle andere s. 12

14 Indexatie functie De verwijsindex wordt gevoed door de Indexatie functie, welke actief bij de s in het netwerk ophaalt of een partij informatie over een cliënt heeft en vanuit welke bedrijfsfunctie deze informatie is ontstaan. De indexatie functie maakt hierbij gebruik van de gegevens die zijn vastgelegd in de Station Directory om de endpoints van alle s in het netwerk te indexeren. 13

15 Applicatie Services Een applicatie service ontsluit een applicatie functie naar de buitenwereld. In het onderstaande overzicht is weergegeven welke applicatie services voor de andere partijen in het netwerk toegankelijk zijn en welke alleen voor de eigenaar van het datastation beschikbaar zijn. Service Interface type Component Extern / Intern DataStation service REST DataStation Intern Backend integration service Data Interaction service REST DataStation Intern REST, Query DataStation Extern Subscription service REST DataStation Extern Message service WebService (edelivery) DataStation Extern Metadata service REST DataStation Extern Logging service REST DataStation Extern (beperkt) DataStorage service REST DataStorage Intern StationDirectory service REST StationDirectory Extern Autorisatie service REST Autorisatie voorziening Extern 14

16 Interactiepatronen In dit hoofdstuk wordt beschreven hoe de datastations interacteren met de gedeelde voorziening. Raadplegen Station Directory Om een interne vraag te kunnen routeren naar de Data Interaction service van een extern moet het endpoint van het betreffende bekend zijn bij de Dispatcher. Raadplegen Het onderstaande sequence diagram geeft de volledige interactie flow met twee datastations weer, inclusief het bevragen van een datastation dat dienst doet als index en de Station Directory. Indien de index n partijen teruggeeft worden de interacties vanaf dat punt voor elke partije uitgevoerd. Het volledige resultaat wordt als 1 response aan de vragende backoffice applicatie teruggeven. 15

17 Procesverloop raadplegen (wettelijke grondslag) 1. Zorgleverancier verstuurt een informatieverzoek naar de dispatcher 2. De dispatcher raadpleegt de verwijsindex, hier krijgt de dispatcher toegang toe via de de gatekeeper. Deze valideert dat er een consent is voor het BSN van de cliënt voor de betreffende zorgverlener. Als deze niet bestaat maar de zorgpartij heeft wel een wettelijke grondslag, dan wordt er op basis van een template een consent toegevoegd (zgn. automated consent) 3. Uit de verwijsindex ontvangt de dispatcher de netwerkpartijen die informatie bezitten over de cliënt 4. Via de Station Directory haalt de Dispatcher de bijbehorende endpoints op 5. De dispatcher raadpleegt vervolgens de individuele s, de Gatekeeper toetst bij elk verzoek of er een consent bestaat Procesverloop raadplegen (handmatige consent) 1. Klant staat aan de balie 2. Scant QR code om zorgleverancier toegang te geven tot zijn gegevens bij andere netwerk partijen 3. Zorgleverancier verstuurt een informatieverzoek naar de dispatcher 4. De dispatcher raadpleegt de verwijsindex, hier krijgt de dispatcher toegang toe via de de gatekeeper. Deze valideert dat er een consent is voor het BSN van de cliënt voor de betreffende zorgverlener 5. Uit de verwijsindex ontvangt de dispatcher de netwerkpartijen die informatie bezitten over de cliënt 16

18 6. Via de Station Directory haalt de Dispatcher de bijbehorende endpoints op 7. De dispatcher raadpleegt vervolgens de individuele s, de Gatekeeper toetst bij elk verzoek of er een consent bestaat Abonneren Een partij kan zich abonneren op wijzigingen van een entiteit of een set van entiteiten. Bij het plaatsen van een abonnement wordt aangegeven om welk type abonnement het gaat. Afhankelijk van het type abonnement worden 1 of meerdere parameters meegegeven. Wanneer er een wijziging in de entiteit ontstaat, ontvangt de partij die het abonnement heeft ingesteld hier een notificatie van. Een succesvol geplaatst abonnement is direct actief. Een abonnee zal dus genotificeerd worden zodra de betreffende entiteit wijzigt. Een abonnement kan worden ingetrokken door een DELETE operatie uit te voeren op het abonnementid. 17

19 Procesverloop abonneren 1. Zorgleverancier verstuurt een abonnements verzoek via de API van het 2. De dispatcher raadpleegt indien nodig de Verwijsindex, hier krijgt de Dispatcher toegang toe via de de Autorisatie voorziening. Deze valideert dat er een consent is voor het BSN van de cliënt voor de betreffende zorgverlener. Als deze niet bestaat maar de zorgpartij heeft wel een wettelijke grondslag, dan wordt er op basis van een template een consent toegevoegd (zgn. automated consent) 3. Uit de verwijsindex ontvangt de Dispatcher de netwerkpartijen die informatie bezitten over de cliënt 4. Via de Station Directory haalt de Dispatcher de bijbehorende endpoints op 18

20 5. De Dispatcher stuurt vervolgens een abonnement verzoek naar de abonneer-service van de betreffende datastations 6. Het ontvangende persisteert het abonnement verzoek (abonnementtype + partij + parameters) en retourneert een abonnementid naar het vragende. 7. Vervolgens zet het ontvangende het abonnementid, abonnementtype en de parameters door naar de backoffice applicatie. Notificeren op abonnement Wanneer een entiteit wijzigt waar een abonnement op geplaatst is, moet er een notificatie gestuurd worden naar de partij die het abonnement heeft geplaatst. Afhankelijk van het soort wijziging (create, update, delete) wordt een notificatie van het type new, changed of deleted verstuurd door het. Notificaties worden reliable verstuurd in de vorm van een webservice bericht conform de edelivery standaard. Procesverloop Notificeren 1. Het backoffice systeem detecteert een wijziging in een gegeven waarop een abonnement is geplaatst 2. Het backoffice systeem meldt via de API van het dat er een notificatie is ontstaan op een specifiek abonnementid en om welk type notificatie het gaat 3. De Subscription handler van het zoekt de partij op die het abonnement heeft geplaatst en vraagt het endpoint op bij de Station Directory 4. Vervolgens wordt via het Message Access Point de notificatie naar het Message Access Point van het betreffende verzonden. 5. Het ontvangende zet de notificatie door naar het backoffice systeem 6. Het backoffice systeem bepaalt vervolgens hoe de notificatie verwerkt wordt en haalt indien nodig de nieuwe gegevens op via het proces Raadplegen. 19

21 (Terug)Melden Indien een partij een andere netwerkpartij spontaan ergens over wil informeren kan dit gedaan worden door een melding te versturen. Dit kan een reguliere spontane melding zijn, bijvoorbeeld een verzoek om dienstverlening te starten of een zogenaamde Terugmelding om een mogelijke fout in een bepaald gegeven te melden. Meldingen worden reliable (dwz verzekerd van aflevering) verstuurd in de vorm van een webservice bericht conform de edelivery standaard. Procesverloop melden 1. Een proces in de backoffice applicatie leidt tot het verzenden van een (terug)melding 2. Het bronsysteem stuurt een melding naar het via de API 3. Het Message Access Point van het zoekt het endpoint van de geadresseerde partij op bij de Station Directory 4. Vervolgens wordt via het Message Access Point de (terug)melding naar het Message Access Point van het betreffende verzonden. 5. Het ontvangende zet de (terug)melding door naar het backoffice systeem 6. Het backoffice systeem bepaalt vervolgens hoe de (terug)melding intern wordt afgehandeld. Statuscodes De REST-webservice maakt in beginsel gebruik van de standaard HTTP status codes om aan te geven of een request succesvol is uitgevoerd. Code Betekenis Toelichting 20

22 200 OK Alles werkt zoals het hoort 201 OK Nieuwe entiteit is aangemaakt, bijvoorbeeld een abonnement 204 OK De entiteit is succesvol verwijderd 400 Bad Request Het request was ongeldig of kon niet worden uitgevoerd 401 Unauthorized De organisatie heeft geen toegang tot deze dienst of gegevensset 403 Forbidden De organisatie heeft onvoldoende rechten om het request uit te voeren 404 Not Found De betreffende entiteit kan niet worden gevonden, bijvoorbeeld het opvragen van een indicatie met een onbekend indicatienummer 409 Conflict De betreffende entiteit bestaat al, bijvoorbeeld wanneer een abonnement reeds is aangemaakt Overzicht koppelvlakken Componenten van de technische basisstructuur zijn met elkaar verbonden door middel van koppelvlakken. De volgende koppelvlakken zullen als product door het actieprogramma worden opgeleverd. Naam Provider Consumer Naam service Functies Koppelvlak integratie services Backoffice applicatie service - raadplegen - abonneren - notificeren - melden - terugmelden Koppelvlak integratie services Bron applicatie Backend integration service - afleveren notificaties - afleveren meldingen - afleveren terugmeldingen Koppelvlak integratie services Bron applicatie Data Storage service - ophalen gegevens tbv raadpleging Koppelvlak Data Interaction service - raadplegen Koppelvlak Backoffice Messaging - notificeren 21

23 applicatie service - melden - terugmelden Koppelvlak Station Directory Station Directory Station Directory service - opvragen endpoints Koppelvlak Autorisatie Autorisatie voorziening Autorisatie service - Autorisatie Welke koppelvlakken voor een netwerk deelnemer relevant zijn is afhankelijk van de implementatiestrategie van de deelnemer. Wanneer gebruik wordt gemaakt van een losstaand dient de deelnemer het Koppelvlak integratie services te ondersteunen. Wanneer de deelnemer de functionaliteiten van het in het eigen systeem incorporeert dient met zelf aan te sluiten op het Koppelvlak Station Directory, Koppelvlak Autorisatie en het Koppelvlak. Wanneer deze implementatiestrategie wordt gekozen zal het primair systeem als Data Station gecertificeerd moeten worden voordat deelname aan het netwerk wordt toegestaan. 22