Overzicht
Zorgdata staat niet in één systeem. De gegevens van een patiënt zijn verdeeld over de huisarts, het ziekenhuis, de medisch specialist, de apotheek met de medicatiegeschiedenis en het laboratorium met de uitslagen. Goede zorg vraagt dat die gegevens betrouwbaar en bruikbaar tussen systemen worden uitgewisseld.
HL7 en FHIR zijn de internationale standaarden die deze data-uitwisseling mogelijk maken. HL7 v2 is de berichtenstandaard waarop klinische data-uitwisseling al tientallen jaren draait. HL7 FHIR is de moderne RESTful standaard die steeds meer de basis is voor nieuwe klinische systeemintegraties.
Wij bouwen HL7 v2 en FHIR integratieoplossingen voor zorgorganisaties, gezondheidstechnologiebedrijven, leveranciers van klinische systemen en elke organisatie die klinische data moet uitwisselen met zorgsystemen.
HL7 v2 — De Gevestigde Klinische Berichtenstandaard
HL7 versie 2 is al sinds de jaren 1980 de dominante klinische berichtenstandaard. Veel koppelingen in Nederlandse ziekenhuizen gebruiken het nog steeds. Huisartsensystemen wisselen daarnaast nog Edifact-berichten uit, bijvoorbeeld voor labuitslagen en brieven.
Berichttypen.
ADT (Admit, Discharge, Transfer) berichten melden opname, overplaatsing en ontslag aan ontvangende systemen — A01 patiëntopname, A02 patiëntoverdracht, A03 patiëntontslag, A08 patiëntinformatie-update.
ORM (Order) en ORU (Observation Result) berichten bevatten klinische orders en hun resultaten — laboratoriumorders en resultaten, radiologieorders en rapporten, medicatieorders.
SIU (Scheduling Information Unsolicited) berichten bevatten afspraakplanningsinformatie tussen planningssystemen en klinische dossiers.
MDM (Medical Document Management) berichten bevatten klinische documenten — ontslagbrieven, klinische brieven, operatieverslagen.
Berichttransport. HL7 v2 berichten worden typisch uitgewisseld via MLLP (Minimal Lower Layer Protocol) — een TCP-gebaseerd transportprotocol ontworpen voor betrouwbare klinische berichtlevering. Wij implementeren MLLP-client en -servercomponenten in zowel verzend- als ontvangstconfiguraties, met het verbindingsbeheer, bevestigingsverwerking en foutafhandeling die betrouwbare HL7 v2 berichtuitwisseling vereist.
Transformatie en mapping. HL7 v2 berichten die aankomen van klinische systemen bevatten niet altijd data in de structuur of het codeersysteem dat de ontvangende applicatie nodig heeft. Diagnosecodering in ICD-9 die moet worden gekoppeld aan ICD-10. Observatieresultaten met lokale codering die moet worden gekoppeld aan LOINC.
HL7 FHIR — De Moderne Klinische Interoperabiliteitsstandaard
FHIR (Fast Healthcare Interoperability Resources) is de HL7-standaard voor moderne klinische data-uitwisseling. FHIR is een RESTful API-standaard die resourcetypen definieert die klinische entiteiten vertegenwoordigen — Patient, Encounter, Observation, Condition, Medication, Procedure, DiagnosticReport.
FHIR resourcemodel. FHIR definieert meer dan 150 resourcetypen over het volledige bereik van zorgdata: klinische resources, administratieve resources en infrastructuurresources.
FHIR API-operaties. De FHIR REST API definieert standaardoperaties over alle resourcetypen — lezen, aanmaken, bijwerken, verwijderen, zoeken en geschiedenis.
FHIR profielen en implementatiegidsen. De Nederlandse FHIR-implementatiegidsen — de profielen op basis van de zib's (zorginformatiebouwstenen) van Nictiz — definiëren de specifieke FHIR-profielen die Nederlandse zorgdata-uitwisseling vereist.
MedMij. MedMij is het Nederlandse afsprakenstelsel waarmee patiënten hun gezondheidsgegevens bij zorgaanbieders ophalen in een persoonlijke gezondheidsomgeving (PGO) naar keuze. De uitwisseling gebeurt met FHIR, volgens de informatiestandaarden van Nictiz voor onder meer medicatie, huisartsgegevens en labuitslagen. Zorgaanbieders sluiten aan via een MedMij-gekwalificeerde dienstverlener; wij bouwen de FHIR-koppelingen tussen uw systemen en die dienstverlener, of voor health-techbedrijven de integratie met de standaarden zelf.
Integratiearchitecturen
Punt-tot-punt integratie. Een directe verbinding tussen twee systemen, met berichten of FHIR-resources die direct van afzender naar ontvanger stromen. Geschikt wanneer de integratie tussen twee specifieke systemen is en de datastromen gedefinieerd en stabiel zijn.
Integratie-engine en middleware. Wanneer integraties veel systemen omvatten die veel berichttypen uitwisselen, biedt integratie-engine middleware de routerings-, transformatie- en orchestratielaag die de complexiteit beheert.
FHIR server implementatie. Voor organisaties die hun klinische data via een FHIR API moeten aanbieden — om te voldoen aan eisen voor gegevenstoegang, om deel te nemen aan MedMij — bouwen wij FHIR-servers die de vereiste resourcetypen aanbieden.
FHIR client integratie. Voor applicaties die klinische data moeten consumeren van FHIR-servers bouwen wij FHIR client integraties die FHIR authenticatiestromen, resource-ophaling en zoeken, het verwerken van bundels en het profielconform inlezen van geretourneerde resources afhandelen.
Nederlands Zorgintegratielandschap
VIPP en de Wegiz. De VIPP-programma's waren subsidieprogramma's die ziekenhuizen en andere zorgaanbieders hielpen patiënten digitaal toegang te geven tot hun gegevens, onder meer via MedMij, en gestandaardiseerde gegevensuitwisseling in te voeren. De Wegiz (Wet elektronische gegevensuitwisseling in de zorg, sinds 1 juli 2023 van kracht) gaat verder: die maakt elektronische uitwisseling stap voor stap verplicht voor aangewezen gegevensuitwisselingen, op basis van afgesproken standaarden.
LSP en de nationale infrastructuur. Het Landelijk Schakelpunt (LSP) is de landelijke infrastructuur waarmee huisartsen, huisartsenposten, apotheken en ziekenhuizen gegevens kunnen delen met andere behandelaars, als de patiënt daarvoor toestemming heeft gegeven.
Koppeltaal. Koppeltaal is de integratiestandaard voor het verbinden van eHealth-applicaties met klinische informatiesystemen in Nederland.
ZIBs (Zorginformatiebouwstenen). De Nederlandse klinische bouwstenen — ZIBs — definiëren de informatiemodellen voor Nederlandse klinische data-uitwisseling.
Datakwaliteit en Klinische Veiligheid
Patiëntidentiteitsmatching. De meest kritieke correctheidsvereiste in klinische data-uitwisseling is het matchen van inkomende data aan het juiste patiëntrecord. Wij implementeren patiëntidentiteitsmatching met alle beschikbare identificerende attributen — BSN (Burgerservicenummer) waar beschikbaar, gecombineerde demografische matching waar dat niet het geval is.
Bevestiging en foutafhandeling. HL7 v2 berichtbevestigingen en FHIR OperationOutcome-responses dragen de informatie over of data correct is ontvangen en verwerkt. Wij verwerken bevestigingen en foutmeldingen zo dat mislukte berichten zichtbaar worden en worden opgepakt.
Berichtordening en -sequentiëring. Klinische events hebben een natuurlijke volgorde — een patiënt wordt eerst opgenomen en daarna ontslagen. Berichten die buiten volgorde aankomen en in aankomstvolgorde worden verwerkt leveren onjuiste klinische data op.
Gebruikte Technologieën
- C# / ASP.NET Core — HL7 v2 MLLP client en server, FHIR server implementatie, transformatie-engine, NHapi voor HL7 v2 parsing
- Rust / Axum — FHIR API-backends en HL7 v2-berichtverwerking voor grote volumes
- React / Next.js — integratiemonitoringdashboards, interfaces om berichten te inspecteren, configuratiebeheer
- TypeScript — typeveilige frontend en FHIR client code
- SQL (PostgreSQL, MySQL) — berichtopslag, FHIR resource persistentie, audittrail
- Redis — berichtwachtrijen, verwerkingsstatus, integratiemonitoring
- HL7 v2 / MLLP — gevestigde klinische berichtuitwisseling
- FHIR R4 / R5 — moderne klinische resource-uitwisseling
- ZIB profielen — Nederlandse klinische bouwsteen conformiteit
- MedMij — Nederlandse patiëntgestuurde gezondheidsdata-uitwisseling
- Koppeltaal — Nederlandse eHealth applicatie integratie
- SMART on FHIR — OAuth2-gebaseerde FHIR authenticatie voor toegang door applicaties van derden
- Auth0 / SAML — identiteitsbeheer voor klinische systeemauthenticatie
- REST / Webhooks — niet-HL7 integratie voor verbonden systemen
Veelgestelde vragen
HL7 v2 of FHIR: wat hebben wij nodig?
Dat hangt af van de systemen die u koppelt. Veel ziekenhuissystemen wisselen nog HL7 v2-berichten uit, terwijl nieuwe koppelingen, MedMij en de meeste Nictiz-standaarden FHIR gebruiken. Vaak gebruikt een koppeling beide, met een vertaling ertussen.
Werkt u met de Nederlandse profielen?
Ja. Koppelingen volgen de FHIR-profielen op basis van de zib's en de informatiestandaarden van Nictiz die voor de toepassing gelden, niet alleen de basisspecificatie.
Kunt u een eHealth-app koppelen aan het systeem van een zorgaanbieder?
Ja, via Koppeltaal voor ggz- en eHealth-toepassingen, of via de FHIR- of HL7-interfaces die het systeem biedt.
Hoe voorkomt u dat data bij de verkeerde patiënt terechtkomt?
Met strikte patiëntmatching op BSN waar beschikbaar en op meerdere kenmerken waar niet, een expliciete afhandeling van twijfelgevallen, en bevestigingen en monitoring zodat geen bericht ongemerkt verdwijnt.
Wie is eigenaar van de code?
Het eigendom van de broncode wordt in het contract vastgelegd, en de code kan volledig van u zijn, inclusief documentatie en tests.
Zie ook patiëntdata tooling, API-integraties en wat is FHIR.
Klinische Data-uitwisseling die Werkt
De standaarden liggen vast; het werk zit in de details van elk systeem. Of u nu een nieuwe applicatie koppelt aan de Nederlandse zorginfrastructuur, een FHIR-server bouwt of een kwetsbare HL7 v2-koppeling vervangt: wij bouwen het betrouwbaar en traceerbaar.