Nieuwe standaard zorggegevens

De voordelen van gestandaardiseerde zorggegevens zijn groot. Vrijwel alle ziekenhuizen in Nederland gebruiken de standaard HL7 versie 2. Maar die is verouderd. De aanpak voor de nieuwe standaard, FHIR, past bij deze tijd, zegt Ewout Kramer, de open-sourcegedachte staat centraal. De tweede versie komt uit in het najaar, de eerste definitieve versie in 2016.

Standaardisatie en uitwisseling van gestandaardiseerde gegevens bieden grote voordelen. Als je buiten bewustzijn in een vreemd ziekenhuis belandt, is het belangrijk dat de artsen daar je allergieën en huidige medicatie kennen. De vraag is echter hoe dit is te realiseren. Dit jaar wordt hierin een belangrijke stap genomen met FHIR, een nieuwe standaard voor de uitwisseling van zorggegevens.

Standaardisatie is niet vanzelfsprekend. Als maker van apparatuur of software moet je met producenten en concurrenten om de tafel, je product aanpassen en vaak leren leven met de beperkingen van een standaard. Dit probleem groeit naarmate het onderwerp van standaardisatie complexer is. Afspraken maken over maten van een schroef zijn nog tot daar aan toe, maar hoe standaardiseer je bijvoorbeeld zorggegevens? Hoe legt een huisartseninformatiesysteem een allergie of behandelplan zó vast dat een ziekenhuisinformatiesysteem deze gegevens naadloos kan overnemen, zonder levensgevaarlijke misverstanden te krijgen?

De voordelen van gestandaardiseerde zorg­gegevens zijn zo groot, dat er al geruime tijd pogingen worden ondernomen om ook deze gegevens uit te kunnen wisselen. De van oorsprong Amerikaanse organisatie HL7 (Health Level 7) maakt al sinds 1987 standaarden die momenteel in ruim dertig landen in gebruik zijn. De nieuwste telg uit deze familie is FHIR (Fast Healthcare Interoperability Resources). Om de vraag of dit dé standaard wordt voor de uitwisseling van zorggegevens te kunnen beantwoorden, moeten we terug in de tijd naar HL7 versie 2. Vrijwel alle ziekenhuizen in Nederland en België (en eigenlijk de gehele geautomatiseerde wereld) gebruiken op dit moment deze versie. Versie 2 (en daarvoor versie 1) ontstond vanuit de behoefte om onder andere laboratoriumuitslagen niet handmatig in te voeren, maar geautomatiseerd uit te wisselen tussen systemen binnen een ziekenhuis. Belanghebbenden zaten om de tafel en ontwierpen een standaard die voldeed aan de directe eisen van de betrokkenen: precies goed genoeg voor (Amerikaanse) laboratoriumdoeleinden, en binnen afzienbare tijd te realiseren door de leveranciers van de softwaresystemen.

 

Top-down

Rond 2000 ontstond de behoefte aan herziening van de standaard. Doelen waren meer consistentie, betere mogelijkheden voor lokale aanpassingen en een ontwerp met herbruikbare delen, zodat niet voor elke koppeling opnieuw software geschreven moet worden. Dit nieuwe product – HL7 versie 3 – richtte zich op het gebruik van een sterke methodiek om zorgstandaarden te ontwerpen die wereldwijd onderling consistent en herbruikbaar zijn. Ongemerkt leidde dit er echter toe dat de nadruk kwam te liggen op modeltechniek en ontwerp en minder op daadwerkelijke toepasbaarheid en implementeerbaarheid in softwaresystemen. De modelleur kreeg voorrang boven de softwareontwikkelaar. Bovendien vereist versie 3 een top-down-aanpak. De internationale standaard bevat veel ‘open plekken’, die nationale en regionale standaardisatieorganisaties eerst moeten invullen voordat de standaard lokaal (in een regionale uitwisseling) is te gebruiken. Het gevolg hiervan werd pas in de jaren na publicatie van de standaard duidelijk: de software­leveranciers zijn afhankelijk van regionale overheden (en hun prioriteiten) om de standaard lokaal inzetbaar te maken. Versie 3 bleek in de praktijk te complex, met als gevolg dat de marktvraag ver achter bleef bij versie 2.

De HL7-organisatie realiseerde zich dat versie 3 de beoogde doelen niet ging halen en dat een succesvolle standaard meer bottom-up ingestoken moet worden. De behoeften van de producent moesten ook aan bod komen. Bovendien voorzag de organisatie het risico dat leveranciers op zoek zouden gaan naar een alternatieve standaard. Reden om in januari 2011 te starten met het Fresh Look-initiatief. De organisatie vroeg een internationale werkgroep om vanaf nul een nieuwe HL7-standaard te ontwikkelen. Basisvereisten: de ontwikkelaar moet centraal staan, open standaarden als uitgangspunt en de standaard moet compatible zijn met hoe iedere ontwikkelaar – ook degenen die niet uit de zorg komen – omgaat met cloud en mobiele technologie. XML, JSON en RESTful-technologie moesten een vast onderdeel van de standaard zijn.

 

Bottom-up

De laatste grote les die getrokken was uit de ontwikkelingen rond HL7 versie 3, was dat het bereiken van universele, overal gestandaardiseerde gegevensstructuren een te ambitieus doel is. Het is veelal voldoende (én kosteneffectiever) om te standaardiseren wat gegeven een bepaald domein, branche of regio gestandaardiseerd móet worden en de rest vrij te laten. Het Amerikaanse bureau voor statistiek mag dan wel van patiënten het ras en geloof willen vastleggen, in Europa gebeurt dat niet. FHIR laat de one-size-fits-all-gedachte los en standaardiseert alleen wat internationaal gangbaar is in bestaande systemen, in FHIR aangeduid met ‘de kern’. Daarbuiten mag iedereen, voor de eigen context en businesscase, de standaard uitbreiden. Dat betekent dat niet langer alleen nationale instellingen, maar ook leveranciers (en concurrenten) onderling de voor hun branche specifieke zaken kunnen toevoegen. De intentie is om al deze zelf ontwikkelde uitbreidingen te uploaden naar een internationale bibliotheek, zodat ze herbruikbaar zijn voor andere FHIR-gebruikers.

De aanpak voor FHIR past bij deze tijd. De open-sourcegedachte maakt het mogelijk dat de developer community invloed uitoefent op de standaard. Kleine, individuele ontwikkelaars zijn even welkom om mee te denken als grote organisaties. De HL7-organisatie stelt dan ook testservers, voorbeelden en broncode in open source ter beschikking aan de community. Speciaal hiervoor is in januari 2014 een voorlopige versie gepubliceerd, waar iedereen op mag schieten. Via forums is feedback te geven op dit voorlopige product. Hun input wordt direct verwerkt in een tweede voorlopige versie die na de zomer van 2015 uitkomt. Deze is dermate stabiel dat zij in de Verenigde Staten voor semi-productietoepassingen gebruikt gaat worden. De eerste definitieve versie is gepland voor 2016.

Deze iteratieve werkwijze – direct geïnspireerd door softwareontwikkeling in de laatste tien jaar – zorgt ervoor dat op het moment van publicatie in 2016 geen nare verrassingen kunnen optreden. Op technisch niveau is FHIR al door vele tientallen partijen uitgeprobeerd. Nu richt de aandacht zich op de flexibiliteit om eigen uitbreidingen toe te voegen en het valideren van de ‘kern’. Hierbij wordt strikt gekeken naar wat in de praktijk gebruikelijk is: wat hebben systemen die nu in de markt zijn nodig van een standaard? Aan de hand hiervan blijft de standaard pragmatisch en gericht op de leverancier en eindgebruiker.

 

Vliegende start

Naast vele kleinere partijen zijn ook grote Amerikaanse EPD-leveranciers en zorgconglomeraten (zoals Epic, Cerner en Intermountain Healthcare en de Veterans Association) met FHIR aan de slag. Ook de Amerikaanse overheid heeft de nieuwe standaard omarmd. Het recente JASON-rapport (zeg maar onze weten­schappelijke raad voor regeringsbeleid) neemt FHIR als voorbeeld voor de weg naar interoperabiliteit via gestandaardiseerde API’s. Daarnaast wordt FHIR onderdeel van het automatiseringsbeleid van het Amerikaanse ministerie van gezondheidszorg.

FHIR heeft met de eerste versie vorig jaar een vliegende start gemaakt. De intentie om een alternatief te bieden in de vorm van een ‘bottom-up’-standaard, gericht op de ontwikkelaar, wordt positief ontvangen. Zeker omdat deze aanpak het eenvoudig zal maken om basisgegevens uit te wisselen en het mogelijk maakt om de standaard naar eigen behoeften uit te breiden.

De komende maanden moet blijken of FHIR ook uitgebreidere usecases goed ondersteunt. De eerste ervaringen laten wel zien dat softwareproducenten sneller geneigd zijn FHIR toe te passen uit eigen beweging. Dit dus zonder subsidies en als alternatief voor branchespecifieke, zelf bedachte standaarden. De uiteindelijke intentie is de basiskosten voor het ontwikkelen van software voor uitwisseling van zorggegevens te verlagen, met minder tijdsinspanning. Wij zijn ervan overtuigd dat deze besparingen worden besteed aan waar het uiteindelijk om gaat: het realiseren van functionaliteit voor de eindgebruiker. Op dit moment wordt een groot gedeelte van het budget besteed aan het mogelijk maken van communicatie. Dit zou echter een gemakkelijk te realiseren basisvoorwaarde moeten zijn. Door verdere standaardisatie moeten ontwikkelaars apps kunnen maken die vrijelijk en met een breed aantal systemen kunnen samenwerken, en niet met één of twee specifieke zorgsystemen. Zo wordt uitwisseling en standaardisatie weer nuttig, betaalbaar, en wie weet zelfs leuk.

 

Kenmerken Fast Health Interoperability Resources

Een eenduidige manier voor data-uitwisseling, die dichterbij de softwareontwikkelaar staat dan bijvoorbeeld HL7 versie 3. Maakt gebruik van in alle industrieën gangbare technologie, zoals van REST en OAuth. ‘Bottom-up’-aanpak: de community test en geeft feedback. Deze informatie wordt gebruikt om de standaard te optimaliseren. FHIR richt zich op 80 procent standaardisatie, 20 procent van de standaard is flexibel in te vullen (80/20 regel).

 

HL7 FHIR Developer Days

Binnen Europa speelt Nederland een belangrijke rol bij de verdere ontwikkeling van FHIR. Niet voor niets vonden de allereerste wereldwijde HL7 FHIR Developer Days eind november 2014 plaats in Amsterdam. Ruim zeventig deelnemers uit meer dan vijftien verschillende landen van over de hele wereld waren drie dagen in Amsterdam aanwezig om meer te leren over FHIR en te ontwikkelen met FHIR. De FHIR Developer Days staan dit jaar gepland op 18, 19 en 20 november 2015 in Amsterdam (zie: www.hl7.org/fhir).

Tag

HL7
EPD

Onderwerp



Niet gevonden? Vraag het de redactie!

Heeft u het antwoord op uw vraag niet gevonden, of bent u op zoek naar specifieke informatie? Laat het ons weten! Dan zorgen we ervoor dat deze content zo snel mogelijk wordt toegevoegd, of persoonlijk aan u wordt geleverd!

Stel uw vraag