zib-compliance algemeen Reacties i-Ziekenhuis op stelling 1 "“Het interne datamodel van epd’s moet gebaseerd zijn op de zibs”

[Christine van der Aa]

Op 30 maart hebben we in het kader van het einde van het programma Registratie aan de bron de behaalde resultaten uitgelicht. Daarbij hebben we de deelnemers gevraagd om met behulp van Mural te reageren op vier stellingen, elk over een van de categorieën van het zib-compliance raamwerk.

Daar kwamen heel wat reacties op! Zie het plaatje hieronder.

De eerste stelling luidde “Het interne datamodel van epd’s moet gebaseerd zijn op de zibs”. De meningen over deze stelling waren redelijk in evenwicht: 10 eens, 12 oneens, en 9 deels eens.

Bekijk bijlage 30 maart 2022 i-Ziekenhuis Mural.png

 

[ChristineOude]

Dit werd geschreven door deelnemers van i-Ziekenhuis die het EENS waren met de stelling:

• Eens, dat zou efficiënter zijn dat dat alle ziekenhuizen dit afzonderlijk doen. Het kost erg veel tijd om alle zibs te mappen.
• Eens, eenmalig veel impact en tijd investering. Daarna winst tov mappen die zich in korte termijn terugverdient.
• Als het datamodel al gekunsteld is en er allerlei mappings/migraties nodig zijn, dan blijft het houtje-touwtje.

 

[ChristineOude]

Dit waren reacties van mensen die het DEELS EENS waren met de stelling:

• Deels eens. Het datamodel hoeft niet hetzelfde te zijn als de dataelementen maar terug te vinden zijn. Het is niet handig als er heel veel gemapt moet worden.
• Deels eens, zolang de vastgelegde data maar volgens de zib op te halen is voor gegevensuitwisseling.
• Eens, maar uitbreiding en aanpassing tbv eigen systeem moet mogelijk zijn. Maar zie ook dat internationale standaarden misschien nog belangrijker worden.
• Deels eens, het interne datamodel moet ook rijker kunnen zijn.
• Deels eens. Het gaat erom dat de interne informatiehuishouding ook gebaseerd is op de zibs en de zibs niet alleen gebruikt worden voor uitwisseling maar ook voor de registratie. Hoe dat op het datamodel (en op het scherm) zijn weerslag heeft staat daar los van.
• Deels oneens, Als je het maar kunt mappen.
• Ja en nee. Geen overlap in zibs en mutaties minimaal. Nauwe relatie met user interface (bijv user interface zibs gebaseerd, opslag in bijv. FHIR resources (beperkt aantal, internationale standaard).
• We zouden in Nederland moeten toewerken naar 1 informatiemodel in de organisatie, waar de zibs een eerste aanzet voor zijn. EPDs moeten dit kunnen toepassen. Zoveel mogelijk aansluiten op internationale standaarden.
• Of een meer internationale standaard?

 

[ChristineOude]

En deze opmerkingen werden geschreven door mensen die het ONEENS waren met de stelling:

• Oneens, want een datamodel voor implementatie stelt andere eisen dan een conceptueel model.
• Het moet vertaalbaar zijn naar zibs, datamodel helemaal baseren op zibs maakt het veel te star.
• Nee, er is behoefte aan duidelijke datadefinities. Daarmee blijf je onafhankelijk van de EPD indeling.
• Oneens, mits de gegevens wel opgeslagen kunnen worden.
• Dit is geen randvoorwaarde om zibs uit te kunnen wisselen. Zolang de data maar conform de informatiestandaard wordt vastgelegd (overeengekomen codestelsels, classificaties en terminologiestandaarden). Je kunt leveranciers niet dwingen hun proprietary datamodel volledig aan te passen. Als je in NL een gezamenlijk common datamodel gaat propageren is het niet verstandig om voor een standaard te kiezen die alleen in NL wordt gebruikt. Dan lijkt openEHR een meer voor de hand liggende keuze. We moeten in NL stoppen minder werken met lokale standaarden en meer gebruik maken van internationale standaarden.

 

[William Goossen]

Als de oneens stemmer het puur en alleen conceptueel bekijkt snap ik het wel. Maar een zib is nu juist de vertaling van het conceptueel model (dat dus in de zib wel degelijk aanwezig is!) naar een logisch model. En dit laatste behoort zonder problemen implementeerbaar te zijn in elk EPD. Want het logisch model zegt: deze zib heeft precies de volgende data elementen. En die data elementen hebben de volgende definities, data typen, relaties, codes (codestelsels, waardenlijsten, terminologie) en bij PQ data ook de unit. En dit is geen rocket science maar al sinds Codd normaal mogelijk in data modellen. Dat het proprietary datamodel natuurlijk niet 100% op de zibs kan worden geent is ook duidelijk en helemaal niet nodig. Er zijn genoeg slimme oplossingen om de gegevens conform zibs, met hun semantische codes en relaties, op te slaan, terug te vinden, te verwerken, presenteren en uit te wisselen. OpenEHR is in Nederland al drie keer geopperd als de oplossing voor dit probleem en al drie keer uiteindelijk afgewezen omdat de structuur van de archetypes ook niet matchen met de EPD datamodellen. Dus dat zou het ene probleem voor het andere inruilen betekenen.