openEHR
openEHR is een technische specificatie in de zorg-ICT, die een manier van opslaan, terugvinden en uitwisselen van medische gegevens beschrijft. EHR betekent electronic health record, Engels voor elektronisch patiëntendossier. openEHR beschrijft deze activiteiten zonder afhankelijk te zijn van leveranciers van systemen. openEHR kan meerdere uitwisselstandaarden ondersteunen, bijvoorbeeld EN 13606 of HL7.
De openEHR-specificatie wordt onderhouden door de openEHR Foundation. Dit is een non-profitorganisatie die onderzoek, ontwikkeling en implementatie van de specificatie ondersteunt. De specificaties zijn gedurende 15 jaar onderzoek ontstaan. Een kenmerk is dat ze al meer dan vijf jaar stabiel zijn. De specificaties bestaan uit nieuwe paradigma's, bekend als archetypegebaseerde inhoudspecificatie[1][2].
De openEHR-specificaties bevatten informatie en servicemodellen voor EHR (Electronic Health Record), demografische gegevens, klinische processen en archetypen.
Het bijzondere aan openEHR is dat het logisch gezien uit twee lagen bestaat die vanuit ontwikkelstandpunt apart worden bezien. De technische basis bevat een fysiek datamodel dat niet is vastgelegd in de specificaties, de klinische kant is het Referentiemodel. Dit is een samenstel van ongeveer 50 classes die het tezamen mogelijk maken om iedere denkbare medische datacombinatie te kunnen verwerken. De technische basis, het fysieke datamodel, heeft als enige taak het Referentiemodel te kunnen opslaan en terughalen. De gebruikte fysieke datamodellen kunnen bestaan uit enkele tabellen, een XML-database of een uitgebreide relationele database. Het doet niet ter zake zolang er maar aan de enige taak wordt voldaan. Op deze wijze kan er aan de technische basis geïnnoveerd worden zonder dat de klinische kant verandert. En omgekeerd, de functionaliteit naar de gebruiker toe kan worden gewijzigd zonder het fysieke datamodel en de tussenliggende softwarelagen te wijzigen.
Single Level modelling
bewerken
De voordelen van Two level modelling zijn beter verklaarbaar indien uitgelegd wat Single Level modelling is. In deze vorm van applicatie modelleren is aan een kant van belang een gebruiker (dokter of verpleegkundige), aan de andere kant, de deskundige van het domein (dokter), en daartussen zit de software-ontwikkelaar. De software-ontwikkelaar heeft de moeilijke taak om eisen vanuit het domein, die moeilijk zijn te begrijpen zonder medische kennis, te vertalen naar software, die aan de andere kant, eenvoudig en ergonomisch bruikbaar moet zijn. Deze interactie wordt in het diagram weergegeven.
Een ander probleem is dat indien er een verandering verlangd wordt in het informatie-data-domein, dit vaak een waterval veroorzaakt door alle lagen van de software heen. Zie voor voorbeelden hiervan een weinig verderop in de tekst.
Two Level modelling met archetypen
bewerken
In het Two Level modelling proces is de applicatie-ontwikkelaar klaar, en worden de domein-specificaties direct aan de gebruiker gecommuniceerd. Dit gebeurt via archetypen. Een groot voordeel is dat de applicatieprogrammeur niet hoeft te worden ingeschakeld en ook geen domeinkennis hoeft te hebben. De domeinkennis blijft bij die mensen waar deze kennis begrepen kan worden: de gebruikers (bijvoorbeeld dokters en verpleegkundigen) en de domein-deskundigen (bijvoorbeeld dokters). Een ander groot voordeel is dat bij gewijzigde of toegevoegde informatiebehoefte de hele applicatie niet doorwerkt hoeft te worden. De wijziging speelt zich af op het niveau tussen gebruiker en domeindeskundige. Het programmeren van medische software gebeurt in openEHR in de vorm van Two Level modelling.
Het communicatiemiddel waarop dit proces leunt zijn de archetypen. Archetypen kunnen begrepen worden als verfijningen van het bovengenoemde Reference Model. Deze verfijning bestaat onder meer uit het toevoegen van beperkingen.
Bijvoorbeeld een temperatuurmeting maakt gebruik van de class Observatie. In een archetype wordt bepaald dat een bepaalde Observatie over temperatuur-meting gaat. Het fysieke datamodel kan iedere denkbare Observatie opslaan, maar een dataset is gekoppeld aan een archetype, en dat bepaalt dat een bepaalde observatie een temperatuur-meting betreft. Een volgende verfijning zou kunnen zijn dat de temperatuur wordt uitgedrukt in graden Celsius, of juist in graden Fahrenheit, maar nog logischer is dat er in het archetype een beschrijving wordt opgenomen of het Celsius, Fahrenheit of Kelvin betreft, zodat alle drie de waarden gebruikt kunnen worden. Immers de beschrijving wordt dan opgeslagen samen met de andere data die in het archetype zijn gedefinieerd. Een daaropvolgende verfijning zou kunnen zijn het apparaat waarmee de temperatuur is gemeten, kwik, elektronische warmtemeting, infrarood? Weer een verfijning zou kunnen aangeven op welke plaats in het lichaam is gemeten, en hoe het meetproces eruitzag. Bijvoorbeeld: een minuut rectaal. Verfijningen kunnen verplicht worden of optioneel.
Al deze wijzigingen kunnen worden geïmplementeerd zonder dat de applicatie wordt gewijzigd.
Een ander voorbeeld van archetype-gebruik en het gemak waarmee datadefinities kunnen worden aangepast:
Stel een applicatie dient bloeddruk op te slaan, zoals gebruikelijk, bovendruk en onderdruk. Nu komt er een extra richtlijn die bepaalt dat er ook moet worden opgeslagen of de bloeddruk staand, zittend of liggend is gemeten. Door enkel het archetype te wijzigen wordt deze wijziging geïmplementeerd.
Ter illustratie van hoe het in een klassieke medische applicatie werkt, het betekent in dat geval dat het fysieke datamodel moet worden gewijzigd. Eveneens moeten allerlei softwarelagen worden gewijzigd die tot het fysieke datamodel leiden. Dit is een duur project, met allerlei risico's. Niet zelden komt men terecht in een verouderde codebrij die door voorgangers is aangericht. ICT-bedrijven werken soms weken, soms zelfs maanden aan een dergelijke wijzigingen. Het fysieke datamodel is immers een afspiegeling van de applicatiefunctionaliteit, en bij wijziging van die functionaliteit moet een applicatie worden herbouwd tot in de diepste lagen
Samengevat: De belangrijkste innovatie in het openEHR-framework is dus de scheiding tussen klinische informatie en het Informatiemodel. Archetypen worden los van het systeem onderhouden door domein-experts (artsen, medische informatica-specialisten). Hierdoor wordt bereikt dat de archetypen goed aansluiten bij wat er benodigd is door de gebruikers. Archetypen bevatten de medische kennis, en ze kunnen evolueren samen met het kennisgebied dat ze vertegenwoordigen. Dit kan onafhankelijk van het systeem plaatsvinden.
De informatie in openEHR is altijd weergegeven in archetypen, meerdere archetypen, of fragmenten daarvan kunnen worden gebruikt om 'templates' te creëren. De templates kunnen dan dienen om data te importeren of te exporteren naar een definitie die buiten de archetypen staat, Bijvoorbeeld, gebruikers-interfaces, documenten of berichten.
De openEHR-benadering gebruikt de CEN- en ISO-gestandaardiseerde "archetype definition language", deze wordt weergegeven in ADL-syntaxis of XML. Archetypen kunnen worden hergebruikt, ze vormen formele modellen van domeinconcepten[3] Archetypen worden gebruikt in openEHR om klinische concepten zoals bloeddruk te modelleren.
Internationale samenwerking
bewerkenDe openEHR-benadering, het gebruik van gedeelde archetypen zorgt ervoor dat de openEHR-data gemanipuleerd of bezien kunnen worden met optioneel behoud van consistentie, onafhankelijk van technische, organisatorische of culturele context. Deze benadering betekent ook dat de datamodellen die door EHR's worden gebruikt flexibel zijn omdat nieuwe archetypen gedefinieerd kunnen worden die tegemoetkomen aan toekomstige behoeften van klinische dataverwerking. In Australië is gedemonstreerd hoe archetypen en templates gebruikt kunnen worden om het benaderen van legacy data in databases of berichten te faciliteren binnen een openEHR-systeem en deze te kunnen uitvoeren naar gestandaardiseerde berichten of CDA-documenten.
Het openEHR-framework is consistent met de nieuwe Europese Electronic Health Record en Communication Standaard EN 13606. Delen van het framework worden gebruikt binnen de NHS en het is geselecteerd als basis voor de nationale Zorg-ICT in Zweden. Tevens wordt het gebruikt in commerciële - en onderzoeksprojecten door de hele wereld, waaronder Denemarken, Slovenië, Italië, Uruguay, Israël, Nederland, Chili en Brazilië.
Clinical Knowledge Manager
bewerkenEen van de belangrijke werkzaamheden van openEHR-community is het ontwikkelen van archetypestructuren en terminologieën om Zorg-ICT data weer te geven. Deze structuren zijn publiek beschikbaar om gebruikt te worden. Ook gebruikers in internetcommunity's delen, bespreken en beoordelen deze structuren in archetype repositories die bekendstaan als Clinical Knowledge Manager (CKM).
Zie ook
bewerken- EN 13606 (ISO/CEN EN 13606 - EHRcom)
- HL7
- Health Insurance Portability and Accountability Act(HIPAA)
Externe links
bewerken- ↑ Beale, Thomas (2002). Archetypes: Constraint-based Domain Models for Future-proof Information Systems. Proceedings of the 11th OOPSLA Workshop on Behavioural Semantics. (PDF)
- ↑ S. Heard & T. Beale. (eds.), openEHR Architecture Overview. openEHR (2007). Geraadpleegd op 21 June 2010. (PDF)
- ↑ Archetypes FAQs. openEHR.org. Gearchiveerd op 10 mei 2008. Geraadpleegd op 21 June 2010. (gearchiveerd)