Model voor
stelselregie
Versie 6.4 | 25 juli 2022

Voorwoord
Nictiz heeft dit rapport opgesteld in afstemming met het ministerie van Volksgezondheid Welzijn
en Sport. Het is onderdeel van de voorbereidingen die Nictiz doet, om de mogelijk toekomstige
taak als Stelselbeheerder goed te kunnen invullen.
In dit document beschrijven we een model voor stelselregie, inclusief een tweetal casussen in de
bijlagen. Dit model is tot stand gekomen met NEN 7522:2021 als belangrijkste basis, maar het
beschrijft zaken als producten en processen op stelselniveau ook nog uitgebreider dan NEN
7522:2021. Daarnaast geven we met dit document een mogelijk concrete invulling van het stelsel
(hoofdstuk 5).
We hebben diverse discussies gevoerd, zowel met het ministerie van Volksgezondheid Welzijn en
Sport als intern bij Nictiz, bijvoorbeeld in de bespreking met het Architectuurteam van Nictiz.
Daaruit bleek dat er op bepaalde onderwerpen behoefte is aan nadere aanscherping en
precisering. Deze onderwerpen hebben we benoemd in een extra paragraaf: 1.9 De complexiteit
van stelselregie.
Je zou dus kunnen zeggen dat dit document (Model voor stelselregie ) aanvulling en
aanscherping behoeft. Er is echter een groot belang om een daadwerkelijke en snelle start te
maken met stelselregie en de concrete invulling daarvan. En om tegelijkertijd een periode (van
drie jaar?) in te bouwen van ervaring opdoen, samen met relevante stakeholders. Op deze manier
kunnen we de inrichting en werking van stelselregie optimaliseren en onderwerpen, zoals in
paragraaf 1.9 benoemd, vanuit een praktijkervaring aanscherpen. We zoeken met andere
woorden een goed evenwicht tussen ‘met de voeten in de klei’ (daadwerkelijke praktijkervaring)
en ‘met het hoofd in de wolken’ (alle aspecten van stelselregie scherp in beeld en op waarde
geschat).
Het organiseren van stelselregie, wat in zichzelf top-down is, moet gecombineerd worden met het
organiseren van bestuurlijk commitment van veldpartijen binnen het stelsel. Daarbij is het
daadwerkelijk starten en ervaring opdoen met stelselregie, gebaseerd op dit document,
belangrijk.

Inhoud
Managementsamenvatting

1
1.1
1.2
1.3
1.4
1.5
1.6
1.7
1.8
1.9
1.10
1.11

Inleiding
Aanleiding 7
Begrippenkader 7
Afhankelijkheden door het uitwisselen van informatie 9
Behoefte aan samenhang 10
Stelsel van standaarden 11
Definitie van stelselregie 12
Doel van stelselregie 12
Visie op stelselregie 13
De complexiteit van stelselregie 14
Governance 14
Een blik in de toekomst 15

2
2.1
2.2
2.3
2.4
2.5
2.6

Beschrijving van stelselregie
Inleiding 17
Stelsel - verzameling standaarden 17
Samenhang door gezamenlijke afspraken 18
Rol van stelselarchitectuur 19
Reikwijdte van het stelsel 20
Ontwikkeling van het stelsel 22

3
3.1
3.2
3.3
3.4
3.5
3.6
3.7

Processen en producten
Inleiding 25
Opnemen, wijzigen en uitfaseren van een standaard 25
Wijzigen standaard 26
Opstellen en onderhouden meerjarenstrategie 26
Onderhouden stelselcatalogus 27
Vaststellen en onderhouden stelselarchitectuur 27
Vaststellen en onderhouden kaders 28

3.8
3.9
3.10
3.11

Vaststellen en onderhouden roadmap en releasekalender 28
Monitoren adoptiegraad en besluiten 28
Opstellen stakeholderanalyse 29
Samenhang processen en producten 29

4
4.1
4.2
4.3
4.4
4.5
4.6
4.7
4.8
4.9

Governance
Inleiding 31
Stakeholders 31
Rollen in NEN 7522 32
Rolverdeling bij individuele standaarden 32
Rolverdeling bij stelselregie 33
Besluitvorming 36
Taken en verantwoordelijkheden stelselhouder 37
Taken en verantwoordelijkheden stelselautorisator 38
Taken en verantwoordelijkheden stelselbeheerder 39

5
5.1
5.2
5.3
5.4
5.5
5.6

Concrete invulling van het stelsel
(Tijdelijke) invulling van de stelselrollen voor periode van drie jaar 41
Uitgangspunten en toelatingscriteria 42
Stelselproducten 42
Stelselarchitectuur 43
Afbakening van het stelsel 43
Overleggen en vergaderingen 44

6

Slotoverwegingen ten aanzien van operationalisering

Casus zorginformatie-bouwstenen (zibs)
Casus CDA versus FHIR

Auteurs: Paul Deurvorst (PBLQ), Fred Smeele (Nictiz), Mischa Tol (Nictiz), in afstemming met VWS

Managementsamenvatting
Nictiz heeft dit rapport opgesteld in afstemming met het ministerie van VWS. Het rapport
beschrijft de aspecten van stelselregie, zoals de noodzaak van stelselregie, de producten en
processen op het niveau van stelselregie en de rol van een stelselarchitectuur. Daarnaast
beschrijft dit rapport de governance van stelselregie en dan met name de relatie met de
governance van het beheer van individuele standaarden en de taken en verantwoordelijkheden
van de belangrijkste rollen op stelselniveau: de stelselhouder en de stelselbeheerder. De in 2021
gepubliceerde norm voor het beheer van individuele standaarden en een stelsel van standaarden
(NEN 7522) vormt daarbij de basis.
Ook geven we een voorstel voor een concrete invulling van het stelsel als startmodel.
De belangrijkste boodschappen in dit rapport zijn:
1.
Het is van groot belang om een daadwerkelijke en snelle start te maken met stelselregie,
volgens een ‘groeimodel’.
2.
De inrichting van stelselregie moet ook het monitoren van de opvolging van
stelselbesluiten omvatten. Datzelfde geldt voor het organiseren van financiering, die als
gevolg van stelselbesluiten noodzakelijk is.
3.
Stelselregie komt niet in plaats van het beheer van individuele standaarden, maar voegt
een overkoepelende regie toe.
4.
Het organiseren van bestuurlijk commitment van veldpartijen binnen het stelsel is
essentieel voor het welslagen van het stelsel.
5.
Een belangrijke succesfactor is het vinden van het juiste evenwicht tussen een topdown-aanpak (‘de stelselhouder bepaalt’) en een bottom-up-aanpak (‘commitment van
veldpartijen’).
Tot slot illustreren we in de bijlagen hoe stelselregie werkt in de praktijk aan de hand van een
tweetal casussen.

Model voor stelselregie

1
Inleiding

6

Model voor stelselregie

1.1 Aanleiding

Met het voorstel voor de Wet elektronische gegevensuitwisseling in de zorg (Wegiz) en met de
publicatie van de European Health Data Space (EHDS), gaan standaarden voor de uitwisseling van
informatie een steeds prominentere rol spelen bij het elektronisch uitwisselen van gegevens door
zorgverleners. Dat geldt niet alleen voor de specifieke uitwisselingen die bij de Wegiz worden
geregeld, maar voor alle informatie-uitwisselingen in de zorg. De minister van VWS heeft in de
kamerbrief van 15 oktober 2021 aangeven dat de standaarden ‘in samenhang beheerd en
doorontwikkeld worden’ en laat momenteel de organisatie daarvan onderzoeken. Een van de
vraagstukken daarbij is wat verstaan wordt onder die samenhang. Dit wordt aangeduid met de
begrippen stelsel van standaarden en stelselregie.
Dit document beschrijft wat we onder stelselregie verstaan, welke processen en producten
stelselregie omvat en welke rollen, taken, verantwoordelijkheden en bevoegdheden daaraan zijn
gekoppeld.

1.2 Begrippenkader

Om het begrip stelselregie te kunnen duiden is een eenduidig begrippenkader van groot belang.
Vertrekpunt daarvoor zijn de NEN 7522:2021 norm voor het beheer van (stelsels van) standaarden
in de zorg en de publicatie Informatietandaarden 1 van Nictiz.
Deze laatste begint met de constatering dat er een groot aantal initiatieven en activiteiten ontwikkelingen - bestaat om de uitwisseling van medische gegevens tussen zorgverleners
onderling en tussen zorgverleners en patiënten mogelijk te maken en op te schalen. Deze
ontwikkelingen resulteren in verzamelingen van afspraken tussen partijen op de verschillende
lagen van het interoperabiliteitsmodel voor de uitwisseling van informatie in de zorg (het
‘lagenmodel’).
Het begrip stelselregie gaat over de samenhang tussen de afspraken op de verschillende lagen
van het interoperabiliteitsmodel. Om de aard en de noodzaak van die samenhang te duiden,
vatten we eerst samen wat we verstaan onder standaarden, wat het onderscheid is tussen
usecase-standaarden en generieke standaarden en wat we verstaan onder het beheer en de
implementatie van standaarden.
― Standaarden
Het Forum Standaardisatie, dat de publieke sector adviseert over het gebruik van ICTstandaarden, hanteert als definitie 2:

1

Informatiestandaarden: basis voor gegevensuitwisseling in de zorg, Nictiz, 8 september 2020

2

https://www.forumstandaardisatie.nl/open-standaarden/wat-zijn-open-standaarden

7

Model voor stelselregie

Een standaard is een afspraak over informatie of een proces. Als computersystemen
gegevens uitwisselen, dan moeten zij die afspraken of processen hanteren.
NB: Binnen deze definitie zijn twee niveaus van standaarden te onderscheiden; de
inhoudelijke specificatie van de standaard en een afspraak over het gebruik van de
specificaties. In dit document wordt met standaarden verwezen naar de inhoudelijke
specificaties.

Het toepassen van standaarden zorgt in het algemeen voor tijdsbesparing,
kwaliteitsverbetering en kennisborging, maar conformatie aan standaarden betekent soms
ook vermindering van flexibiliteit. Standaardisatie van informatie-uitwisseling in de zorg
betekent dat de betrokken veldpartijen (verzamelingen van zorgaanbieders) en hun
leveranciers niet steeds opnieuw afspraken hoeven te maken.
― Usecase--(specifieke) standaarden
Een usecase-standaard is een verzameling afspraken over alle lagen voor een specifieke
situatie in het zorgdomein. Een usecase-standaard in het zorgdomein heeft betrekking op
registratie, hergebruik en uitwisseling van informatie. Een usecase-standaard kan informatieuitwisseling betreffen tussen zorgaanbieders van één specifieke veldpartij (bijvoorbeeld
tussen huisartsen onderling), of informatie-uitwisseling tussen zorgaanbieders van
verschillende veldpartijen (bijvoorbeeld tussen ziekenhuizen en huisartsen). Dit is
geïllustreerd in figuur 1.
Partij B

Partij A
Use case standaard A

Use case standaard C

Use case standaard B

Organisatiebeleid

Organisatiebeleid

Organisatiebeleid

Zorgproces

Zorgproces

Zorgproces

Informatie

Informatie

Informatie

Applicatie

Applicatie

Applicatie

IT-infrastructuur

IT-infrastructuur

IT-infrastructuur

Figuur 1 - Usecase-standaard

Een usecase-standaard kan ook informatie-uitwisseling betreffen die ondersteunend is voor
het directe zorgproces, zoals informatie-uitwisseling ten dienste van kwaliteitsverbetering of
een bevolkingsonderzoek.
― Generieke standaarden
Een generieke standaard is een gemeenschappelijke afspraak voor een (deel van een)
specifieke laag uit het lagenmodel voor een aantal usecase-standaarden(zie figuur 2).
Voorbeelden hiervan zijn zibs voor de informatielaag en HL7 CDA/HL7 FHIR voor de

8

Model voor stelselregie

applicatielaag. Feitelijk is op lagenniveau sprake van ‘standaardoverstijgende
standaardisatie’. Dit vergt per usecase-standaard een puntafspraak om de betreffende
generieke standaard toe te passen.

UC 1

UC 2

UC …

Punt
afspraak

Punt
afspraak

Punt
afspraak

Generieke standaard

Figuur 2 - Generieke standaard

― Beheer van standaarden
Het beheer van standaarden in de zorg is beschreven in de NEN 7522 standaard. De
eindverantwoordelijke partij is de houder van de standaard.
― Implementatie en adoptie
Standaarden hebben pas waarde als ze worden toegepast. Voor een goede toepassing zijn
afspraken nodig over de wijze en het tempo van de implementatie. De adoptiegraad is de
mate waarin een standaard wordt toegepast.

1.3 Afhankelijkheden door het uitwisselen van
informatie

De afgelopen jaren is in het zorgdomein een groot aantal standaarden ontwikkeld, zowel usecasespecifiek, als generiek op het niveau van individuele lagen.
De toenemende behoefte aan informatie-uitwisseling tussen verschillende veldpartijen leidt tot
informatieketens en informatienetwerken waarbij meerdere veldpartijen zijn betrokken en
veldpartijen als knooppunt deel uitmaken van meerdere ketens. Dit is geïllustreerd in figuur 3.
D

F

A

E

B

standaard
organisatie
informatiestroom

Figuur 3 - Informatieketens en knooppunten

C

G

9

Model voor stelselregie

1.4 Behoefte aan samenhang
Tot nu toe is de heersende gedachte dat je het ontwikkelen van standaarden het beste kunt
overlaten aan het veld (de ‘markt’). Er is nauwelijks sprake van centrale regie.
Dat kan leiden tot suboptimale keuzes. Dit is geïllustreerd met het onderstaande voorbeeld.

Twee veldpartijen A en B hebben elk een eigen usecase-specifieke standaard
gedefinieerd: UCS A en UCS B. In UCS A wordt op laag X ervoor gekozen om
generieke standaard GS1 toe te passen; in UCB wordt ervoor gekozen om
generieke standaard GS2 toe te passen. Dit is geïllustreerd in figuur 4.

A

B

X: GS1
UCS A

X: GS2
UCS B

Figuur 4 - Verschillende versies van een generieke standaard - geen samenhang

Deze keuzes - puntafspraken - hebben geen consequenties omdat er geen
sprake is van informatie-uitwisseling tussen A en B.
De situatie verandert als een nieuwe usecase-standaard wordt gebruikt voor de
onderlinge uitwisseling van informatie. Dit geldt met name voor de drie
onderste lagen van het lagenmodel: op informatie-, applicatie- en
infrastructuurniveau. Dit is geïllustreerd in figuur 5.

A

X: GS?

X: GS1
UCS A

UCS AB

B

X: GS2
UCS B

Figuur 5 - Verschillende versies van een generieke standaard - wel samenhang

Op laag X bestaat nu de keuze tussen GS1 of GS2. Bij keuze voor GS1 moet
veldpartij B zijn systeem aanpassen, bij keuze voor GS2 moet veldpartij A zijn
systeem aanpassen.

De vrijheid voor A en B om in het verleden op laag X verschillende keuzes te maken belemmert
het uitwisselen van informatie. 3 Vanuit een zorgbreed perspectief zijn verschillende keuzes
suboptimaal. Het naast elkaar bestaan van verschillende (versies van) generieke standaarden is
ongewenst om de volgende redenen:
3

Zie bijlage 1 voor een concreet voorbeeld (verschillende versies van zibs)

10

Model voor stelselregie

―
―

Het is ineffectief als bij informatie-uitwisseling informatieverlies optreedt, bijvoorbeeld door
het hanteren van verschillende informatiemodellen en/of terminologie.
Het is inefficiënt als leveranciers verschillende uitwisselingsstandaarden naast elkaar in één
systeem moeten implementeren. Die vertaalt zich in toenemende zorgkosten.

Beide situaties zijn maatschappelijk ongewenst. Er is dus behoefte aan meer samenhang tussen
standaarden. Een stelsel van standaarden beoogt die samenhang te organiseren. Een van de
mogelijkheden daarbij is het verdergaand toepassen van generieke standaarden per laag van het
interoperabiliteitsmodel.

1.5 Stelsel van standaarden
Samenhang ontstaat bijvoorbeeld als houders van usecase-standaarden gezamenlijk afspraken
maken over het toepassen van - dezelfde versie van - een generieke standaard. Dit vergt regie bij
de ontwikkeling van usecase-standaarden. Dat betekent niet dat usecase-standaarden centraal
moeten worden ontwikkeld, maar dat op cruciale punten gezamenlijke afspraken worden
gemaakt over het toepassen van dezelfde generieke standaard. Overigens blijft de individuele
standaardhouder verantwoordelijk voor de strategie en (door)ontwikkeling van zijn standaard.
Overkoepelende afspraken over implementatie van standaarden of over registratie van informatie
in het zorgproces kunnen ook samenhang bevorderen.
Een stelsel van standaarden is een verzameling standaarden waarover gezamenlijke afspraken
worden gemaakt. Die gezamenlijke afspraken kunnen ook betrekking hebben op bijvoorbeeld
financiering van implementatie van standaarden. Het tot stand laten komen van deze afspraken
noemen we stelselregie. Een randvoorwaarde hiervoor is dat het houderschap van standaarden is
belegd bij standaardhouders, die eindverantwoordelijk zijn voor de standaard. In de praktijk is
het houderschap van standaarden niet in alle gevallen belegd.
Het maken van gezamenlijke afspraken impliceert dat de houders van standaarden (zowel de
usecase-standaarden als de generieke standaarden) moeten samenwerken. Dat gebeurt onder
regie van een stelselhouder die verantwoordelijk is voor de ontwikkeling en het beheer van het
stelsel.
Standaardhouders en stelselhouder samen worden aangeduid als de deelnemers
aan het stelsel.

11

Model voor stelselregie

1.6 Definitie van stelselregie
Stelselregie beschrijft welke processen en producten op stelselniveau nodig zijn om te bereiken
dat het beheer van standaarden zodanig wordt ingericht dat het bijdraagt aan een effectievere en
efficiëntere uitwisseling van informatie.
Stelselregie omvat het samenspel tussen standaardhouders en stelselhouder in de
vorm van processen, producten en governance.
NB Het zwaartepunt van het samenspel ligt bij standaardhouders en stelselhouder.
De overige rollen, zoals met name gebruikers en eindgebruikers conform NEN 7522,
zijn ook betrokken.
Een belangrijk aspect van de regietaak is het zoveel mogelijk harmoniseren van generieke
standaarden. Dit heeft betrekking op zowel inhoudelijke verschillen (bijvoorbeeld CDA versus FHIR
bij gegevensuitwisseling) 4, als op versieverschillen in dezelfde generieke standaard (bijvoorbeeld
publicatieversies van zibs bij informatiemodellen.
Een belangrijk onderdeel van de regietaak is de planning van het invoeren van nieuwe versies en
het uitfaseren van oude versies van standaarden. Het bestaan van meerdere versies zorgt
weliswaar voor flexibiliteit bij de overgang naar een nieuwe versie, maar betekent extra kosten bij
het onderhoud van systemen.
Gezamenlijke afspraken over een langetermijnplanning voor de ontwikkeling van generieke
standaarden zorgen voor duidelijkheid naar houders van usecase-standaarden, naar
zorgaanbieders en naar leveranciers.

1.7 Doel van stelselregie
Conform NEN 7522 heeft stelselregie de volgende doelen:
— Aantoonbare bruikbaarheid (voor gebruikers en eindgebruikers) van de standaarden die
tot het stelsel behoren.
— Compatibiliteit van standaarden ten behoeve van interoperabiliteit.
— Draagvlak onder gebruikers en eindgebruikers van de standaarden die tot het stelsel
behoren.
— Implementeerbaarheid bij gebruikers en eindgebruikers van de standaarden die tot het
stelsel behoren.
— Implementeerbaarheid bij leveranciers van de standaarden die tot het stelsel behoren.
— Kwaliteit van standaarden en de samenhang hiertussen.
In dit document (Model voor stelselregie) vatten we deze subdoelen vanuit NEN 7522 als volgt
samen: stelselregie heeft tot doel om de samenhang tussen en het effectief gebruik van
standaarden te bevorderen ten behoeve van optimale informatie-uitwisseling in de zorg. De regie

4

Zie bijlage 2 voor de uitwerking van de concrete casus CDA versus FHIR

12

Model voor stelselregie

beoogt het commitment en de actieve participatie van alle deelnemers aan het stelsel te
vergroten.
Daarbij bestaat een spanningsveld tussen het gevestigde belang van veldpartijen die een
generieke standaard hebben geïmplementeerd en het belang van veldpartijen die om medische
of technische redenen deze standaard willen vernieuwen. De essentie is om op een zodanige
wijze samen te werken dat het gemeenschappelijk - zorgbrede - belang prevaleert boven het
belang van de individuele houders van standaarden.
Je zou dus kunnen zeggen dat een belangrijk doel van stelselregie is om relevante veldpartijen te
laten samenwerken, bij elkaar te brengen en zich te laten binden (committeren) aan het stelsel.
Het stelsel zou een instrumentarium moeten bieden om gemeenschappelijke regie en
commitment tot stand te brengen.
Standaardiseren in de zorg veroorzaakt onvermijdelijk ook ‘pijn’ en lasten. Een ander doel van
stelselregie is dan ook om die lasten op het juiste niveau, namelijk het gemeenschappelijke
niveau van het stelsel, neer te leggen, te verdelen en af te wegen tegen de baten van dezelfde
standaardisatie.

1.8 Visie op stelselregie
Om het doel van stelselregie, zoals in paragraaf 1.6 beschreven, te bereiken, kan stelselregie op
meer dan één manier worden ingericht. Onderliggend daaraan is de visie over hoe het doel van
stelselregie voor informatievoorziening in de zorg in Nederland op de meest effectieve en
efficiënte manier bereikt kan worden. Hetzelfde doel kan immers op verschillende manieren
bereikt worden. Bijvoorbeeld op een sterk afdwingende manier (top-down) of juist meer bottomup.
Voor de inrichting van stelselregie is een ‘groeimodel’ nodig. Het denken in een stelsel en de
inrichting van stelselregie zijn nieuw in de zorg in Nederland, en zowel de inrichting als de visie
moeten zich ontwikkelen. Zo moet er zeker in de eerste fase ruimte zijn voor bijsturing en
veranderingen in zowel de inrichting van als de visie op stelselregie.
De belangrijkste observatie is dat enerzijds de tijd van vrijblijvendheid van veldpartijen in de
informatievoorziening in Nederland voorbij is, maar dat anderzijds een volledige top-downbenadering, met sturing en verplichting van bovenaf via bijvoorbeeld wetgeving, in de
Nederlandse situatie niet werkt. Wet- en regelgeving kan wel een belangrijk middel zijn om
veldpartijen te stimuleren en uiteindelijk te dwingen, maar dit werkt nooit als dit het enige
middel is. Consensus en het ervaren van een gemeenschappelijk belang bij het maken van
afspraken moet daaraan voorafgaan.
Dat betekent dat het organiseren van stelselregie, wat in zichzelf top-down is, gecombineerd
moet worden met het organiseren van bestuurlijk commitment van veldpartijen binnen het
stelsel.
Besluiten in het stelsel moeten dan ook het karakter hebben van (gevoeld worden als)
gezamenlijke besluiten van veldpartijen op bestuurlijk niveau.

13

Model voor stelselregie

1.9 De complexiteit van stelselregie
Om stelselregie effectief en efficiënt te laten werken is een goede balans essentieel tussen het
beleggen van doorzettingsmacht en verantwoordelijkheid binnen het stelsel en een optimaal
draagvlak bij relevante stakeholders.
Stelselregie is echter inherent complex. Om de genoemde effectiviteit en efficiëntie te bereiken is
duidelijkheid nodig op een aantal onderwerpen, zoals:
― Een duurzaam beheersbaar onderscheid én verband tussen generieke standaarden en
specifieke standaarden. Dat moet het stelsel een stevige architectuurbasis geven, beschreven
in de stelselarchitectuur. Zo’n architectuurbasis laat in voldoende scherpte zien welke
soorten standaarden aan de orde zijn in en om het stelsel, waarvoor welke soort precies wel
en niet wordt gebruikt, hoe de soorten zich tot elkaar verhouden, door welke soort
veldpartijen ze moeten worden toegepast, wie welke standaard beheert, et cetera.
― Een scherpe visie op de regie van het stelsel van standaarden en een werkbaar evenwicht
tussen een centraal/top-down benadering enerzijds, en een decentraal/bottom-up
benadering anderzijds.
― De manier waarop het stelsel van standaarden past in, respectievelijk bijdraagt aan, het
(duurzaam) zorginformatiestelsel. Dan gaat het bijvoorbeeld over de vraag hoe regie op het
stelsel van standaarden zich verhoudt tot regie op (het stelsel van) generieke voorzieningen.
― De manier waarop betrokkenen (relevante stakeholders) in en om het stelsel samenwerken
en overleggen, om het gewenste optimale draagvlak te creëren.
Naast de observatie dat stelselregie inherent complex is, zien we ook dat er zo goed als geen
ervaring is met hoe stelselregie effectief kan werken in de zorg in Nederland. En dat het belangrijk
is om hier ervaring mee op te doen. Op deze manier kunnen we onderwerpen, zoals hierboven
genoemd, vanuit een praktijkervaring nader beschrijven en invullen, en zo nodig aanscherpen of
aanpassen.

1.10 Governance
Door deel uit te maken van een stelsel en gemeenschappelijke afspraken te maken verschuift een
deel van de zeggenschap van de houders van standaarden naar een centraal niveau: naar de
houder van het stelsel van standaarden. Deze verdeling van rollen taken, verantwoordelijkheden
en bevoegdheden duiden we aan met stelselgovernance.
In de volgende hoofdstukken werken we verder uit:
—
—
—

wat de reikwijdte is van stelselregie: samenhang van standaarden door
gezamenlijke afspraken;
hoe vorm wordt gegeven aan stelselregie: producten en processen;
hoe de governance wordt geregeld: verdeling van rollen, taken en
bevoegdheden.

14

Model voor stelselregie

1.11 Een blik in de toekomst
Ten tijde van het schrijven van dit rapport is veel informatievoorziening in de zorg, en met name
de uitwisseling van informatie, gebaseerd op vooraf gemaakte afspraken. Bij de verwijzing van
een patiënt door de huisarts naar een medisch specialist is het bijvoorbeeld gebruikelijk dat de
huisarts de verwijzing aanvult met een verwijsbrief, met relevante medische informatie voor de
ontvanger. Hetzelfde geldt ook voor een verpleegkundige overdracht (eOverdracht): de
(verpleegkundige) overdracht van een patiënt van een ziekenhuis naar een verpleeghuis. Ook
hiervoor zijn afspraken over de informatievoorziening gemaakt, die in de informatiestandaard
eOverdracht gespecificeerd zijn. Op basis hiervan worden systemen gebouwd en
geïmplementeerd ter ondersteuning van die informatievoorziening.
Een andere manier om tegen de informatievoorziening in de zorg aan te kijken is dat we die zo
inrichten, dat een zorgverlener informatie opvraagt over zijn of haar patiënt op het moment dat
die informatie nodig en relevant is. Nieuwe technologieën, zoals het ontsluiten van
informatiesystemen in de zorg via het toepassen van zogenaamde (gestandaarde) API’s (een
‘Application Programming Interface’), brengen deze nieuwe manier van inrichten van de
informatievoorziening dichterbij.
Je zou kunnen spreken over een mogelijke paradigmaverschuiving: in plaats van afspraken vooraf
over informatie die beschikbaar moet zijn, veelal beschreven in informatiestandaarden, het
invullen van de informatiebehoefte ad hoc, real time en op het moment dat die
informatiebehoefte ontstaat. Deze paradigmaverschuiving kan en zal echter niet alleen
technologiegedreven zijn. Processen in de zorg, en de daarbij behorende afspraken, zullen ook
moeten worden aangepast. Want op dit moment is een medisch specialist in een ziekenhuis, die
een patiënt van een huisarts krijgt doorverwezen, gewend om in de verwijsbrief (of een bijlage
daarbij, al dan niet elektronisch) alle relevante medisch informatie van de patiënt te ontvangen.
Bij een paradigmaverschuiving, zoals hierboven beschreven, wordt dit (grotendeels) omgedraaid:
de medisch specialist bepaalt elke keer en op het juiste moment zelf welke informatie hij of zij
nodig heeft en vraagt dat real time en ad hoc op in het informatiesysteem van de huisarts.
De auteurs van dit rapport schatten in dat met deze paradigmaverschuiving een modernisering
van de informatievoorziening in de zorg in het verschiet ligt, maar schatten ook in dat er nog
enige tijd overheen zal gaan, voordat dit de oude werkwijze zal vervangen. Om die reden is een
van de uitgangspunten van dit rapport (Model voor stelselregie) de huidige situatie: de afspraken,
met de bijbehorende informatiestandaarden, die vooraf gemaakt zijn.
Tegelijkertijd is het van belang om vanuit stelselregie alle toekomstige ontwikkelingen, en dus
ook deze, in de strategie en ontwikkeling in het stelsel mee te nemen.

15

Model voor stelselregie

2
Beschrijving van
stelselregie

16

Model voor stelselregie

2.1 Inleiding

Stelselregie moet worden opgevat als de besturing van de samenhang van ontwikkeling en
beheer van standaarden, en een verzameling gezamenlijke afspraken over die standaarden.
Stelselregie gaat dus niet over het beheer van individuele standaarden. Een goed functionerende
stelselregie bevordert ook de implementatie en het gebruik van de samenhangende standaarden.

2.2 Stelsel - verzameling standaarden

Een stelsel van standaarden betekent dat onderscheid gemaakt kan worden tussen standaarden
die deel uitmaken van het stelsel en standaarden die buiten het stelsel vallen. Omdat die
verzameling niet statisch is, betekent dit ook dat standaarden opgenomen moeten kunnen
worden in het stelsel en ook moeten kunnen worden verwijderd. Standaarden kunnen immers
wijzigen. Uit oogpunt van beheer is het in het algemeen niet wenselijk dat er meerdere versies
van een standaard naast elkaar bestaan. Want daarmee wordt het doel van standaardisatie
ondergraven.
Stelselregie omvat processen voor het opnemen, wijzigen en verwijderen van
standaarden.
De standaarden die deel uitmaken van het stelsel nemen we op in een stelselcatalogus. Deze
catalogus zullen we periodiek aanpassen. Binnen de stelselcatalogus maken we onderscheid
tussen een catalogus van generieke standaarden en een catalogus van usecase-standaarden
(specifieke standaarden) 5.
Het opnemen van een standaard in de stelselcatalogus moet niet verward worden met het besluit
om een standaard te ontwikkelen. Op dit moment ligt de verantwoordelijkheid voor het
ontwikkelen van standaarden - met name usecase-standaarden - in het zorgveld. In de hiervoor
gehanteerde definitie van stelselregie ligt de nadruk op de toegevoegde waarde van een stelsel,
niet op het nut van standaardisatie in het algemeen en de bijdrage daarvan aan
beleidsdoelstellingen. Niettemin kan besloten worden om de stelselhouder een sturende rol te
geven bij de ontwikkeling van standaarden.
De basis voor het opnemen, wijzigen en verwijderen van standaarden is een stelselstrategie voor
het doorontwikkelen van de stelselcatalogus.
Stelselregie omvat een proces voor het opstellen van een meerjarenstrategie.

5

In de NEN 7522: 2021 standaard wordt dit de ‘portfolio van business use cases’ genoemd

17

Model voor stelselregie

Om te bepalen of een standaard kan worden opgenomen in het stelsel zal deze worden getoetst
aan toelatingscriteria met betrekking tot implementeerbaarheid, kwaliteit en vorm, bijvoorbeeld
conventies die worden gehanteerd om een standaard te beschrijven (‘het hoe’).
Stelselregie omvat processen voor kaderstelling en toezicht.

2.3 Samenhang door gezamenlijke afspraken
De samenhang in het stelsel wordt gevormd doordat de deelnemers gezamenlijk afspraken
maken, bijvoorbeeld over het toepassen van generieke standaarden.
Stelselregie omvat processen voor het maken van afspraken over het gezamenlijk
toepassen van generieke standaarden.
Houders van usecase-standaarden spreken daarmee af dezelfde versie van een generieke
standaard te hanteren. Dit is geïllustreerd met het onderstaande voorbeeld.

Binnen het stelsel gebruiken UC-standaard 1 en 2 op de informatielaag
generieke versie N van standaard X (b.v. zib-X, versie N). UC-standaard 3 en 4
gebruiken versie M. Vervolgens wordt op stelselniveau afgesproken om
voortaan versie N te hanteren. Als elders binnen het stelsel versie M niet wordt
gehanteerd, kan versie M worden verwijderd uit het stelsel.

UC 1

UC 2

UC 3

UC 4

Punt
afspraak

Punt
afspraak

Punt
afspraak

Punt
afspraak

Generieke standaard X, versie N

Punt
afspraak

Punt
afspraak

Generieke standaard X, versie M

Figuur 6 - Harmonisatie van versies van generieke standaarden

De essentie is dat er binnen het stelsel harmonisatie optreedt van puntafspraken. Houders van
standaarden en de houder van het stelsel spreken gezamenlijk af om dezelfde versie van een
generieke standaard X, versie N te implementeren en conformeren zich daaraan. Het tot stand

18

Model voor stelselregie

komen van een dergelijke afspraak is een stelselproces. Het totaal van deze gezamenlijke
afspraken wordt vastgelegd in een stelselarchitectuur.
De stelselarchitectuur beschrijft de samenhang tussen de standaarden in het
stelsel.

Het wil overigens niet zeggen dat de houder van het stelsel deze gemeenschappelijke afspraken
bepaalt en voorschrijft. Ook hoeft een versie van een generieke standaard niet stelselbreed te
worden toegepast.
Er kunnen goede redenen zijn om toch meerdere versies naast elkaar in stand te houden omdat
de baten van harmonisatie niet opwegen tegen de kosten. Dat betekent dat aan voorstellen voor
harmonisatie een impactanalyse met een vorm van een businesscase ten grondslag moet liggen.
Stelselregie omvat een proces voor het opstellen van impactanalyses om
afwegingen over het conformeren aan generieke standaarden te onderbouwen.
Het tot stand komen van deze voorstellen en het maken van afwegingen is een gezamenlijke
verantwoordelijkheid van de deelnemers aan het stelsel. De essentie is daarbij om een
compromis te vinden tussen de individuele belangen van de houders van individuele usecasestandaarden en het gemeenschappelijk belang van alle deelnemers. De houders van de generieke
standaarden zijn de primaire vertegenwoordigers van dit laatste.
Stelselregie gaat over wat de houders van usecase-standaarden bindt en behelst
een continue afweging van individuele en gemeenschappelijke belangen.

2.4 Rol van stelselarchitectuur
Zoals hiervoor aangegeven beschrijft de stelselarchitectuur de samenhang van de standaarden in
het stelsel en gaat daarbij onder andere in op twee belangrijke, samenhangende aspecten van de
werking van het stelsel:
1. De rol die generieke standaarden spelen.
2. Hoe we moeten omgaan met veranderingen in de tijd en verschillen in en tussen
zorgdomeinen.
Standaarden en een stelsel van standaarden hebben als hoofddoel om (her)gebruik van
informatie ten dienste van het zorgproces optimaal te ondersteunen. Interoperabiliteit in de
informatie-uitwisseling in de zorg is daarbij een belangrijke voorwaarde. Hoe de
informatievoorziening zodanig ingericht moet worden dat maximale interoperabiliteit wordt
bereikt is een informatiekundige uitdaging. Een belangrijk mechanisme daarbij zijn de generieke
standaarden die gelden voor de usecase-standaarden binnen het stelsel.

19

Model voor stelselregie

Een generieke standaard als de zorginformatiebouwstenen (de zibs) creëert Eenheid van Taal en
structuur over klinische concepten, zoals diagnoses en verrichtingen, en draagt daarmee
belangrijk bij aan interoperabiliteit. Tegelijkertijd moeten usecase-standaarden binnen het
stelsel, gebruikmakend van generieke standaarden, (her)gebruik van informatie ten dienste van
het zorgproces optimaal ondersteunen.
De stelselarchitectuur beschrijft hoe generieke standaarden optimaal bijdragen aan
interoperabiliteit. Daarbij is het van groot belang om goed te bepalen en te beschrijven wat
generiek is (moet zijn) binnen het stelsel en wat usecase-specifiek is (kan blijven). En aanvullend
daarop: hoe het onderscheid generiek/usecase-specifiek optimaal bij kan dragen aan de
gewenste regie enerzijds en de noodzakelijke dynamiek en variëteit anderzijds.
Standaarden (generieke standaarden en usecase-standaarden) zijn in de praktijk dynamisch; er
komen in de loop van de tijd nieuwe versies van de standaard uit. Ook zullen er noodzakelijke
verschillen zijn tussen zorgdomeinen, met name in de manier waarop partijen in die domeinen
generieke standaarden, zoals de zibs, gebruiken en toepassen.
De stelselarchitectuur beschrijft hoe binnen het stelsel wordt omgegaan met deze veranderingen
in de loop van de tijd en de verschillen tussen zorgdomeinen. Op deze manier is er enerzijds op
stelselniveau voldoende sprake van regie, en anderzijds kunnen de partijen in de zorgdomeinen
de usecase-standaarden optimaal toepassen.

2.5 Reikwijdte van het stelsel
Uitgangspunt voor de reikwijdte van het stelsel van standaarden is het duurzaam
informatiestelsel zorg (DIZ). Het informatiestelsel definiëren we als een stelsel van afspraken,
convenanten, standaarden en gegevenswoordenboeken voor het realiseren van veilige en
betrouwbare zorgbrede informatiestromen 6.

Opgemerkt dient te worden dat het DIZ niet alleen standaarden bevat, maar ook
met standaarden corresponderende (gemeenschappelijke) voorzieningen.
Sommige generieke standaarden vergen door hun aard een centrale, landelijke
implementatie, in de vorm van een generieke voorziening. In dat geval zijn
afspraken over het toepassen van die generieke standaard één-op-één gekoppeld
aan de implementatie van een generieke voorziening. Een voorbeeld daarvan is
de standaard voor adressering van zorgaanbieders en zorgverleners (noodzakelijk
als generieke functie voor elektronische gegevensuitwisseling), waarop een
gemeenschappelijk voorziening is gebaseerd: het Zorgaanbiedersadresboek
(ZAB). Hoewel dit soort generieke voorzieningen dus onlosmakelijk verbonden
zijn aan standaarden, maken de ontwikkeling en het beheer van deze
voorzieningen geen deel uit van het stelsel van standaarden. Daarmee is gelijk
gezegd hoe belangrijk het is de regie op het stelsel van standaarden en de regie op
(het stelsel van) generieke voorzieningen samenhangend vorm te geven.
6

Kaders voor een duurzaam informatiestelsel - deel 1 principes, Informatieberaad Zorg, 10 december 2018

20

Model voor stelselregie

Met dit uitgangspunt voor de reikwijdte (de scope) van het stelsel, is het zaak om op voorhand
geen (soorten) standaarden uit te sluiten, maar in eerste instantie de reikwijdte van het stelsel
breed te nemen.
Binnen de zorg is sprake van een groot aantal standaarden van uiteenlopende aard Het is daarom
zinvol te duiden in welke volgorde welk type standaarden deel uit gaan maken van het stelsel van
standaarden voor informatie-uitwisseling in de zorg. Hiermee kan ook een groeimodel voor het
stelsel worden ingericht: breed denken, maar smal beginnen (zie verder paragraaf 2.6). Globaal
genomen kunnen we in het zorgdomein onderscheid maken tussen de volgende soorten
standaarden die (deels) betrekking hebben op informatie:
A. Zorginhoudelijke kwaliteitsstandaarden
In een kwaliteitsstandaard (zoals een richtlijn, zorgstandaard, generieke module, etc.) staan
aanwijzingen voor zorgverleners over hoe zij goede zorg kunnen verlenen. Deze
kwaliteitsstandaarden zijn opgenomen in register van kwaliteitsstandaarden dat het
Zorginstituut Nederland beheert.
B. (Informatie)standaarden voor zorginhoudelijke processen
Deze standaarden beschrijven de uitwisseling en het hergebruik van zorginhoudelijke
informatie in de eerste, tweede en derde lijn voor zowel cure- als careprocessen tussen
zorgverleners onderling, als tussen zorgverleners en patiënt. Deze standaarden zijn
gebaseerd op kwaliteitsstandaarden vanuit de zorg (categorie A) én kwaliteitsstandaarden
vanuit de IT.
C. (Informatie)standaarden voor niet-zorginhoudelijke processen
Dit zijn standaarden voor processen op het gebied van onder andere financiën,
administratie 7, kwaliteitsverbetering en onderzoek.
Het stelsel van standaarden zoals beschreven in dit document richt zich in eerste instantie op
categorie B, maar kan uitgebreid worden met categorie C. Belangrijk hierbij is op te merken dat
als principe is gehanteerd om uit te gaan van informatie in het zorginhoudelijke proces. De
informatie die noodzakelijk is voor andersoortige processen (categorie C), moet worden afgeleid
van de informatie in het zorginhoudelijke proces. Dit principe is ook het hoofdprincipe van het
‘Registreren aan de Bron’.
Daarnaast is hergebruik van informatie binnen zorginhoudelijke processen een belangrijk doel
van standaarden. Informatie die (al) beschikbaar is bij de ene zorgverlener (bijvoorbeeld huisarts)
en relevant is voor het zorgproces bij een andere zorgverlener (bijvoorbeeld medisch specialist),
moet worden hergebruikt.
Zoals aangegeven maken we bij standaarden - conform NEN 7522 - onderscheid tussen usecasespecifieke standaarden en generieke standaarden.

7

Een voorbeeld zijn de i-Standaarden die gebruikt worden om informatie uit te wisselen in het kader van de

uitvoering van de wetten Wlz, Wmo en Jeugdwet

21

Model voor stelselregie

2.6 Ontwikkeling van het stelsel
Hoewel de samenstelling van de standaarden en de afspraken die tot het stelsel behoren niet
statisch zal zijn, is het voor de beeldvorming belangrijk om een inzicht te krijgen in de aard en
omvang van de standaarden die potentieel deel uit gaan maken van het stelsel. Daarom geven we
ter illustratie in tabel 1 een - niet uitputtend - overzicht van usecase-standaarden die momenteel
in aanmerking komen voor opname in het stelsel. Dit overzicht is gebaseerd op de al beschikbare
standaarden en de onderwerpen uit de meerjarenagenda van de Wegiz.
Usecase-standaarden
1
2
3
4
5
6
7
8
9
10
11
12
13

Uitwisseling medisch specialistische zorg - BgZ 8
Uitwisseling medisch specialistische zorg - beeld en verslag
Verpleegkundige overdracht (eOverdracht)
Medicatieoverdracht
Acute zorg
Informatiestandaarden t.b.v. uitwisseling met het PGO
Labuitwisseling
Huisartswaarneming (HWG)
Paramedische zorg
Geboortezorg
Jeugdgezondheidszorg
Gegevensuitwisseling in de oncologische zorg
Beelduitwisseling pathologie

Tabel 1 – Voorbeeld: overzicht usecase-standaarden

In tabel 2 geven we een overzicht van generieke standaarden die in aanmerking komen voor
opname in het stelsel.

8

Er moet onderscheid worden gemaakt tussen de BgZ als verzameling van gegevens (generieke standaard) en de

uitwisseling van BgZ gegevens tussen instellingen voor Medisch Specialistische Zorg (usecase-standaard).

22

Model voor stelselregie

1
2
3
4
5
6
7
8

Generieke standaarden

Laag interoperabiliteitsmodel

SNOMED CT
Zibs
Basisgegevensset Zorg (BgZ)
HL7 CDA
HL7 FHIR
Zorgaanbiedersadresboek
Standaarden binnen Twiin 9
DigiD 10

Informatie
Informatie
Informatie
Applicatie
Applicatie
Infrastructuur
Zie voetnoot
Zie voetnoot

Tabel 2 – Voorbeeld: overzicht generieke standaarden

Het lijkt verstandig om voor de opbouw van het stelsel een groeimodel te kiezen waarbij
gefaseerd standaarden worden toegevoegd aan het stelsel.
Een eerste versie van het stelsel zou kunnen bestaan uit een combinatie van de usecasestandaarden die bovenaan staan in de meerjarenagenda Wegiz 2021 (prioritaire standaarden) en
de generieke standaarden, die deze usecase-standaarden gebruiken en noodzakelijk zijn
hiervoor. In ieder geval de zibs omdat de zibs op informatieniveau het cement vormen van het
stelsel. Maar ook generieke standaarden als HL7 CDA, HL7 FHIR en SNOMED CT, die door de
genoemde prioritaire standaarden gebruikt worden naast de zibs.

9

Twinn is een afsprakenstelsel dat afspraken bevat over te gebruiken standaarden op de applicatie- en

infrastructuurlaag, bijvoorbeeld IHE XDS.
10

‘Informatiebeveiliging’ wordt in het lagenmodel niet weergegeven als een laag, maar als een verticale kolom.

DigiD is een voorbeeld van een generieke standaard op de verticale kolom Informatiebeveiliging.

23

Model voor stelselregie

3
Processen en
producten

24

Model voor stelselregie

3.1 Inleiding
Het kernproces van stelselregie is het beheer van een portfolio van standaarden. Omdat er een
continue ontwikkeling is van standaarden, is het stelsel een dynamisch geheel. Standaarden
zullen worden opgenomen in het stelsel, standaarden zullen wijzigen en uiteindelijk - aan het
einde van hun levenscyclus - worden verwijderd uit het stelsel. Dit is geïllustreerd in figuur 7.

Ontwikkelen
standaard

Opnemen in
stelsel

Wijzigen
standaard

Uitfaseren
standaard

Figuur 7 - Levenscyclus standaard

De eerste stap, het ontwikkelen van een standaard, vindt plaats onder regie van de houder van de
standaard. Het opnemen, wijzigen en verwijderen van standaarden zijn de primaire
stelselprocessen.
Daarnaast zijn er processen voor het ontwikkelen en onderhouden van een meerjarenstrategie,
toelatingscriteria, architectuur en stelselcatalogus.

3.2 Opnemen, wijzigen en uitfaseren van een
standaard
Dit proces bestaat uit drie fasen - intake, analyse en besluitvorming - en start met het aanmelden
van de standaard bij de beheerder van het stelsel.
Tijdens de intakefase levert de beheerder van de standaard de volgende informatie aan:
― Een beschrijving van de nieuwe standaard
De beschrijving van de standaard bestaat uit een functionele beschrijving en een technische
beschrijving waarbij elke laag uit het interoperabiliteitsmodel is gespecificeerd als het een
usecase-standaard betreft.
― Een impactanalyse met een businesscase voor het opnemen, wijzigen of uitfaseren van een
standaard. De impactanalyse beschrijft:
—
de toegevoegde waarde voor de zorg in termen van kwaliteitsverbetering en/of
kostenbesparing (de baten);
—
de impact op zorgverleners, zorgaanbieders en leveranciers in termen van
benodigde veranderingen en de daarvoor benodigde incidentele en structurele
middelen (de kosten);
—
de te vervullen randvoorwaarden en eventuele risico’s, bijvoorbeeld ten
aanzien van acceptatie en planning;
—
de impact op andere standaarden in het stelsel.
― Een implementatieplan
Het implementatieplan beschrijft globaal de migratiestrategie, fasering en planning voor de
beoogde invoering van de standaard in het stelsel en de eventuele uitfasering van (een)
eventueel bestaande standaard(en).
Tijdens de analysefase wordt de aangeleverde informatie over de standaard getoetst aan:

25

Model voor stelselregie

― Toelatingscriteria
Toetsing aan toelatingscriteria heeft tot doel vast te stellen in hoeverre:
—

—

de aangeleverde functionele en technische beschrijving kwalitatief voldoende is
uitgewerkt en is voldaan aan algemene eisen met betrekking tot vorm en
structuur;
de impactanalyse en het implementatieplan voldoende zijn uitgewerkt om een
besluit te kunnen nemen over toelating van de standaard.

― Stelselarchitectuur
De stelselarchitectuur wordt gebruikt om te toetsen in hoeverre invoering van de nieuwe
standaard - en dit geldt met name voor generieke standaarden - impact heeft op andere
standaarden.
― Meerjarenstrategie
De meerjarenstrategie wordt gebruikt om - daar waar een relatie bestaat met andere
standaarden - de invoering in de tijd te synchroniseren.
De analysefase resulteert in een advies. Waar nodig past de houder van de standaard de
aangeleverde beschrijving van de standaard, de impactanalyse en het implementatieplan aan.
De laatste stap is de besluitvormingsfase. Hierin nemen de houders van de individuele
standaarden en de houder van het stelsel gezamenlijk een besluit over het opnemen van de
nieuwe standaard in het stelsel. Ook nemen zij een besluit over de ingangsdatum en de eventuele
uitfasering van bestaande standaarden.

3.3 Wijzigen standaard

Hoewel je het wijzigen van een standaard kunt opvatten als het opnemen van een nieuwe versie
van een standaard en het uitfaseren van een oude versie, zijn er ook argumenten om wijziging als
een apart proces te benoemen. Dit heeft te maken met de omvang en impact van een
voorgestelde wijziging. Er kunnen redenen zijn om details aan te passen, bijvoorbeeld als gevolg
van fouten, omissies of tussentijdse wijzigingen in onderliggende (internationale) standaarden.
De spelregels hiervoor worden vastgelegd in het versiebeleid. Denk bijvoorbeeld aan conventies
met betrekking tot versienummering.
Een voorbeeld van hoe een wijziging van een standaard zou kunnen werken is geschetst in
bijlage 1.

3.4 Opstellen en onderhouden
meerjarenstrategie

De meerjarenstrategie vormt een toetsingskader om voorgenomen veranderingen in standaarden
te relateren aan langetermijnontwikkelingen en een globale meerjarenplanning met als doel
keuzes te maken en prioriteiten te stellen. De meerjarenstrategie beschrijft onder meer:

26

Model voor stelselregie

externe ontwikkelingen (politiek, maatschappelijk, zorginhoudelijk, ICTtechnisch, internationale standaarden, etc.) die van invloed zijn op de
doorontwikkeling van standaarden in Nederland;
—
vertaling van externe ontwikkelingen naar toepassing van generieke
standaarden;
—
beoogde uitbreiding en verbetering van het stelsel door opname van nieuwe
usecase-standaarden.
De strategie voor doorontwikkeling van een individuele standaard moet passen binnen de
meerjarenstrategie van het stelsel.
—

3.5 Onderhouden stelselcatalogus

De stelselcatalogus is een lijst met zowel de usecase-standaarden als de generieke standaarden
die deel uitmaken van het stelsel. De stelselcatalogus wordt bijgewerkt bij elke wijziging van het
stelsel als gevolg van het opnemen, wijzigen en uitfaseren van standaarden. Per standaard
worden minimaal de volgende gegevens bijgehouden:
― naam standaard
― houder standaard
― beheerder standaard
― versienummer
― ingangsdatum geldigheid
― einddatum geldigheid
― verwijzing naar specificaties (functioneel en technisch ontwerp)
― certificerende instantie
― gecertificeerde leveranciers

3.6 Vaststellen en onderhouden
stelselarchitectuur
De stelselarchitectuur is geen klassieke I-architectuur met de vaak toegepaste onderverdeling in
lagen: business-, informatie-, applicatie- en infrastructuurarchitectuur.
De stelselarchitectuur beschrijft binnen het stelsel - per laag uit het interoperabiliteitsmodel - de
relaties tussen de usecase-standaarden en de generieke standaarden. Het primaire doel van de
architectuur is het inzichtelijk maken van relaties.
Binnen de stelselarchitectuur maken we onderscheid tussen actuele situatie (de ‘ist’) en de
toekomstige gewenste architectuur (de doelarchitectuur, ofwel de ‘soll’).
De actuele stelselarchitectuur wordt bijgewerkt bij elke wijziging van het stelsel als gevolg van het
opnemen, wijzigen en uitfaseren van standaarden. Stelselarchitectuur en stelselcatalogus zijn
onlosmakelijk met elkaar verbonden.

27

Model voor stelselregie

3.7 Vaststellen en onderhouden kaders
Voor opname van standaarden in het stelsel worden kaders gesteld in de vorm van:
― Uitgangspunten en spelregels
Bijvoorbeeld, per standaard zijn in het stelsel niet meer dan twee versies opgenomen: een
baselineversie (een vigerende oftewel van kracht zijnde versie) en een toekomstige versie.
― Toelatingscriteria
Bijvoorbeeld, aan een standaard worden generieke eisen gesteld ten aanzien van inhoud en
vorm. Op basis van deze eisen kan worden vastgesteld of een standaard voldoende is
uitgewerkt.
Kaders worden op stelselniveau vastgesteld en periodiek herijkt.

3.8 Vaststellen en onderhouden roadmap en
releasekalender
De roadmap is een langetermijnplanning voor het opnemen, wijzigen en uitfaseren van
standaarden en is gekoppeld aan de meerjarenstrategie.

Een releasekalender is een kortetermijnplanning met concrete afspraken over het opnemen,
wijzigen en uitfaseren van standaarden.
De roadmap en de releasekalender vormen onmisbare instrumenten om in de tijd de impact van
nieuwe en te wijzigen standaarden op andere standaarden te bepalen. De releasekalender wordt
continu onderhouden.

3.9 Monitoren adoptiegraad en besluiten
Omdat afspraken over standaarden nog niet impliceren dat ze daadwerkelijk worden toegepast,
is het in beeld brengen van de adoptiegraad belangrijke informatie bij besluitvorming over
standaarden. Zo is voor de standaard voor huisartswaarneming in beeld gebracht bij welk
percentage van de huisartsensystemen de standaard is ingebouwd. Zonder een beeld van de
adoptiegraad van bestaande standaarden is impactanalyse en besluitvorming voor nieuwe
standaarden niet goed mogelijk.
De mate waarin besluiten over standaardisatie worden geïmplementeerd en de adoptiegraad in
de betreffende systemen van zorgaanbieders moeten daarom continu worden gemonitord.
Periodiek wordt hierover op stelselniveau gerapporteerd, waarbij in de rapportage ook een
verband wordt gelegd met genomen besluiten. Op deze manier is het monitoren van de
adoptiegraad een belangrijk middel om te volgen in hoeverre stelselbesluiten worden nageleefd.

28

Model voor stelselregie

3.10 Opstellen stakeholderanalyse
Op stelselniveau worden met behulp van een stakeholderanalyse de belangen van alle betrokken
partijen in kaart gebracht. Op basis van deze analyse worden de rollen binnen het stelsel
verdeeld.

3.11 Samenhang processen en producten
In figuur 8 is de samenhang tussen de verschillende processen en producten weergegeven.
Vertrekpunt voor het beheer van het stelsel zijn de kaders: een meerjarenstrategie,
toelatingscriteria en een beoogde (‘soll’) stelselarchitectuur, en de door het ministerie van VWS
bepaalde financiële kaders.
De kern van stelselregie omvat het opnemen, wijzigen en uitfaseren van standaarden.
Besluitvorming hierover wordt ondersteund door middel van een stelselcatalogus, een
releasekalender en een vigerende (‘ist’) stelselarchitectuur.
De feitelijke implementatie van standaarden wordt bewaakt door het monitoren van de
uitvoering van besluiten en de adoptiegraad van standaarden in systemen. Op basis van deze
informatie wordt het beheer van de standaarden bijgestuurd.
Vaststellen meerjarenstrategie en roadmap

Vastellen kaders

Vastellen stelselarchitectuur (“soll”)

Financiële kaders

Uitfaseren standaard

Rapporteren en adviseren

Toetsen aan
Opnemen standaard

Wijzigen standaard

Vertalen naar
Onderhouden
releasekalender

Onderhouden
stelselcatalogus

Figuur 8 - Samenhang stelselprocessen

Onderhoud “ist”
stelselarchitectuur

Monitoren en evalueren
adoptiegraad

29

Model voor stelselregie

4
Governance

30

Model voor stelselregie

4.1 Inleiding

Aangezien stelselregie in essentie gaat om het maken van gezamenlijke afspraken is het van groot
belang om te duiden tussen wie die afspraken gemaakt worden en hoe de verhouding is tussen
de houders van de standaarden en de houder van het stelsel. Anders dan het beheer van een
individuele standaard, waarbij sprake is van één houder, is bij een stelsel sprake van meerdere
houders en neemt het aantal potentiële belangenconflicten toe.
Tot nu toe hebben we voor de eenvoud gesteld dat de verantwoordelijkheid voor een standaard
berust bij een houder. In de realiteit is echter sprake van diverse partijen die als stakeholders een
belang hebben bij het bepalen van standaarden en die een rol vervullen bij de ontwikkeling, het
beheer en het gebruik van standaarden. Daarom duiden we eerst wat we verstaan onder
stakeholders en rollen.

4.2 Stakeholders

Het zorgveld bestaat een groot aantal partijen die elk een eigen belang hebben bij het proces van
standaardisatie. Juist op stelselniveau worden belangentegenstellingen zichtbaar omdat het gaat
om standaardoverstijgende afspraken. Omdat stelselregie gaat over afspraken tussen partijen is
het belangrijk om zorgvuldig te definiëren wat we verstaan onder een stakeholder. In de NEN
7522 standaard worden verschillende categorieën stakeholders benoemd. In tabel 3 hebben we
de meest relevante stakeholders benoemd in relatie tot stelselregie.
Stakeholder

Rol

1
2
3
4
5

Landelijk programma
Standaardisatie-expert
Belangenorganisatie
Leverancier
Ministerie van VWS

6
7
8
9

Zorgverlener
Zorgaanbieder
Patiënt
Verzekeraar

Tijdelijke organisatie die rol speelt in ontwikkeling van standaarden
Organisatie belast met beheer, normering, governance, etc.
Organisatie die belang behartigt van groep stakeholders
Organisatie die IT-systemen, infrastructuur of diensten levert
Zorgt voor wetgeving, beleid, financiering en uitvoering landelijke
taken
Natuurlijk persoon die beroepsmatig zorg verleent
Bestuurder van instelling of solistisch werkende zorgverlener
Persoon die zorg ontvangt
Organisatie belast met de uitvoering van de bekostiging van de zorg

Tabel 3 - Overzicht stakeholders

31

Model voor stelselregie

4.3 Rollen in NEN 7522

In de NEN 7522 standaard is vanuit het principe van functiescheiding een aantal rollen
gedefinieerd die van belang zijn bij de ontwikkeling en het beheer van zowel usecasestandaarden, generieke standaarden als ook het stelsel van standaarden. In tabel 4 staan de voor
stelselregie meest relevante rollen weergegeven:

A
B
C
D
E
F
G

Rol

Rolomschrijving

Houder
Autorisator
Functioneel beheerder
Expert
Technisch beheerder
Distributeur
Gebruiker

Is eindverantwoordelijk voor beheer en bepaalt kaders
Keurt een standaard goed
Voert regie over het beheerproces, voert beheerproces uit
Brengt expertise in
Verzorgt het technisch beheer
Verzorgt de communicatie over standaarden
Gebruikt de standaarden, levert wijzigingsvoorstellen

Tabel 4 - Overzicht rollen

De in paragraaf 4.2 genoemde stakeholders vervullen deze rollen. Een stakeholder kan daarbij
meerdere rollen vervullen en een rol kan vervuld worden door meerdere stakeholders.

4.4 Rolverdeling bij individuele standaarden
De rolverdeling bij het beheer van individuele standaarden kunnen we het beste toelichten aan
de hand van het generiek beheerproces voor standaarden. De belangrijkste rollen hierbij zijn die
van gebruiker, expert, functioneel beheerder, autorisator, technisch beheerder en distributeur. Dit
is geïllustreerd in figuur 9. Per stap hebben we de betrokken rollen weergeven, waarbij de
hoofdverantwoordelijke is onderstreept.

Processtap

1. Intake

2. Analyse

3. Besluitvorming

4. Realisatie

5. Publicatie

Rol

Functioneel
beheerder
Gebruiker

Functioneel
beheerder
Expert

Autorisator
Functioneel
beheerder
Expert

Technisch
beheerder
Functioneel
beheerder

Distributeur
Gebruiker

Figuur 9 - Rolverdeling in generiek beheerproces

In dit procesmodel wordt de eindverantwoordelijke - de houder van de standaard - niet genoemd.
Dit procesmodel is dan ook bedoeld voor het operationeel beheer van individuele standaarden.

32

Model voor stelselregie

De houder van de standaard houdt zich vooral bezig met meerjarenstrategie, kwaliteitsbeleid en
speelt daarnaast een rol bij escalaties. Een groot deel van het beheer van individuele standaarden
omvat bottom-up gedreven processen.

4.5 Rolverdeling bij stelselregie
Zoals in hoofdstuk 2 is aangegeven gaat stelselregie in essentie over het opnemen van
standaarden in het stelsel en het maken van afspraken over het gebruik van generieke
standaarden. Hierbij past een meer strategische benadering en speelt de stelselhouder een
belangrijkere rol om de volgende redenen:
1. Afweging van belangen
De houders van de generieke standaarden en de houder van het stelsel vertegenwoordigen
een gemeenschappelijk (algemeen) belang. Er zal dus een afweging moeten worden gemaakt
tussen het gemeenschappelijke belang en de belangen van de houders van individuele
standaarden. Wanneer de partijen geen consensus bereiken, neemt de stelselhouder als
vertegenwoordiger van het algemeen belang een besluit.
2. Kaders
Een randvoorwaarde voor een samenhangend stelsel zijn uitgangspunten, principes en
toelatingscriteria voor standaarden. De stelselhouder is verantwoordelijk voor het vaststellen
van beleid en kaders, en ook het organiseren van toetsing daaraan.
3. Meerjarenstrategie
De stelselhouder is verantwoordelijk voor het opstellen van een meerjarenstrategie met
betrekking tot de doorontwikkeling van het stelsel.
Stelselregie is daarmee primair een samenspel tussen de houder van het stelsel, de beheerder
van het stelsel en de houders van de individuele standaarden. Onder de laatste categorie verstaan
we zowel de houders van usecase-standaarden, als de houders van generieke standaarden.
Merk op dat - vanuit het gemeenschappelijk belang - de belangen van de houders van generieke
standaarden en die van de houder van het stelsel in elkaars verlengde liggen. Het ligt dan ook
voor de hand dat de stelselhouder op termijn ook de houder wordt van de generieke
standaarden.

33

Model voor stelselregie

34

Uitgaande van de in paragraaf 3.11 geschetste samenhang van processen is in tabel 5 de rolverdeling op hoofdlijnen weergegeven.
Stelsel
Veldpartijen
― Strategie
― Kaders

Standaarden
Houder

Autorisator

Financiers

Beheerder

Experts

Houder

Autorisator

Besluiten

Adviseren
houder

Financieel
kader
stellen

Opstellen

Adviseren
beheerder

Besluiten

Adviseren
houder

Besluiten over
implementatie

Besluiten
over inhoud

Voorbereiden

Adviseren

Besluiten over
implementatie

Besluiten
over inhoud

― Architectuur
— Opnemen standaard
— Wijzigen standaard
— Uitfaseren standaard

Besluiten over
implementatie

— Onderhouden
catalogus
— Onderhouden
releasekalender
— Onderhouden
architectuur
— Monitoren
adoptiegraad
Tabel 5 - Rolverdeling op hoofdlijnen bij stelselregie

Vaststellen

Middelen
beschikbaar
stellen

Uitvoeren

Model voor stelselregie

Bij de opzet van deze rolverdeling hanteren we de volgende uitgangspunten:
1.

Gezamenlijke besluitvorming door houder van het stelsel én de veldpartijen
De houder van het stelsel, de houders van de standaarden én de betrokken veldpartijen
nemen gezamenlijk besluiten over standaarden op stelselniveau en over stelselproducten .
De houder van het stelsel is eindverantwoordelijk, maar streeft naar bestuurlijk commitment
van alle betrokken veldpartijen. Hierbij is het van belang een goede balans te vinden tussen
publiek houderschap met enige doorzettingsmacht én werkelijk eigenaarschap voor
standaardisatie bij de veldpartijen.

2.

Getrapte besluitvorming
Aan de besluitvorming over standaarden door de houders gaat overleg van de
stelselautorisator en de autorisators van de standaarden vooraf. De autorisators nemen eerst
een inhoudelijk besluit en adviseren de stelselhouder over implementatie. Ook adviseert de
stelselautorisator (eventueel samen met autorisators van standaarden) de stelselhouder bij
besluiten over kaders, strategie en architectuur. De wijze van besluitvorming over
standaarden lichten we nader toe in paragraaf 4.6.

3.

Uitvoering en besluitvorming zijn gescheiden
De stelselhouder neemt besluiten, de stelselbeheerder is verantwoordelijk voor de
voorbereiding van de besluitvorming (= uitvoering). De stelselhouder is eindverantwoordelijk
voor zowel de besluiten als de uitvoering. De implicatie daarvan is dat de stelselhouder een
duidelijk gedefinieerde relatie moet hebben met zowel de stelselautorisator als de
stelselbeheerder.

4.

Advisering door experts bij voorbereiding besluitvorming
De stelselbeheerder laat zich bij de voorbereiding van de besluitvorming adviseren door
experts. De stelselhouder is verantwoordelijk voor het aanwijzen van experts.

5.

De financier reikt een kader aan en stelt middelen beschikbaar
De financier van het stelsel geeft aan de stelselhouder een financieel kader mee voor de
ontwikkeling én implementatie van nieuwe (versies van) standaarden binnen het stelsel.
Houders van standaarden kunnen zich bij substantiële implementatiekosten immers alleen
committeren aan nieuwe versies als de betrokken zorgaanbieders een tegemoetkoming
ontvangen bij de benodigde investeringen. In het financieel kader wordt ook aangegeven
welke wijzigingen van standaarden zorgaanbieders uit hun eigen begroting moeten
bekostigen. Het financieel kader bestaat daarmee uit een beschikbaar budget plus de
spelregels voor verdeling en toekenning.

35

Model voor stelselregie

6.

Vertaling van besluiten naar stelselproducten
De stelselbeheerder legt de resultaten van de besluitvorming over standaarden vast in a) een
stelselcatalogus, b) een releasekalender, c) een vigerende stelselarchitectuur. En de
stelselhouder legt dit vervolgens ook weer vast.

7.

Monitoring van de uitvoering van besluiten
De adoptiegraad van standaarden wordt gemonitord en periodiek gerapporteerd aan de
stelselhouder.

Merk op dat deze rolverdeling voor stelselregie enigszins afwijkt van de NEN 7522 standaard daar
waar het gaat over de rolverdeling tussen de stelselhouder en de stelselautorisator bij de
besluitvorming over standaarden in het stelsel.

4.6 Besluitvorming

Zoals aangegeven maken we onderscheid tussen besluitvorming over de inhoud van standaarden
en besluitvorming over de implementatie van standaarden. De reden hiervoor is dat het
opnemen, wijzigen en uitfaseren van standaarden in het stelsel een complex
besluitvormingsproces vereist. Daarom ligt een getrapte besluitvorming voor de hand. In tabel 6
zijn de drie fasen van besluitvorming - voorbereiding, inhoudelijke besluitvorming en bestuurlijke
besluitvorming - uitgewerkt.
Fase

Voorbereiding

Inhoudelijke
besluitvorming
— Besluiten nemen over
inhoud van de
standaard

Bestuurlijke
besluitvorming
— Besluiten nemen over
implementatie van de
standaard

Wat

— Inbrengen informatie
over standaard
— Toetsen volledigheid en
juistheid

Hoe

— Verzamelen informatie
— Reviewen ingebrachte
informatie
— Formuleren voorstel
nieuwe standaard en
uitbrengen advies

— Toetsen aan strategie,
kaders en architectuur
— Toetsen impactanalyse
(… alle aspecten
geadresseerd…)

— Toetsen haalbaarheid
implementatieplan
— Toetsen financiering

Product — Voorstel en advies
nieuwe standaard
— Beschrijving standaard
— Impactanalyse
(‘uitvoeringstoets’)
— Implementatieplan
— Adviezen experts
(optioneel)

— Akkoord op beschrijving
standaard
— Akkoord op
impactanalyse
— Advies op
implementatieplan

— Commitment geven
voor uitvoering
— Beschikbaar stellen
middelen

36

Model voor stelselregie

Wie

— Beheerder stelsel
— Beheerder standaard
— Experts

— Autorisator van het
stelsel
— Autorisator van de
standaarden

— Houder van het stelsel
— Houder van de
standaard

Tabel 6 - Besluitvorming

In de voorbereidingsfase verzamelt de stelselbeheerder alle benodigde informatie voor
besluitvorming op aangeven van de beheerders van de betrokken standaarden. De
stelselbeheerder toetst de informatie, maakt een voorstel en geeft een advies. Zo nodig wordt
advies ingewonnen bij experts.
De inhoudelijke besluitvorming betreft een samenspel tussen de autorisator van het stelsel en de
autorisators van de standaarden in het stelsel. Zij stellen op basis van de aangeleverde informatie
vast of de opname c.q. wijziging van de standaard past binnen de kaders, de meerjarenstrategie
en de architectuur. Ook stellen zij vast of de impact voldoende in beeld is gebracht en geven een
advies over de implementatie. Een wijziging in een generieke standaard kan immers gevolgen
hebben voor usecase-standaarden. Besluitvorming hierover vindt in gezamenlijkheid plaats.
Tijdens de bestuurlijke besluitvorming neemt de houder van het stelsel, samen met de
veldpartijen en de houders van de standaarden, een besluit over de implementatie van een
standaard en de allocatie van de beschikbare middelen. Implementatie van een standaard kan
immers grote operationele en financiële gevolgen hebben. Daarom kunnen partijen zich alleen
op bestuurlijk niveau committeren aan de implementatie van standaarden.
Een aandachtspunt is dat de bestuurlijke vertegenwoordiger van een veldpartij niet dezelfde
hoeft te zijn als de houder van een standaard. Bovendien zal vaak sprake zijn van meerdere
veldpartijen. Dit wordt geïllustreerd door het onderstaande voorbeeld.

Stel dat binnen het stelsel voorgesteld wordt om de publicatieversie van de zibs
te wijzigen. Dan betekent dit dat de usecase- standaard eOverdracht moet
worden aangepast. Dat vereist niet alleen instemming van de standaardhouder
van eOverdracht (V&VN, de beroepsvereniging van verzorgenden en
verpleegkundigen), maar ook instemming van de betrokken veldpartijen bij
eOverdracht, zoals NVZ (algemene ziekenhuizen), ZKN (zelfstandige klinieken),
NFU (universitair medische centra) en ActiZ (zorgorganisaties in o.a.
verpleegzorg).

4.7 Taken en verantwoordelijkheden
stelselhouder
De stelselhouder is verantwoordelijk voor:

37

Model voor stelselregie

1. Het (laten) opstellen en vaststellen van de meerjarenstrategie en roadmap voor de
(door)ontwikkeling van het stelsel van standaarden.
2.

Het (laten) opstellen en vaststellen van de kaders voor het stelsel.

3. Het (laten) opstellen en vaststellen van de stelselarchitectuur.
4. Het (laten) vaststellen van de stelselcatalogus en de releasekalender.
5. Het opstellen van een stakeholderanalyse en toewijzen van stelselrollen.
6. Het afstemmen van het financieel kader met de stelselfinancier.
7. Het houderschap voor generieke standaarden.
Het laatste punt vergt toelichting. Van nature is het houderschap van generieke standaarden,
zoals de zibs, terminologie (SNOMED CT) en de BgZ, niet of niet eenvoudig bij veldpartijen te
beleggen. Omdat generieke standaarden een belangrijke (verbindende) rol vervullen binnen een
stelsel, is een logische conclusie om het houderschap van deze generieke standaarden te laten
invullen door (te beleggen bij) de stelselhouder.
Als het houderschap van generieke standaarden wordt belegd bij de stelselhouder, dan betreffen
de bovenstaande beschreven verantwoordelijkheden van de stelselhouder en de producten
binnen het stelsel (meerjarenstrategie en roadmap, kaders, stelselarchitectuur,
stakeholderanalyse, financiële kaders) ook de generieke standaarden die tot het stelsel behoren.
NB Het samenvallen van het houderschap van het stelsel en van generieke standaarden hoeft niet
voor alle generieke standaarden die tot het stelsel behoren, het geval te zijn. Zo zal het
houderschap voor een generieke standaard als HL7 FHIR of HL7 CDA bij de betreffende
standaardisatieorganisatie (HL7 Nederland of HL7 Internationaal) belegd worden.
Bij voorkeur heeft de stelselhouder voor het effectueren van besluiten ook middelen, zoals een
wettelijk mandaat en mogelijkheden voor financiering.

4.8 Taken en verantwoordelijkheden
stelselautorisator
De stelselautorisator is verantwoordelijk voor:

1. Het besluiten over de inhoud van de standaarden in het stelsel.
2. Het adviseren over stelselproducten waaronder: de meerjarenstrategie, de roadmap voor de
(door)ontwikkeling van het stelsel van standaarden, de kaders van het stelsel en de
stelselarchitectuur.
De rollen van stelselhouder en stelselautorisator liggen dicht bij elkaar. Het is daarom van belang
een grote mate van gemeenschappelijkheid tussen stelselhouder en stelselautorisator te creëren.

38

Model voor stelselregie

4.9 Taken en verantwoordelijkheden
stelselbeheerder
Hoewel de NEN 7522 standaard onderscheid maakt tussen de rollen van functioneel beheerder,
technisch beheerder en distributeur, voegen we deze rollen gemakshalve samen tot de rol van
stelselbeheerder. Zowel bij individuele standaarden als bij een stelsel van standaarden worden
deze drie rollen namelijk vrijwel altijd om praktische redenen aan één partij toegewezen.
De stelselbeheerder is verantwoordelijk voor:
1. Het uitvoeren van de afgesproken procedures voor intake, analyse en uitbrengen van een
advies bij de besluitvorming over het opnemen, wijzigen of uitfaseren van standaarden.
2. Het uitwerken en beheren van de meerjarenstrategie, roadmap, kaders en beoogde
stelselarchitectuur in opdracht van de stelselhouder en het desgewenst adviseren van de
stelselhouder daarover.
3. Het monitoren en evalueren van het gebruik van individuele (generiek en usecase-specifiek)
standaarden binnen het stelsel, en ook het rapporteren en adviseren daarover aan de
stelselhouder.
4. Het onderhouden, technisch beheren en distribueren van de stelselcatalogus, releasekalender
en vigerende architectuur naar aanleiding van besluiten over het opnemen, wijzigen en
uitfaseren van standaarden.
NB Onder technisch beheer valt de verantwoordelijkheid voor de technische omgeving
waarin het onderhoud plaatsvindt van de producten die in beheer zijn . Zo’n technische
omgeving zal bestaan uit het geheel aan ICT-middelen (tools, hardware, netwerken, e.d.) die
noodzakelijk zijn om het functioneel beheer uit te kunnen voeren op de producten. Hieronder
valt onder andere het kunnen toepassen van versionering.

39

Model voor stelselregie

5
Concrete
invulling van
het stelsel

40

Model voor stelselregie

In dit hoofdstuk geven we een concrete invulling van het stelsel op basis van een aantal
aannames. Het doel van deze paragraaf is om te illustreren hoe een stelsel in de praktijk werkt,
respectievelijk kan werken.

5.1 (Tijdelijke) invulling van de stelselrollen voor
periode van drie jaar

Bij het concreet benoemen van stelselrollen, met name de rollen van stelselhouder en
stelselautorisator, is het belangrijk te zoeken naar de juiste balans tussen enerzijds het voldoen
aan NEN 7522, zoals de eis dat de stelselhouder een rechtspersoon moet zijn, en anderzijds het
beleggen van de bestuurlijke stelselverantwoordelijkheid bij veldpartijen.
Het voorstel is om de verschillende rollen als volgt concreet in te vullen:
― Stelselhouder: VWS
De houder is de secretaris-generaal van het ministerie VWS, die deze taak heeft gedelegeerd
aan de directie Informatiebeleid VWS, in samenwerking met relevante veldpartijen. Deze
samenwerking wordt geconcretiseerd via een convenant tussen de relevante veldpartijen en
het ministerie van VWS.
― Stelselautorisator: directie Informatiebeleid ministerie van VWS
Feitelijk valt de rol van stelselhouder en stelselautorisator hiermee samen bij het ministerie
van VWS, in ieder geval voor de periode van drie jaar. De stelselautorisator zal bij het nemen
van besluiten moeten zorgen voor voldoende commitment van de relevante veldpartijen, die
de besluiten van de stelselautorisator mede zullen moeten uitvoeren en dragen. Denk daarbij
aan veldpartijen die zitting hebben in het Informatieberaad Zorg (IB). In het IB zitten
bestuurlijk verantwoordelijke veldpartijen die feitelijk (mede)verantwoordelijk zijn (lees:
(mede)verantwoordelijkheid moeten gaan nemen) voor de onderliggende standaardisatie
van zorginformatieprocessen. En deze partijen zijn in het algemeen ook houder van de
standaarden die tot het stelsel behoren.
― Stelselbeheerder: Nictiz
Toelichting bij de rol van het IB
In het IB zitten de veldpartijen die bestuurlijk (mede)verantwoordelijkheid moeten nemen voor
het goed laten functioneren van het zorginformatiestelsel in de praktijk, onder voorzitterschap
van de secretaris-generaal van het ministerie van VWS. Het IB kan de inhoudelijke discussies en
overwegingen bij voorgenomen adviezen aan de stelselautorisator delegeren aan onderliggende
gremia, zoals de kerngroep van het IB. Daardoor kan het IB zich vooral richten op het formuleren
van stelsel-adviezen op basis van procesmatige overwegingen. Bijvoorbeeld of relevante
stakeholders betrokken zijn bij een voorgenomen advies aan de stelselautorisator en in de
gelegenheid zijn geweest om hun input te geven.
Toelichting bij Nictiz als stelselbeheerder

41

Model voor stelselregie

Het stelselbeheer wordt ondergebracht binnen Nictiz. We werken nog nader uit hoe we binnen
Nictiz de kennis maximaal kunnen bundelen en hoe we toch voldoende onderscheid kunnen
maken tussen stelselbeheertaken en de ontwikkeling en het beheer van individuele standaarden.
Nictiz heeft door al haar activiteiten op diverse gebieden van standaardisatie veel kennis,
overzicht en inzicht. Daarnaast beschikken we bijvoorbeeld over tooling en andere
mogelijkheden om monitoring op adoptie van standaarden in het stelsel uit te voeren. Nictiz als
stelselbeheerder fungeert op deze manier als ‘koppelvlak’ met alle standaarden binnen het
stelsel. Het monitoren van de adoptiegraad van standaarden is een belangrijk middel om te
volgen in hoeverre stelselbesluiten worden gevolgd.

5.2 Uitgangspunten en toelatingscriteria
Concrete invulling en formuleringen (niet uitputtend, en bedoeld als voorbeelden):
― Uitgangspunt: van elke standaard in het stelsel worden maximaal twee versies binnen het
stelsel toegestaan.
― Uitgangspunt: standaardhouders van standaarden binnen het stelsel nemen deel aan het
jaarlijks overleg standaardhouders.
― Toelatingscriterium: het beheer van de standaard moet zijn ingericht conform NEN 7522.
― Toelatingscriterium: een standaard moet zo veel als redelijkerwijs mogelijk gebaseerd zijn op
internationale standaarden.

5.3 Stelselproducten
We voorzien volgende stelselproducten:

a) Stelselstrategie
Deze beantwoordt de volgende vragen. Wat zijn de belangrijkste te realiseren doelstellingen
voor het stelsel van standaarden om bij te dragen aan het optimaal functioneren van het
zorginformatiestelsel? Welke ontwikkelingen moeten worden geïnitieerd of gestimuleerd en
welke knelpunten of belemmeringen moeten worden aangepakt?
b) Stelselroadmap
Hierin wordt beschreven hoe de (door)ontwikkeling van de standaarden en de
implementaties daarvan er in grote lijnen in de tijd (over een tijdspanne van drie à vijf jaar)
uitziet. De stelselroadmap komt voort uit de stelselstrategie.
c) Stelselfinanciering
Binnen het stelsel zijn langs twee kanten regelingen voor financiering noodzakelijk:
― (door)ontwikkeling van standaarden die tot het stelsel behoren
― financiering van implementaties van standaarden die tot het stelsel behoren
d) Stelselkaders
Hierin worden de principes en toelatingscriteria van het stelsel benoemd, zoals:
― Toelatingscriteria: o.a. beheer van de standaard ingericht conform NEN 7522.

42

Model voor stelselregie

—
—

― Toegestane versies per standaard: van elke standaard (zowel usecase-specifieke als
generieke standaarden) zijn binnen het stelsel toegestaan:
één versie als baselineversie 11
één versie als eerstvolgende versie, volgend op de baselineversie

5.4 Stelselarchitectuur

In de stelselarchitectuur staat beschreven:
― hoe de standaarden binnen het stelsel met elkaar samenhangen en welke rol generieke
standaarden daarin spelen in relatie tot usecase-standaarden;
― hoe bijvoorbeeld de zibs, als belangrijke generieke standaard, fungeren als instrument
binnen het stelsel om noodzakelijke regie te voeren;
― hoe we binnen het stelsel omgaan met veranderingen in de tijd en verschillen tussen
zorgdomeinen.

5.5 Afbakening van het stelsel

In de stelselcatalogus zijn opgenomen:
― usecase digitaal voorschrijven en ter hand stellen, met bijbehorende Informatiestandaard
MP9
― usecase BgZ-uitwisseling tussen instellingen voor medisch specialistische zorg, met
bijbehorende Informatiestandaard versie 1.0
― usecase beeldbeschikbaarheid, met bijbehorende Informatiestandaard versie 1.0
― usecase verpleegkundige overdracht, met bijbehorende Informatiestandaard eOverdracht
versie 4.0
― generieke standaard zibs Publicatie 2017 (= baselineversie binnen het stelsel)
― generieke standaard zibs Publicatie 2020 (= eerstvolgende versie)
― generieke standaard BgZ 2017 (= baselineversie binnen het stelsel)
― generieke standaard BgZ 2020 (= eerstvolgende versie)
― generieke standaard HL7 CDA release 2
― generieke standaard HL7 FHIR STU3 (= baselineversie binnen het stelsel)
― generieke standaard HL7 FHIR R4.01 (= eerstvolgende versie)
― generieke standaard SNOMED CT
Toelichting: de aanname bij de samenstelling van deze stelselcatalogus is dat zibs Publicatie 2015
en zibs Publicatie 2016 geen valide versies zijn binnen het stelsel.

11

Met een baselineversie wordt de versie bedoeld van een standaard die alle partijen die de standaard gebruiken, minimaal

moeten ondersteunen.

43

Model voor stelselregie

5.6 Overleggen en vergaderingen
Binnen het stelsel zijn de volgende overleggen en vergaderingen:

― Diverse ‘tafels’
Dit zijn overleggen, waarbij relevante stakeholders met elkaar en met de stelselhouder en
stelselbeheerder actuele issues in het stelsel bespreken en aandragen.
― Informatieberaad zorg (IB)
Het IB heeft de rol van stelselautorisator en bestaat vooral uit bestuurders van zorgpartijen.
Binnen het IB bespreken deze partijen relevante thema’s in en voor een ‘duurzaam
informatiestelsel in de zorg’. Het IB neemt de daadwerkelijke stelselbesluiten. Het IB kan de
inhoudelijke discussies en overwegingen bij voorgenomen besluiten delegeren aan
onderliggende gremia, zoals de kerngroep van het IB.
― Jaarlijks overleg standaardhouders
Dit is een vergadering waarin standaardhouders van standaarden binnen het stelsel zich
jaarlijks committeren en conformeren aan het stelsel en de besluiten daarin. Een belangrijk
onderwerp daarbij is de financiering, zowel als het gaan om de (door)ontwikkeling van
standaarden die tot het stelsel behoren, als de financiering van implementaties van
standaarden die tot het stelsel behoren.
NB Elke standaardhouder zorgt voor een meerjarenstrategie van de standaard, inclusief
roadmap en financiering die afgestemd is met de meerjarenstrategie voor het stelsel.

44

Model voor stelselregie

6
Slotoverwegingen
ten aanzien van
operationalisering

45

Model voor stelselregie

Aan het slot van dit rapport eindigen we met overwegingen met betrekking tot het
operationaliseren. Dit rapport hebben we in een aantal conceptversies eerder besproken, met
name binnen Nictiz en binnen het ministerie VWS, en dit heeft geleid tot de huidige, 6.3-versie.
Ook in deze 6.3-versie zijn er onderwerpen, die nadere aanvulling en aanscherping behoeven,
zoals:
― Visie op stelselregie (paragraaf 1.8), inclusief een duidelijke ‘eindplaat’ (waar willen we
eindigen met stelselregie?). Een eindplaat zou een van de producten moeten zijn van
stelselregie.
― De rol van stelselarchitectuur (paragraaf 2.4) is een van de producten van stelselregie.
― In de definitie van stelselregie (paragraaf 1.6) zit een beperking tot een stelsel van
standaarden. Dat roept de vraag op hoe de samenhang is tussen (vooral generieke)
standaarden en bijbehorende voorzieningen.
― Behalve de twee uitgewerkte voorbeelden (FHIR/CDA en versies van zibs,), zouden we nog
meer voorbeelden in de tekst kunnen verwerken.
― In hoofdstuk 5 wordt een ‘groeimodel’ voorgesteld en om te beginnen met een eerste versie
van het stelsel, dat de vier prioritaire uitwisselingen van de Wegiz bevat, inclusief de daarvoor
relevante andere (generieke) standaarden. Moeten we niet meteen ook (bijvoorbeeld) de
PGO-standaarden (MedMij) in het stelsel betrekken?
― Kaders en toelatingscriteria.
Een van de boodschappen van dit rapport is om snel te beginnen met de inrichting van de rollen
van stelselregie en om snel een daadwerkelijke start te maken met stelselregie. Sommige van de
onderwerpen, die in bovenstaande opsomming genoemd worden, kan je vertalen als producten
van stelselregie. Het is niet verkeerd om bij de start van stelselregie, geformuleerd in bijvoorbeeld
dit rapport, te beschrijven wat voor producten dit zijn en hoe je ze moet positioneren binnen
stelselregie. Een nadere aanvulling en aanscherping komt echter pas tot stand als ze als
producten van stelselregie na de daadwerkelijke start van stelselregie worden opgesteld. Dat
geldt bijvoorbeeld voor de:
― stelselarchitectuur, inclusief de soll-situatie (de ‘eindplaat’)
― stelselkaders (waaronder toelatingscriteria)
― stelselroadmap
De twee belangrijkste punten waar we voor pleiten in deze slotoverweging zijn dus:
1. Maak een daadwerkelijke en snelle start met stelselregie.
2. Hanteer een ‘groeimodel’. In hoofdstuk 5 staat een concrete uitwerking van een
mogelijke eerste fase in dit groeimodel.

46

Model voor stelselregie

Casus
zorginformatie
-bouwstenen
(zibs)

47

Bijlage 1

Aan de hand van een casus geven we een voorbeeld van het handelen van een stelselbeheerder
en de bijbehorende verantwoordelijkheidsverdeling tussen standaardhouder en stelselhouder.
Let op! Wat nu volgt is een fictieve casus. Weliswaar zo realistisch mogelijk,
maar toch fictief.

Casus

In het stelsel van standaarden zijn twee vigerende publicaties (zibs 2017 en zibs 2020)
opgenomen in de catalogus van generieke standaarden met de zib AllergieIntolerantie als
onderdeel van zib 2017 en zib 2020. In Q1 2023 is een nieuwe zib-publicatie (zibs 2022)
opgenomen in het stelsel (opgenomen in de catalogus van generieke standaarden) waarin de zib
AllergieIntolerantie is vervallen en vervangen door twee nieuwe zibs: zib Overgevoeligheid en zib
Reactie. Deze verbetering is zowel vanuit het oogpunt van medicatie als vaccinatie belangrijk en
ondersteunt onder andere het op een goede, uniforme manier registreren van reacties op COVID19-vaccinaties.
Standaard

Ingang geldigheid

Einddatum geldigheid

Zib Publicatie 2017
Zib Publicatie 2020
Zib Publicatie 2022

01-01-2018
01-01-2021
01-01-2023

-

Leverancier “x” participeert in verschillende uitwisselingen en meldt bij de
stelselbeheerder het probleem dat de publicaties zibs 2017/zibs 2020 en zibs 2022
versies functioneel niet tegelijk kunnen worden ondersteund (publicatie zibs 2022 is
niet backwards compatible met zibs 2017/zibs 2020).

Tabel 6 - Fictief fragment uit Catalogus generieke standaarden

6.1.1 Intake
De stelselbeheerder neemt de melding in ontvangst en gaat aan de slag met het verzamelen van
de benodigde informatie bij de leverancier, beheerder van de generieke standaard en betrokken
informatiestandaarden.

Uitvraag leverancier
Gegevens
Naam gebruikte standaarden

Casus
— Vaccinatie
— Huisartswaarneemgegevens
— Huisartsgegevens (patiënt-usecase)
— BgZ (zorg- en patiënt-usecase)

48

Bijlage 1

Beschrijving van ervaren probleem

De verschillende gebruikte zib-versies leiden tot
onoverkomelijke implementatiewerkzaamheden en
bijbehorende kosten.

Tabel 7 - Input leverancier

Uitvraag betrokken generieke standaarden
De stelselbeheerder verzoekt de beheerder van de zorginformatiebouwstenen het onderscheid
tussen de verschillende zib-publicaties in kaart te brengen.
Reactie beheerder zibs

Zib mbt AllergieIntolerantie

Zibs 2017
Zibs 2020
AllergieIntolerantie AllergieIntolerantie
3.2
3.3

Zibs 2022
Overgevoeligheid 1.0
Reactie 1.0

Tabel 8. Input beheerder zibs

Vanuit een brede landelijke werkgroep onder MP9 (medicatieproces) is de behoefte naar voren
gekomen om de bestaande zib AllergieIntolerantie te splitsen in 2 nieuwe zibs: Overgevoeligheid en
Reactie. Onderliggend daaraan is o.a. dat met name de nieuwe zib Reactie ook ingezet kan worden
voor reacties op vaccinaties, zoals met name Covid19-vaccinaties. De houder van de zibs streeft
ernaar per januari 2024 de publicatie zibs 2017 uit te faseren.
Uitvraag betrokken informatiestandaarden
De stelselbeheerder verzoekt betrokken beheerders van informatiestandaarden de volgende
informatie aan te leveren over de gebruikte zib-publicatie:
― gebruikte versie van de zib AllergieIntolerantie;
― inzicht in doorontwikkeling van de informatiestandaarden.
De informatie die wordt aangeleverd schetst het volgende beeld:

Informatiestandaard
Vaccinatie

Zib
Overgevoeligheid 1.0
Reactie 1.0
Huisartswaarneemgegevens AllergieIntolerantie 3.3
+ patiënt use case
BgZ 2017, 2020
AllergieIntolerantie 3.3
BgZ patiënt use case

AllergieIntolerantie 3.2

Standaardhouder
RIVM
NHG
Publiek (dwz ingevuld
door de ‘Stelselhouder’)
Stichting MedMij

Tabel 9 - Input beheerders informatiestandaarden

Verifiëren problematiek leveranciers
Op basis van de aangeleverde informatie door de leverancier en betrokken beheerders, wordt bij
betrokken leveranciers geverifieerd of dit probleem breder wordt ervaren.

49

Bijlage 1

6.1.2 Analyse
Analyse problematiek bij Leveranciers
Bij de leveranciers die gemeld hebben dat ze hetzelfde probleem ervaren, wordt de aard van het
probleem onderzocht. Hierbij is het van belang om een aantal aspecten te analyseren,
bijvoorbeeld:
― Is het een breder probleem bij leveranciers?
― Betreft dit leveranciers met gedeelde kenmerken?
― Is er een relatie tussen het ervaren probleem en de inrichting van het systeem?
Standaardisatie problematiek
Op basis van de verzamelde informatie geeft de onderstaande afbeelding inzicht in het probleem
op stelselniveau.

Casus AllergieIntolerantie
RIVM
2022

???

…

XXX

???

…
Huisarts en

Patiënten (MedMij)

???

…

MedMij

2017

MedMij

2020

PGO

MedMij

2020

HIS

2017

Legenda
Stakeholder

Ziekenh uizen
BGZ

Waarneming

2017, 2022

ZIS/EPD

???

…

Informatiesysteem
Standaard
vertaling

Element van een use
case standaard voor
deze casus
publicatieversie zib
informatiestroom

Figuur 10 - Probleemschets op stelselniveau

Scenario’s voor een oplossing
Op basis van de probleemschets ziet de stelselbeheerder een aantal scenario’s:
Scenario 0: Meerdere versies accepteren
Zib Publicatie 2017 blijft een geldige generieke standaard binnen het stelsel en het is aan de
individuele standaardhouders om het migratiepad naar de nieuwe versie van de zibs vast te
stellen.
NB Binnen dit scenario is in verschillende mate ondersteuning in middelen van
softwareleveranciers en/of zorgaanbieders mogelijk.

50

Bijlage 1

Scenario 1: Harmoniseren van gebruikte zib-publicaties
Introduceren van een uitgangspunt dat maximaal twee versies van een standaard binnen het
stelsel opgenomen kunnen zijn. Dit leidt met direct ingang tot de verwijdering van de Zib
Publicatie 2017 uit de catalogus van generieke standaarden. Dat heeft weer als resultaat dat
opgenomen informatiestandaarden gebaseerd op zibs 2017 niet langer deel kunnen uitmaken
van het stelsel tot ze de overstap hebben gemaakt naar geldige nieuwe zib-publicaties;
NB Binnen dit scenario is in verschillende mate ondersteuning in middelen mogelijk.
Scenario 2: Geleidelijke harmonisering
Geleidelijk introduceren van een uitgangspunt dat maximaal twee versies van een standaard
binnen het stelsel opgenomen kunnen zijn. In de catalogus van generieke standaarden wordt in
Q1 2023 een paragraaf toegevoegd om het moment van uitfaseren van zib-publicaties in de
catalogus van generieke standaarden aan te kondigen. Deze einddatum wordt ook toegevoegd bij
informatiestandaarden die van de desbetreffende zib-publicatie gebruik maken.
NB Binnen dit scenario is in verschillende mate ondersteuning in middelen mogelijk.
Elk scenario wordt door de stelselbeheerder getoetst om een goed onderbouwd advies te vormen
en te geven aan de stelselhouder.
Toetsen aan stelselstrategie
Een stelselstrategie kan in deze casus richting geven in de vorm van een aantal toetsbare
uitgangspunten die de stelselhouder heeft vastgesteld, waaronder een:
― focus op stabiliteit/innovatie en bijbehorende kaders voor bewegingsruimte
standaardhouders
― vastgestelde stelselroadmap
― maximum aan aantal versies van een standaard die in het stelsel geldig kunnen zijn (zie
scenario 1)
Impactanalyse
Voor de impact worden de kosten en baten per scenario onderzocht en gewogen:
― toegevoegde waarde (softwareleveranciers en zorgaanbieders)
― implementatiewerkzaamheden voor gebruikers (softwareleveranciers en zorgaanbieders)
― kosten voor stelselgebruikers
Prioritering
De nieuwe zib-publicatie is niet de enige ontwikkeling die plaatsvindt binnen het stelsel, overige
ontwikkelingen zijn:
― uitfasering eOverdracht versie 6.x i.v.m. opname nieuwe publicatie
― overgang van CDA naar FHIR
Van alle ontwikkelingen worden de uitkomsten van de impactanalyse gewogen om te beoordelen
of deze ontwikkelingen tegelijk kunnen plaatsvinden of dat er geprioriteerd moet worden.
Consulteren
Vanuit verschillende expertise wordt advies ingewonnen ten behoeve van de verschillende
scenario’s:
― expertgroep

51

Bijlage 1

—
zorginhoudelijke vertegenwoordiging betrokken domeinen
—
methodische vertegenwoordiging betrokken softwareleveranciers
—
vertegenwoordiging vanuit architectuur
—
advies
betrokken standaardhouders -belangen in kaart brengen ten aanzien van de casus, waarbij de
volgende belangen worden gemeld:
― adopteren zibs 2022;
― verminderen aantal geldige zib-versies
― stabiliteit voor gebruikers
― adopteren zibs 2020

Besluitvorming
Advies stelselbeheerder
De stelselbeheerder stelt een advies op aan de stelselhouder met het volgende:
― probleembeschrijving
― verkende scenario’s t.b.v. een oplossing
― resultaten analyse
― advies met gewogen input expertgroep en standaardhouders
De stelselbeheerder weegt bovenstaande tot een finaal advies aan de stelselhouder: scenario 2.
Besluitvorming stelselautorisator
Houder besluit te kiezen voor scenario 2.
Effectueren besluit door stelselbeheerder
Naar aanleiding van het besluit onderneemt de stelselbeheerder de volgende stappen:
― Creëren van een nieuw uitgangspunt in de stelselstrategie.
—
Maximaal twee versies van een standaard kunnen binnen het stelsel tegelijk geldig zijn.
― Toevoegen einddatum catalogus generieke standaarden.
De stelselbeheerder voegt conform besluit een einddatum toe aan de publicaties.
Standaard

Ingang geldigheid

Einddatum geldigheid

Zib Publicatie 2017
Zib Publicatie 2020
Zib Publicatie 2022

01-01-2018
01-01-2021
01-01-2023

01-06-2023
01-06-2024
-

Tabel 10. Catalogus: Generieke standaarden

Toevoegen einddatum catalogus specifieke standaarden;
Informatiestandaard
Vaccinatie
Huisartswaarneemgegevens +
patiënt usecase
BgZ 2017, 2020

Einddatum geldigheid
01-06-2024
01-06-2024

52

Bijlage 1

BgZ patiënt usecase

01-06-2023

Tabel 11 - Catalogus: informatiestandaarden

Monitoring en signalering
De stelselbeheerder heeft een belangrijke monitorende functie voor de naleving van het
genomen besluit op stelselniveau. Daarvoor is het van belang dat de stelselbeheerder
toegankelijk is. Dit kan via een loket, maar het kan ook zo zijn dat er structureel contact is vanuit
de stelselbeheerder met houders/beheerders van deelnemende standaarden, ICT-leveranciers en
zorgaanbieders.
Daarnaast is een aantal gegevens nodig om meetbaar inzicht te hebben in de naleving van het
stelselbesluit:
― gegevens t.a.v. implementatie van deelnemende standaarden
― inzicht in de implementatiegraad
― gecertificeerde/gekwalificeerde softwareleveranciers
― in gebruik bij zorgaanbieders
― geactualiseerde roadmap van deelnemende standaarden
Periodiek wordt over bovenstaande gerapporteerd. Op het moment dat uit de monitoring naar
voren komt dat het besluit niet wordt nageleefd, neemt de stelselbeheerder contact op om de
betrokken(en) te horen. Op basis van het gesprek kan er al dan niet gesignaleerd worden naar de
stelselhouder om te interveniëren ten behoeve van de naleving.

53

Casus CDA
versus FHIR

Bijlage 2

Let op! Wat nu volgt is een fictieve casus. Weliswaar zo realistisch mogelijk,
maar toch fictief.

Casus

De stelselbeheerder heeft een belangrijke monitorende functie om problemen ten behoeve van
de interoperabiliteit te kunnen identificeren en signaleren. In de stelselcatalogus zijn op een zeker
moment de volgende standaarden toegelaten.
Standaard

Versie

Ingang geldigheid

CDA
FHIR STU3
FHIR R4
Zib Publicatie 2017
Zib Publicatie 2020
BgZ 2017
BgZ 2020

2.0
3.0.2
4.0.1
1.0
1.0
1.1
1.0

01-01-2015
01-01-2015
01-01-2018
01-01-2017
01-01-2020
01-01-2017
01-01-2020

Einddatum geldigheid

Tabel 13. Catalogus: generieke standaarden

Standaard

Versie

Raadplegen
3.0
Basisgegevensset Zorg
in persoonlijke
gezondheidsomgeving
(patiënt)
Dossier
1.0
wijzigingsverzoek
(patiënt)
BgZ uitwisseling
1.0
medischspecialistische zorg
BgZ uitwisseling
1.0
medischspecialistische zorg

Ingang
geldigheid

Gebruikte
Generieke standaard

01-01-2021

Zib Publicatie 2017
FHIR STU3

01-01-2022

Zib Publicatie 2020
FHIR R4

01-01-2017

Zib Publicatie 2017
CDA

01-01-2022

Zib Publicatie 2017
FHIR STU3

Einddatum
geldigheid

Tabel 14 - Catalogus: specifieke standaarden

De overstap van specifieke standaarden die de zibs 2017 gebruikte naar zibs 2020 wordt zichtbaar
gecombineerd met de overstap naar FHIR R4. De stelselbeheerder signaleert een mogelijkheid
om de gebruikte communicatiestandaarden in de overstap naar zibs 2020 te harmoniseren en
start proactief met het analyseren van de mogelijkheden.

55

Bijlage 2

56

Analyse

Allereerst wordt onderzocht of de huidige opzet voldoende samenhang biedt tussen de
standaarden in het stelsel.
Analyseren situatie bij leveranciers
Bij gecertificeerde leveranciers wordt het volgende uitgevraagd en geanalyseerd:
― Hoe wordt het ondersteunen van verschillende versies van communicatiestandaarden
ervaren?
― Zijn er verschillen in ervaring te onderscheiden tussen leveranciers met gedeelde
kenmerken?
― Zijn er verschillen in ervaring te onderscheiden die afhankelijk zijn van de inrichting van het
systeem van de leverancier?
Standaardisatieproblematiek
Op basis van alle verzamelde gegevens wordt de situatie geschetst.
Patiënten
(MedMij)

Zelfstandige
klinieken

Universitair
Medische Centra
FHIR STU3/BgZ2017
FHIR R4/BgZ2020

FHIR STU3/BgZ2017
FHIR R4/BgZ2020

FHIR STU3/BgZ2017
FHIR R4/BgZ2020

Ziekenhuizen
FHIR STU3/BgZ2017
FHIR R4/BgZ2020
CDA/BgZ2
017

Figuur 11 - Schets impactanalyse op basis van input standaardbeheerders

Scenario’s voor een oplossing
Op basis van de probleemschets ziet de beheerder een aantal scenario’s:
Scenario 0: Huidige situatie in doorontwikkeling accepteren
Zowel CDA, HL7 FHIR STU3 en HL7 FHIR R4 blijven geldig binnen het stelsel van standaarden. Het
is aan de houder van de individuele standaarden om de doorontwikkeling vorm te geven van de
individuele standaarden en daarbij te kiezen voor een van de drie communicatiestandaarden.
NB Binnen dit scenario is in verschillende mate ondersteuning in middelen van
softwareleveranciers en/of zorgaanbieders mogelijk.
Scenario 1: Harmonisatie van gebruikte communicatiestandaarden in doorontwikkeling
De stelselhouder stelt een uitgangspunt vast ten behoeve van de meerjarenstrategie om de
collectieve doorontwikkeling van het stelsel van standaarden richting FHIR vorm te geven. HL7

CDA/BgZ2
017

Bijlage 2

FHIR STU3 & R4 vormen de basis voor communicatiestandaarden binnen het stelsel. Waarbij
gedurende de overstap HL7 FHIR STU3 de baseline vormt voor alle specifieke standaarden.
NB Binnen dit scenario is in verschillende mate ondersteuning in middelen van
softwareleveranciers en/of zorgaanbieders mogelijk.
Scenario 2: Huidige situatie accepteren en sturen op generieke vertalingen
Zowel HL7 CDA als HL7 FHIR STU3 en HL7 FHIR R4 kunnen in de huidige vorm binnen het stelsel
geldig blijven. Het stelsel stuurt daarbij actief op het ontwikkelen en beheren van vertalingen die
specificeren hoe de conversie eenduidig moet plaatsvinden van CDA naar FHIR en andersom. Let
wel, dit betreft enkel de specificatie en niet de implementatie en uitvoering daarvan. Dat valt
immers onder een andere verantwoordelijkheid.
NB Binnen dit scenario is in verschillende mate ondersteuning in middelen van
softwareleveranciers en/of zorgaanbieders mogelijk.
Impactanalyse
De beheerders van individuele standaarden die niet gebaseerd zijn op CDA worden gevraagd de
volgende informatie aan te leveren om een inschatting te kunnen maken van de impact:
— In hoeverre leveren de scenario’s toegevoegde waarde voor de zorg in termen van
kwaliteitsverbetering en/of kostenbesparing?
— In hoeverre hebben de scenario’s impact op zorgverleners, zorgaanbieders en leveranciers in
termen van benodigde veranderingen en de daarvoor benodigde incidentele en structurele
middelen?
— Wat zijn de te vervullen randvoorwaarden en eventuele risico’s, bijvoorbeeld ten aanzien van
acceptatie en planning bij de scenario’s?
— Wat is de impact op andere standaarden in het stelsel?

57

Bijlage 2

Toegevoegde waarde:

Scenario
1
2

Toegevoegde waarde
Geen
Complexiteitsvermindering in
gegevensuitwisseling
Ondersteuning in omgang met complexiteit

3

Tabel 15. Toegevoegde waarde per scenario (fictief)

Benodigde incidentele middelen:

Scenario
1
2
3

Schatting benodigde middelen (€)
xxx
yyy
zzz

Tabel 16. Incidentele middelen per scenario (fictief)

Te vervullen randvoorwaarden
Schatting verschillende standaardbeheerders obv CDA in de te maken overstap naar FHIR STU3

Standaard 2

01-01-2024
Standaard 1

01-01-2025

01-01-2026
Standaard 3

Figuur 12. Fragment Roadmap van CDA gebaseerde standaarden naar FHIR STU3.

De stelselbeheerder maakt ten aanzien van de impactanalyse een aantal overwegingen:
― Wegen de kosten op tegen de toegevoegde waarde die de overstap naar FHIR biedt?
― Is er een baseline in FHIR te definiëren op basis van de tijdlijnen in de overstap van de
standaardbeheerder?
Toetsen aan stelselarchitectuur
Op basis van de aangeleverde impact op de andere standaarden in het stelsel wordt een analyse
gedaan op de impact op de stelselarchitectuur, bijvoorbeeld:
― Hoe verhoudt eventuele besluitvorming ten aanzien van CDA zich tot andere gebruikte
communicatiestandaarden als HL7 v2 (laboratoria) en Edifact (huisartsen)?

58

Bijlage 2

Besluitvorming
Advies stelselbeheerder
De stelselbeheerder stelt een wijzigingsvoorstel op met het volgende:
― analyse vraagstuk
― verkende scenario’s t.b.v. een oplossing
― Resultaten impactanalyse en toetsing
De stelselbeheerder weegt bovenstaande tot een finaal advies aan de stelselautorisator:
Scenario 1: Harmonisatie van gebruikte communicatiestandaarden in doorontwikkeling
De stelselhouder stelt een uitgangspunt vast ten behoeve van de meerjarenstrategie om de
collectieve doorontwikkeling van het stelsel van standaarden richting FHIR vorm te geven. HL7
FHIR STU3 & R4 vormen de basis voor communicatiestandaarden binnen het stelsel. Waarbij
gedurende de overstap HL7 FHIR STU3 de baseline vormt voor alle specifieke standaarden.
Hiervoor wordt een overgangstermijn geboden van 5 jaar.
Besluit stelselautorisator
De stelselautorisator neemt het volgende besluit:
― Uitbreiden van de meerjarenstrategie met een uitspraak over de overstap naar FHIR binnen vijf
jaar.
― CDA zal na een termijn van vijf jaar worden uitgefaseerd uit het stelsel van standaarden.
Vervolg na het besluit
― De stelselhouder stelt de herziene meerjarenstrategie vast met de uitspraak over de overstap
naar FHIR.
― De stelselbeheerder voegt in de catalogus een einddatum toe aan CDA.
Standaard

Versie

Ingang geldigheid

Einddatum geldigheid

CDA
FHIR STU3
FHIR R4
BgZ 2017
BgZ 2020

2.0
3.0.2
4.0.1
1.1
1.0

01-01-2015
01-01-2015
01-01-2018
01-01-2017
01-01-2020

01-01-2027

Tabel 17 - Catalogus: generieke standaarden

― De stelselbeheerder voegt in de catalogus een einddatum toe aan specifieke standaarden die
gebaseerd zijn op CDA.

59

Bijlage 2

Informatiestandaard

Versie

Ingang
geldigheid

Gebruikte
Communicatiestandaard

Einddatum
geldigheid

Raadplegen Basisgegevensset Zorg in
persoonlijke gezondheidsomgeving
(patiënt)
Dossier wijzigingsverzoek (patiënt)

3.0

01-01-2021

Zib Publicatie 2017
FHIR STU3

1.0

01-01-2022

BgZ uitwisseling medischspecialistische zorg
BgZ uitwisseling medischspecialistische zorg

1.0

01-01-2017

1.0

01-01-2022

Zib Publicatie 2020
FHIR R4
Zib Publicatie 2017 01-01-2027
CDA
Zib Publicatie 2017
FHIR STU3

Tabel 18 - Catalogus: informatiestandaarden

Monitoring en signalering
Standaardhouder
De standaardhouder maakt onderdeel uit van de autorisator. Via deelname aan de
besluitvorming als autorisator, committeert die zich aan de gevolgen daarvan. De
standaardhouder is er ook verantwoordelijk voor dat actuele informatie beschikbaar is over de
status van de overstap naar FHIR aan de hand van de stelselroadmap en releasekalender.

Stelselbeheerder
Monitort de naleving van het besluit via onder andere:
― gegevens op de stelselroadmap
― gegevens op de releasekalender
― gecertificeerde leveranciers (catalogus)

60

Nictiz is de Nederlandse kennisorganisatie voor digitale informatievoorziening in de zorg.
Nictiz ontwikkelt een visie op het zorginformatiestelsel en de architectuur die dat stelsel
ondersteunt. We ontwikkelen en beheren standaarden die digitale informatievoorziening
mogelijk maken en zorgen ervoor dat zorginformatie eenduidig kan worden vastgelegd en
uitgewisseld. Daarnaast adviseren we en delen we kennis over digitale informatievoorziening in
de zorg. Daarbij kijken we niet alleen naar Nederland, maar ook naar wat er internationaal
gebeurt.

Nictiz | Postbus 19121 | 2500 CC Den Haag | Oude Middenweg 55 | 2491 AC Den Haag
070 - 317 34 50 | www.nictiz.nl

https://creativecommons.org/licenses/by-sa/4.0/