Data-extractie uit silo's - de aanpak van CODE24

De zorg-IT staat op een cruciaal kruispunt. Iedereen heeft het over databeschikbaarheid, regionale samenwerking en datagedreven zorg. De dagelijkse realiteit op de IT-afdeling is echter vaak een stuk weerbarstiger. De data zit namelijk vaak muurvast, gevangen in zorgsystemen die prima hun werk doen voor die ene specifieke afdeling of instelling, maar die afgeschermd zijn voor de rest van de wereld. Bij CODE24 geloven we dat de échte waarde van zorgdata zit in de vloeibaarheid en het hergebruik ervan. Waarom zou je data telkens opnieuw handmatig inkloppen of tig keer kopiëren voor gebruik in andere systemen?

Om echt toekomstbestendig te zijn en echte databeschikbaarheid te realiseren, moet data geëxtraheerd kunnen worden uit traditionele systemen en omgezet worden naar een toekomstbestendig, leveranciersonafhankelijk format: openEHR. Wanneer data gemodelleerd en opgeslagen wordt volgens een generiek en open informatiemodel, bouw je aan een solide fundament waar je vervolgens oneindig veel nieuwe toepassingen op kunt bouwen. Maar hoe doe je dat als leveranciers van zorgsystemen deze aanpak niet ondersteunen of zelfs tegenwerken?

De uitdaging: de deur is dicht

Als je al langer meeloopt in de zorg-IT, herken je het patroon direct. Legacy zorgsystemen hebben een aantal hardnekkige eigenschappen die data-extractie ingewikkeld maken. Ze werken vaak met een strikt leveranciersafhankelijk informatiemodel. Databaseschema’s zijn vaak niet beschikbaar. 

Ook het maken van koppelingen tussen systemen ten behoeve van interoperabiliteit is tricky. Voor elke nieuwe koppeling, use-case of gewenste functionaliteit moeten er nieuwe API-koppelingen worden ontwikkeld, wat zorgorganisaties flink wat tijd en geld kost. 

Er zijn dus diverse barrières - tijd om die te doorbreken! 

De aanpak: gestructureerd extraheren

Hoe vlieg je een dergelijk data-extractieproject aan zonder te verzanden in een meerjarenplan? Het geheim zit in een ijzersterke governance gecombineerd met een pragmatisch extractieplan. Je moet precies weten wat je gaat halen, waar het staat en hoe vaak je dat doet. Meestal praten we hierbij over éénrichtingsverkeer: we lezen de data uit bij het legacy zorgsystemen en schrijven het weg naar openEHR. Terugschrijven naar de legacy bron gebeurt veelal niet, tenzij de leverancier hiervoor de nodige middelen (een beschikbare API) aanbiedt.

Het informatie-extractieplan in 6 stappen

1. Welk zorgsysteem? Identificeer exact de legacy bron (inclusief specifieke softwareversie) waaruit de data afkomstig is.
2. Welke dataset? Baken de scope af. We hoeven niet blind alles te kopiëren; welke klinische data is écht relevant voor de use-case?
3. Welke methodiek? Bepaal de technische route op basis van de beschikbare opties (zie het overzicht van methoden hieronder).
4. Welke frequentie? Hoe actueel moet de data in openEHR zijn? Moet dit direct (near real-time), of volstaat elke minuut, elk uur, dagelijks of wekelijks?
5. Welk informatieobject? Leg de metadata, de exacte opslaglocatie en het versiebeheer van het doelelement nauwkeurig vast.
6. Welk proces? Richt het eigenaarschap, de foutafhandeling en de monitoring in rondom de datastroom (wie grijpt er in als een extractie faalt?).

De methode

• De API: als er een bruikbare, gedocumenteerde API van het zorgsysteem beschikbaar is, dan gebruiken we die uiteraard als formele route.
• Extractie middels berichten: zijn er geen directe API's, maar stuurt het systeem wel FHIR-bronnen, HL7 v2-berichten of CDA-documenten uit bij bepaalde events? Dan vangen we deze stromen op om de openEHR-omgeving te voeden.
• Directe SQL-queries: is het systeem volledig hermetisch gesloten en is er geen ondersteuning vanuit de leverancier mogelijk? Dan is er soms nog de mogelijkheid om rechtstreeks via SQL-queries op de onderliggende database de benodigde tabellen te extraheren.
• Het datawarehouse: is er al een datawarehouse met gestandaardiseerde data uit het zorgsysteem beschikbaar? Dan tappen we daar direct uit. 

De rol van de ETL-tool

Om het uitgekristalliseerde proces in goede banen te leiden, zetten we een robuuste ETL-tool (Extract, Transform, Load) in. Deze tool moet moeiteloos overweg kunnen met de verschillende (FHIR-)dialecten die leveranciers hanteren, want 'standaard FHIR' is in de praktijk helaas zelden écht standaard. Daarnaast moet de ETL-tool onzichtbaar en stabiel als achtergrondproces kunnen draaien en moet de extractiefrequentie per gekoppeld zorgsysteem afzonderlijk instelbaar zijn. 

Geleerde lessen uit de praktijk

Mooi, al die uitgeschreven theorie, maar hoe vertaalt zich dit naar de weerbarstige praktijk? Bij CODE24 hebben we deze aanpak inmiddels succesvol toegepast bij diverse complexe use cases, waaronder:

1. Ontsluiting vanuit HiX naar PGO
   Het ontsluiten van gestructureerde data vanuit een EPD zoals ChipSoft HiX naar een MedMij-gecertificeerde Persoonlijke Gezondheidsomgeving (PGO) is vaak een hoofdpijndossier. Door data te syncen middels HL7 en aanvullend op te halen middels queries, kon dit vervolgens met tussenkomst van een open zorgdata platform via de API van het PGO doorgezet worden. Een mooi voorbeeld van hoe data beschikbaar gemaakt kan worden voor de patiënt. 

2. Gezamenlijke behandeling EPA-doelgroep
   Bij de behandeling van de Ernstig Psychiatrische Aandoeningen (EPA) doelgroep trekken meerdere ggz-instellingen samen op. Twee verschillende organisaties, verschillende EPDs, maar één gezamenlijke patiënt. Door de data via ons extractieplatform veilig samen te brengen in een openEHR data platform, ontstaat er één actueel, gedeeld behandelbeeld voor de behandelaars van beide instellingen.

3. Ambulante samenwerking met actieve dataontsluiting
   In de ambulante zorg wil je niet achteraf horen wat er gisteren is gebeurd; je hebt nú de data nodig. Voor een van onze klanten hebben we een actieve data-ontsluiting gerealiseerd waarbij de meest actuele data continu uit het bron-EPD wordt gehaald voor gebruik in de ambulante applicatie. Ook hier werd er gebruikgemaakt van een combinatie van een synchronisatie middels HL7-berichten en het ophalen van zorgdata middels queries.

Zorgdata-autonomie begint vandaag

De mogelijkheid hebben om data uit zorgsystemen te extraheren en dit te standaardiseren voor meervoudig gebruik is een strategische noodzaak om als zorginstelling de regie op je eigen zorgdata terug te pakken. Het is niet gemakkelijk, maar met het juiste extractieplan, een flexibele ETL-laag die dialecten begrijpt en een heldere visie op het hergebruik van data, is meermaals bewezen dat het kan.

Benieuwd hoe we jouw zorgdata uit de silo’s kunnen halen, klaar voor meervoudige bruikbaarheid? Als Value Added Reseller (VAR) van het openEHR data platform Cadasto hebben we zowel de know-how als het platform om een dergelijk project succesvol bij je op te starten. Laten we eens informeel sparren.