De architectuur van de zorginformatie-systemen van de toekomst

In onze eerdere artikelen in de reeks ‘De toekomst van databeschikbaarheid in de zorg’ belichtten we de mogelijkheden die open (zorgdata)platformen te bieden hebben voor databeschikbaarheid. Maar wat betekent dit voor de architectuur van zorginformatiesystemen zoals EPDs? Welke veranderingen zijn er vereist om open platformen zo te kunnen inzetten dat de zorg in de toekomst écht datagedreven kan werken?

Twee programmeurs werken samen aan de architectuur van hun zorginformatiesysteem.


De data-laag ‘lostrekken’ van de functionaliteit

In ons artikel ‘Open platformen voor optimale databeschikbaarheid in de zorg’ stipten we het al even aan: wanneer we open platformen inzetten voor databeschikbaarheid, bevatten deze open platformen de data en kunnen deze middels open API’s communiceren met de applicaties van allerhande zorgsystemen.

Dit betekent dan, simpel gezegd, dat zorginformatiesystemen zélf dus geen data meer bevatten. De verschillende zorginformatiesystemen benaderen en verwerken de data die gestandaardiseerd opgeslagen zijn in de open platformen (meer over deze standaarden hieronder).

Dit is echter niet hoe de meeste zorginformatiesystemen nu zijn opgebouwd - deze doen nu veelal zelf de data-opslag op basis van een eigen datamodel en dit is op technisch vlak verweven met de rest van de applicatie. Dit moet dus ‘losgetrokken' worden, zodat de applicatie ook aan een externe data-laag gekoppeld kan worden: het open platform.

Een transitie

Dit ‘lostrekken’ van de data-laag en de applicatie vereist uiteraard wat van de leveranciers van zorginformatiesystemen. Zij moeten dit (willen) faciliteren, zodat we niet blijven hangen in het eeuwig dupliceren van data ten behoeve van data-uitwisseling en écht een toekomst voor ons kunnen zien waarin databeschikbaarheid de norm is.

Wij zien in deze transitie ruwweg drie fases, wat we ter voorbeeld even voorstellen als het fictieve scenario voor Medisch Centrum NL, dat een EPD in gebruik heeft:

Fase 1 - het nulpunt

Medisch Centrum NL gebruikt een EPD dat een eigen data-repository heeft. Het verdere ‘landschap’ aan zorginformatiesystemen staat hier in basis los van. Wanneer er integraties gerealiseerd worden tussen het EPD en de andere zorginformatiesystemen (die eigenlijk samen het EPD-landschap vormen), kan data wel uitgewisseld worden tussen de verschillende systemen, maar dit is effectief data-duplicatie. Dit is momenteel de realiteit voor veel zorgorganisaties / leveranciers.

Fase 2 - in transitie

Medisch Centrum NL gebruikt een EPD-applicatie, dat gekoppeld is aan een open platform dat de data en diverse diensten bevat - binnen het open platform heeft het Medisch Centrum ook een eigen data-repository. Andere zorginformatiesystemen kunnen ook met dit open platform koppelen. Dit maakt integraties gemakkelijker en laagdrempeliger en zorgt dat data niet meer gedupliceerd hoeft te worden om beschikbaar gemaakt te worden. Meerdere systemen kunnen data benaderen vanuit dezelfde bron: het open platform. Andere zorgorganisaties kunnen dezelfde werkwijze hanteren en, wanneer de juiste authenticatie verkregen is, dezelfde data benaderen. Bij een aantal leveranciers, zoals CODE24, staat de data-laag al los van het EPD, waardoor dit scenario al realiteit is.

Fase 3 - het eindscenario

Het Medisch Centrum stelt zelf modulair een EPD samen. Al deze EPD-modules vormen samen het EPD-landschap en dit gehele landschap benadert data vanaf dezelfde bron: het open platform. Afhankelijk van welke diensten er op dataniveau benodigd zijn kan Medisch Centrum NL kiezen om met één of meerdere open platformen samen te werken.

De gefedereerde laag

In bovenstaande scenario’s hebben we het voor het gemak gehad over ‘een’ open platform - maar in de praktijk zullen dit er meerdere zijn, die ieder eigen services aan kunnen bieden. We noemden eerder in deze blogreeks al het belang van een gefedereerde samenwerkings-laag om te zorgen dat de data uit deze open platformen toch samengevoegd kan worden om noodzakelijke ‘totaalplaatjes’ te vormen, die de zorgorganisaties kunnen benaderen. Hoe deze federatie er in de praktijk uit zal komen te zien is in een sand-box omgeving door Ernst and Young (EY) bepaald en beschikbaar voor open platform leveranciers om te implementeren.

Open standaarden

De hierboven geschetste scenario’s vereisen standaardisering van de opslag en het modelleren van zorgdata. Dat zijn an sich geen nieuwe concepten, de ISO 18308 norm voor EPD-architectuur (waar bijvoorbeeld openEHR op gebaseerd is) stelde al:

“The EHR should […] provid[e] a framework for standardized representation of information, and the consistent use of coding systems within that representation, that improves data quality at source and enhances reuse of data.”

Door standaardisering van de opslag van data (en van de structuur van data-modellen) wordt zorgdata meervoudig bruikbaar en interpretabel over verschillende zorgdomeinen en taalgebieden. “[E]enduidige zorginformatie voor primair en secundair (meervoudig) gebruik” is bovendien een van de pijlers van de European Health Data Space, zie daarvoor ook deze publicatie van Nictiz. Hoog tijd om vanuit de overheid sturing te geven op basis van deze ISO-norm en het als leveranciers echt te gaan naleven.

Partijen als Nictiz en EY doen uitgebreid onderzoek naar de optimale samenhang van standaarden voor het Nederlandse zorgstelsel - zie bijvoorbeeld het “Onderzoek toekomstscenario’s zibs”. De algemene consensus lijkt helder: we moeten kijken naar een combinatie van standaarden, waarbij iedere standaard datgene doet waar het goed in is. HL7 FHIR wordt dan ingezet voor het veilig uitwisselen van zorgdata tussen systemen, openEHR voor de gestandaardiseerde opslag van zorgdata en zibs bijvoorbeeld als verbinding tussen data-opslag en data-uitwisseling.

Als leveranciers deze standaarden en de bijbehorende ‘bouwstenen’ willen ondersteunen, zullen zij moeten kijken naar de architectuur die aan hun applicaties ten grondslag ligt. Een mogelijke oplossingsrichting is bijvoorbeeld een meer modulair opgebouwd systeem.

Uitdagingen

Dit herstructureren van bestaande architecturen en applicaties zal nogal wat voeten in de aarde hebben - dit proces is veelal complex en duur. De noodzaak wordt echter in toenemende mate helder - met alleen gegevensuitwisseling komen we er niet. Het zal wellicht helpen als er vanuit de overheid richting gegeven wordt aan de standaardisering van data-opslag. In 2022 heeft VWS op het gebied van gegevensuitwisseling al de keuze gemaakt voor HL7 FHIR als uitwisselingsstandaard - wellicht kan er eenzelfde keuze gemaakt worden voor openEHR als standaard voor de opslag en het modelleren van zorgdata (of kan er op zijn minst actiever nadruk gelegd worden op de naleving van de ISO 18308).

Het voordeel van openEHR is uiteraard dat je het wiel niet volledig zelf hoeft uit te vinden. Er is bovendien een actieve internationale community die werkt aan de doorontwikkeling van de standaard (de archetypen en templates, zoals open source beschikbaar binnen de openEHR Clinical Knowledge Manager).

Vanuit CODE24 zien we de toekomst in zorginformatiesystemen zoals hierboven omschreven in ‘fase 3’, maar we zijn ook realistisch: met de grote variëteit aan stakeholders, technologieën en belangen zal het even duren voor we zover zijn.

Stap voor stap

Ondanks de geschetste uitdagingen is het van belang om de fundering te leggen voor de architectuur van het zorginformatiesysteem van de toekomst én om elkaar scherp te houden. Zo zien we dat in recente discussies de term ‘databeschikbaarheid’ soms al aan devaluatie onderhevig is. Er worden projecten en POCs gestart in het kader van databeschikbaarheid waarbij de focus ligt op het kunnen lezen van (een beperkt deel van) data, middels bijvoorbeeld een FHIR Viewer, maar waarbij de noodzaak om ook direct bij de bron te kunnen schrijven niet wordt meegenomen. Een beperkte vorm van databeschikbaarheid naar onze mening. In de praktijk wordt er dan ook wel eens gesproken van ‘databereikbaarheid’ of ‘datatoegankelijkheid’, wat accuratere termen zijn.

We moeten blijven streven naar échte databeschikbaarheid, waarbij het maken van datakopieën grotendeels overbodig wordt. Om dit te bereiken is de aanpassing van de architecturen van onze zorginformatiesystemen een vereiste. Het zal goede samenwerking tussen de zorgorganisaties, de overheid, adviesorganen en leveranciers vereisen om deze architectuur vorm te geven, zonder concessies te doen aan het einddoel.

Dit artikel is deel van de blogreeks ‘De toekomst van databeschikbaarheid in de zorg’, waarin we ingaan op de mogelijkheden van open platformen voor databeschikbaarheid, de uitdagingen van die oplossingsrichting en de visie van CODE24 op dit onderwerp.

Lees ook:

Jenny Luco

Jenny is de marketingmanager van CODE24.

https://www.code24.nl
Vorige
Vorige

De kernwaarden van CODE24

Volgende
Volgende

De meerwaarde van Lab24 voor Dimence Groep