Enige tijd geleden kwam er een interessant verzoek langs op het openEHR forum: zouden developers en CTO’s van EPD’s het eerlijke verhaal achter de implementatie van openEHR willen delen? Wat waren de verwachtingen, tegen welke problemen liep men aan?
Onze architect, bestuurslid van openEHR Nederland en vicevoorzitter van de Specificatiecommissie van openEHR International Sebastian Iancu deelde graag zijn ervaringen op het forum. Daarnaast bedachten we ons dat deze vragen waarschijnlijk bij meer organisaties spelen - daarom legden we Sebastian de vragen nogmaals voor. Zijn antwoorden, met Sebastians kenmerkende eerlijkheid en focus op techniek die de zorg dient, delen we met je in dit artikel.
Wat waren je verwachtingen toen je openEHR implementeerde?
“Toen we CODE24 in 2011 oprichtten, zijn we vanaf de basis begonnen met het implementeren van de openEHR-specificaties. We namen de beslissing om dit te gaan doen gebaseerd op 2-3 jaar ervaring met eerdere projecten waarbij we de openEHR technologie gebruikten.
Onze verwachting was dat openEHR ons zou helpen om een schone en schaalbare backend te hebben, gebaseerd op internationale standaarden, zodat we snel door konden ontwikkelen, konden integreren met andere systemen en de mogelijkheid zouden hebben om medische kennis (vastgelegd in gemeenschappelijk ontwikkelde informatiemodellen, archetypes) te (her)gebruiken.”
Zijn je verwachtingen ook uitgekomen?
“Ja, in eerste instantie was het een flinke investering om alle specificaties te implementeren, maar uiteindelijk is het gelukt en dient het nog steeds zijn doel en heeft het ons laten uitgroeien tot wat CODE24 nu is.
Het heeft ons ook geholpen om wendbaarder te zijn en snel nieuwe technologieën te adopteren (zoals FHIR), of om deel te nemen aan landelijke projecten zoals MedMij - iets wat we in 2011 nog niet hadden voorzien.
We hadden wel ook verwacht dat meer leveranciers de openEHR visie op het gebied van gezondheidsgegevens en patiëntgerichte systemen zouden begrijpen en dat zij zich hierbij zouden aansluiten en de specificaties zouden gaan inzetten. Hoewel dit in de loop der jaren is verbeterd, van slechts een paar implementaties en leveranciers tot de grotere gemeenschap die het nu is, is het een langzaam proces. Het is nog niet zo ver als we twaalf jaar geleden dachten.”
Welke problemen had je al voorzien?
“Het implementeren van een complexe standaard zoals openEHR vergt een bepaalde mate van toewijding (focus) en ervaring. Dit is echt iets wat je moet opbouwen, en dat vereist tijd en geduld. Dit wisten we van tevoren.
Op technisch niveau wisten we dat het complex zou zijn om een query engine te bouwen die voldoende schaalbaar is en die ook het two-level modelling van openEHR ondersteunt. Uiteindelijk kwamen we op een architectuur en verscheidene indexerings- en query-optimalisaties die ons met dit probleem konden helpen.
We verwachtten ook problemen rond de snelheid waarmee openEHR omarmd zou worden - je hebt andere partijen nodig die openEHR ‘spreken’ voor een betere interoperabiliteit - maar gelukkig verbetert dit nog steeds, zeker de laatste tijd.”
Tegen welke onverwachte problemen liep je aan?
“We zijn door de jaren heen meerdere onverwachte problemen tegengekomen, maar we hebben altijd oplossingen gevonden - vaak vanuit de openEHR specificaties en technologie. We hebben zelf ook bijgedragen aan de specificaties, door onze ervaringen en bevindingen met de gemeenschap te delen zodat dit meegenomen kon worden in nieuwe releases.
Een aantal van de belangrijkste onverwachte problemen hingen samen met het integreren en gebruiken van niet-medische concepten in medische applicaties. Denk aan demografische gegevens of administratieve resources, bronnen of fysieke items (voor een resource planner) of informatie met betrekking tot sociale zorg.
Andere problemen hadden te maken met nationale standaarden of regelgeving waar we aan moesten voldoen, die niet goed aansloten bij de internationale standaarden. Denk aan informatiemodellen en technieken, bepaalde aspecten van het zorgproces, et cetera.”
Hoe is de performance?
“De openEHR specificaties schrijven geen specifieke fysieke of technische infrastructuur voor en ook geen specifiek implementatie-ontwerp. Daarom is de performance subjectief - het hangt af van de oplossing van de leverancier en hun technologische stack.
Wat we wel door de jaren heen hebben geleerd is dat performance sterk afhankelijk is van de infrastructuur, use cases, work-load en de efficiëntie van de applicatielaag, of van functionele vereisten die (in)efficiënt zijn geïmplementeerd. Over het algemeen is de performance vanuit onze ervaring goed - we zien altijd mogelijkheden om deze nog verder te optimaliseren. We horen ook eigenlijk nooit klachten over de performance van onze eindgebruikers.”
Geeft de openEHR standaard je genoeg vrijheid?
“We zijn heel blij met de vrijheid die we nu hebben. Met de openEHR archetypes en templates hebben we alle vrijheid en flexibiliteit die we nodig hebben en met het openEHR Reference Model hebben we een solide ‘technische laag’ die we vrijelijk kunnen gebruiken.
Aan de andere kant beperkt het voldoen aan de standaard en aan de internationaal gepubliceerde archetypes deze vrijheid soms enigszins. Maar uiteindelijk denken we dat dit een goed doel dient, namelijk: interoperabiliteit.”
Meer weten?
Overweegt jouw organisatie om openEHR te gebruiken in jullie software en heb je nog vragen? Schroom niet om contact met ons op te nemen - of stel je vraag op het openEHR forum!