Deze publicatie verscheen eerder als een column in ‘Transforming Healthcare Together - openEHR Supports Innovation’, een bundel met bijdragen door partners van openEHR International.
Een van de uitdagingen met betrekking tot de opslag van zorgdata is dat er veel verschillende soorten data zijn en dat elk daarvan zijn eigen specifieke uitdagingen met zich meebrengt. In dit artikel gaan we dieper in op demografische gegevens, zoals naam, leeftijd, woonplaats, relaties, enzovoort.
Het openEHR Referentiemodel is vanaf het begin in staat geweest om dergelijke gegevens op te slaan, maar veel partijen hebben ervoor gekozen om demografische gegevens middels HL7 FHIR op te slaan - of ze standaardiseren demografische gegevens überhaupt niet. Waarom is dit het geval en zou openEHR niet gebruikt kunnen worden? Bij CODE24 gebruiken we sinds ons prille begin het openEHR Demografiemodel. We delen graag onze visie hierop.
Een van de problemen waarmee veel mensen worden geconfronteerd wanneer ze overwegen om het openEHR Demografiemodel te gebruiken, is dat de demografische gegevens niet binnen het EHR (dossier) worden opgeslagen, maar in zekere zin ‘ernaast’. Zodoende kan er een dossier aan een patiënt gekoppeld worden en tegelijkertijd kan de veiligheid van de gegevens geborgd worden. Het betekent echter ook dat je de AQL niet kunt gebruiken om demografische gegevens op te vragen, aangezien dat soort gegevens nog niet door de AQL-specificaties wordt ondersteund. Een ander probleem is dat demografische archetypen types en definities uit een andere namespace nodig hebben, waardoor het moeilijk is om die gegevens te gebruiken wanneer je klinische archetypen modelleert.
Door het gebrek aan AQL-ondersteuning, de schaarste aan beschikbare archetypen en het ontbreken van API-specificaties zagen leveranciers er jarenlang geen heil in om te investeren in de implementatie van het openEHR Demografiemodel. Ook vanuit zorginstellingen was er geen specifieke vraag naar – er waren alternatieve oplossingen beschikbaar, waardoor het niet rendabel was om naar nieuwere, innovatievere oplossingen te kijken. Dit gebrek aan vraag vanuit de markt zal ook een rol hebben gespeeld in het gebrek aan interesse van de leveranciers.
Gelukkig beschikken we tegenwoordig over specificaties voor openEHR Demografische API's. Er heeft ook een verschuiving plaatsgevonden in de markt, wat betekent dat er een groeiende belangstelling is voor wat openEHR te bieden heeft op het gebied van het opslaan en modelleren van zorgdata, waaronder demografische gegevens.
Bij CODE24 hebben we het voordeel dat we vanaf het begin gebruik hebben gemaakt van het openEHR Demografiemodel. We konden met een schone lei beginnen en alleen de openEHR-specificaties gebruiken. Bij andere organisaties zijn er vaak bestaande (administratieve) processen waarvoor al oplossingen voor het opslaan van demografische gegevens worden gebruikt, zoals HL7 FHIR. Denk bijvoorbeeld aan facturering, gebruikersbeheer of het bijhouden van permissies en audit trails. Wij hadden geen dergelijke legacy en waren vrij om alle facetten van de openEHR-specificaties volledig te omarmen, inclusief het Demografiemodel.
Door de jaren heen zijn we erg blij geweest met onze keuze om het Demografiemodel te gebruiken voor de caseload van zorgverleners, zorgteams, patiëntrelaties, het opnameproces, enzovoort. Het heeft ons de flexibiliteit gegeven die we nodig hebben en biedt ons een solide basis waarop we ons portfolio van oplossingen kunnen blijven uitbreiden. Wanneer je meer gegevens opslaat volgens de openEHR-specificaties, kun je in grotere mate vanuit één bron werken en is er minder behoefte aan het mappen en kopiëren van gegevens om deze te delen. OpenEHR is ook zeer geschikt om de geschiedenis van patiëntgegevens op te slaan, dankzij het versiebeheermechanisme dat beschikbaar is voor alle openEHR-gegevens die worden bewaard. Bij alternatieven ontbreken vaak oudere demografische gegevens (zoals een oud adres of oudere zorgrelaties). Het beschikbaar hebben van deze gegevens is waardevol voor zowel onderzoek als preventie.
We gaven er sterk de voorkeur aan om zoveel mogelijk één enkele open standaard te gebruiken, om zo de complexiteit van de code en het systeem dat we aan het ontwikkelen waren te verminderen. Het combineren van openEHR- en FHIR-specificaties is natuurlijk in veel opzichten nog steeds een standaardwerkwijze in onze sector, maar wij geven er de voorkeur aan om gegevens zoveel mogelijk volgens de openEHR-specificaties op te slaan. Deze zijn speciaal voor dit doel ontwikkeld en wij zijn overtuigd van de voordelen ervan.
De afgelopen drie tot vier jaar is de belangstelling voor het openEHR Demografiemodel gegroeid. Er zijn veel bijeenkomsten geweest waar ons werd gevraagd om de voordelen van het gebruik van het openEHR Demografiemodel te laten zien. Onze architect Sebastian heeft, als lid van de openEHR International SEC, gepleit voor het toevoegen van ondersteuning hiervoor in zowel de API's als de AQL's. Dit heeft geleid tot een conceptversie van deze specificaties voor de API's en we verwachten dat er voor het einde van het jaar een voorstel voor de AQL zal volgen.
Gezien de huidige marktsituatie en de uitdagingen waarmee de IT-sector in de gezondheidszorg wordt geconfronteerd, onderzoeken zorginstellingen steeds vaker wat openEHR te bieden heeft. Wij zijn dan ook van mening dat zodra API- en AQL-ondersteuning beschikbaar is, de ondersteuning van leveranciers voor het gebruik van het openEHR Demografiemodel zal toenemen en dat steeds meer leveranciers dit model zullen implementeren. Als CODE24 juichen wij een dergelijke ontwikkeling toe en staan we ervoor open om onze ervaring met het openEHR Demografiemodel met de community te delen.