Het gebrek aan de toepassing van standaarden blijft een hardnekkig probleem in de zorg. Daardoor is de uitwisseling tussen ICT-systemen van verschillende zorgaanbieders lastig of onmogelijk. Van 16 tot 18 november zijn softwareontwikkelaars uit de hele wereld in Amsterdam bij elkaar omdat ze verder aan de slag willen met een nieuwe standaard die snel aan populariteit wint: FHIR (spreek uit fire). Op de HL7 FHIR DevDays zullen veel voorbeelden worden getoond van toepassingen om zorggegevens gemakkelijk uit te wisselen. Waarom zijn ontwikkelaars zo enthousiast?
Er is bepaald geen gebrek aan ICT-standaarden in de zorg. Het probleem is dat ze te weinig worden gebruikt, zegt Ewout Kramer, bijvoorbeeld omdat ze te ingewikkeld zijn. Kramer is software-ontwikkelaar bij het Nederlandse Furore en architect in de zorg. Hij houdt zich al jaren bezig met het uitwisselen van patiëntgegevens tussen zorgsystemen. Hij is sinds het ontstaan van FHIR betrokken geweest bij de ontwikkeling van deze nieuwe standaard en is vaak te vinden op congressen en conferenties om over de FHIR standaard te vertellen.
Lijvige documentatie
De internationale HL7 organisatie werkt sinds 1987 aan de ontwikkeling van standaarden voor de opslag, de bewerking en de uitwisseling van medische gegevens. Die standaarden worden beschreven in lijvige specificaties en hebben namen als v2, CDA en CCOW. Het duurt jaren voordat de commissies die eraan werken een nieuwe versie opleveren.
Met de FHIR standaard koos HL7 voor een andere aanpak, door voort te borduren op de community-aanpak die veel meer aansluit op de open-source manier waarop programmeurs tegenwoordig werken. De standaard is geen ei dat na jaren studie door een kleine groep wordt gelegd, maar een set afspraken die letterlijk wekelijks wordt uitgebreid door een actieve groep software-ontwikkelaars en medewerkers van standaardisatie-organisaties.
Ewout Kramer: "Geen gebrek aan standaarden, wel aan toepassing ervan"
Wat de FHIR-standaard volgens Kramer verder onderscheidt van zijn voorgangers is dat hij veel gemakkelijker is om te gebruiken. Enerzijds omdat de standaard uit losse bouwstenen bestaat (zogeheten resources), en anderzijds omdat de techniek van FHIR naadloos aansluit op moderne webstandaarden die al bekend zijn bij vrijwel alle programmeurs.
Mickey Mouse voorbij
Er zijn al twee eerdere edities van de FHIR DevDays geweest. Maar dit jaar is volgens Kramer aan alles te merken dat FHIR is doorgebroken. “FHIR is definitief uit de Mickey Mouse fase gekomen in 2016. Bij vorige edities bekeken we demo’s en toepassingen die nog net in productie waren. Inmiddels zie je dat FHIR wordt gebruikt in serieuze toepassingen, zoals medicatie-berichten of thuismonitoring. Epic en Cerner, twee grootste leveranciers van informatiesystemen voor ziekenhuizen, ondersteunen de FHIR-standaard in hun nieuwste versies. Philips gebruikt FHIR in hun HealthSuite. We zijn de experimenten voorbij.”
Stichting Koppeltaal GGZ gebruikt FHIR voor de integratie tussen eHealth-toepassingen in de GGZ
In Nederland wordt door de Stichting Koppeltaal GGZ hard gewerkt aan FHIR profielen voor de integratie tussen eHealth platforms in de GGZ en games, oefeningen en ondersteunende apps die voor specifieke doelgroepen binnen de GGZ worden ontwikkeld. En Nictiz, het nationale instituut voor eHealth, kondigde deze maand aan dat het FHIR bouwstenen voor de Nederlandse situatie gaat valideren, beheren en publiceren.
Niet langer waarom, maar hoe
Kramer merkt de verschuiving ook aan de vragen die hij krijgt op zijn FHIR website. “Tot vorig jaar gingen die vragen nog over het 'waarom' van FHIR en de ontwerpfilosofie. Tegenwoordig gaan de meest vragen over de manier waarop je FHIR toepast: hoe werkt het in de praktijk?”
FHIR was (en is) niet onomstreden. Er zijn sceptici die zeggen dat de eenvoud van de FHIR bouwstenen een te grote versimpeling van de werkelijkheid is, en dat softwaremakers te veel vrijheid hebben om een eigen interpretatie aan data te geven. Daarmee wordt volgens hen de uitwisselbaarheid van gegevens juist minder.
Volgens sceptici is de eenvoud van de FHIR bouwstenen een te grote versimpeling van de werkelijkheid
Kramer begrijp dat geluid, maar is het er niet mee eens. “Bestaande standaarden probeerden alle complexiteit, inclusief juridische en culturele verschillen tussen zorgsystemen in één groot abstract bouwwerk te stoppen. Op papier werkt dat misschien goed, maar het vraagt van softwareontwikkelaars een fors leertraject en meer flexibiliteit dan ze in hun systemen willen of kunnen inbouwen. Daarbij maken die bestaande standaarden ook nog eens gebruik van infrastructuren die gedateerd zijn. ”
"Programmeurs gewend aan internet-technologie"
Internet-generatie
De generatie programmeurs die met apps en internet is opgegroeid, is volgens Kramer gewend aan een duidelijke specificatie om tegen te programmeren. De koppelingen (API's) die Facebook, Google of Twitter aan programmeurs bieden zijn helder en gemakkelijk toe te passen.
FHIR streeft die overzichtelijkheid na. Elke afzonderlijke FHIR module staat op zichzelf, de specificatie is zo duidelijk dat een programmeur er direct mee aan de slag kan. Dat betekent dat je compromissen moet sluiten, zegt Kramer. "Een Nederlandse module moet bijvoorbeeld weten wie je huisarts is. In de oudere standaarden probeerden de makers in de systematiek van alle patiënt-zorgverlener systemen van de hele wereld te voorzien. Maar je kunt als tussenweg ook kijken hoe dat binnen EU-landen werkt, of als dat nog te ingewikkeld is, dan is een module voor alleen de Nederlandse situatie misschien een betere oplossing." Hij benadrukt dat het om een voorbeeld gaat, maar in de praktijk lopen programmeurs tegen veel gelijksoortige vragen aan.
Geen vervanging van alle bestaande standaarden
FHIR is nadrukkelijk geen vervanging van alle bestaande standaarden voor de opslag van diagnostische beelden, ziekenhuislogistiek of declaratie-afhandeling. De nieuwe standaard is vooral geschikt gemaakt om smartphones, wearables of sensoren te laten communiceren met de grotere en doorgaans complexe systemen waarvan zorginstellingen gebruik maken. Bijvoorbeeld om via een app je medisch dossier te kunnen inzien, of om zelfgemeten bloeddrukwaardes uit te wisselen met het ziekenhuis. De FHIR voorstanders sluiten op voorhand echter geen enkele nieuwe toepassing uit.
"Complexiteit kun je met standaarden niet wegpoetsen"
“Ook de conservatievere garde binnen organisaties als HL7 ziet natuurlijk wel dat de bestaande standaarden nu niet bepaald een doorslaand succes zijn geweest”, meent Kramer. “Er kwamen steeds minder bezoekers op de jaarcongressen, en landelijke overheden waren terughouden met het afdwingen ervan. Met de brede acceptatie van FHIR is HL7 net op tijd de goede kant opgegaan.”
Kramer benadrukt dat ook FHIR niet een oplossing voor alles is: complexiteit kun je met standaarden niet wegpoetsen. “De ambitie van FHIR is om simpele dingen gemakkelijker te maken. Dat is al een hele uitdaging.”
Beste Ewout,
Dat veranderingen gepaard gaan met tegenwerking is heel menselijk. Dat er binnen HL-7 veel obsolete kennis zit is daar de oorzaak van. Oude garden die vasthouden aan hun eigen kindje en weigeren van hun rots af te komen.
Een stroming verander je door ook rekening te houden met je eigen ontstaansrecht. De mensen die zich hebben hard gemaakt om HL-7 V2 (de nog steeds meest gehanteerde versie van HL 7) bedoeld voor het versturen van berichten en het updaten daarvan, verdienen nog alle respect. Toen HL-7 met versie 3 kwam zaten daar hele goede gedachten achter en heeft het RIM model opgeleverd. Een architectuurmodel waarop wereldwijd vele EPD systemen op geïnspireerd zijn.
Jullie bij HL-7 zouden eens onderling moeten afstemmen welke onderdelen en versies van HL-7 tot jullie beste wereldwijde usecase ’s (best practices) behoren. Vindt elkaar en vul elkaar aan! Immers een standaard dient ook onderhouden te worden en dat brengt nu eenmaal veranderingen met zich mee. Op zijn Cruijffiaans zou ik zeggen “wie software maakt dient nu eenmaal zijn kennis te onderhouden, de informatie technologie is de snelst evoluerende industrie en wie daar niet in mee wil zou van het veld moeten gaan… dat is toch logisch”.
Tijdens de laatste IHE Wold Summit (afgelopen juni in Amsterdam). Zat ik in een overleg met je collega Rien Werdheim en Charles Parisot. IHE wil graag in overleg met HL-7 een testomgeving voor PHIR opzetten zodat deze in onze wereldwijde test omgeving kunnen inzetten tijdens onze Connecthatons. Kun je Rien eens vragen wat daar nu de status van is?
Zoals je weet staat de wereldwijde community die zich heeft verenigd binnen IHE, altijd open voor nieuwe versies van software die mee groeien met zijn tijd en deel uitmaken van ook modernere IHE profielen.
En dat is in het belang van de Global patient!
Dan had ik nog een paar kleine vragen
Je geeft aan:
“Daarbij maken die bestaande standaarden ook nog eens gebruik van infrastructuren die gedateerd zijn ”
Kun je me dat nader specificeren?
En dan zeg je ook:
“Maar je kunt als tussenweg ook kijken hoe dat binnen EU-landen werkt, of als dat nog te ingewikkeld is, dan is een module voor alleen de Nederlandse situatie misschien een betere oplossing.”
Hier ben ik het niet mee eens. Er zijn verschillende Europese initiatieven waar uitwisseling van patiënten gegevens is aangetoond. Zo is er veel gemeenschapsgeld in het Epsos project gestopt en daar zitten uitvoerig geteste componenten (gebaseerd op standaarden) in die hergebruik verdienen. Dit in het belang van de “Global Patient”!
Met vriendelijke groeten en tot snel!