Secretaris Generaal / plv.
Secretaris Generaal
Directie Informatiebeleid /
CIO
Cluster iBeleid team A
Bezoekadres:
Parnassusplein 5
2511 VX Den Haag
T 070 340 79 11
www.rijksoverheid.nl
Inlichtingen bij

Implementatie FHIR

Aanleiding
Er wordt in de zorg voor gegevensuitwisseling gebruik gemaakt van verschillende
technische en semantische uitwisselingsstandaarden (zie bijlage 1). Het gaat om
verschillende versies van FHIR, het verouderde CDA en Edifact en verschillende
zib-versies. Deze versies zijn niet interoperabel met elkaar. Dit heeft diverse
ongewenste gevolgen:
Slechts met zeer complexe en daarmee logge en dure ICT-infrastructuur
kan digitale gegevensuitwisseling gerealiseerd worden. Te vaak is dit niet
haalbaar en vindt geen gegevensuitwisseling plaats. Het meest urgent is
dit knelpunt op dit moment bij ziekenhuizen o.a. omdat VIPP 5, module 3
op dit moment niet uitvoerbaar is.
Softwareontwikkelaars en IT-afdelingen van zorgverleners zijn onzeker
over in welk technische en semantische standaarden ze moeten investeren
richting de toekomst.

Datum
21 oktober 2022
Aantal pagina's
5

Het Informatieberaad heeft 21 september 2020 geconcludeerd dat overstappen op
FHIR wenselijk is en ook in het IZA is dit afgesproken.
Besluit
VWS is als tijdelijk houder van het stelsel van standaarden (zie IZA, onderdeel I,
2.1, B, e op blz 93) voornemens een implementatiestrategie voor de FHIRstandaard en Zibs vast te stellen die helpt om interoperabiliteit bij
gegevensuitwisselingen in de zorg te bewerkstelligen. VWS wordt hierbij
geadviseerd door Nictiz als tijdelijk beheerder van het stelsel van standaarden
conform NEN7522.
Na advies van de tijdelijk stelselbeheerder (Nictiz, zie bijlage 2) en consultatie met
stakeholders (Informatieberaad in 2020 en afvaardiging softwareleveranciers)
besluit VWS als tijdelijk stelselhouder (zie IZA, onderdeel I, 2.1, B, e op blz 93)
dat:
1. FHIR STU3 en FHIR R4 zijn de generieke technische
uitwisselingsstandaarden. Standaardhouders kunnen beide versies kiezen
als technische uitwisselingsstandaard bij de (door)ontwikkeling van
uitwisselingsstandaarden. Het is niet de bedoeling dat standaardhouders
daarvoor nog andere versies (van standaarden) gebruiken; en
2. Zibs 2017 en Zibs 2020 zijn de generieke semantische
uitwisselingsstandaarden. Standaardhouders kunnen beide versies kiezen
bij het opstellen van uitwisselingsstandaarden. Het is niet de bedoeling dat

Pagina 1 van 5

standaardhouders daarvoor nog andere versies (van standaarden)
gebruiken; en
3. Zibs 2017 wordt alleen gebruikt in combinatie met FHIR STU3. Zibs 2020
wordt alleen gebruikt in combinatie met FHIR R4; en
4. De standaardhouder van de Zibs (VWS) dient te zorgen dat een
translatiespecificatie opgesteld wordt tussen Zibs 2017 en Zibs 2020 voor
uitwisseling binnen HL7 FHIR.
a. De translatiespecificatie is gepland beschikbaar te zijn in het derde
kwartaal van 2023
b. De kosten voor de translatiespecificatie bedragen € 0,6 miljoen en
worden gefinancierd uit de subsidie die Nictiz van VWS heeft
ontvangen; en
5. Houders van informatiestandaarden dienen – naar verwachting met
ondersteuning van hun standaardbeheerder en in afstemming met
stakeholders – migratieplannen op te stellen om over te stappen op de
generieke standaarden voor zover dat nog niet het geval is. Dit maakt
inzichtelijk hoe snel en onder welke voorwaarden de overstap op FHIR
gemaakt kan worden en wat daar de consequenties van zijn.
a. VWS zal standaardhouders een brief sturen met het verzoek zoals
geformuleerd in dit besluit, inclusief een procesbeschrijving hoe
binnen een ambitieuze, maar realistische termijn migratieplannen
aangeleverd kunnen worden.
b. Een overzicht van houders die een brief zullen ontvangen is
opgenomen in bijlage 3.
c. Het format voor het migratieplan is opgenomen in de bijlage 4.
d. Het migratieplan moet ook een aanpak bevatten van de
implementatie van de informatiestandaard bij zorgaanbieders,
waaronder de implementatie in de softwaresystemen van
leveranciers, die zorgaanbieders gebruiken. Daarmee wordt
duidelijk wanneer er overgegaan kan worden op daadwerkelijke
gegevensuitwisseling gebruik makend van de generieke
standaarden.

Secretaris Generaal / plv.
Secretaris Generaal
Directie Informatiebeleid /
CIO
Cluster iBeleid team A
Datum
21 oktober 2022

Toelichting
Het Informatieberaad heeft medio 2020 reeds geconcludeerd om over te stappen
naar FHIR 1. Deze conclusie is getrokken nadat is beschreven dat er grote
functionele meerwaarde is van de FHIR-standaard ten opzichte van andere
technische uitwisselingsstandaarden. Zo is het met FHIR mogelijk via een vraagantwoord-spel om vraag gestuurd gegevens uit te wisselen waardoor
zorgverleners voortdurend de actuele gegevens van andere zorgverleners tot hun
beschikking hebben. Deze functionaliteit past bij de visie over databeschikbaarheid
die op dit moment wordt ontwikkeld onder verantwoordelijkheid van VWS. Deze
functionaliteit wordt onvoldoende geboden door andere gebruikte technische
standaarden. Ook in het Integraal Zorgakkoord (onderdeel I, 2.1, B, k op blz 94)
hebben partijen zich gecommitteerd aan de implementatie van FHIR. De
verwachting is dat voor grensoverschrijdende gegevensuitwisseling binnen de
Europese Unie ook wordt overgegaan op FHIR.

1 Het Informatieberaad heeft 21 september 2020 besloten dat waar mogelijk de

stap naar FHIR gemaakt moet worden.

Pagina 2 van 5

Om tot implementatie van de FHIR standaard te komen is verdere duidelijkheid
nodig over welke versie(s) van technische uitwisselingsstandaard(en) leidend zijn
bij de uitwisseling van gegevensontwikkeling.
Het gebruik van FHIR en Zibs zijn een belangrijke randvoorwaarde om tot
gegevensuitwisseling te komen. Echter, consistent gebruik van de juiste
terminologie, adequate dossiervoering en uitrol en gebruik van zogenaamde
generieke functies zijn ook belangrijke randvoorwaarden die ook nog niet overal
voldoende zijn ingevuld. Parallel aan de uitvoering van het voorliggende besluit
wordt aan andere tafels met VWS, zorgverleners en andere betrokkenen gewerkt
om de situatie voor de andere randvoorwaarden te verbeteren.

Secretaris Generaal / plv.
Secretaris Generaal
Directie Informatiebeleid /
CIO
Cluster iBeleid team A
Datum
21 oktober 2022

Ad 1, 2 en 3 – Generieke standaarden
Generieke standaarden hebben binnen het stelsel van standaarden een bijzondere
status. Het zijn de bouwblokken voor use case specifieke standaarden.
Standaarden die (ongeveer) hetzelfde doen als de generieke standaarden binnen
het stelsel moeten zo snel als mogelijk vervangen worden door de generieke
standaarden om interoperabiliteit te realiseren.
De meeste standaarden die FHIR toepassen zitten op de versies STU3 of R4 2.
Daarom is gekozen om beide versies als generieke technische
uitwisselingsstandaard te definiëren. De meeste standaarden die Zibs toepassen
zitten op versie 2017 of versie 2020. Daarom is gekozen beide versies als
generieke semantische standaard te definiëren.
In de praktijk wordt de semantische standaard Zibs 2017 alleen gebruikt samen
met de technische uitwisselingsstandaard FHIR STU3. Zibs 2020 wordt alleen
gebruikt samen met FHIR R4. Het is de bedoeling deze praktijk te bestendigen.
Zibs dekken niet alle zorginformatie dat uitgewisseld wordt. Wanneer er geen zib
beschikbaar is om de benodigde zorginformatie op te nemen in de
uitwisselingsstandaard zijn andere semantische standaarden ontwikkeld door
betrokkenen. Conform dit besluit wordt van standaardhouders verwacht dat zij
ook in deze situatie FHIR STU3 of FHIR R4 als technische uitwisselingsstandaard
gebruiken. Naast de technische transportlaag, bevat FHIR daarnaast ook een
semantische “core”. Deze semantische core valt buiten dit besluit,
standaardhouders hoeven de semantische core van FHIR niet op te nemen in hun
uitwisselingsstandaard.
Op één onderdeel wijkt dit besluit expliciet af van het advies van Nictiz na
consultatie van dit besluit met betrokken partijen. Nictiz adviseert om te werken
met een huidige (actuele) en toekomstige versie van de generieke standaarden.
Over een aantal jaar zal de toekomstige versie als de actuele versie worden
gedefinieerd en dient de huidige versie uitgefaseerd te worden. Als toekomstige
versie stelt Nictiz FHIR R4 en Zibs 2020 voor. Nictiz adviseert daarnaast om de
geldigheid van Zibs 2017 en FHIR STU3 te beëindigen per 1 januari 2025.
Dit besluit wijkt af van dit advies. Zibs 2020 en FHIR R4 zijn reeds enige tijd in
omloop en binnen enkele jaren worden nieuwe versies verwacht van FHIR en van
Zibs. Daarom is gekozen om nu geen toekomstige versie te definiëren, maar twee
huidige versies. Dit geeft de flexibiliteit om - wanneer meer duidelijk is over de

Zie het bijgevoegde rapport van Nictiz waarin meer toelichting wordt
gegeven op deze versies.
2

Pagina 3 van 5

nieuwe releases van Zibs en FHIR – eventueel de implementatie van Zibs 2020 of
FHIR R4 over te slaan. Over het al dan niet overslaan en over hoe lang Zibs 2017
en FHIR STU3 gebruikt kan worden, wordt besloten wanneer meer duidelijk is over
de nieuwe releases. Daarbij wordt een werkbare overgangstermijn afgesproken.
Vanwege de functionele meerwaarde van Zibs 2020 ten opzichte van Zibs 2017
worden zorgaanbieders wel aangemoedigd om Zibs 2020 in combinatie met FHIR
R4 te implementeren, mits dit in te passen is in de ontwikkelcapaciteit van
softwareleveranciers.

Secretaris Generaal / plv.
Secretaris Generaal
Directie Informatiebeleid /
CIO
Cluster iBeleid team A
Datum
21 oktober 2022

Ad 4 – Translatie
Het is ongewenst dat gegevensuitwisseling wordt bemoeilijkt tussen partijen die
werken met verschillende generieke uitwisselingsstandaarden. In dit geval gaat
het om de twee versies van Zibs op de verschillende versies van FHIR. Op verzoek
van VWS stelt Nictiz de translatiespecificatie op tussen de twee Zib versies en
neemt deze daarna in beheer. Het is vervolgens aan softwareleveranciers om de
translatie in systemen in te bouwen op verzoek van zorgaanbieders wanneer dit
nodig is voor de gegevensuitwisseling met ketenpartners. Deze translatie kan
mogelijk ook gebruikt worden om ondersteuning te bieden in situaties waarbij
gegevens in de EPD worden verwerkt op basis van Zibs 2017, maar in de
uitwisseling al over gaat naar Zibs 2020.
Ad 5 – Migratieplannen
De overstap naar generieke standaarden kan en hoeft niet overal even snel te
verlopen. Bij ziekenhuizen is in het kader van de BGZ de urgentie groot om over
te stappen van CDA naar FHIR. Andere partijen hebben juist recentelijk
geïnvesteerd in de implementatie van CDA. De migratieplannen kunnen dus een
verschillend tijdpad hebben. De tijdelijk stelselbeheerder zal beoordelen of de
voorgestelde tijdpaden tot belangrijke knelpunten in de gegevensuitwisseling
leiden en daarover de stelselhouder informeren (zie hieronder: vervolgproces).
NB, in het IZA is door veldpartijen het commitment uitgesproken om zowel de
aanpassingen aan de softwaresystemen van leveranciers als de implementatie
daarvan bij zorgaanbieders uiterlijk 31 december 2025 af te ronden.
Het is de verantwoordelijkheid van de standaardhouder om het migratieplan op te
stellen. VWS zal de standaardhouders daarover berichten. De standaardhouder zal
dit echter niet alleen kunnen. Het is daarom de verwachting dat de
standaardbeheerder in vrijwel alle gevallen door de standaardhouder gevraagd
wordt een voorstel te formuleren voor een migratieplan. Het is dan vervolgens aan
de standaardhouder om te waarborgen dat het migratieplan op draagvlak kan
rekenen bij zorgverleners, andere stakeholders zoals patiënten en uitvoerbaar is
voor softwareleveranciers. Dit kan via (consultatie van) een autorisator (zie NEN
7522). Het aanspreekpunt voor VWS is en blijft echter de standaardhouder.
Nictiz coördineert als tijdelijk stelselbeheerder de activiteiten rondom het opstellen
van migratieplannen en is beschikbaar voor nadere toelichting.

Pagina 4 van 5

Vervolgproces
Na aanlevering beoordeelt Nictiz als tijdelijk stelselbeheerder de migratieplannen.
Deze beoordeling ziet op of de plannen voldoen aan de inhoudelijke eisen,
conform de uitgangspunten en werkwijze. De focus ligt op de migratie van CDA
naar FHIR.
Daarnaast zal de tijdelijk stelselbeheerder bekijken in hoeverre de uitvoering van
de migratieplannen leidt tot knelpunten in de gegevensuitwisseling. Dit kan
bijvoorbeeld het geval zijn wanneer de ene ketenpartner met de grootst mogelijke
spoed overstapt op de generieke standaard, terwijl de andere ketenpartner een
dergelijke spoed niet haalbaar of wenselijk vindt. In deze gevallen zal Nictiz
contact zoeken met de betreffende standaardhouders om dit probleem te
signaleren en oplossingen te verkennen. In deze gevallen wordt meegewogen hoe
ernstig de belemmeringen zijn die voortvloeien uit het gebruik van een
verouderde standaard versus de kosten/inspanningen om snel te migreren. Deze
analyse kan leiden tot aanpassingen in de migratieplannen.

Secretaris Generaal / plv.
Secretaris Generaal
Directie Informatiebeleid /
CIO
Cluster iBeleid team A
Datum
21 oktober 2022

Na beoordeling van de migratieplannen stelt Nictiz een advies op voor VWS over
de migratieplannen. Dit advies bevat ook afwegingen over hoe om te gaan met
knelpunten in de migratie. VWS zal na consultatie met stakeholders, inclusief
softwareleveranciers, de knoop doorhakken hoe om te gaan met deze knelpunten.

Pagina 5 van 5

Advies HL7 CDA en HL7 FHIR 2

Voorwoord
Deze notitie is geschreven door Nictiz vanuit onze expertise op het gebied van standaarden.
Bedoeld als advies aan de partij (het ministerie van VWS) die binnen de beoogde Stelselregie de rol
heeft van tijdelijk stelselhouder. Bij de totstandkoming van dit advies hebben we waar mogelijk de
procedures gevolgd binnen de beoogde Stelselregie. Zoals het consulteren van relevante
stelselpartijen en -experts zoals leveranciers1.
Met deze notitie wil Nictiz de tijdelijk Stelselhouder van een advies voorzien. Dit over de op dit
moment gebruikte versies van technische standaarden voor uitwisseling en de op dit moment
gebruikte versies van de zorginformatiebouwstenen (zibs).
In de voorbereidingen op dit advies en in de met relevante veldpartijen gevoerde gesprekken
daarover, kwamen we tot het inzicht dat het verstandig is onderscheid te maken tussen:
1. De principiële kant van het vraagstuk. Met name het voorstel om dit vraagstuk op
stelselniveau (en dus zorgbreed) te positioneren en wat dit betekent voor relevante
veldpartijen.
2. De feitelijke invulling. Met mogelijke oplossingen voor diverse situaties, zoals het inzetten
van translatiediensten voor de overgang van CDA naar FHIR en/of de overgang van
zibs2017 naar zibs2020.
Het eerste deel (de principiële kant) hebben we in een ‘tussenrapportage’ geformuleerd en
gepresenteerd op de houderschapsdag van 10 november 2022. Dit document is de eindrapportage.
Dit advies, het besluit daarover en de daarop volgende inrichting kun je beschouwen als een eerste
concrete inrichting van Stelselregie, zoals bepleit in het Rapport – Model voor Stelselregie2.

1

Voor deze versie van dit document z jn geconsulteerd: VIPP5, VZVZ, HL7-experts van Nictiz, ChipSoft, Epic, Nexus,

Productmanagers Nictiz (PDM), waaronder PDM MedMij, Nictiz-MT
2

Model voor stelselregie - Nictiz

Advies HL7 CDA en HL7 FHIR 4

Samenvatting
Zorginstellingen in Nederland maken voor de digitale uitwisseling van informatie gebruik van tal
van informatiestandaarden. Binnen deze standaarden worden verschillende technische
standaarden voor het verzenden en ontvangen van medische gegevens toegepast. De
voornaamste zijn HL7 Clinical Document Architecture (CDA) en twee versies van HL7 Fast
Healthcare Interoperability Resources (FHIR), hierna kortweg CDA en FHIR genaamd.
Het gevolg is dat zorginstellingen die verschillende technische standaarden hanteren, informatie
niet digitaal kunnen uitwisselen óf dat hun informatiesystemen meerdere standaarden moeten
ondersteunen. Dit vormt een belangrijke belemmering bij het op landelijke schaal realiseren van
digitale uitwisseling van informatie tussen zorginstellingen en met patiënten.
In mei hebben NFU, NVZ en ZKN in een brief aan VWS aangegeven dat het naast elkaar bestaan
van CDA en FHIR een van de knelpunten vormt bij de landelijke invoering van de BgZ tussen
instellingen voor medisch specialistische zorg. Ziekenhuizen en UMC’s gebruiken overwegend
CDA, zelfstandige klinieken en categorale instellingen wisselen informatie voornamelijk uit op
basis van FHIR.
Dit vraagstuk speelt binnen de zorg echter op bredere schaal dan alleen bij de BgZ. Daarnaast is
de technische uitwisseling van informatie gerelateerd aan de verschillende publicatie versies van
de zibs. Daarom heeft VWS aan Nictiz gevraagd te onderzoeken op welke wijze we meer
uniformiteit kunnen bereiken bij het toepassen van deze zogeheten generieke standaarden.
Vertrekpunt bij dit onderzoek was het vraagstuk rondom CDA en FHIR in relatie tot het gebruik
van zibs. Keuzes ten aanzien van andere generieke standaarden, bijvoorbeeld op het gebied van
infrastructuur en beveiliging, staan hier los van. Deze hebben we in het rapport buiten
beschouwing gelaten en dienen apart te worden geadresseerd.
In het bijgaande rapport adviseren we allereerst om als algemeen beleid vast te stellen dat er
binnen het stelsel van informatiestandaarden niet meer dan twee zogeheten baselineversies
van generieke standaarden zijn toegestaan: een huidige (vigerende) versie en een toekomstige
versie.
Vervolgens stellen we specifiek voor het vraagstuk CDA - FHIR FHIR versie STU3 als huidige
baseline voor en FHIR versie R4 als toekomstige baseline. Gezien de nauwe relatie tussen zibs
en standaarden voor uitwisseling, stellen we tevens voor om als huidige baseline Zibs-2017 te
hanteren en als toekomstige baseline Zibs-2020.
Deze fundamentele stelselbrede beleidskeuzes betekenen dat houders van
informatiestandaarden niet meer hun eigen afwegingen kunnen maken bij het toepassen van
generieke standaarden. Dit voorkomt deeloplossingen en vermindert daarmee het risico dat
instellingen en hun leveranciers worden geconfronteerd met incompatibele standaarden die
gegevensuitwisseling belemmeren of kostbare aanpassingen vergen.
Daarnaast geeft dit beleid leveranciers duidelijkheid over investeringen in toekomstige
generieke standaarden. Een voldoende lange overgangstermijn biedt hun de garantie dat zij
investeringen kunnen terugverdienen.
De implementatie van deze beleidskeuzes kost veel tijd en inspanning. Daarom vragen we
houders van informatiestandaarden om migratieplannen op te stellen voor de uitfasering van
oudere versies van generieke standaarden.
De BgZ-uitwisseling voor medisch specialistische zorg (VIPP5 module 3) heeft op korte termijn
behoefte aan concrete oplossingen. Dit werken we dan ook uit in een apart document in de
vorm van een migratieplan. Specifiek voor de BgZ-uitwisseling voor medisch specialistische zorg
werken we daarin uit wat de impact is van de migratie van CDA naar FHIR.

1
Inleiding

Inleiding Advies HL7 CDA en HL7 FHIR 6

1.1 Aanleiding
De uitwisseling van zorginformatie en de daarvoor benodigde standaardisatie is voortdurend in
beweging en wordt beïnvloed door zowel ontwikkelingen vanuit de zorg (bijvoorbeeld
patiëntparticipatie en multidisciplinaire samenwerking), als door technologische ontwikkelingen.
Ontwikkelingen vanuit de zorg vinden vooral hun weerslag in nieuwe versies van de zibs (als
generieke standaarden) en in nieuwe versies van de uscase-specifieke informatiestandaarden die
de zibs gebruiken. Ontwikkelingen in de technologie vinden hun weerslag vooral in nieuwe versies
van technische standaarden voor uitwisseling.
In de praktijk hebben de relevante partijen die betrokken zijn bij zo’n informatiestandaard, per
uitwisseling keuzes gemaakt voor de te gebruiken technische standaarden en voor de versies van
zibs. En soms, vooral bij de al wat oudere informatiestandaarden, alleen keuzes voor technische
standaarden voor uitwisseling.
Een voorbeeld daarvan is de BgZ-uitwisseling tussen instellingen voor medisch specialistische zorg
(VIPP5 module 3). Recent (12 mei 2022), hebben NFU, NVZ en ZKN een brandbrief aan VWS gestuurd
om hun zorgen over landelijke uitwisseling en de haalbaarheid van VIPP5 module 3 kenbaar te
maken. In die brandbrief pleit men onder andere voor het binnen uiterlijk vijf jaar beëindigen van
het toestaan van verschillende technische standaarden en het verplicht stellen van uitwisseling
van de BgZ op basis van HL7 FHIR.
In september 2022 is in het Integraal Zorgakkoord3 afgesproken dat om interoperabiliteit te
bereiken alle zorgaanbieders en leveranciers in 2025 minimaal […] kerngegevens moeten kunnen
uitwisselen, waarbij uitwisseling van zibs via de FHIR-standaard plaatsvindt. In dit advies wordt de
keuze voor FHIR beargumenteerd en worden de consequenties van deze keuze nader uitgewerkt.
Met de introductie van Stelselregie positioneren we de overkoepelende, noodzakelijke afspraken
over bijvoorbeeld geldige versies van zibs en geldige versies van technische specificaties voor
uitwisseling op stelselniveau. Stelselregie (een stelsel van standaarden) is gebaseerd op NEN75224.
Voor de werking van Stelselregie baseren we ons vooralsnog op het Rapport – Model voor
Stelselregie V6.4’5, waarin Nictiz advies geeft op de inrichting en werking van Stelselregie.
Ons belangrijkste uitgangspunt hierbij is dat men keuzes voor toepassing van generieke
standaarden binnen informatiestandaarden maakt op stelselniveau in gezamenlijke
besluitvorming door de houder van het stelsel en de veldpartijen.

3

onderdeel I, 2.1, B, k op blz. 94

4

https://www.nen.nl/nen-7522-2021-nl-283706

5

Model voor stelselregie - Nictiz

Inleiding Advies HL7 CDA en HL7 FHIR 7

1.2 Vraagstelling
Bij de uitwisseling van informatie in de zorg worden verschillende versies van technische
standaarden voor uitwisseling van gegevens gebruikt (zoals HL7 FHIR en HL7 CDA). Dit belemmert
de uitwisseling van informatie tussen zorginstellingen. De centrale vraag is: op welke wijze kunnen
stelselbrede keuzes voor beperking van het aantal versies van technische standaarden die
belemmering ? En: wat is daarvoor nodig?

1.3 Scope
Wat betreft de informatievoorziening in de zorg is het gebruikelijk om het lagenmodel van Nictiz6
te hanteren als leidraad. Dit advies beperkt zich tot de informatie- en applicatielaag van het dit
model, in onderstaande figuur weergegeven met de rode stippellijn:

Figuur 1 - Lagenmodel Interoperabiliteit en scope dit rapport

Deze beperking plaatst een aantal belangrijke onderwerpen voor de daadwerkelijke uitwisseling
van informatie buiten de scope, met name:
1. Afspraken en beschikbaarheid van voorzieningen op het gebied van infrastructuur
(Infrastructuurlaag.
2. Afspraken en beschikbaarheid van voorzieningen op het gebied van beveiliging (verticale
kolom Beveiliging) en meer specifiek op het gebied van:
― Identificatie en authenticatie
3. Afspraken en beschikbaarheid van voorzieningen op het gebied van wet- en regelgeving
(verticale kolom Wet- en regelgeving), en meer specifiek op het gebied van:
― Toestemming van de patiënt voor uitwisseling
― Autorisatie

6

https://nictiz.nl/wat-we-doen/zorginformatiestelsel/interoperabiliteit/lagenmodel/

2
Huidige situatie

Huidige situatie Advies HL7 CDA en HL7 FHIR 10
generieke standaarden. Het onderscheid tussen informatiestandaarden en generieke
standaarden is beschreven in de NEN75227 norm voor de ontwikkeling en het beheer van
standaarden.

2.2 Informatielaag
Op de informatielaag van het interoperabiliteitsmodel zijn de generieke afspraken gepositioneerd
over de uit te wisselen informatie. Dit noemen we semantische standaarden.
Zibs gaan over de betekenis van informatie en zijn een voorbeeld van een semantische standaard.
Zibs zijn niet alleen in het Nederlandse zorgveld geadopteerd, maar de zib-methodiek (namelijk
clinical modelling) wordt ook internationaal erkend. In februari 2022 kwam, gesteund door een
kleine 40-tal landen, een internationale ISO-standaard voor de zibs beschikbaar: ISO139738. Op dit
moment zijn de meest relevante versies: Zib Publicatie 2017 en Zib Publicatie 2020 (hierna verder
kortweg Zibs-2017 en Zibs-2020). Zibs zijn techniek-onafhankelijk en dus ook onafhankelijk van
technische specificaties voor uitwisseling.
Naast zibs is de BgZ9 ook een belangrijke generieke standaard. De BgZ is een minimale set
patiëntengegevens die altijd relevant is voor het zorgproces. Deze dataset is opgebouwd uit zibs,
techniek-onafhankelijk en gekoppeld aan de vigerende zib-publicatie. Zie bijlage 1 voor een
analyse van de verschillen tussen de verschillende zib-publicaties en de BgZ.

2.3 Applicatielaag
Op de applicatielaag van het interoperabiliteitsmodel zijn de afspraken gepositioneerd voor
technische uitwisselingsformaten. Dit noemen we syntactische standaarden.
Een oude, sinds ongeveer 1990 beschikbaar zijnde, maar nog steeds gebruikte standaard op dit
gebied is Edifact (Electronic Data Interchange For Administration, Commerce and Transport). Met
deze standaard kun je berichten versturen via netwerken zoals OZIS of Zorgmail.
In Nederland gebruiken we vooral standaarden van HL7 voor gegevensuitwisseling in de zorg .
Daarbij zijn er twee hoofdstromen: HL7 v3 CDA10 en HL7 FHIR11. Bij CDA (Clinical Document
Architecture) stuurt het bronsysteem gegevens in de vorm van documenten naar het ontvangende
systeem.
Bij FHIR (Fast Healthcare Implementation Resources) is sprake van een vraag-antwoordspel waarbij
de ontvangende partij gegevens opvraagt bij het bronsysteem dat daarvoor een standaard API
(Application Programming Interface) aanbiedt.
FHIR is moderner en biedt meer flexibiliteit door het gebruik van API’s. Ook internationaal kijkt men
in toenemende mate naar de mogelijkheid om van HL7 CDA de overstap te maken naar HL7 FHIR.
Sinds 2015/2016 heeft HL7 FHIR de dominantie overgenomen van HL7 v3 CDAr. In 2015 is FHIR STU3
beschikbaar gekomen en vanaf 2018 de nieuwe versie: FHIR R4. Zie bijlage 1 voor een verdere
toelichting op de verschillen tussen CDA en FHIR.

7

https://www.nen.nl/nen-7522-2021-nl-283706

8

Zie https://www.iso.org/standard/79498.html

9

Niet te verwarren met de informatiestandaarden BgZ uitwisseling Medische Specialistische Zorg en BgZ uitwisseling PGO (zie

tabel 1)
10

In Nederland gebruiken we één versie van HL7 CDA. Wereldwijd/internationaal is dat niet (altijd) zo en bij internationale

uitwisselingen gaan verschillende versies van HL7 CDA een rol spelen.
11

HL7 FHIR is niet alleen technisch: HL7 FHIR kent ook functionele specificaties in de vorm van Resources.

Huidige situatie Advies HL7 CDA en HL7 FHIR 11
Op verzoek van het Informatieberaad in 2020 adviseerde12 HL7 Nederland in 2020 over te stappen
op FHIR. De belangrijkste argumenten daarvoor zijn:
― FHIR is meer gebaseerd op een vraaggestuurde informatie-uitwisseling van individuele
gegevenselementen. Daardoor is het veel beter geschikt voor inzage, bewerking en
completering van medische dossiers, alsmede dataverzameling, onderzoek en communicatie
met de patiënt.
― FHIR is gebaseerd op gangbare ontwikkelstandaarden buiten de zorg waardoor de
ontwikkelsnelheid van nieuwe toepassingen hoog is.
In het Informatieberaad in september 202013 is geconcludeerd dat er veel draagvlak is voor de stap
naar FHIR.

2.4 Combinatie van generieke standaarden
De hiervoor genoemde standaarden voor de informatielaag en de applicatielaag zijn niet geheel
onafhankelijk. Hoewel in theorie de verschillende versies van zibs (Publicaties 2017 en 2020)
onafhankelijk zijn van de technische uitwisseling (CDA of FHIR – en daarbinnen STU3 en R4), komen
sommige combinaties in de praktijk niet voor.
Er zijn bijvoorbeeld geen (in ieder geval geen complete) HL7 CDA en HL7 FHIR STU3 specificaties
van Zibs-2020 en geen HL7 FHIR R4 specificaties van Zibs-2017 beschikbaar. De reden hiervan is
dat HL7 CDA en HL7 FHIR STU3 en Zibs-2017 verouderd raken en het daardoor niet zinvol is om in
verouderde versies te investeren. Daarom is een keuze voor een bepaalde versie van technische
specificaties voor uitwisseling een impliciete keuze voor een versie van de zibs, en vice versa.
In de praktijk zijn er momenteel in hoofdlijnen drie combinaties te onderscheiden:
1. Zibs-2017 en HL7 CDA
2. Zibs-2017 en HL7 FHIR STU3
3. Zibs-2020 en HL7 FHIR R4
Daarnaast is sprake van uitwisseling van gegevens op basis van oudere standaarden, onder andere:
4. Niet zib-gebaseerd en HL7 V314
5. Niet zib-gebaseerd en Edifact.
N.B. dit overzicht is niet bedoeld als uitputtend of volledig, maar geeft de hoofdlijnen aan.
In bijlage 1 geven we een gedetailleerd overzicht van de huidige en geplande versies van generieke
standaarden per informatiestandaard.

12

Zie https://www.hl7.nl/component/zoo/item/hl7-cda-vergeleken-met-hl7-fhir.html

13

1b1 Concept verslag IB 21 september 2020 | Verslag | Informatieberaad Zorg

14

Het kan, vooral bij wat oudere informatiestandaarden, nog sporadisch voorkomen dat HL7 CDA of HL7 FHIR gekozen zijn als
technisch uitwissel formaat, zonder gebruik te maken van een versie van de zibs op de informatie laag (voor de betekenis van
de informatie, die uitgewisseld wordt). Maar bij (grote) revisies van oude informatiestandaarden en nieuwe
informatiestandaarden is dat niet meer het geval: dan wordt ook een keuze gemaakt voor een versie van de zibs.

3
Probleemstelling
en advies

Probleemstelling en advies Advies HL7 CDA en HL7 FHIR 14

Het naast elkaar voorkomen van verschillende (versies van) generieke standaarden16, vormt een
belemmering voor de uitwisseling van informatie omdat deze standaarden niet volledig
compatibel zijn. Zo kan een informatiesysteem met een CDA-interface geen gegevens uitwisselen
met informatiesysteem met een FHIR-interface.
Het gevolg is dat de uitwisseling van informatie niet digitaal kan plaatsvinden of dat een
informatiesysteem meerdere standaarden moet ondersteunen. Dit betekent in de praktijk dat een
informatiesysteem (bijvoorbeeld een EPD), voor de ene uitwisseling HL7 CDA moet ondersteunen,
voor de volgende uitwisseling HL7 FHIR STU3, en voor een ander uitwisseling HL7 FHIR R4. Het
ondersteunen van meerdere standaarden is kostenverhogend en zorgt bij leveranciers voor
terughoudendheid bij de adaptie van nieuwe standaarden.
Daarnaast leidt de keuze uit verschillende generieke standaarden tot onzekerheid over de te kiezen
richting en daardoor soms tot uitstel van keuzes. Die onzekerheid wordt versterkt door de
constatering dat de generieke standaarden op de informatielaag (de zibs) en de generieke
standaarden op de applicatielaag (HL7 CDA en HL7 FHIR) in beweging zijn: een nieuwe versie van
de zibs (Zibs-2020) bevat meer en betere functionaliteit dan de vorige versie, en HL7 FHIR als
opvolger van HL7 CDA is meer toegerust voor moderne manieren van uitwisseling, zoals via API’s.

Een voorbeeld van deze situatie is de BgZ-uitwisseling tussen instellingen voor medisch
specialistische zorg. Daarbij hebben de grotere ziekenhuizen (en hun leveranciers) gekozen voor
CDA (meestal CDA via XDS) , terwijl de zelfstandige klinieken (en hun leveranciers) inzetten op HL7
FHIR (STU3). Deze heeft men gemaakt zonder overkoepelende, zorgbrede afspraken over de te
gebruiken geldige versies en de overgang van oud naar nieuw. Inmiddels wordt gewerkt aan het
beschikbaar stellen van de generieke standaarden zibs2020 en HL7 FHIR R4, onder meer ter
vervanging van oudere vormen van uitwisseling van gegevens.
Dit leidt tot een onacceptabele situatie: uitwisseling van de BgZ tussen instellingen, met name
tussen zelfstandige klinieken en ziekenhuizen, is niet mogelijk. Daarnaast weten zelfstandige
klinieken (en hun leveranciers) niet zeker waar ze op moeten inzetten en in moeten investeren
(VIPP5-module 3). Een van de zichtbare gevolgen van de bovenstaande problemen is dat de VIPP5module 3 regeling vooral wordt gebruikt voor het realiseren van point-to-point uitwisselingen, maar
niet voor duurzame uitwisseling van de BgZ tussen alle instellingen voor medisch specialistische
zorg. Deze problematiek hebben we nader uitgewerkt in bijlage 2.

3.2 Oorzaak – gebrek aan regie
Het naast elkaar bestaan van een veelvoud aan generieke standaarden, wordt primair veroorzaakt
doordat de houders van informatiestandaarden hun eigen afwegingen maken bij de keuze van
generieke standaarden. Ook leveranciers maken hun eigen keuzes over op welke standaarden men
inzet en waarin men investeert. Er is tot nu geen sprake geweest van zorgbrede overkoepelende
regievoering die leidt tot heldere en eenduidige afspraken ten aanzien van:
1. de gewenste en toegestane generieke standaarden;
2. de baseline (de generieke standaarden, waar iedereen aan moet voldoen);
3. de migratie van de baseline naar de eerstvolgende baseline.

16

Er zijn ook belemmeringen ten aanzien van de infrastructuur, beveiliging en wet- en regelgeving, maar die zijn buiten de scope

van dit advies, zie Figuur 1 - Lagenmodel Interoperabiliteit en scope dit rapport.

Probleemstelling en advies Advies HL7 CDA en HL7 FHIR 15
In de praktijk lossen de betrokken partijen interoperabiliteitsvraagstukken op adhoc basis op
door:
a) aanpassing van systemen bij een van de bij de uitwisseling betrokken partijen, zodat beide
partijen dezelfde generieke standaarden gebruiken, of
b) een translatie (‘vertaling’), die er voor zorgt dat uitwisseling mogelijk wordt. Zo’n translatie kan
lokaal, dat wil zeggen onder verantwoordelijkheid van de verzendende of ontvangende partij
in de uitwisseling worden uitgevoerd, of (centraal) onder verantwoordelijkheid van een derde
partij.
Deze keuzes kunnen lokaal weliswaar tot een oplossing leiden, maar zijn suboptimaal omdat er
zorgbreed nog steeds verschillen zijn. Uit figuur 2 blijkt dat elke aanpassing op het niveau van
individuele informatiestandaarden weliswaar een specifiek probleem kan oplossen, maar elders
weer nieuwe problemen kan creëren. De keuze voor generieke standaarden dient daarom op
stelselniveau te worden genomen.

3.3 Oplossingsrichting
De ideale oplossing voor de bovenstaande problematiek is om zorgbreed gebruik te maken van
één set van generieke standaarden. Het vergt echter een zeer grote inspanning en doorlooptijd om
daar te komen. Ondertussen zullen zorginhoudelijke en technische ontwikkelingen er steeds weer
toe leiden dat er behoefte is aan ontwikkeling van de standaarden.
Een meer praktische benadering is om zorgbreed te streven naar twee baselineversies van
generieke standaarden: één vigerende en één toekomstige. Daarbij dient men afspraken te maken
over een overgangstermijn voor zorgaanbieders en hun leveranciers om te migreren van de
bestaande naar de toekomstige baseline.
Dit schept duidelijkheid voor leveranciers over de toekomstige set van generieke standaarden
waarin men moet investeren. Een voldoende lange overgangstermijn biedt leveranciers de
garantie dat zij de investeringen in de huidige baselineversie in de toekomst kunnen
terugverdienen. Het betekent ook dat we op termijn afscheid moeten nemen van een aantal
oudere generieke standaarden. Dit is weergegeven in figuur 3.
Ontwikkeling
Generieke
standaard

D (toekomstige baseline)
C (huidige baseline)

B (verouderd)
A (verouderd)
Nu

Tijd

Figuur 3 – Illustratie levensloop van generieke standaarden.
In deze figuur zie je schematisch vier versies van een generieke standaard. A en B zijn verouderd.
Deze dienen zo snel als mogelijk te worden uit gefaseerd. C is een modernere standaard waarop
recentelijk door leveranciers is geïnvesteerd. Ondertussen wordt echter al gewerkt aan combinatie
D. Door toe te werken naar C en D als baseline, worden investeringen in C zeker gesteld en tevens
perspectief geboden op toekomstige vernieuwingen. De benadering van werken met twee

Probleemstelling en advies Advies HL7 CDA en HL7 FHIR 16
baselineversies, namelijk één vigerende en één toekomstige, is vergelijkbaar met het beleid van
leveranciers van softwareplatformen.
De eerste stap is het zorgbreed vaststellen opstellen van een beleid dat sprake is van twee
baselineversies van generieke standaarden binnen het beoogd stelsel: een huidige en een
toekomstige. Daarbij worden de volgende uitgangspunten gehanteerd:
― De keuze voor generieke standaarden wordt zorgbreed gemaakt en vormt daarmee een
stelselvraagstuk.
― Er zijn slechts twee baselines versies: een huidige en een toekomstige.
― Voor zowel de informatielaag als de applicatielaag worden baselines voor generieke
standaarden vastgesteld.
― Overige versies van generieke standaarden worden niet geldig verklaard. Dat betekent dat men
bij nieuwe (versies van) informatiestandaarden geen gebruik kan maken van deze generieke
standaarden.

3.4 Uitwerking consequenties
Het beleid van het hanteren van twee baselineversies van generieke standaarden heeft een aantal
consequenties. In de eerste plaats moet het concreet gemaakt worden ten aanzien van de
bestaande standaarden. In de tweede plaats moet de impact van een dergelijke keuze nader
worden uitgewerkt en ten slotte moet men afspraken maken over het transitie pad.
Concreet betekent dit dat we de volgende vragen moeten beantwoorden:
1. Welke generieke standaarden worden aangewezen als huidige en toekomstige baseline?
Zoals in hoofdstuk 2 is aangegeven zijn niet op zibs gebaseerde standaarden en de op HL7 V3
CDA gebaseerde standaarden inmiddels verouderd en wordt (internationaal) steeds meer
gebruik gemaakt van FHIR. Daarom is het advies om zo snel mogelijk deze oude generieke
standaarden niet meer geldig te verklaren. Dit houdt in dat nieuwe (versies van)
informatiestandaarden gebaseerd op ongeldige versies van generieke standaarden niet meer
toegelaten worden tot het stelsel.
Bij het ontwikkelen van nieuwe informatiestandaarden wordt het daardoor verplicht om
gebruik te maken van de volgende generieke standaarden:
― Zibs-2017 als huidige baselineversie of Zibs-2020 als toekomstige baselineversie;
― FHIR STU3 als huidige baselineversie of FHIR R4 als toekomstige baselineversie.
NB1. Op dit moment zijn zogenaamde ‘stelselcriteria’ (stelselkaders) in ontwikkeling. De
keuzes voor de genoemde huidige baselineversie en toekomstige baselineversie zullen nog aan
deze stelselcriteria moeten worden getoetst.
NB2. Het aanwijzen van twee baselines versie voor zowel de informatielaag als de
applicatielaag betekent dat er in theorie vier geldige combinaties zijn. Een dergelijk groot
aantal varianten is nog steeds ongewenst uit oogpunt van interoperabiliteit en kosten. Zoals
we in paragraaf 2.4 is constateerden, komen momenteel echter in de praktijk slechts twee
combinaties voor: a) Zibs-2017 in combinatie met FHIR STU3 en b) Zibs-2020 in combinatie
met FHIR R4. Ons advies is om voorlopig alleen deze combinaties toe te staan. Zodra er
behoefte ontstaat aan een nieuwe baselineversie voor zibs én op dat moment ook een nieuwe
versie van FHIR beschikbaar is (bijvoorbeeld R5), zal men op stelselniveau nieuwe afwegingen
moeten maken.

Probleemstelling en advies Advies HL7 CDA en HL7 FHIR 17
2. Wanneer worden de huidige baselineversies Zibs-2017 en FHIR STU3 niet meer geldig
verklaard?
Omdat al wordt nagedacht over een volgende publicatieversie van Zibs(-2024?) en een
volgende versie van FHIR (FHIR R5) in aantocht is, is de vraag hoe lang Zibs-2017 en FHIR STU3
als baselineversies worden gehanteerd. Om zorgaanbieders en leveranciers voldoende
duidelijkheid te bieden moet een termijn worden bepaald waarbinnen deze standaard geldig
blijft. Daarom stellen wij voor om zowel Zibs-2017 als FHIR STU3 geldig te verklaren tot 1
januari 2025.
3. Wat betekent het niet meer geldig verklaren van generieke standaarden voor
informatiestandaarden?
De keuze (zie 1) voor de huidige en de toekomstige baselineversies voor generieke standaarden
impliceert dat oudere versies per direct niet meer geldig worden verklaard. Dat geldt
bijvoorbeeld voor Edifact en HL7 V3 CDA.
Het per direct niet meer geldig verklaren van oudere generieke standaarden impliceert niet dat
bestaande uitwisselingen van gegevens, die op de hiervoor genoemde oudere generieke
standaarden zijn gebaseerd, zo snel mogelijk moeten worden aangepast. Zo heeft men
bijvoorbeeld recentelijk geïnvesteerd in de combinatie van Zibs-2017 met HL7 V3 CDA.
Dit impliceert wél dat, onder verantwoordelijkheid van de standaardhouder, voor de
betreffende standaard een migratieplan moet worden opgesteld. Die moet het tijdspad
beschrijven waarin men moet overgaan van de verouderde, niet meer geldige generieke
standaard, naar de geldige generieke standaard.
Dit migratieplan zal op stelselniveau beoordeeld moeten worden, waarbij meegewogen moet
worden hoe ernstig de belemmeringen zijn die voortvloeien uit het gebruik van een
verouderde standaard versus de kosten en inspanningen om snel te migreren. Dus wat nodig
is per informatiestandaard, zijn:
― het opstellen van een migratieplan;
― de besluitvorming hierover, inclusief het commitment om het plan uit te voeren;
― een mogelijke invulling van de financiële kaders voor de uitvoering.
Het niet meer geldig verklaren, impliceert ook dat bij het uitbrengen van nieuwe (versies van)
informatiestandaarden deze oudere generieke standaarden niet meer toegepast mogen
worden. Op basis van de verschillende migratieplannen en de bekende ontwikkeling van
nieuwe standaarden wordt de impact van de bovenstaande beleidskeuze rond generieke
standaarden op de bestaande informatiestandaarden bepaald. Vervolgens wordt aan de hand
daarvan op stelselniveau een exit-strategie van het gebruik van niet meer geldige generieke
standaarden vastgesteld.
4. Op welke wijze kan de transitie naar nieuwe generieke standaarden worden ondersteund?
Het op stelselniveau positioneren van dit vraagstuk impliceert dat er ondersteunende
maatregelen nodig zijn waaronder
a) translatievoorzieningen en
b) een monitoringfunctie.
Translatievoorzieningen
Het toewerken naar twee baselineversies van generieke standaarden impliceert dat we een
zekere overgangstijd moeten aanhouden. Gedurende deze periode zullen standaarden naast
elkaar blijven bestaan. Dit geldt zowel voor de transitie van oudere standaarden naar de

Probleemstelling en advies Advies HL7 CDA en HL7 FHIR 18
baselineversies, als de transitie van de ene naar de ander baselineversie. Daarnaast zal er
sowieso altijd sprake moeten zijn van interoperabiliteit tussen systemen met verschillende –
maar geldige – baselineversies.
Om de interoperabiliteit tussen systemen met verschillende generieke standaarden mogelijk
te maken, kan gebruik gemaakt worden van translatievoorzieningen waarbij de uitvoering kan
geschieden op een (of meer) van de volgende manieren:
― Bij en onder verantwoordelijkheid van de verzender van de informatie, die gebruikmaakt
van een niet meer geldige generieke standaard.
― Bij en onder verantwoordelijkheid van de ontvanger van de informatie, die gebruikmaakt
van een niet meer geldige generieke standaard.
― Bij een derde partij die optreedt als dienstverlener.
Uitgangspunt hierbij is dat men bij elke translatie gebruikmaakt van één op stelselniveau
vastgestelde specificatie, die de stelselbeheerder opstelt en beheert.
Monitoringfunctie
Hiermee kun je de opvolging van het besluit (de besluiten) volgen. In ieder geval zal
gemonitord moeten worden:
1. In hoeverre elke individuele standaard (al) voldoet aan de geldige baselineversies, dan
wel wanneer ze er aan gaan voldoen, op basis het migratieplan.
2. In hoeverre systemen aangepast zijn aan en beschikbaar voor nieuwe versies van
informatiestandaarden, die voldoen aan de geldige baselineversies;
3. In hoeverre aangepaste systemen (zoals bedoeld bij 2) geïmplementeerd en in gebruik
zijn bij zorgaanbieders.
In hoofdstuk 4 hebben we de voorstellen voor deze maatregelen uitgewerkt.

Probleemstelling en advies Advies HL7 CDA en HL7 FHIR 20
Na besluitvorming over bovenstaande adviezen zal de stelselbeheerder, na consultatie van de
relevante veldpartijen en na het beschikbaar komen van de migratieplannen, komen met een
voorstel (een advies) over onder meer de volgende concrete punten:
― waar en op welke manier translaties worden ingezet, en
― waarvoor en hoe een monitoringfunctie wordt ingezet.
Tevens betekent dit dat na besluitvorming over bovenstaande adviezen het volgende gevraagd
wordt:
― Aan bestuurders van (organisaties van) zorgaanbieders die gebruikmaken van
zorginformatiesystemen en systemen voor uitwisseling van informatie dat zij:
― zich maximaal gaan inspannen om te zorgen dat hun informatiesystemen gebruik
maken van de geldige baselineversies van generieke standaarden;
― actief overleg zoeken met hun leveranciers en waar nodig - door samen op te trekken
met collega-zorgaanbieders – van hun leveranciers eisen dat hun systemen
gebruikmaken van de geldige baselineversies van generieke standaarden;
― onoverkomelijke obstakels tijdig signaleren, zodat stelselhouder en -beheerder in
overleg met het Informatieberaad kunnen zoeken naar oplossingen.
― Aan ICT-Leveranciers die zorginformatiesystemen en elektronische uitwisselsystemen voor
uitwisseling van informatie op de markt brengen:
― dat hun producten gaan voldoen aan de geldige baselineversies voor generieke
standaarden binnen het stelsel.
― Aan standaardhouders die gebruikmaken van niet meer geldige generieke standaarden:
― dat zij een migratieplan opstellen voor de overgang naar de geldige baselineversie van
generieke standaarden.
― Aan standaardhouders die gebruik maken van de huidige baseline van geldige generieke
standaarden:
― dat zij een migratieplan opstellen voor de overgang naar de toekomstige baselineversie
van generieke standaarden.
― Aan beheerders van informatiestandaarden (zoals Nictiz):
― dat zij bij nieuwe informatiestandaarden en grote doorontwikkelingen voldoen aan de
geldige baselineversies van generieke standaarden.

4
Stelselinstrumentarium

Stelsel-instrumentarium Advies HL7 CDA en HL7 FHIR 22

4.1 Monitoring
Een van de benodigde maatregelen is de ontwikkeling van een monitoringsfunctie. Een monitor
kun je inzetten als instrument om de opvolging van besluiten over baselineversies en
implementatie van informatiestandaarden te controleren.
De monitor zal op verschillende niveaus informatie bevatten; zowel op het niveau van
zorginstellingen, als het niveau van leveranciers en standaarden. Het doel ervan is om in één
oogopslag - aan de hand van een zogeheten stoplichtweergave - te laten zien in hoeverre systemen
aangepast en beschikbaar zijn voor nieuwe versies van informatiestandaarden. Alsook de
conformiteit van informatiestandaarden aan de baselineversies.
Er worden Het stelselinstrumentarium voorziet in drie niveaus van monitoring:
1. Per (informatie)standaard:
― De beschikbaarheid van een migratieplan om te voldoen aan de baselineversies van
het stelsel.
― De beschikbaarheid van een versie van de (informatie)standaard die de baselineversie
ondersteunt.
2. Per informatiesysteem van een leverancier:
― De beschikbaarheid van een versie van het informatiesysteem (zoals een EPD) die de
juiste versie van de informatiestandaard ondersteunt.
3. Per zorgaanbieder (instelling) die een informatiesysteem van een leverancier gebruikt:
― Of de juiste (zie 2) versie van het informatiesysteem (zoals een EPD) is
geïmplementeerd.
Daarbij dient de monitor als benchmark voor veldpartijen. Door inzichtelijk te maken wie er
voldoet aan de baseline of wie de aangepaste systemen al geïmplementeerd heeft, kunnen
veldpartijen hun eigen voortgang vergelijken met de rest van Nederland. Hieruit kun je vervolgens
zelf concluderen of ze behoren tot de koplopers of dat beweging gewenst is.
Op een later moment zou de monitor met functionaliteiten kunnen worden uitgebreid. Dit kan
bijvoorbeeld door het gebruik en de groei van bepaalde informatiestandaarden weer te geven.
Bijvoorbeeld, een ziekenhuis dat gebruik maakt van de huidige baselineversies Zibs-2017 en FHIR
STU3 krijgt een groen licht, terwijl een ziekenhuis dat nog niet voldoet een rood licht krijgt. Figuur
4 geeft een indruk hoe de landkaart eruit zou komen te zien.

Stelsel-instrumentarium Advies HL7 CDA en HL7 FHIR 23

Figuur 4 - Voorbeeld van de monitorfunctie
Bovenstaande landkaart is de implementatiekaart van de informatiestandaard Acute zorg standaard via AMIGO! .

Stelsel-instrumentarium Advies HL7 CDA en HL7 FHIR 24

4.2 Generieke translaties
4.2.1 Uitgangspunten
In hoofdstuk 3 hebben we de volgende uitgangspunten geformuleerd:
1. Men introduceert beleid waarbij sprake is van twee baselineversies van generieke standaarden
binnen het beoogd stelsel: een huidige en een toekomstige.
2. Bij de start van het stelsel worden benoemd:
a. Zibs-2017 als huidige baselineversie (semantische generieke standaard) en Zibs-2020
als toekomstige baselineversie;
b. FHIR STU3 als huidige baselineversie (syntactische generieke standaard) en FHIR R4
als toekomstige baselineversie.
3. Zibs-2017 komt alleen voor in combinatie met FHIR STU3 en Zibs-2020 komt alleen voor in
combinatie met FHIR R4.
Als stelselinstrumentarium worden op stelsel niveau geen translaties CDA  FHIR aangeboden.
Dat betekent niet dat translaties CDA  FHIR geen rol kunnen spelen, maar dat die (eventueel)
vanuit een specifieke uitwisseling moeten worden opgesteld en geïmplementeerd. Bijvoorbeeld
als gevolg van een migratieplan van de betreffende Informatiestandaard om over te gaan op FHIR.
Voor de generieke translaties Zibs-2017 / FHIR STU3  Zibs-2020 / FHIR R4 geldt dat:
― De specificaties van deze generieke translaties centraal worden opgesteld en dat Nictiz die
beheert;
― De uitvoering van de translaties is aan marktpartijen.
Deze generieke translaties Zibs-2017 / FHIR STU3  Zibs-2020 / FHIR R4 kunnen niet alleen
gebruikt worden om uitwisselingen te ondersteunen, waarbij de zender en de ontvanger op
verschillende versies van de baseline gebruiken, maar ook in situaties waarbij een bron-systeem
(bijvoorbeeld een EPD) nog op de huidige baseline is gebaseerd, maar de uitwisselingen al over zijn
op de toekomstige baseline.
In de volgende paragrafen gaan we nader in op de translaties tussen Zibs-2017 / FHIR STU3 en Zibs2020 / FHIR R4.

4.2.2 Verschillen Zibs-2017 en Zibs-2020
Een belangrijk onderdeel van de translaties FHIR STU3 / Zibs-2017 <-> FHIR R4 / Zibs-2020 is de
translatie tussen Zibs-2017 en Zibs-2020. Dit zijn translaties van de betekenis van informatie
tussen Zibs-2017 en Zibs-2020.
Per zib kan de impact van de overgang (translatie) van Publicatieversie 2017 naar Publicatieversie
2020 verschillen. Er kan sprake zijn van nieuwe zibs en/of wijziging van bestaande zibs. Die
wijzigingen kunnen betrekking hebben op (combinaties van) gegevenselementen, kardinaliteit van
gegevenselementen of waardenlijsten.
De volgende twee tabellen tonen de verschillen tussen Zibs-2017 en Zibs-2020:
― Tabel 3 geeft een overzicht van de verschillen voor de zibs van de BgZ;
― Tabel 4 geeft een overzicht van de verschillen voor de overige zibs.
In beide tabellen illustreren we de impact met een kleur die afhankelijk is van het niveau waarop
het versienummer van de betreffende zib wijzigt, namelijk:
― Groen:
geen wijziging
― Geel:
patchwijziging (geen wijziging op het informatiemodel van de zib)
― Oranje:
minor wijziging
― Rood:
major wijziging, niet backward-compatibel of geheel nieuwe zib

Stelsel-instrumentarium Advies HL7 CDA en HL7 FHIR 27

4.2.3 Aard van de translatie
Anders dan bij de translatie van technische standaarden heeft de translatie op het niveau van zibs
inhoudelijke consequenties. Bij de informatieoverdracht van bijvoorbeeld een EPD met een oude
versie naar een EPD met een nieuwe versie, zullen bepaalde gegevens in het ontvangende EPD niet
worden getoond omdat die in het bron-EPD niet kunnen worden geregistreerd. Omgekeerd zal bij
de informatieoverdracht van een EPD met een nieuwe versie naar een EPD met een oude versie
mogelijk informatie verloren gaan.
Om de uitwisseling van de zibs tussen EPD’s (of andere informatiesystemen) met verschillende
publicatieversie van de zibs mogelijk te maken, moeten gegevens worden geconverteerd. Om
problemen bij de uitwisseling van zibs te voorkomen, moet men daarom eenduidige
translatieregels opstellen. Leveranciers moeten die strikt toepassen. Daarbij horen ook de regels
(specificaties) indien sprake is van verlies van informatie na translatie.
De beheerder van de zibs is verantwoordelijk voor het opstellen van translatieregels
voor de uitwisseling van de zibs (en dus ook van de BgZ) tussen informatiesystemen
zoals EPD’s met verschillende baselineversie van de generieke standaarden. Deze
translatieregels worden beschikbaar gesteld in een afgesproken format
(ConceptMaps), zodat je ze als automatische input kunt gebruiken voor de
technische (syntactische) translatieregels. De houder van de zibs stelt de
translatieregels vast.

4.2.4 Gecombineerde translatie van zibs en FHIR
De translatiespecificaties Zibs-2017 / FHIR STU3  Zibs-2020 / FHIR R4 bestaan uit regels voor de:
― Translatie van de inhoud (semantische regels) tussen zibs-2017 en zibs-2020;
― Translatie van de technische specificatie tussen FHIR STU3 en FHIR R4 (syntactische
translatieregels).
Figuur 5 illustreert de samenhang:

Figuur 5 - Generieke translatie specificaties, samenhang semantische en syntactische regels.

Het beoogde resultaat is één translatie-specificatie, waarin de semantische translaties (tussen
versie van de zibs) en de syntactische translaties (tussen FHIR STU3 en FHIR R4) één geheel vormen.

Stelsel-instrumentarium Advies HL7 CDA en HL7 FHIR 29

4.3.3 Translatie zibs-2017 naar zibs-2020
De translatieregels voor de overgang van de zibs-2017 naar de zibs-2020 zal Nictiz centraal
beschikbaar stellen en beheren. Vervolgens zullen deze specificaties moeten worden omgezet naar
translatiespecificaties tussen FHIR-STU3 en FHIR R4, zie verder paragraaf 4.2.4. De specificatie van
de translatieregels tussen FHIR STU3 en FHIR R4 zal worden uitgewerkt. Samen met FHIRspecialisten beheert en publiceert Nictiz deze. De ontwikkeling van translatiesoftware op basis van
de translatieregels kan worden belegd bij marktpartijen. Evenals de uitvoering van de translaties –
het verzorgen van translaties zelf -.

4.3.4 Zorginstellingen
Bij zorginstellingen zal de overgang naar een nieuwe baselineversie neerkomen op het
implementeren van een nieuwe versie van de EPD-software.

4.4 Migratieplannen per informatiestandaard
In de nog op te stellen migratieplannen per informatiestandaard dienen de volgende onderwerpen
te worden uitgewerkt:
1. Beschrijving huidige situatie met daarin een specificatie van:
― Soort(en) informatie uitwisseling(en).
― Betrokken zorginstellingen inclusief aantallen.
― Betrokken leveranciers inclusief aantallen en marktverdeling.
― Samenhang met relevante informatiestandaarden.
2. Beschrijving gewenste situatie.
3. Uitwerking benodigde transitie met eventuele scenario’s.
4. Impact op:
― Standaarden
― Leveranciers
― Benodigde translatie
― Zorginstellingen
5. Globale inschatting van de kosten en waar die kosten liggen.
6. Globale planning en doorlooptijd met in ieder geval:
― De ingangsdatum geldigheid (en beschikbaarheid) van de nieuwe versie van de
Informatiestandaard die voldoet aan een geldige baselineversie binnen het stelsel.
― De einddatum geldigheid van de versie van de informatiestandaard die niet aan een
geldige baselineversie binnen het stelsel voldoet.
Bovenstaande is een opsomming van de onderwerpen, die men in een migratieplan per
informatiestandaard moet uitwerken en is niet per se bedoeld als hoofdstukindeling.
Bij het opstellen van de migratieplannen zal vanuit de Stelselhouder en Stelselbeheerder de
nodige ondersteuning worden georganiseerd en aangeboden aan de Standaardhouder en
Standaardbeheerder. Doel daarvan is dat het proces van opstellen van de migratieplannen
effectief en efficiënt verloopt en dat er een ‘ eenheid van proces’ wordt gecreëerd.

Bijlage 1
FHIR, CDA, zibs

Advies HL7 CDA en HL7 FHIR 31

Verschil tussen de Zib Publicaties 2017 en 2020
In Zib Publicatie 2020 hebben we, ten opzichte van Zib Publicatie 2017, enkele honderden
wijzigingen doorgevoerd en een kleine 20 nieuwe zibs beschikbaar gesteld. Bij de wijzigingen
zitten zowel kleine wijzigingen, die backward compatibel zijn met Zib Publicatie 2017, maar ook
enkele grote functionele wijzigingen, die niet backward compatibel zijn met Zib Publicatie 2017.
Bij de nieuwe zibs in Publicatie 2020 zitten onder andere nieuwe zibs voor de 1e lijn en de
oncologische zorg.

Verschil tussen de BgZ versies
Los van de verschillen in de versies Publicatie 2017 respectievelijk Publicatie 2020 van de zibs,
waaruit de BgZ bestaat (zie alinea hierboven), zijn er slechts enkele kleine verschillen tussen
BgZ2017 en BgZ202017.

Verschil tussen FHIR STU3 en FHIR R4
FHIR kent meerdere versies. Op dit moment zijn dat FHIR STU3 en R4. Ondertussen wordt
gewerkt aan R5. FHIR STU3 en R4 hebben syntactisch een grote overeenkomst. Er zitten wel
verschillen in semantiek (welke velden zitten erin, welke gecodeerde waarden zijn toegestaan).
Door de syntactische overeenkomst tussen FHIR STU3 en FHIR R4 is translatie niet complex. Toch
bestaat het risico dat de semantische verschillen ertoe leiden dat bij een conversie
informatieverlies optreedt, bijvoorbeeld wanneer een code in de ene versie niet bestaat maar in
de andere wel.

FHIR Documents en FHIR API
FHIR biedt naast een API ook ondersteuning van de uitwisseling van documenten (FHIR Documents)
waarbij de inhoud van een FHIR-document is opgebouwd uit de data elementen van de FHIR API.
Hiermee biedt FHIR Documents dezelfde functionaliteit als CDA en is daarmee een logische stap in
de transitie van FHIR naar CDA. FHIR Documents biedt uiteraard niet de voordelen van de FHIR API.

Overgang van CDA naar FHIR
CDA heeft het einde van zijn levenscyclus bereikt omdat het niet dynamisch genoeg is om te
voorzien in de behoeftes die aan hedendaagse zorgverlening en gegevensuitwisseling worden
gesteld. Daarom is FHIR ontwikkeld en is de doorontwikkeling van CDA enkele jaren geleden
stopgezet. Het kost inspanning om CDA te vervangen door FHIR in de systemen van zorgverleners.
FHIR en CDA zijn syntactisch verschillend. Een translatie is daardoor een significant grotere
inspanning dan FHIR 2 FHIR. Er kunnen ook semantische verschillen zijn tussen FHIR en CDA,
waardoor het mogelijke informatieverlies ook sneller op zal treden.
Ook internationaal, met name in Europa, wordt er in toenemende mate gekeken naar de
mogelijkheid om van HL7 CDA de overstap te maken naar HL7 FHIR. In de Europese subgroepen
(Subgroup on Semantics en Subgroup on Technical Interoperability) zijn de twee standaarden
naast elkaar gezet en is er, met name door meer en betere functionaliteiten, een voorkeur voor
HL7 FHIR uitgesproken. Daarnaast wordt CDA door HL7 ook niet meer verder ontwikkeld, waar
dat bij FHIR wel gebeurt.
Ondanks dat de huidige domeinen (ePrescription en Patient Summary) in Europa binnen de
nieuwe infrastructuur MyHealth@EU momenteel gebaseerd zijn op HL7 CDA, wordt er een
definitieve afweging gemaakt om de overstap te maken naar HL7 FHIR. Dit geldt ook voor de
17

Voor releasenotes zie blz 6 van https://www.nictiz.nl/wp-content/uploads/BgZ2020-specificatie-obv-zibs-2020-v1.1.pdf

Advies HL7 CDA en HL7 FHIR 33

bij ziekenhuizen (en Universitair Medische Centra) een veelvoud van generieke standaarden
(stekkers ) ondersteund moet worden om uitwisselingen mogelijk te maken.

Bijlage 2
Probleem BgZ

Bijlage 4 - Format migratieplannen
In de nog op te stellen migratieplannen per informatiestandaard dienen de volgende onderwerpen te
worden uitgewerkt:
1. Beschrijving huidige situatie met daarin een specificatie van:
• Soort(en) informatie uitwisseling(en),
• Betrokken zorginstellingen inclusief aantallen,
• Betrokken leveranciers inclusief aantallen en marktverdeling,
• Samenhang met relevante informatiestandaarden.
2. Beschrijving gewenste situatie
3. Uitwerking benodigde transitie met eventuele scenario’s
4. Impact op:
• Standaarden,
• Leveranciers,
• Benodigde translatie,
• Zorginstellingen.
5. Globale inschatting van de kosten en waar die kosten liggen
6. Globale planning en doorlooptijd met in ieder geval:
• De ingangsdatum geldigheid (en beschikbaarheid) van de nieuwe versie van de
Informatiestandaard die voldoet aan een geldige baselineversie binnen het stelsel.
• De einddatum geldigheid van de versie van de informatiestandaard die niet aan een geldige
baselineversie binnen het stelsel voldoet.
Bovenstaande is een opsomming van de onderwerpen, die in een migratieplan per informatiestandaard
uitgewerkt moeten worden, en is niet persé bedoeld als hoofdstukindeling.