openehr spesifikaatiot

hyväksymispäivä arvosana arvostelija openehr spesifikaatiot Teemu Pääkkö Helsinki 27.3.2016 HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos

HELSINGIN YLIOPISTO HELSINGFORS UNIVERSITET UNIVERSITY OF HELSINKI Tiedekunta Fakultet Faculty Laitos Institution Department Matemaattis-luonnontieteellinen tiedekunta Tekijä Författare Author Tietojenkäsittelytieteen laitos Teemu Pääkkö Työn nimi Arbetets titel Title openehr spesifikaatiot Oppiaine Läroämne Subject Tietojenkäsittelytiede Työn laji Arbetets art Level Seminaarityö Tiivistelmä Referat Abstract Aika Datum Month and year 27.3.2014 Sivumäärä Sidoantal Number of pages 18 sivua Tämä kirjoitus on tarkoitettu Helsingin Yliopiston Tietojenkäsittelytieteen laitoksen tiedonhallinta terveydenhuollossa seminaarin kirjalliseksi osuudeksi. Työssä käydään korkealla tasolla lävitse mitä sähköisellä potilaskertomuksella tarkoitetaan, mitä hyötyä siitä on ja mitä haasteita siihen liittyy. Sen jälkeen tarkastellaan tarkemmin terveydenhuollon yhteentoimivuuden haastetta ja sen ratkaisemiseksi kehitettyä kahden mallin arkkitehtuuri-ratkaisutapaa. Lopuksi tutustutaan kahden mallin arkkitehtuurin toteuttavaan openehr spesifikaatioon. ACM Computing Classification System (CCS): Health care information systems Health informatics Avainsanat Nyckelord Keywords Sähköinen sairauskertomus, kahden mallin arkkitehtuuri, openehr Säilytyspaikka Förvaringställe Where deposited Muita tietoja Övriga uppgifter Additional information

Sisältö 1 Johdanto 1 2 Sähköinen potilastieto 1 3 Sähköisen potilaskertomuksen hyödyt 2 4 Vaatimukset sähköiselle potilaskertomukselle ja potilastietojärjestelmälle 2 4.1 Vaatimukset terveydenhuollon tietojärjestelmien yhteentoimivuudelle 3 5 Sähköisen potilaskertomuksen yhteentoimivuuden ratkaisutavat 4 6 openehr säätiö ja spesifikaatiot 5 6.1 openehr:n suunnitteluperiaatteet 6 6.2 openehr:n viitemalli 7 6.3 openehr:n sähköinen potilaskertomus 8 6.4 openehr:n arkkityypit ja sapluunat 10 6.4.1 openehr:n arkkityyppien määrittelykieli 2 12 6.4.2 openehr:n arkkityyppien kyselykieli 13 7 Yhteenveto 13 Lähteet 16

1 Johdanto 1 Monen maan terveydenhuollon haasteena on kasvavaan kysyntään vastaaminen rajallisilla resursseilla. Kysyntää kasvattaa kansalaisten eliniän pidentymien yhdessä terveydenhuollon kehityksen kanssa. Kansalaiset ovat myös tietoisia terveydenhuollon kehityksestä ja odotukset terveydenhuoltoa kohtaan ovat nousseet [Dob10] [FiE13]. Tilanteeseen pyritään vastaamaan tehostamalla edelleen terveydenhuollon toimintaa terveydenhuollon tietotekniikan avulla [Dob10][Kal06][BlP 09]. Erityisesti kaikki sidosryhmät huomioivasta, paikkariippumattomasta ja läpinäkyvästä sähköisestä potilaskertomuksesta toivotaan edelleen apua [Dob10] [FiE13][Kal06][BlP 09]. Luvussa kaksi esitellään työn kannalta oleelliset käsitteet koskien sähköistä potilastietoa. Luvussa kolme kuvataan lyhyesti sähköisestä potilaskertomuksesta saatavia höytyjä. Luvussa neljä esitellään korkealla tasolla sähköiselle potilaskertomukselle ja potilastietojärjestelmälle asetettuja vaatimuksia tutustuen tarkemmin yhteentoimivuuden vaatimukseen. Luvussa viisi mainitaan yhteentoimivuuden ratkaisutapoja ja esitellään tarkemmin tällä hetkellä kehittyneimpänä tapana pidetyn kahden mallin lähestymistavan. Luvussa kuusi esitellään sähköisen sairauskertomuksen ja potilastietojärjestelmän rakentamiseen ja yhteentoimivuuden varmistamiseen suunniteltu openehr spesifikaatio. Luku seitsemän sisältää yhteenvedon. 2 Sähköinen potilastieto Sähköisesti tallennettuun potilastietoon on viitattu ja viitataan edelleen monilla eri termeillä. Eri termit ovat syntyneet tarpeesta erotella sähköisen potilastiedon uusi käsittelytapa aiemmista[wae03]. Eri toimijat käyttävät samoja termejä hieman eri tarkoituksessa tai synonyymeinä. Erityisesti sähköinen sairauskertomus ja sähköinen potilaskertomus termit menevät helposti keskenään sekaisin. Termejä käytetään paljon ristiin, vaikka käsitteellisesti kyseessä on eri käsitteet [GaD06]. Käytettyjen termien takana on sama perusidea: Hoitoa annettaessa potilaskohtaista tietoa tallennetaan, sekä käytetään hoitoa tarjoavissa organisaatioissa [GaD06]. ISO:n tekninen raportti ISO TR 20514:2005 [ISO05] määrittelee sähköisen sairauskertomuksen sähköisen potilaskertomuksen erikoistapaukseksi, jossa tietoa on rajattu lääketieteellisesti tai hoitoa antavan organisaation perusteella. Sähköinen sairauskertomus

2 sisältää tietoa yhden tai useamman organisaation käyttöön, mutta ei sisällä tieto kaikista mahdollisista lähteistä. Sähköinen potilaskertomus on nykyään globaalisti hyväksytty yleisluontoinen termi, joka kattaa kaikki aiemmat sähköisen potilastiedon käsitteet [Wae03]. ISO:n teknisen raportin ISO/TR 20514:2005 [ISO05] mukaan se on käsite, jota sähköisestä potilaskertomuksesta tulisi nykyään käyttää, on integroidun hoidon sähköinen potilaskertomus (electronic health record for integrated care /ICHER). Se on määritelty raportissa seuraavasti: Kokoelma hoidettavan henkilön terveyttä koskevia tietoja tietokoneella prosessoitavassa muodossa, joita säilytetään ja siirretään turvallisesti ja joihin on pääsy monilla auktorisoidulla käyttäjällä, joilla on standardoitu tai yhteisesti sovittu potilastietojärjestelmästä irrallaan oleva looginen tietomalli ja jonka pääasiallinen tarkoitus on tukea hoidon jatkuvuutta sekä tehokasta ja laadukasta integroitua terveydenhoitoa. Kokoelma sisältävät retrospektiivista, tämänhetkistä ja prospektiivista tietoa.. Raportti määrittelee potilastietojärjestelmän seuraavasti: Joukko komponentteja jotka muodostavat mekanismit, joilla sähköiset potilastiedot luodaan, käytetään, varastoidaan ja haetaan huomioiden ihmiset, tiedot, säännöt, proseduurit, prosessointivälineet, tallennusvälineet, kommunikointivälineet sekä ylläpitovälineet. Tässä työssä sähköisellä potilaskertomuksella ja potilastietojärjestelmällä tarkoitetaan ISO:n teknisen raportin mukaista järjestelmää. 3 Sähköisen potilaskertomuksen hyödyt Sähköisen potilaskertomuksen edut paperille tallennettuun potilastietoon ovat selkeät. Sähköinen potilaskertomus on aina saatavilla useammalle käyttäjälle samanaikaisesti, niitä voidaan siirtää sähköisesti ja niistä voidaan luoda eri näkymiä hoitajille, lääkäreille, fysioterapeuteille ja muille käyttäjille. Näkymissä tieto voidaan näyttää ongelmalähtöisesti, aikalähtöisesti tai tiivistelmänä [GGH00][KaI06]. Sähköinen potilaskertomus on myös alusta lukuisille toiminnallisuuksille, joista odotetaan suurta hyötyä terveydenhuollossa. Sähköisen potilaskertomuksen pohjalta järjestelmät voivat tarjota automaattiset muistutukset, automaattiset hälytykset, päätöksenteon tukea ja näyttöön pohjautuvan lääketieteen tukea [Suj98] [KaI06][GGH00]. 4 Vaatimukset sähköiselle potilaskertomukselle ja

potilastietojärjestelmälle 3 Sähköiseen potilaskertomukseen ja potilastietojärjestelmään kohdistuu monia vaatimuksia useilta eri sidosryhmiltä. Sidosryhmien vaatimukset ovat heterogeenisiä ja koskevat terveydenhuollon eri toimialoja [HoA10]. Eri sidosryhmien vaatimukset voivat myös olla ristiriitaisia [KaI06]. Kattavin vaatimusluettelo sähköisen potilaskertomuksen arkkitehtuurin ydinvaatimuksista on ISO:n koostama ISO 18308 standardi [Kal06]. Standardi [ISO11] määrittää sähköisiä potilaskertomuksia käsitteleville, hallinnoiville ja välittäville tietojärjestelmille vaatimuksia. Vaatimukset kohdistuvat tietojärjestelmien arkkitehtuuriin ja niiden tarjoamiin palveluihin kattaen sähköisen potilaskertomuksen. Osa vaatimuksista pätee niin sähköiseen potilaskertomukseen kuin potilastietojärjestelmään. ISO 18308 sisältää kaikkiaan 124 vaatimusta [ZKW10], jotka on luokiteltu kahdeksaan pääluokkaan. Pääluokat ovat rakenne, prosessit, kommunikointi, yksityisyys ja tietoturva, terveydenhuollon oikeusturva, eettisyys, kuluttajat/kulttuuri ja evoluutio. Seuraavassa aliluvussa käsitellään tietojärjestelmien yhteentoimivuuden vaatimusta, jonka on yksi tärkeimmistä vaatimuksista sähköiselle potilaskertomukselle [KaI06]. 4.1 Vaatimukset terveydenhuollon tietojärjestelmien yhteentoimivuudelle Terveydenhuollon tietojärjestelmien yhteentoimivuudelle on olemassa useita määritelmiä. ISO:n tekninen raportti [ISO05] määrittelee yhteentoimivuuden seuraavasti: Kyvykkyys vaihtaa tietoa yhden tai useamman järjestelmän kesken ja semanttisen yhteentoimivuuden seuraavasti Kyvyksi ymmärtää järjestelmien jakama tieto formaalien domain käsitteiden tasolla. Ensimmäisen määritelmän mukainen funktionaalinen yhteentoimivuus tarkoittaa järjestelmien välistä tiedon siirtoa ihmisen luettavissa olevassa muodossa [Beg07] [SCH06]. Semanttinen yhteentoimivuus vuorostaan tarkoittaa järjestelmien välistä tiedon siirtoa koneiden luettavissa olevassa muodossa [Beg07] [SCH06]. Semanttisen yhteentoimivuuden saavuttaminen on huomattavasti haastavampaa kuin funktionaalisen yhteentoimivuuden [SCH06]. Sähköisen potilaskertomuksen semanttinen yhteentoimivuus edellyttää neljää asiaa. Standardoitua viitemallia, mikä määrittelee sähköisen potilaskertomuksen domain riippumattomat, yhteiset tietorakenteet. Standardia järjestelmien välillä vaihdettaville viesteille, mikä määrittelee viestien rakenteen. Standardoituja domain kohtaisia malleja, sekä standardoitua terminologiaa [Beg07][Mea06]. Tässä työssä yhteentoimivuudella tarkoitetaan ISO:n teknisen raportin

mukaista semanttisen yhteentoimivuuden määritelmää. 4 5 Sähköisen potilaskertomuksen yhteentoimivuuden ratkaisutavat Terveydenhuollon sähköisesti tallennettu tieto sijaitsee nykyisin ja jatkossakin lukuisissa, tiettyä käyttöä varten rakennetuissa järjestelmissä. Grimsonin ja kumppaneiden mukaan eri järjestelmissä sijaitsevan tiedon yhdistämistä voidaan lähestyä federaatio ajattelumallin mukaisesti. Federoidussa järjestelmässä jokainen osajärjestelmä on oma autonomininen järjestelmä. Oman toiminnan lisäksi osajärjestelmät toimivat osana federaatiota. Federoidun, sähköisen potilaskertomuksen rakentamista voidaan lähestyä kolmella eri tavalla. Lähestymistavat ovat Viestipohjainen, tietovarasto tai yhteisarkkitehtuuri [GGH00]. Kehittyneimmät ratkaisut [MMF10] pohjautuvat ns. kahden mallin arkkitehtuuriin [Bea02]. Kahden mallin arkkitehtuuri tietojärjestelmissä pohjautuu idealle tiedon (information) ja tietämyksen (knowledge) eriyttämisestä. Beale määrittää tiedoksi toteamuksen, joka koskee yhtä entiteettiä. Tietämys on puolestaan toteamus, joka koskee kaikkia tietyn luokan entiteettejä. Tietotason malleja kutsutaan viitemalleiksi (reference model). Tietämystason malleja kutsutaan arkkityypeiksi. Viitemalli määrittelee domainin yleiset komponentit ja kuinka ne liittyvät toisiinsa. Viitemallissa määriteltävien luokkien tulee olla vakaita ja niitä tulee olla suhteellisesti pieni määrä. Laajemman, enemmän luokkia sisältävän tietomallin tallentaminen viitemallin rakenteeseen perustuu viitemallin luokkien kooste komponenttiin, jonka sisällä voidaan määritellä minkälainen looginen rakenne tahansa [Bea02]. Esimerkiksi terveydenhuollon tapauksessa viitemalli määrittelee sähköisen potilaskertomuksen rakennuspalikat. Terveydenhuoltoon liittyvä viitemalli määrittelee lisäksi metatiedon liittyen tiedon eettisyyden, lainmukaisuuden ja jäljitettävyyden varmistamiseen [Kal06]. Koska viitemallin rakenteeseen voidaan tallettaa vapaasti hyvin laajalti erilaisia tietomalleja, tulee tätä vapautta rajata halutun domainin mukaisen tietomallin saamiseksi. Rajaaminen tehdään arkkityyppien avulla [Bea02]. Arkkityyppi (Archetype) on formaali määrittely, jossa viitemallin määrittelemistä komponenteista koostetaan tietyn alueen tai organisaation tarvitsemien sähköisen potilaskertomuksen tietojen rakenteet, esimerkiksi verenpainemittauksen tai laboratoriotuloksen rakenne. Arkkityyppi tekee kostamisen määrittelemällä ja rajaamalla joukon viitemallin

5 aliluokkia sekä luokkien nimet, attribuutit, attribuuttien arvot, pakollisuuden, lukumäärän sekä datan tyypin ja sallitut arvot. Arkkityyppi määrittelee siten säännöt, joiden avulla viitemallista johdetaan yhdenmukaisia ja yhteiskäyttöisiä kliinisiä dokumentteja [Kal06][Eic05][KaA08]. Ohjelman suorituksen aikana käyttäjien syöttämän tiedon vastaavuus domainin tietomallin vaatimuksiin varmistetaan validoimalla syötteet arkkityyppejä vastaan [Eic05][Bea02][KaA08]. Syötteen validoinnin jälkeen tieto tallennetaan viitemallin mukaiseen varastoon, esimerkiksi relaatiotietokannan tauluihin. Viitemalli itsessään on vakaa vaikka kliiniset käsitteet, eli arkkityypit, muuttuisivat. Näin kliinisten käsitteiden muuttuessa tietovarastoon ei tarvitse tehdä muutoksia, ainoastaan arkkityyppeihin [Eic05]. Kuvassa yksi esitellään arkkityyppien ja viitemallin suhdetta. Kuvassa vasemmalla on verenpaineen määrittelevän arkkityypin mukainen olio ja oikealla demografia arkkityypin mukainen olio. Keskellä löytyy kuvitteellisen viitenallin neljä luokkaa relaatiotietokannassa. Arkkityyppien määrittelemien attribuuttien arvot tallennetaan olioista katkoviivojen osoittamiin taulujen sarakkeisiin. Kuva 1: Esimerkki arkkityyppien ja viitemallien tietorakenteiden suhteesta Arkkityyppien käyttö takaa järjestelmien yhteentoimivuuden tietämyksen tasolla ja niiden avulla monimutkaiseen tietoon voidaan tehdä tehokkaita hakuja [Bea02]. 6 openehr säätiö ja spesifikaatiot openehr säätiön perustivat vuonna 2000 University College London Britanniasta ja Ocean Informatic yritys Australiasta. Säätiön tavoite on tukea potilastietojen yhteiskäyt-

6 töisyyttä standardeihin pohjautuvien, avoimen lähdekoodin toteutusten kautta [Kal06] Erityinen painoarvo on laadukkaan tietojen vaihdon varmistamisella eri sidosryhmien välillä semanttisesti yhteentoimivasti [BaM13]. Tavoitteena on [KaA08] myös tukea semantiikalla automaattisia hälytyksiä, hoitopolkuja sekä hoitoprotokollia. Toinen tavoite on tukea potilaiden ja heidän läheisten osallistumista mahdollistamalla sähköisen potilastiedon liittämisen selittävään materiaaliin. Kolmas tavoite on tukea ammattilaisen kehittymistä liittämällä sähköinen potilastieto koulutusmateriaaleihin. Neljäs tavoite on taata riittävä tiedon laatu ja johdonmukaisuus mahdollistaen sen mielekkään ja luotettavan käyttämisen kansanterveydessä, tutkimuksessa ja terveydenhuollon hallinnossa. 6.1 openehr:n suunnitteluperiaatteet openehr:n suunnittelussa on noudatettu periaatteita jotka johtavat mallien eriyttämiseen ja komponenttipohjaiseen arkkitehtuuriin. Tämän johtaa parempaan ylläpidettävyyteen, laajennettavuuteen ja joustavaan asennukseen. Suunnitteluperiaatteet ovat Ontologinen eriyttäminen (Ontological Separation), kahden tason arkitehtuuri ja arkkityypit (Two-level Modelling and Archetypes), vastuiden eriyttäminen (Separation of Responsibilities) ja näkökulmien eriyttäminen (Separation of Viewpoints) [Ope16a]. Ontologinen eriyttäminen tapahtuu openehr:ssä kahdella päätasolla. Tasot ovat Ontologiat tiedosta (Ontologies of information) ja ontologiat todellisuudesta (Ontologiat of reality). Ontologiat tiedosta sisältävät tietosisältöjen mallit ja se jakautuu vielä kahteen tasoon, domainin sisältömalleihin (Domain content models) ja tietomalleihin (information models). Domainin sisältömallit mallintavat muuttuvan tietosisällön, esimerkiksi laboratoriotulokset. Tietomallit mallintavat muuttumattoman tietosisällön, esimerkiksi perus tietotyypit, koodatut termit ja tietorakenteet. Ontologiat todellisuudesta sisältävät aitojen ilmiöiden kuvaukset ja luokittelut, esimerkiksi ICDx luokittelun tai SNOMED- CT terminilogian. Tiedon jako ontologioiden tietomalliin ja domainin sisältömalleihin saavutetaan kahden tason arkkitehtuuria käyttäen. Domainin muuttuvat sisältömallit rajataan ensimmäisen tason vakaasta tietomallista arkkityyppejä käyttäen. Arkkityyppien käyttämisen seurauksena saavutettu semantiikka mahdollistaa myös tiedon sidokset luokitteluihin ja kliinisiin tietämysjärjestelmiin [Ope16a]. Kuvassa kaksi kuvataan openehr spesifikaatioiden ontologinen kartta. Vasemmalla on ontologiat tiedosta, oikealla ontologiat todellisuudesta.

7 Kuva 2: openehr ontologinen kartta Vastuiden eriyttäminen saavutetaan jakamalla vaadittu toiminnallisuus osa-alueisiin, eli järjestelmien järjestelmäksi. Alijärjestelmät vastaavat omista loogisista kokonaisuuksistaan ja niiden mallit voidaan määritellä erillään muista. Näin saavutetaan alhaiset sidokset, kapselointi ja komponenttipohjainen arkkitehtuuri. [Ope16a]. openehr:ssä järjestelmien käsittelemä tieto ja tapa kommunikoida määritellään myös eri näkökulmien kautta. Käytetyt näkökulmat vastaavat ISO RM/ODP mallin geneerisiä näkökulmia. ISO RM/ODP malllin geneeriset näkökulmat ovat yritys (Enterprise), tieto (Information), laskennallinen (Computational), tekninen (Engineering) ja teknologinen (Technological). openehr määrittelyissä ei ole vastaavuutta yritys näkökulmaan, muihin neljään näkökulmaan määrittelyissä on vastaavuus. Viitemalli vastaa tietonäkökulmaa, palvelumalli vastaa laskennallista näkökulmaa, toteutusteknologiset määrittelyt vastaavat teknistä näkökulmaa ja määrittelyt toteuttavan järjestelmän teknologiat vastaavat teknologianäkökulmaa [Ope16a]. 6.2 openehr:n viitemalli openehr:n viitemallin 163 luokkaa on jaettu paketteihin jotka voivat pitää sisällään luokkia tai paketteja. Ylimmällä tasolla on seuraava kymmenen pakettia: sähköinen potilaskertomus (ehr), demografinen (demographic), sähköisen potilaskertomuksen otos (ehr_extract), kooste (composition), integraatio (integration), turvallisuus (security), yhteinen (common), tietorakenteet (data_structures), tietotyypit (data_types) ja tuki (support). Demografisen paketin 13 luokkaa kuvaavat geneeriset konseptit toimijoille ja niihin liittyvän tiedon. Toimijoita ovat esimerkiksi rooli (role) ja asianosainen (party).

8 Niihin liittyvä tieto on esimerkiksi osoitetieto. Sähköisen potilaskertomuksen otos paketin 30 luokkaa kuvaavat kuinka sähköisestä potilaskertomuksesta voidaan rakentaa vain osan sen tiedosta sisältävä otos. Integraatio paketti kuvaa ENTRY luokan aliluokan GENERIC_ENTRY, jonka avulla voidaan esittää mitä tahansa tietoa puutietorakenteessa. Näin malliin voidaan liittää tietoa muista järjestelmistä. Turva paketin luokka ACCESS_CONTROL_SETTINGS kuvaa sähköiseen potilaskertomukseen liittyvät pääsynhallinnan käsitteet. Yhteinen paketin 26 luokkaa kuvaavat muissa paketeissa käytettäviä peruskäsitteitä. Esimerkiksi luokat LOCATABLE ja ARCHETYPED, joiden avulla sidos tietomallin ja arkkityyppien välillä kuvataan. Tietorakenteet paketin 13 luokkaa kuvaavat geneeriset tietorakenteet, esimerkiksi listan ja puun. Tietotyypit paketin 33 luokkaa kuvaavat geneeriset ja kliiniset tietotyypit, kuten esimerkiksi boolean, teksti tai multimedia tietotyypit. Tuki paketin 26 luokkaa kuvaavat peruskäsitteet, joita kaikki muut paketit tarvitsevat. Paketin luokkien sisältävät esimerkiksi tunnisteet ja liitynnät tietämyspalveluihin, kuten terminologiat. Sähköinen potilaskertomus ja kooste pakettien kuusi ja 14 luokkaa kuvaavat sähköisen potilaskertomuksen avainkäsitteet, kuten luokat EHR, COMPOSITION, SECTION ja ENTRY [Ope16a]. 6.3 openehr:n sähköinen potilaskertomus Sähköinen potilaskertomus rakentuu korkealla tasolla seuraavista osista: Sähköisen potilaskertomuksen juuriobjektista (EHR), joka pitää sisällään objektin luontiajanhetken, objektin luontijärjestelmässä yksilöivän tunnisteen ja objektin globaalisti yksilöivän tunnisteen. Tiedot ovat muuttumattomia [Ope16b]. Versioidusta pääsyobjektista (EHR_access), joka pitää sisällään oletusoikeudet sähköiseen potilaskertomuksen kaikkiin tietoihin sekä kaikki tahot ja niiden oikeudet per kooste mikäli oikeudet poikkeavat oletusoikeuksista [Ope16b]. Versioidusta statusobjektista (EHR_status), joka pitää sisällään mahdollisen potilaan yksilöivän tunnisteen, objektin aktiivisuustiedon, onko objekti löydettävissä kyselyillä. Objektin arkkityypitettävään osaan voidaan vapaasti kirjata muuta metatietoa. Esimerkiksi sovelluksen versiotieto, millä objekti luotiin [Ope16b]. Versioiduista koosteista (Compositions), jotka pitävät sisällään kaiken kliinisen ja hallinnollisen tiedon. Koosteita käytetään kahdessa eri merkityksessä. Tapahtumakoosteina (Event Compositions) ja jatkuvina koosteina (Persistent Compositions). Tapahtumakoosteeseen tallennetaan yhden terveydenhuollossa potilasta koskevan tapahtuman tiedot. Tällainen tapahtuma on esimerkiksi terveydenhuollon ammattilaisen kohtaaminen

9 potilaan kanssa tai potilaan verinäytteestä tehty laboratoriotutkimus. Tapahtumiin tallennetaan tapahtuman tiedon lisäksi tapahtuman konteksti, eli kuka, missä ja milloin. Jatkuvaan koosteeseen tallennetaan pidempään muuttumattomana pysyvää taustatietoa potilaasta, kuten esimerkiksi nykyinen lääkitys, perhehistoria ja rokotukset [Ope16b]. Kirjaukset (Contributions) tietueet pitävät sisällään jokaisen sähköiseen potilaskertomukseen tehdyn lisäyksen, muutoksen tai poiston. Yksi kirjaus tyypillisesti vastaa yhtä potilastapahtumaa ja pitää sisällään muutoksia merkintöinä useampaan eri tietoon (versioituun olioon). Esimerkiksi yksi kirjaus voi pitää sisällään merkinnät potilaalle tehdystä tutkimuksesta sekä määrätystä lääkkeestä. Kaikki kirjaukset yhdessä muodostavat nykytilan, sekä kaiken kirjatun tiedon sisältävän historian. Yhdessä tietueessa on viittaus muutokset tehneeseen käyttäjään sekä yhteen tai useampaan versioituun olioon. Versioiduissa olioissa on vastaavasti viite ko. olion luoneeseen kirjaukseen [Ope16e]. Versioidusta hakemistosta (Directory), jonka hierarkkista rakennetta voi käyttää koosteiden kansioimiseen. Kansiosta on ainoastaan viite koosteeseen, joten useampi kuin yksi kansio voi viitata samaan koosteeseen. Kansiot ovat arkkityypitettävissä [Ope16b]. Kaikki sähköiseen potilaskertomukseen tallennettu kliininen tieto tallennetaan merkintä (Entry) luokan ilmentyminä. Merkintä on yksittäinen kliininen toteamus, joka sisältää hyvin vaihtelevan määrän tietoa yksittäisestä lauseesta psykiatrisiin tutkimuskirjauksiin. Merkityn tiedon semantiikka määritellään rajaamalla merkintä luokkaa tai sen aliluokkia arkkityypeillä [Ope16b]. Merkintä luokkaa tai sen aliluokkaa rajaavat arkkityypit muodostavatkin selkeän enemmistön kaikista arkkityypeistä. Aliluokat ovat hoitomerkintä (CARE_ENTRY) ja hallinnollinen merkintä (ADMIN_ENTRY). Hallinnollisella merkinnällä ei ole aliluokkia, mutta hoitomerkinnällä on neljä. Hoitomerkinnän aliluokat ovat havainto (OBSERVATION), evaluointi (EVALUATION), ohje (INSTRUCTI- ON) ja toiminta (ACTION) [Ope16a]. Kuvassa kolme on sähköisen potilaskertomuksen yleiskuva ja kirjausten rakenne. Vasemmalla on versioidut oliot ja oikealla kirjauksiin liittyvät.

10 Kuva 3: openehr sähköisen potilaskertomuksen viitemallin yleiskuva openehr:n sähköisen potilaskertomuksen ydinominaisuudet [KaA08] ovat dokumenttitason, kansioiden ja hienojakoisten kirjausten myötä aikaansaatu rakenne. Toimijoiden, kuten potilaskertomuksen kohteen, tiedon kirjaajan, allekirjoitusten ja tiedon tuottajan tallentamisen mahdollistaminen. Päivämäärien ja ajanhetkien määrittely siten, että tapahtuman tapahtumahetki ja sen järjestelmään kirjaamisen hetki voidaan tallettaa. Ilmentymien yksilöivät tunnisteet ja versionhallintaominaisuudet. Tietotyypit termien, määrien, päivämäärien, aikojen jne.. johdonmukaiseen esittämiseen. Roolipohjainen pääsynhallinta, joka mahdollistaa lain vaatimien profiilien käyttämisen. Domain tason kliinisen tietämyksen poisjättäminen tietomallista. 6.4 openehr:n arkkityypit ja sapluunat Arkkityypeillä saadaan geneerisestä tietomallista rajattua tietyn domain tarpeiden mukainen. Käytännössä geneeriseen tietomalliin saadaan lisättyä domainin mukainen semantiikkaa. Uudelleenkäytettävät arkkityypit muodostavat yhdessä arkkityyppien kirjaston [Ope16c]. Sapluunat mallintavat tietyn käyttötapauksen, esimerkiksi tulosteen sisällön, käyttäjän näkemän ruudun sisällön, dokumentin rakenteen tai integraatiossa tarvittavan viestin rakenteen. Sisältö koostetaan yhden tai useamman arkkityypin sisältämistä elementeistä rajaamalla sallittuja arvoja ja terminologiaa vastaamaan tiettyä käyttötarkoitusta. Sapluunat vastaavat tuotantokäytössä olevassa järjestelmässä usein esimerkiksi yhtä ruudul-

11 la näkyvää lomaketta ja ne ovat tapa käyttää arkkityyppejä järjestelmässä suorituksen aikana [Ope16c]. Arkkityypit ja sapluunat määrittelevät tietoa tietoteorian (epistemological) näkökulmasta. Ne mallintavat tietyn tietoinstanssin mahdollisen tietorakenteen, mutta eivät määritä rakenteen sisältämälle tiedolle ontologiaa. Ontologiat ovat välttämättömät ja ne sidotaan terminologisilla sidoksilla (terminology bindings) arkkityyppeihin ja sapluunoihin. Terminologisten sidosten avulla on mahdollista määritellä ontologisesti mistä tietyssä arkkityypin tai sapluunan elementissä on kyse tai määritellä elementin arvojen keskinäinen suhde [Ope16c]. Kuvassa neljä on kuvattu arkkityyppien ja sapluunoiden suhteet muihin ohjelmistokomponentteihin ja terminologioihin. Kuva 4; openehr semantiikan arkkitehtuuri Käytännössä arkkityypin määrittely koostuu kolmesta osasta. Kuvailevasta tiedosta, rajoitussäännöistä ja ontologisista määrittelyistä [Eic05]. Kuvaileva tieto sisältää arkkityypin yksilöllisen tunnisteen, arkkityypin määrittelevän kliinisen käsitteen koodin koneluettavassa muodossa, sekä arkkityyppiin liittyvää metadataa. Metadata sisältää esimerkiksi versionumeron, arkkityypin käyttötarkoituksen, sen tekijän ja tiedon mikäli arkkityyppi on erikoistettu toisesta arkkityypistä. Rajoitussäännöt ovat arkkityypin ydin. Niiden avulla rajoitetaan sähköisessä potilaskertomuksessa käsiteltävää tietoa rajoittamalla sallittua rakennetta, kardinaliteettiä ja sisältöä arkkityypin mukaisten olioiden osalta. Ontologiset määrittelyt määrittelevät sanastot (koneen luettavat koodit) joilla arkkityypin mukaisen olion tietoa voi kuvata ontologisessa mielessä. Määrittelyt sisältävät myös koodistojen merkitysten mahdolliset käännökset eri ihmisten kielille. Lisäksi

12 siinä voidaan määritellä rajoituksia arkkityypin sisällä oleville koodatuille arvoille perustuen toisiin saman arkkityypin sisältämiin koodattuihin arvoihin. 6.4.1 openehr:n arkkityyppien määrittelykieli 2 Arkkityyppien määrittelykieli (The Archetype Definition Language 2/ADL2) käytää kolmea muuta syntaksia. Rajaavaa arkkityyppien määrittelykieltä (cadl), instanssin datanotaatiota (Object Data Instance Notation) ja versiota ensimmäisen kertaluvun predikaattilogiikasta (First-Order Predicate Logic/FOPL). cadl ja FOPL syntakseilla kuvataan rajoituksia, joilla arkkityyppi rajaa viitemallia. ODIN syntaksia käytetään ADL arkkityypin kieltä sisältävissä osioissa. Täten ADL itsessään on koostava syntaksi, joka käyttää muita ilmaisemaan tiedon ja sen rakenteiden rajoituksia [Ope16f]. Kuvassa viisi esitellään arkkityypin määrittelyn eri osakokonaisuudet. Kuva 5: openehr:n arkkityypin määrittelyn rakenne

13 Määrittelyosiossa kuvataan rajoitukset määrittelykielellä lohkorakenteisena. Rajoitukset kuvataan puuna objekti-attribuutti-objekti rakenteena. Solmut ovat objekteja ja lehdet ovat attribuutteja. Rajoitukset arvojoukkoon määritellään AC-koodilla ja rajoitukset yksittäiseen termiin määritellään AT-koodilla. Jokaisella solmulla (objektilla) on sen arkkityypin sisällä yksilöivä pakollinen tunniste. Lisäksi jokainen solmun nimi viittaa alapuolisen viitemallin luokkaan. Nämä mahdollistavat sen, että jokaiseen arkkityypin solmuun voidaan viitata yksiselitteisesti ja solmuja voidaan käyttää ohjelman suorituksen aikana tiedon rajaamiseen. Lisäksi jokaisella solmulle kyetään muodostamaan yksilöllinen polku [Ope16f]. Rajoitusten puurakenteesta johtuen poluilla on sama objekti/attribuutti/objekti rakenne [Ope16f]. Määrittelyosiossa voidaan määritellä rajoituksia myös terminologialle. Terminologiset rajoitukset voivat koskea yhtä arvoa tai arvojoukkoa. Termit itsessään voidaan määritellä arkkityypin sisällä tai viitata ulkopuoliseen terminologiaan [Ope16f], molemmissa tapauksessa termit määritellään terminologia osiossa. Säännöt osiossa määritellään säännöt, joiden määrittelyyn cadl kielen kuvausvoima ei riitä. Tällaisia sääntöjä ovat säännöt, joissa käsitellään useamman kuin yhtä solmua. Säännöt, joissa on ennalta määritelty arvo, esimerkiksi current_date. Säännöt, jotka hyödyntävät kyselyn vastausta, esimerkiksi potilaan ikää [Ope16f]. 6.4.2 openehr:n arkkityyppien kyselykieli Arkkityyppien kyselykieli (The Archetype Query Language/AQL) on deklaratiivinen kyselykieli kliinisen datan hakemiselle arkkityypeihin perustuvista sähköisistä potilaskertomuksista. Sen syntaksi on irrallaan ohjelmointikielistä, järjestelmäympäristöistä ja tallennusmalleista. Sen avulla kyselyt voidaan tehdä semanttisella tasolla perinteisen tietotason sijaan. Kerran tehtyä kyselyä voidaan käyttää AQL:n minimivaatimukset täyttävissä muissa järjestelmissä sellaisenaan. Minimivaatimukset ovat arkkityyppien ja terminologian käyttö siten, että järjestelmän sisältämä tieto on merkattu arkkityyppi- ja terminologiakoodeilla riittävän hienojakoisesti [Ope16d]. 7 Yhteenveto Monessa maassa terveydenhuollon toimintaa yritetään tehostaa ottamalla käyttöön ter-

14 veydenhuollon tietotekniikkaa. Erityisesti sähköisestä potilaskertomuksesta ja sen varaan rakentuvasta toiminnallisuudesta, kuten päätöksenteon tuesta ja näyttöön pohjautuvasta lääketieteestä odotetaan suuria. Tulevaisuudessa genetiikkaan perustuvasta henkilökohtaisesta hoidosta toivotaan lisää tehokkuutta. Sähköinen potilaskertomus ja sen varaan pohjautuvat toiminnallisuudet tuovat hyötyjä hyvin laaja-alaisesti monelle eri sidosryhmälle. Sähköisen sairauskertomuksen tietoon pääsee aina käsiksi useampikin käyttäjä yhtä aikaa. Sähköisen sairauskertomuksen tieto tai otos siitä voidaan esittää käyttäjälle juuri hänen tarvitsemassaan muodossa. Laajasta heterogeenisestä käyttäjäkunnasta johtuen sähköiseen potilaskertomukseen ja potilastietojärjestelmään kohdistuu paljon vaatimuksia. Eri käyttäjien vaatimukset voivat myös olla ristiriidassa keskenään. Yleisistä, käyttökohteesta riippumattomat vaatimukset tunnetaan onneksi hyvin. Kansainvälisessä ISO 18308 standardissa listataan ydinvaatimukset potilastietojärjestelmän arkkitehtuurille. Terveydenhuoltoon on vuosikymmenten aikana toteutettu lukuisia erillisiä tietojärjestelmiä. Sen johdosta on minkä tahansa uuden järjestelmän merkittävänä, ellei merkittävämpänä vaatimuksena yhteentoimivuus semanttisella tasolla. Yhteentoimivuus on perinteisesti ratkaistu viestipohjaisesti, tietovarastopohjaisesti tai yhteisarkkitehtuuripohjaisesti. Kehittyneimpänä ja nykyaikaisimpana tapana pidetään kahden mallin ratkaisutapaa. Tapa on eräänlainen yhteisarkkitehtuurimalli, missä tietojärjestelmät jakavat keskenään yhteisen viitemallin. Viitemalli on geneerinen ja se voi käsitellä hyvin monimuotoista tietoa. Järjestelmäkohtaisesti viitemallin geneerisyyttä rajataan arkkityyppien avulla. Arkkityypit mahdollistavat järjestelmäkohtaisesti viitemallin rajaamisen halutun domainin mukaiseksi. Arkkityyppien avulla saavutetaan myös semanttinen yhteentoimivuus kun ne sidotaan ontologioigin terminilogisilla sidoksilla. Täten onnistuu myös semanttisten kyselyiden kohdistaminen sähköisen sairauskertomuksen tietoihin. openehr säätiöt laajat avoimet spesifikaatiot kattavat sähköisen sairauskertomuksen ja potilastietojärjestelmän rakentamisen. Spesifikaatioiden yhtenä merkittävänä tavoitteena on tukea potilastietojärjestelmien semanttista yhteentoimivuutta. Tämän spesifikaatiot saavuttavat kahden mallin arkkitehtuurin avulla jossa pohjalla on viitemalli jota rajataan arkkityypeillä. Spesifikaatioiden mukaisen järjestelmän suunnittelussa on noudatettu montaa periaatetta, joilla pyritään eri komponenttien ja kerrosten välisiä rooleja selkiyttämään ja keskinäisiä sidoksia heikentämään. openehr spesifikaatioiden ja avoimen lähdekoodin toteutusten varaan pystyy rakentamaan modernin sähköisen sairauskerto-

muksen sekä sen tarvitseman potilastietojärjestelmän. 15

16 Lähteet [BaM13] [Bea02] [Beg07] [BlP09] [Dob10] [Eic05] [FiE13] [GaD06] Arshdeep, B., Vijay K., A Cloud-based Approach for Interoperable Electronic Health Records (EHRs), IEEE Journal of Biomedical and Health Informatics, Vol., 17, No. 5, 2013, s. 894-906. Beale, T., Archetypes: Constraint-based Domain Models for Future-proof Information Systems, Workshop on behavioural semantics, Vol. 105, OOPSLA, 2002. Begoyan, A., AN OVERVIEW OF INTEROPERABILITY STANDARDS FOR ELECTRONIC HEALTH RECORDS, Integrated Design and Process Technology, IDPT-2007, Society of Design and Process Science, USA, 2007. Blobel, B., Pharrow, P., Analysis and Evaluation of EHR Approaches, Methods of information in medicine, Vol. 48, Issue 2, 2009, s. 162-169. Dobrev, A., et all., Interoperable ehealth is Worth it, Securing Benefits from Electronic Health Records and eprescribing, Study Report, European Communities, Luxenburg, 2010. Eichelberg, M. et all., A Survey and Analysis of Electronic Healthcare Record Standards, ACM Computing Surveys, VOL 37, No. 4, New York, 2005, s. 277-315. Fitzpatrick, G., Ellingsen, G., A Review of 25 Years of CSCW Research in Healthcare: Contributions, Challenges and Future Agendas, Computer Supported Cooperative Work (CSCW), 22, 2013, s. 609-665. Garets, D., Davis, M., Electronic Medical Records vs. Electronic Health Records: Yes, There Is a Difference. A HIMSS Analytics White Paper, Chicago, USA, 2006. [GGH00] Grimson, J., Grimson, W., Hasselbring, W., The SI Challenge in Health Care, COMMUNICATIONS OFF THE ACM, Vol. 43, No. 6, 2000. [HoA10] Hoerbst, A., Ammenwerth, E., Electronic Health Records A Systematic Review on Quality Requirements, Methods Inf Med, 49, Schattauer, Austria, 2010, s.320-336.

[ISO05] 17 International Organization for Standardization, ISO/TR 20514:2005 Health informatics Electronic health record definition, scope and context, Saatavilla: http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnum ber=39525 [26.03.16]. [ISO11] International Organization for Standardization, ISO 18308:2011 Health informatics -- Requirements for an electronic health record architecture. International Organization for Standardization, 2011, Saatavilla: https://www.iso.org/obp/ui/#iso:std:iso:18308:ed-1:v1:en [26.06.16]. [KaA08] Kalra, D., Tapuria, A., The EHR and Clinical Archetypes: time for clinical engagement!, ehealth Plannin and Management Symposium, 2008. [Kal06] Kalra, D., Electronic Health Record Standards, IMIA Yearbook of Medical Informatics, IMIA and Schautter GmbG, 2006, s. 136-144. [KaI06] Kalra, D., Ingram D., Electronic Health Records, Information technology solutions for healthcare, Springer, London, 2006, s. 135-181. [Mea06] Mead, C., N., Data Interchange Standards in Healthcare IT Computable Semantic Interoperability: Now Possible but Still Difficult, Do We Really Need a Better Mousetrap?, Journal of Healthcare Information Management, Vol. 20, No. 1, 2006, s. 71-78. [MMF10] Martínez-Costa, C., Menárguez-Tortosa, M., Fernández-Breis, T., An approach for the semantic interoperability of ISO EN 13606 and OpenEHR archetypes, Journal of biomedical informatics, 43, Elsevier, 2010, s. 736-746. [Ope16a] openehr Foundation, openehr Architecture Overview release 1.0.3, Saatavilla: http://www.openehr.org/releases/base/release- 1.0.3/docs/architecture_overview/architecture_overview.html [26.06.16]. [Ope16b] openehr Foundation, EHR Information Model, Saatavilla: http://www.openehr.org/releases/rm/latest/docs/ehr/ehr.html [26.06.16].] [Ope16c] openehr Foundation, Archetype Technology Overview, Saatavilla: http://www.openehr.org/releases/am/latest/docs/overview/overview.html [26.06.16]

[Ope16d] openehr Foundation, Archetype Query Language (AQL), Saatavilla: http://www.openehr.org/releases/query/latest/docs/aql/aql.html [26.06.16] 18 [Ope16e] openehr Foundation, Common Information Model, Saatavilla: http://www.openehr.org/releases/rm/latest/docs/common/common.html [26.06.16] [Ope16f] [Sch06] [Suj98] openehr Foundation, Archetype Defination Language 2, Saatavilla: http://www.openehr.org/releases/am/latest/docs/adl2/adl2.html [26.06.16] Schloeffel, P. et all., The relationship between CEN 13606, HL7 and openehr, HIC 2006 Bridging the Digital Divide: Clinician, consumer and computer, Johanna W., Joanne C., Health Informatics Society of Australia Ltd, Sydney, 2006. Sujansky, W., The Benefits and Challenges of an Electronic Medical Record: Much More than a Word-Processed Patient Chart, Western Journal of Medicine, 169, 1998, s.176-183. [Wae03] Waegmann, P., C., EHR vs. CPR vs. EMR, Health Informatics Online 1, 2003. [ZKW10] Zuniga, A., Khin, T., Willy, S., Functionalities of free and open electronic health record systems, International journal of technology assessment in health care, Vol. 24, 4, s. 382-389.