Ben je betrokken bij informatiestandaarden in de zorg? Dan weet je hoe belangrijk aansluiting op internationale ontwikkelingen is. Toch blijkt de stap naar Europese FHIR-specificaties uitdagender dan gedacht. En de klok tikt door. In 2029 gelden de eerste Europese verplichtingen binnen de European Health Data Space (EHDS).
In deze blog ontdek je waar we nu staan, welke knelpunten er zijn en hoe jij je kunt voorbereiden.
Jorn Duwel
Jorn is Interoperability Expert en heeft zich verdiept in de Europese FHIR implementation Guides
Wat speelt er nu?
Eind juni is er gestemd over de publicatie van een aantal Europese FHIR Implemention Guides (IG’s) onder de vlag van HL7 Europe. Vertegenwoordigers uit verschillende Europese landen hebben bepaald dat deze specificaties de status ‘Standard for Trial Use’ krijgen, oftewel dat deze klaar zijn om getest te worden.
Niet toevallig zijn de onderwerpen waar deze IG’s betrekking op hebben, ook de onderwerpen die te maken hebben met de EHDS: laboratoriumuitslagen, medicatievoorschrijvingen en -verstrekkingen, beeldbeschikbaarheid en ontslagbrieven. Hierbij wordt voortgebouwd op functionele specificaties die binnen het Xt-EHR-project bepaald zijn. Binnen deze specificaties, gepubliceerd als ‘Logical Models’, die techniek-onafhankelijk zijn, zijn alle elementen gedefinieerd die straks uitgewisseld moeten worden.
Naast de IG’s voor specifieke domeinen, is er ook aandacht voor de generieke componenten die terugkomen in al deze specificaties. De Logical Models zijn onder de noemer ‘EU Base’ gemapt naar FHIR-profielen. Binnen de ‘EU Core’-profielen is het de bedoeling dat de Base-profielen verrijkt worden met elementen die van belang zijn voor de specifieke usecases.
Op dit moment zijn er profielen voor resource types als Patient, Practitioner en Organization, die in elke IG terugkomen. Het is aannemelijk dat hier in de toekomst andere resource types als Condition en Procedure bij komen.
De uitdagingen in Nederland
Deze gelaagde opbouw van specificaties klinkt voor mensen die bekend zijn met de Nederlandse FHIR-implementaties waarschijnlijk erg bekend! Er zijn erg veel parallellen met hoe Nictiz de functionele Zorginformatiebouwstenen (zibs) eerst mapt in zib-FHIR-profielen, die enkel de elementen uit de zibs mappen, om die vervolgens in de nl-core-profielen uit te breiden met usecasespecifieke informatie.
Wij zijn in Nederland dus wel een en ander gewend als het op specificaties aankomt. Je zou dus kunnen denken dat we er helemaal klaar voor zijn. Toch is er nog een weg te gaan.
Zo zijn de EU IG’s gebaseerd op de FHIR-versies R4 en/of R5. In enkele gevallen zijn er zelfs per IG twee verschillende versies opgesteld, maar van de EU Imaging Study Report IG is alleen een R5-versie beschikbaar. In Nederland werken wij voor een groot deel nog in versie STU3 (met nieuwe ontwikkelingen in R4) en zijn er geen plannen om R5 in een van de zogenaamde ‘baselines’ op te nemen.
Daarnaast overlappen de Nederlandse informatiestandaarden voor een groot deel met de scope van de Europese IG’s, maar zijn er knelpunten die voorkomen dat de EU-specificaties direct in gebruik kunnen worden genomen. Er wordt hard gewerkt om deze punten in kaart te brengen, zowel op functioneel als op technisch vlak (bijvoorbeeld voor Medicatieproces, maar ook voor andere zibs, zowel voor publicatie 2020 als 2024), waardoor de specificaties uiteindelijk met elkaar in lijn gebracht kunnen worden.
Ook de International Patient Summary krijgt een rol
De International Patient Summary (IPS) is een initiatief om wereldwijd de uitwisseling van zorggegevens te harmoniseren, met zijn eigen FHIR IG. Het is bekend dat er redelijk wat verschil is tussen de Basisgegevensset Zorg (BgZ) en de IPS, waar Marc de Graauw enkele interessante blogposts over geschreven heeft. Tot nu toe was er in Nederland geen directe aanleiding om iets aan deze verschillen te doen; de IPS was ‘iets vrijblijvends’.
Dat lijkt nu te veranderen: de EU Core IG heeft op zijn beurt een formele afhankelijkheid van de IPS. Elk FHIR-bericht dat beweert te voldoen aan de EU IG’s, zal dus ook moeten voldoen aan de IPS-variant van dat bericht. Deze afhankelijkheid wordt niet afgedwongen door een IPS-profiel als ‘baseDefinition’ op te geven in de EU-profielen, maar door middel van een ‘imposeProfile’-extensie. Deze extensie geeft de mogelijkheid om in elk profiel meerdere afhankelijkheden te definiëren en wordt ondersteund door de officiële HL7 Validator. Hoe deze verschillende afhankelijkheden duidelijk in beeld worden gebracht voor ontwikkelaars die de profielen implementeren is nog niet helemaal duidelijk.
Of en hoe het Nederlandse model gaat afhangen van de Europese specificaties, zal moeten blijken. Er dient nog een flinke puzzel gelegd te worden, en dat voor maart 2029, wanneer de eerste onderdelen van de EHDS van toepassing worden.
Praktijkvoorbeeld
Om te bekijken wat de impact van de Europese specificaties is, heb ik een nl-core-Patient (een goed gevuld Patiënt-bericht opgebouwd volgens de Nederlandse zib2020-specificaties in FHIR R4) gevalideerd tegen de pre-release van het nieuwe patient-eu-core-profiel. Na het inladen van het hl7.fhir.eu.base-package in de validator en het toevoegen van de patient-eu-core-canonical-url in meta.profile van het Patiënt-bericht, kon de validatie starten.
De resultaten laten geen foutmeldingen zien. Dat is niet heel verwonderlijk – de mapping van de zib Patiënt naar FHIR is zorgvuldig aangebracht, waarbij er weinig verschil in interpretatie tussen Nederlandse en internationale toepassing, mogelijk is. Dit is helaas niet voldoende om te kunnen concluderen dat er dus geen verschillen tussen de beide profielen zijn. Bij het bestuderen van de extensies die in beide profielen zijn gedefinieerd, blijken toch enkele ‘verbeterpunten’.
Zo wordt in het veld ‘address.country’ het land van de patiënt in vrije tekst meegegeven. De Europese IG vraagt om hier, indien bekend, de gecodeerde variant van dit land mee te geven in de extensie met url ‘http://hl7.org/fhir/StructureDefinition/iso21090-SC-coding’. In het Nederlandse profiel wordt dit óók gevraagd, maar dan in een extensie met url ‘http://nictiz.nl/fhir/StructureDefinition/ext-CodeSpecification’. De kans dat een internationaal systeem de Nederlandse code dus niet begrijpt is groot (net als andersom), terwijl in beide specificaties dus wel exact hetzelfde stukje informatie aanwezig is. Tijd voor harmonisatie dus!
Een ander voorbeeld is dat in het Nederlandse bericht op het veld ‘telecom’ een (tekstuele) opmerking bij een telefoonnummer kan worden meegegeven in een extensie volgens de zib Contactgegevens. De Europese specificaties (h)erkennen zo’n soort extensie niet. Bij internationale uitwisseling zal dit stukje informatie dus waarschijnlijk verloren gaan. De vraag is of dit erg is. In dit specifieke voorbeeld waarschijnlijk niet, maar misschien zijn er andere stukjes klinisch relevante informatie die wel behouden moeten blijven.
Kennis begint met inzicht
Tot het moment dat de Europese specificaties ‘officieel’ worden geïntegreerd in het Nederlandse stelsel van standaarden, is de impact voor leveranciers relatief beperkt. Dat betekent echter niet dat we stilzitten!
Binnen het Interoplab-platform is het op dit moment makkelijk om berichten te valideren tegen de zib- en nl-core-implementaties in FHIR. Wij werken aan de mogelijkheid om hiernaast op een simpele manier tegen andere FHIR-specificaties, zoals de EPS of de IPS, te kunnen valideren. Dit is geheel vrijblijvend, maar zorgt ervoor dat we inzicht krijgen in de impact die deze specificaties hebben op onze huidige manier van berichten uitwisselen. Zo kunnen we zowel vanuit Nederlands perspectief feedback leveren op de internationale specificaties, terwijl we ook richting toekomstige versies van de Nederlandse profielen kunnen werken aan de knelpunten.