NICE registratie sorteert met FHIR voor op realtime monitoring

75.000. Zoveel nieuwe ic-opnamen voegen de Nederlandse ic-afdelingen jaarlijks toe aan de landelijke kwaliteitsregistratie van NICE. NICE vergelijkt die gegevens vervolgens op basis van een viertal kwaliteitsindicatoren – mortaliteitsratio, heropname, behandelduur en beademingsduur – en onderzoekt wat de best practices zijn voor bepaalde condities. Zo brengt de NICE registratie in kaart op welke vlakken de ic’s in Nederland kunnen worden geoptimaliseerd richting uitkomstgerichte zorg.

Toe naar een realtimemodel

Het delen van de ic-gegevens voor de kwaliteitsregistratie gebeurt in de meeste deelnemende ziekenhuizen op maandbasis, via CSV-bestanden. En hoewel dat in principe prima werkt, wil de NICE registratie graag toe naar een realtimemodel. ‘Het liefst uiteindelijk zelfs zó realtime dat NICE een pushmelding krijgt bij alle belangrijke momenten in de behandeling,’ licht Abel toe. ‘Dat is natuurlijk een ideaalbeeld, en bovendien nog toekomstmuziek, maar de registratie is er al wel op aan het voorsorteren.’

Een server selecteren

De sleutel naar dat realtimemodel is FHIR, een datastandaard die in de zorg gebruikt wordt om digitaal medische gegevens uit te wisselen. En wie wil gaan werken met FHIR, heeft een FHIR-server nodig. Maar hoe kies je zo’n server, en hoe implementeer je die? Daarvoor vroeg NICE Furore Conclusion om hulp.

‘Er zijn gelukkig niet zo heel veel FHIR-servers, dat scheelt,’ lacht Abel. ‘Maar we hebben als Furore Conclusion toch een overzicht gemaakt van het aanbod. Een stuk of drie servers kunnen we vrijwel altijd aanbevelen, en de uiteindelijke keuze maken we op basis van wat de klant wil. NICE doet bijvoorbeeld alles met Java, en dan is het heel duidelijk: NICE heeft gekozen voor de HAPI server. Maar we hebben ook een klant die meer met .NET doet, en dan raden we juist Firely Server aan.

Customizen met plug-ins 

Met een server alleen ben je er echter nog niet altijd, gaat Abel door. ‘Vaak willen gebruikers net iets anders dan wat de standaardservers te bieden hebben, en dan kun je de server customizen met plug-ins. Die zijn er in twee smaken: óf je kiest voor een standaardplug-in, óf je maakt er zelf een.’

De server van NICE had customisatie nodig op het gebied van multi-tenancy. Abel: ‘We moesten ervoor zorgen dat de aanleverende ziekenhuizen niet bij elkaars data kunnen komen. Daar was geen standaardplug-in voor, dus die hebben we zelf gemaakt. Nu heeft elk ziekenhuis een eigen login die leidt naar een afgebakende omgeving waarin alleen de data van dát specifieke ziekenhuis te zien zijn. NICE is de enige gebruiker die alle ziekenhuizen tegelijkertijd kan zien, omdat zij natuurlijk het overzicht nodig hebben.’

FHIR Facade 

Om ervoor te zorgen dat niet alleen de ontvangst bij NICE, maar ook de aanlevering vanuit de ziekenhuizen soepel verloopt, is er ook een pilot gestart bij het LUMC. Abel: ‘Bij drie ziekenhuizen, UMCU, LUMC en Erasmus MC, zijn we al een tijdje bezig met een zogenaamde FHIR Facade. Dat is ook een FHIR-server, maar dan eentje die data, via een data warehouse, uit het ziekenhuissysteem haalt, en dus niet uit een eigen database. Daardoor hebben we nu aan beide kanten van het systeem een FHIR-server en kunnen we op een soepele en gestandaardiseerde manier de data uitwisselen.’

Sprongen in kwaliteit 

De implementatie is inmiddels afgerond, en Abel kijkt er met een goed gevoel op terug. ‘We zijn op weg naar een nieuwe manier van werken met data, en dat is ontzettend interessant. Als ziekenhuizen continu data aanleveren, kan NICE immers zaken gaan signaleren die nú aan het gebeuren zijn. Dat is nog onontgonnen gebied, maar als je op den duur realtime kunt monitoren welke interventies er worden gedaan en hoe een opname verloopt, dan kun je echt sprongen maken op het gebied van zorgkwaliteit.’