VERSIE: 17-05-2023 STATUS: definitief

Incrementele implementatie
Het iWlz-netwerkmodel wordt incrementeel geïmplementeerd aan de hand van het afsprakenstelsel iWlz-netwerkmodel. Het eerste deel dat wordt geïmplementeerd is het Indicatieregister, voor deze implementatiestap zijn de volgende onderdelen van dit artikel van toepassing:

  • Systeemrollen

    • Bronhouder CIZ

    • Afnemer alleen Zorgkantoren

    • Vertrouwensleverancier VECOZO (op basis van certificaten)

    • Bevoegde uitgever VECOZO (verklaringen over toegangsrechten op basis van JWT (link naar definitie))

    • Stelselbeheerder Zorginstituut

    • Operationeel netwerkbeheerder VECOZO

  • Applicatiecomponenten

    • Bronsysteem alleen Indicatieregister (CIZ)

    • Resource Server alleen Indicatieregister (CIZ)

    • Autorisatie Server (gecentraliseerd uitgevoerd door VECOZO)

    • Trust agent (alleen in de vorm van JWT’s die toegangsrechten bevatten)

    • Web services van Register (alleen raadplegen)

  • Technische specificaties (RFC’s)

    • RFC002 en RFC007

  • Dienstverleners

    • In deze stap is VECOZO de enige dienstverlener die een iWlz-datastation levert. Hiervoor maakt VECOZO gebruik van nID

    • VECOZO levert op basis van nID een iWlz-datastation aan CIZ en zorgkantoren

Inleiding
In dit artikel worden de applicatiecomponenten in het iWlz-netwerkmodel beschreven. Hiermee wordt concreet gemaakt welke generieke afspraken voor de applicatiecomponenten in het iWlz-netwerkmodel van toepassing zijn. De volgende onderwerpen komen hierbij aan bod:

  1. Systeemrollen

  2. Applicatiecomponenten

  3. Technische specificaties

  4. iWlz-datastation

  5. Dienstverleners

De kenmerken die specifiek zijn voor een bepaald register/uitwisselprofiel worden niet in dit artikel maar in de blauwe laag ‘Uitwisselprofielen/registers’ beschreven (zie lagenmodel Afsprakenstelsel).

1. Systeemrollen

Het op een veilige en betrouwbare manier uitwisselen van iWlz-gegevens met behulp van registers stelt eisen aan de structuur van het iWlz-netwerkmodel. Deze eisen zijn, zoals eerder aangegeven in artikel Rollen en deelnemers, gekoppeld aan de DIZRA-systeemrollen. De DIZRA-systeemrollen zijn in het artikel Architectuur gegroepeerd in de volgende bouwstenen:

  • Primaire systeemrollen

    • Bronhouder Indicatieregister

    • Afnemer Indicatieregister

    • Gegevensregisseur

    • Gezondheidsregisseur

  • Vertrouwen

    • Vertrouwensleverancier Indicatieregister

    • Ledenadministratie Indicatieregister

    • Bevoegde uitgever van verklaringen Indicatieregister

  • Vindbaarheid

    • Gegevensgids

  • Beheer

    • Stelselbeheerder Indicatieregister

    • Operationeel netwerkbeheerder Indicatieregister

    • Verzekeraar betrouwbaarheid

In het onderstaande figuur zijn de registers, bouwstenen en systeemrollen schematisch weergegeven.

Overzicht bouwstenen en systeemrollen

De functionele uitwerking van deze bouwstenen en systeemrollen is opgenomen in het artikel Architectuur. Een gedetailleerde beschrijving van de systeemrollen is opgenomen in het artikel Rollen en deelnemers.

De systeemrollen geven inzicht in de verschillende verantwoordelijkheden maar beschrijven niet op welke wijze deze verantwoordelijkheden technisch worden gerealiseerd. In de volgende paragraaf worden de applicatiecomponenten beschreven.

1.1 Systeemrollen Implementatiestap Indicatieregister Indicatieregister

In de implementatiestap Indicatieregister wordt een deel van de systeemrollen ingevuld. De invulling is hieronder weergegeven.

Invulling bouwstenen en systeemrollen in implementatiestap Indicatieregister

2. De applicatiecomponenten

Het technisch realiseren van de verantwoordelijkheden van een systeemrol vindt plaats met behulp van applicatiecomponenten. Hieronder wordt weergegeven welke applicatiecomponenten nodig zijn. Hierbij worden alleen de applicatiecomponenten uitgewerkt die specifiek zijn voor het iWlz-netwerkmodel. Generieke functies zoals Lokalisatievoorziening en Adresboek worden wel genoemd maar worden niet nader uitgewerkt in applicatiecomponenten.

In de onderstaande tabel worden de applicatiecomponenten toegelicht. In de toelichting worden voor ieder applicatiecomponent de relevante capabilities opgesomd. Capabilities zijn algemene eigenschappen die applicatiecomponenten nodig hebben om veilige en betrouwbare gegevensuitwisseling tussen de deelnemers aan het iWlz-netwerkmodel mogelijk te maken. De capabilities zijn niet specifiek voor het iWlz-netwerkmodel.

Systeemrol

Applicatie-component

Toelichting

Systeemrol

Applicatie-component

Toelichting

Bronhouder & Bevoegde uitgever

Bronsysteem Indicatieregister

Het backofficesysteem van de bronhouder.

Capabilities: mTLS, OpenAPI, Activity log

Resource Server Indicatieregister

De Resource Server (RS) zorgt ervoor dat de gegevens uit het bronsysteem in het juiste format (bijv. GraphQL) worden aangeboden.

Capabilities: GraphQL, AAA Proxy, Subscriptions, OpenAPI, Activity log

Wallet

Het applicatiecomponent dat zorgt voor de opslag en het beheer van attesten

Capabilities: Wallet, Verifiable Credentials, OpenAPI, Activity log

Autorisatie Server Indicatieregister

De Autorisatie Server (AS) wordt ingezet voor het uitdelen en aanvragen van toegangsrechten en het controleren van binnenkomende (gegevens)verzoeken.

Capabilities: LUA script, OAuth Server, OpenAPI, Activity log

Trust agent

Het applicatiecomponent dat zorgt voor het uitgeven en verifiëren van attesten.

Capabilities: Key store, JOSE, Decentralized Identifiers, Verifiable Credentials, OpenAPI, Activity log

Web services van Register Indicatieregister

De module die ervoor zorgt dat de diensten van de bronhouder benaderbaar zijn

Capabilities: mTLS, OAuth client, OpenAPI, Activity log

Afnemer

Web services van Afnemer Indicatieregister

De module die ervoor zorgt dat de diensten van de afnemer benaderbaar zijn

Capabilities: mTLS, OAuth client, OpenAPI, Activity log

Trust agent

Het applicatiecomponent dat zorgt voor het presenteren van attesten

Capabilities: Key store, JOSE, Decentralized Identifiers, Verifiable Credentials, OpenAPI, Activity log

Autorisatie Server Indicatieregister

De Autorisatie Server (AS) wordt ingezet voor het aanvragen en uitdelen van toegangsrechten en het controleren van binnenkomende (gegevens)verzoeken

Capabilities: LUA script, OAuth Server, OpenAPI, Activity log

Wallet

Het applicatiecomponent dat zorgt voor de opslag en het beheer van attesten

Capabilities: Wallet, Verifiable Credentials, OpenAPI, Activity log

Resource Server Indicatieregister

De Resource Server (RS) zorgt ervoor dat opgehaalde gegevens in een bepaald gestandaardiseerd formaat (bijv. GraphQL) kunnen worden opgeslagen in het doelsysteem

Capabilities: GraphQL, AAA Proxy, Subscriptions, OpenAPI, Activity log

Doelsysteem Indicatieregister

Het backofficesysteem van de afnemer

Capabilities: mTLS, OpenAPI, Activity log

Hieronder worden de generieke functies toegelicht.

Systeemrol

Generieke functie

Toelichting

Systeemrol

Generieke functie

Toelichting

Gegevensgids

Lokalisatievoorziening

Generieke functie waarin voor specifieke gegevens (bijv. het bsn van een cliënt) kan worden opgezocht welke deelnemers bronhouder zijn

Capabilities: OpenAPI, Activity log

Adresboek

Generieke functie waarin de technische adressen van diensten van deelnemers kunnen worden opgezocht.

Capabilities: Decentralized Identifiers, OpenAPI, Activity log

Vertrouwens-leverancier

Vertrouwens-leverancier Indicatieregister

Generieke functie die, door het uitdelen en beheren van digitale sleutelparen, ervoor zorgt dat iedere deelnemer beschikt over een digitale identiteit

Capabilities: PKI, Decentralised Identifiers, OpenAPI, Activity log

 

2.1 Applicatiecomponenten Implementatiestap Indicatieregister Indicatieregister

3. Technische specificaties (RFC’s)

Om tot veilige en betrouwbare gegevensuitwisseling te komen is het belangrijk dat er eenduidigheid bestaat over de technische werking van de verschillende applicatiecomponenten. De technische specificaties waaraan de verschillende applicatiecomponenten dienen te voldoen, zijn beschreven in RFC’s. Vanuit het afsprakenstelsel iWlz-netwerkmodel wordt waar relevant naar specifieke RFC’s verwezen. Het artikel RFC's iWlz-netwerkmodel bevat een overzicht van de RFC’s.

4. iWlz-datastation

De verzameling applicatiecomponenten die deelnemers aan het iWlz-netwerkmodel nodig hebben, wordt het “iWlz-datastation“ genoemd. Iedere deelnemer aan het iWlz-netwerkmodel beschikt over een iWlz-datastation. De deelnemers aan het iWlz-netwerkmodel wisselen via hun iWlz-datastation gegevens met elkaar uit. De iWlz-datastations communiceren op een veilige en betrouwbare manier met elkaar via het internet. In onderstaand figuur wordt dit weergegeven. Iedere deelnemer aan het iWlz-netwerkmodel heeft een netwerkpunt, dit netwerkpunt bestaat uit het bronsysteem (BS) en een data station (DS).

4.1 iWlz-datastation Implementatiestap Indicatieregister Indicatieregister

5. Dienstverleners

Deelnemers zijn eindverantwoordelijk voor de invulling van het iWlz-datastation conform het Afsprakenstelsel iWLz-netwerkmodel. Deelnemers kunnen voor de invulling van het iWlz-datastation diensten afnemen van een of meerdere dienstverleners (in lijn met randvoorwaarde R01 en ontwerpkeuze O04).

Een dienst voor de invulling van het iWlz-datastation wordt ook wel DaaS (Datastation-as-a-Service) genoemd. Een dienstverlener die een iWlz-datastation levert wordt ook wel een DaaS-leverancier genoemd.

De koppeling tussen het iWlz-datastation en het bronsysteem wordt niet gestandaardiseerd in het afsprakenstelsel iWlz-netwerkmodel en kan onderling tussen de deelnemer en de dienstverlener worden afgestemd.

In dit artikel is beschreven welke applicatiecomponenten nodig zijn voor het iWlz-netwerkmodel. In het volgende artikel wordt de technische uitwerking van de verschillende diensten in het iWlz-netwerkmodel uitgewerkt. Hierbij vormen de applicatiecomponenten de actoren.

5.1 Dienstverleners Implementatiestap Indicatieregister Indicatieregister