HL7 FHIR in de zorg

HL7 FHIR is de moderne HL7-standaard voor digitale gegevensuitwisseling in de zorg. Juist nu zorgorganisaties meer werken met API’s, apps, portalen en persoonlijke gezondheidsomgevingen, wordt FHIR steeds relevanter. De standaard ondersteunt modulaire uitwisseling met afzonderlijke resources en RESTful API’s. Of dit in een concrete implementatie eenvoudiger is dan oudere zorgstandaarden, hangt af van de gekozen use case, profielen en infrastructuur.

Tegelijk is FHIR geen garantie voor volledige interoperabiliteit. Dat een leverancier of applicatie FHIR ondersteunt, betekent nog niet automatisch dat gegevens overal eenduidig aankomen en direct bruikbaar zijn. Op deze pagina leest u wat HL7 en FHIR precies betekenen, hoe FHIR technisch werkt en wat Nederlandse zorgorganisaties daar in de praktijk aan hebben.

Waarom FHIR een andere aanpak kiest dan HL7 V2, V3 en CDA

De basis: wat HL7 is en waar FHIR voor staat

HL7 verwijst zowel naar een internationale familie van zorgstandaarden als naar de organisaties die die standaarden beheren en doorontwikkelen. In Nederland is HL7 Nederland daarbij een herkenbare partij. FHIR staat voor Fast Healthcare Interoperability Resources en is een door HL7 ontwikkelde, moderne standaard voor elektronische gegevensuitwisseling. Bij hl7 fhir in de zorg gaat het dus om een moderne manier om informatie te delen tussen zorgaanbieders onderling én tussen zorgaanbieders en zorggebruikers, zoals patiënten en persoonlijke gezondheidsomgevingen.

Hoe FHIR technisch is opgebouwd

FHIR werkt met resources: compacte bouwstenen voor een afgebakend stukje zorginformatie, zoals een patiënt, observatie, afspraak of medicatiegegeven. Die resources hebben een vaste kernstructuur. Voor een concrete toepassing worden ze verder aangescherpt met profielen, zodat duidelijk is welke elementen verplicht zijn, welke coderingen gebruikt moeten worden en hoe gegevens precies moeten worden aangeleverd.

Daarnaast biedt FHIR ruimte voor extensions. Die flexibiliteit is nuttig, maar alleen als extensions beheerst en consequent worden toegepast. Technisch ondersteunt FHIR onder meer RESTful uitwisseling en XML- en JSON-representaties. FHIR is zelf geen beveiligings- of autorisatieprotocol; in de praktijk wordt het doorgaans gecombineerd met afzonderlijke beveiligingsstandaarden, zoals OAuth/SMART, en aanvullende afspraken. Daardoor is FHIR inzetbaar voor API’s, maar ook voor berichten en documenten. Implementatiebibliotheken, referentievoorbeelden en implementation guides maken ontwikkeling vaak sneller en praktischer voor leveranciers en ontwikkelteams.

Wat FHIR in de zorgpraktijk aantrekkelijk maakt

• FHIR maakt kleinere en modulaire uitwisselingen mogelijk. In plaats van steeds een volledig document of een omvangrijk bericht te versturen, kunt u gerichter precies die gegevens ophalen of aanbieden die op dat moment nodig zijn. Dat past beter bij moderne zorgprocessen en gebruikersschermen.
• De standaard sluit goed aan op apps, portalen, mobiele toepassingen en andere internetgebaseerde oplossingen. Daardoor is FHIR aantrekkelijk voor situaties waarin gegevens niet alleen tussen grote bronsystemen, maar ook richting patiëntomgevingen en nieuwe digitale diensten moeten stromen, bijvoorbeeld voor toepassingen rond AI in de zorg.
• Voor teams die al ervaring hebben met web-API’s en JSON kunnen FHIR-concepten herkenbaar zijn. De implementatie-inspanning hangt echter sterk af van de vereiste profielen, terminologie, beveiliging, testen en lokale afspraken.
• FHIR wordt door HL7 Nederland voor nieuwe toepassingsgebieden als voorkeur genoemd, al kan de gekozen integratiestrategie per leverancier en bestaande omgeving verschillen. FHIR kan als vertrekpunt voor herbruikbare koppelingen dienen, mits de inhoudelijke afspraken goed zijn vastgelegd.
• FHIR wordt vaak gezien als toekomstbestendiger, maar dat voordeel komt niet vanzelf. Verschillende releases, uiteenlopende profielen en organisatie-specifieke invullingen kunnen juist extra afstemming, testen en soms herwerk veroorzaken. Moderne techniek helpt, maar alleen binnen duidelijke afspraken.

Waarom FHIR niet automatisch voor interoperabiliteit zorgt

FHIR is een belangrijke bouwsteen, maar echte interoperabiliteit vraagt meer dan alleen een technisch formaat. Zorgorganisaties moeten ook afspraken maken over informatiestandaarden, identificatie, authenticatie, autorisatie, codestelsels en het precieze gebruik van velden. Zonder die laag van gezamenlijke betekenis blijft uitwisseling kwetsbaar, zelfs als beide systemen technisch gezien FHIR ondersteunen.

Daar komt bij dat te veel lokale variatie in profielen of extensions dezelfde versnippering kan veroorzaken als bij oudere standaarden. Als iedere leverancier of regio net andere keuzes maakt, ontstaat opnieuw maatwerk. Gegevens worden pas breed uitwisselbaar wanneer kernelementen in verschillende toepassingen op dezelfde manier worden vastgelegd, gecodeerd en verstuurd, wat ook belangrijk is voor data-driven healthcare.

Waar FHIR in Nederland al wordt toegepast

• MedMij is een bekend Nederlands voorbeeld waarin FHIR een duidelijke rol speelt. Binnen het MedMij-afsprakenstelsel worden gegevensuitwisselingen tussen zorgaanbieders en persoonlijke gezondheidsomgevingen strak ingekaderd, zodat niet alleen de techniek maar ook de afsprakenlaag is geregeld.
• Ook bij eOverdracht is FHIR zichtbaar als bouwsteen voor gestandaardiseerde gegevensoverdracht. Juist in zo’n ketenproces is het belangrijk dat niet alleen systemen kunnen koppelen, maar dat ook de inhoud van de overdracht eenduidig is beschreven.
• In de geboortezorg wordt FHIR eveneens toegepast in specifieke uitwisselscenario’s. Dat laat goed zien dat FHIR in Nederland vaak landt in afgebakende use cases met een duidelijke functionele scope, in plaats van als volledig vrije standaard zonder kaders.
• Daarnaast bestaat in het Nederlandse landschap een reeks gerichte koppelstandaarden, zoals Koppeltaal. Die voorbeelden onderstrepen dat zorguitwisseling meestal alleen goed werkt wanneer governance, rollen en toepassingsafspraken vooraf scherp zijn vastgelegd.
• De praktische invulling van FHIR wordt bovendien mede bepaald door nationale afspraken en bouwstenen, zoals zibs, en door bredere digitaliseringsprogramma’s in de zorg, een thema dat ook terugkomt op het congres CareTech. In Nederland draait FHIR daarom zelden om alleen de technische specificatie; het gaat vrijwel altijd om FHIR binnen een afgesproken context.

Waar u op moet letten bij invoering of migratie

• Overweeg een gefaseerde migratie, bijvoorbeeld per use case of gegevensstroom, wanneer bestaande koppelingen, leveranciersafspraken en kritische zorgprocessen afhankelijkheden hebben.
• Organisaties kunnen een tijd met hybride koppelingen werken. Oude en nieuwe standaarden draaien dan naast elkaar, of een integratielaag vertaalt tussen bestaande berichten en FHIR-API’s. Vraag leveranciers expliciet naar ondersteunde FHIR-release, resources, lees- en schrijfbewerkingen, profielen, workflow, testmogelijkheden en roadmap.
• Let bij de keuze voor een oplossing altijd op de gebruikte FHIR-versie. Ondersteuning voor FHIR is pas echt betekenisvol als duidelijk is welke release wordt bedoeld, welke implementation guide en profielen gevolgd worden, welke terminologie wordt gebruikt, wat in het capability statement staat en hoe omgegaan wordt met toekomstige wijzigingen. Zonder die helderheid ontstaat snel verwarring in aanbestedingen, implementaties en testen.
• Kijk daarnaast scherp naar profielbeheer, minimum datasets en codestelsels. Welke elementen zijn verplicht, welke terminologie is afgesproken en wie mag wijzigingen doorvoeren? Juist deze ogenschijnlijk kleine keuzes bepalen of gegevens later uitwisselbaar, herbruikbaar en beheersbaar blijven.
• Beheer en governance zijn minstens zo belangrijk als techniek. Leg vast wie eigenaar is van profielen, hoe wijzigingen worden goedgekeurd, hoe backward compatibility wordt bewaakt en hoe testscenario’s worden onderhouden. Zonder dat beheer ontstaat al snel nieuwe versnippering.
• Tot slot is FHIR geen onderwerp voor alleen de IT-afdeling. Projectleiders, informatiemanagers, beleidsmakers en zorgmanagers die betrokken zijn bij het digitaal persoonsgegevens uitwisselen in de zorg, moeten eveneens begrijpen welke afspraken leveranciers daadwerkelijk ondersteunen, welke beperkingen er zijn en wat dat betekent voor processen, planning en besluitvorming.