Terveydenhuollon dokumenttien arkkitehtuuri

Transkriptio

1 Terveydenhuollon dokumenttien arkkitehtuuri Iivo Raitahila Kandidaatin tutkielma HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Helsinki, 8. toukokuuta 2016

2 HELSINGIN YLIOPISTO HELSINGFORS UNIVERSITET UNIVERSITY OF HELSINKI Tiedekunta Fakultet Faculty Laitos Institution Department Matemaattis-luonnontieteellinen Tekijä Författare Author Iivo Raitahila Työn nimi Arbetets titel Title Tietojenkäsittelytieteen laitos Terveydenhuollon dokumenttien arkkitehtuuri Oppiaine Läroämne Subject Tietojenkäsittelytiede Työn laji Arbetets art Level Aika Datum Month and year Sivumäärä Sidoantal Number of pages Kandidaatin tutkielma 8. toukokuuta Tiivistelmä Referat Abstract Terveydenhuollossa käytetään monenlaisia dokumentteja, joita kutsutaan kliinisiksi dokumenteiksi, kuten hoitopalautteita ja lääkärin muistiinpanoja. Tutkielmassa selvitetään perinteisesti paperisten ja vapaamuotoisesti kirjoitettujen dokumenttien nykytilaa tietokonejärjestelmissä. Tutkielmassa keskitytään Suomessa käytettyyn HL7 CDA -standardiin. Esitietoina käydään läpi kliinisten dokumenttien vaatimukset, HL7 RIM-tietomalli ja sanastot. CDA-dokumentti koostuu loogisesti kahdesta osasta: metadataa sisältävästä otsakkeesta sekä runko-osasta, jossa on varsinainen tietosisältö. Runko-osan tieto on kirjoitettava ihmisen luettavassa muodossa ja tietoa voi täydentää koneellisesti käsiteltävällä tiedolla. Myös koneellisesti käsiteltävää tietoa voidaan asettaa pakolliseksi mallineilla. CDA-dokumentit ovat XML-tiedostoja, joten tutkielmassa esitellään muutama XML-tekniikka. Tutkielman lopuksi perehdytään, kuinka Kansallinen Terveysarkisto (Kanta) hyödyntää CDA-standardia. ACM Computing Classification System (CCS): Information systems Document representation Applied computing Health informatics Avainsanat Nyckelord Keywords Kliininen dokumentti, HL7, CDA, Kansallinen Terveysarkisto Säilytyspaikka Förvaringsställe Where deposited Muita tietoja Övriga uppgifter Additional information

3 Sisältö 1 Johdanto 1 2 Kliiniset dokumentit 2 3 Terveydenhuollon viitemalli RIM RIM-luokkakaavion rakenne Tietotyypit ja sanastot RIM-mallissa Mallintaminen Kliinisten dokumenttien CDA-arkkitehtuuri Dokumentin otsake Dokumentin runko-osa Mallineet Allekirjoitus Dokumenttien lukeminen Dokumentit paikallisissa järjestelmissä Vaatimustasot Versioiden eroavuudet Kritiikki ja parannusehdotukset Sovellus: Kansallinen Terveysarkisto (Kanta) Kanta-järjestelmän hyödyt Dokumentin otsake Dokumentin runko-osa Esimerkkidokumentti Yhteenveto 23 Lähteet 24 ii

4 1 Johdanto Terveydenhuollossa käytetään monenlaisia dokumentteja, kuten hoitopalautteita ja lääkärin muistiinpanoja. Näitä kutsutaan kliinisiksi dokumenteiksi. Perinteiset kliiniset dokumentit ovat ihmiselle luettavaksi tarkoitettuja vapaamuotoisella kirjoitustavalla kirjoitettuja kertomuksia, joita siirretään muun muassa postitse ja faxilla. Tutkielman aiheena on selvittää kliinisten dokumenttien käsittelyn nykytilaa tietokonejärjestelmissä keskittyen Suomessa käytettyyn HL7 CDA -standardiin. Terveydenhuollon viestintä- ja dokumenttistandardeja kehittävä Health Level 7 (HL7) -organisaatio on tehnyt standardin kliinisten dokumenttien käsittelyyn tietokonejärjestelmissä [4]. Artikkelissa [5] esitellään HL7 Clinical Document Architecture (CDA) -standardi, joka määrittelee kliinisten dokumenttien merkkaustavan, rakenteen ja semantiikan. CDA:n kehityksen ideana on luoda koneellisesti käsiteltävä muoto perinteisesti ihmisten luettavaksi tarkoitetuista dokumenteista. Koneellisesti käsiteltävän muodon on tarkoitus mahdollistaa dokumenttien sisällön vertailu, tallennus, tiedonsiirto ja hyötykäyttö esimerkiksi päätöksentekoon, vaikka dokumentit on luotu erilaisissa järjestelmissä. Tässä tutkielmassa käsitellään CDA:n Release 2 -versiota, ellei erikseen muuta mainittu. CDA-dokumentti on koodattu Extensible Markup Language (XML) -muotoon ja se voi sisältää tekstiä, kuvia ja multimediasisältöä kattaen kliinisten dokumenttien tarpeet. Semantiikka sekä termistö saadaan HL7 Reference Information Model (RIM) -tietomallista, jolloin tietokone voi käsitellä sisältöä, mutta dokumentti voi sisältää vain ihmisen luettavaksi tarkoitettua tietoakin. Täten käyttöönotto ja myöhempi päivitys tietokonekäsiteltävämpään muotoon on helppoa. CDA-dokumentti voidaan lähettää viestissä sekä sitä voi säilyttää sellaisenaan. Tutkielmassa käsitellään ensin kliinisten dokumenttien ominaispiirteet ja vaatimukset. Esitietovaatimuksina varsinaiselle sisällölle käsitellään RIMviitemalli, joka on koko terveydenhuollon kattava tietomalli. RIM:n tietotyyppejä varten tutustutaan sanastojen eli koodistojen käsitteeseen. CDAdokumentti koostuu loogisesti kahdesta osasta, otsakkeesta ja runko-osasta, jotka käsitellään neljännen kappaleen aluksi. Muita olennaisesti CDA-dokumentteihin liittyviä tekniikoita käsitellään alikappaleissa. Kappaleen lopuksi esitellään lyhyesti CDA:n vanhemman Release 1 ja uudemman Release 2 -versioiden eroja sekä CDA:n kohtaamaa kritiikkiä. Tutkielman viimeinen osa esittelee Suomessa käytettyä Kansallista Terveysarkistoa. 1

5 2 Kliiniset dokumentit Kliiniset dokumentit ovat terveydenhuollossa käytettyjä dokumentteja, kuten hoitopalautteita, lääkärin muistiinpanoja, sairauskertomuksia, lähetteitä, lääkemääräyksiä ja lomakkeita. Ne ovat kirjauksia havainnoista ja tehdyistä asioista sekä suunnitelmista ja tavoitteista. Perinteisesti dokumentit ovat olleet paperisia ja ihmisen luettavaksi tarkoitettuja kertomuksia. Kliinisten dokumenttien digitaalisointiin on useita järjestelmiä. Artikkeli [9] kertoo Japanissa vuodesta 1996 alkaen kehitetyistä Medical Markup Language (MML) -standardeista. MML on CDA:n tapaan XML-pohjainen muoto kliinisen tiedon siirtoon. MML:n versio 3.0 perustuu kuitenkin HL7 CDA -standardiin. Kirjassa [2] mainitaan Digital Imaging and Communications in Medicine (DICOM) -standardista, jota käytetään kuvien siirtoon. HL7:n standardit ja DICOM olivat päällekäisiä, sillä myös CDA:ssa voi siirtää kuvia. Nykyään CDA tukee myös DICOM-kuvien siirtoa. Muita dokumenttistandardeja ovat muun muassa CDISC ODM [7] ja EN13606/OpenEHR [2], mutta tutkielmassa keskitytään Suomessa käytettävään HL7 CDA -standardiin. Dokumentti voidaan myös tallentaa järjestelmän kehittäjän luomassa muodossa, jolloin tiedonsiirto erilaisten järjestelmien välillä hankaloituu. Artikkelissa [4] on selostettu tyhjentävästi kliinisen dokumentin vaatimukset. Kliinisellä dokumentilla on tiettyjä ominaispiirteitä. Kliiniset dokumentit ovat pysyviä, eli dokumenttia säilytetään muuttumattomana säädöksien määräämän ajan (Persistence) ja säilytyksestä vastaa määrätty henkilö tai organisaatio (Stewardship). Kliinisten dokumenttien kokonaisuus ja oikeellisuus on voitava varmistaa lainvoimaisella allekirjoituksella (Potential for authentication). Dokumentista ei voida irrottaa osia huomaamatta, eli niitä on säilytettävä kokonaisina (Wholeness). Allekirjoitus pätee vain koko dokumentille. Dokumenttien on oltava muutettavissa ihmiselle lukukelpoiseen muotoon (Human readability). CDA:n perusperiaatteisiin kuuluu myös teknisiä seikkoja. Painoarvo annetaan dokumenteille, jotka hoidon antanut ammattihenkilö on tehnyt. Esimerkiksi tutkimukseen ja raportointiin käytetyt dokumentit ovat johdettavissa näistä dokumenteista. Standardin käyttöönotto on tehty helpoksi määrittelemällä eri tasoja dokumenteille. Tasojen avuin käyttöönotosta saadaan helppoa ja teknistä hienostuneisuutta voidaan lisätä myöhemmin. Standardissa on otettu huomioon paikalliset vaatimukset, kuten lainsäädäntö, ilman standardin muokkausta. Tiedon säilymistä tuetaan siten, että CDAdokumentit ovat ohjelmisto- ja alustariippumattomia, jotta niitä voidaan käsitellä myös tulevaisuudessa. Dokumentteja voi luoda ohjelmointikielien yleisillä XML-työkaluilla tai vaikka tekstinkäsittelyohjelmalla. Myös tiedonsiirto on ohjelmisto- ja alustariippumatonta. CDA-standardi ei ota kantaa tiedonsiirtotapaan [6] eikä tiedonsiirtoa juuri käsitellä tutkielmassa. Koska CDA-dokumentit ovat XML-tiedostoja, niitä voi käsitellä tiedostojärjestelmässä normaaleina tiedostoina. Siten dokumentteja voi siirtää esimerkiksi 2

6 tiedostonjakoprotokollilla, muistitikuilla, levykkeillä ja sähköpostissa. HL7 on kehittänyt standardin myös tiedonsiirtoa varten. Dokumentteja voidaan päivittää ja niitä voidaan liittää toisiin dokumentteihin. Dokumenttienhallintajärjestelmä on tärkeä, sillä hallintajärjestelmällä varmistetaan, että dokumentti on ajantasainen. Artikkeli [16] käsittelee yleisesti dokumenttien kulkua järjestelmien välillä. Pelkästään tiedonsiirtoon keskittyvät liittymät ovat yksinkertaisia toteuttaa. Sellainen olisi esimerkiksi järjestelmä, jossa ohjelmilla A ja B on omat tietokannat. Kun ohjelmaan B tehdään liittymä ohjelmaan A, se tehdään lukemalla tiedot A:n tietokannasta ja näyttämällä tieto B:n käyttöliittymässä. Tässä kuitenkin ohjelma B määrittää tiedon tarkoituksen näyttäessään sen valitsemassaan kohdassa ja asiayhteydessä käyttöliittymässään. Ongelmia syntyy kun A:n tietokantaan tehdään muutoksia, sillä muutokset on tehtävä myös ohjelmaan B - ja mahdollisesti satoihin muihin B:n kaltaisiin ohjelmiin. Muutos voi vaatia massiivisia muutoksia tietokantaa hyödyntäviin ohjelmiin. Tyypillisesti liittymät ovat erilaisia ja jokaisen tietokuvaus on suunniteltava yksitellen, eli semanttista yhteentoimivuutta ei ole järjestelmien välillä. Semanttisen yhteentoimivuuden luonti voi olla aikaa vievää ja vaikeaa. Organisaation kahdessa eri järjestelmässä voi olla esimerkiksi sama kenttä asiakas, jotka viittaavat eri asioihin. On helpompaa ratkaista epäyhteensopivuus näiden kahden järjestelmän välillä kuin muuttaa organisaation kaikkia järjestelmiä. Yleisesti ottaen tietomallia ja tietoarkkitehtuuria voidaan yksinkertaistaa, jotta tietoon päästään helpommin käsiksi ja tiedonjakoa helpotetaan. Tietomalli määrittää tiedon, jota järjestelmään voidaan tallettaa. Tietomallin luonti vaatii erityisosaamista koko organisaation tarpeista ja järjestelmistä. Semanttisesti yhteensopivan mallin on katettava organisaation kaikkien tietojärjestelmien tarpeet. Esimerkiksi laskutusjärjestelmällä on hyvin erilaiset tarpeet kuin tuotetietojärjestelmällä. Yleisen tietomallin vuoksi saatetaan joutua tekemään kompromisseja ja se saattaa monimutkaistaa vanhojen liittymien käyttöä. 3 Terveydenhuollon viitemalli RIM Standardissa [6] esitelty HL7 Reference Information Model (RIM) on HL7 versio 3 -standardeissa, kuten CDA:ssa, käytetty tietomalli (shared information model). RIM on täsmällisesti määritelty lähde luokille ja attribuuteille. RIM on tekninen kaavio, joka esitetään HL7:n käyttämässä UML:n tapaisessa muodossa. Osa RIM-tietomallia on esitetty kuvassa 1. Standardissa ja kirjassa [2] RIM esitetään kattavasti. RIM:n tavoite on kattaa koko terveydenhuollon alue yhteentoimivuutta varten. RIM perustuu idealle, jossa kaikki dokumentoitava liittyy tapahtumiin (happenings) ja asioihin, kuten ihmisiin, jotka ovat erilaisissa tekemisissä toistensa kanssa. 3

7 Kuva 1: Osa RIM-tietomallia. Tapahtumilla on aikamuoto ja asiat voivat olla erilaisissa rooleissa, kuten ihminen roolissa potilas tai lääkäri. RIM toimii tietokoneiden käyttämänä sanastona, jonka luokkia ja attribuutteja käytetään rakennuspalikoina. 3.1 RIM-luokkakaavion rakenne RIM-tietomallin pääluokat ovat Act, Role ja Entity, joita yhdistävät ActRelationship, Participation ja RoleLink -liitosluokat. Kaikki tapahtumat ovat verbejä vastaavia Act:eja, joihin liittyy Participation-liitosluokan avulla substantiiveja vastaavia Role:ja ja Entity:itä. Tapahtumat voivat liittyä toisiinsa ActRelationship-liitosluokan avulla. Pääluokilla on aliluokkia ja esimerkiksi Person on Living Subject:in aliluokka, joka on Entity:n aliluokka täten Person perii sekä Entity:n että Living Subject:in attribuutit. RIM määrää jokaiselle luokalleen attribuutit, joita voi käyttää, ja jokaisella attribuutilla on tietotyyppi. Attribuuteista ja tietotyypeistä muodostuu XML-elementit. Viesti tai dokumentti koostuu attribuuttien osajoukosta, niiden rajoituksista, käytetyistä elementeistä ja toistojen määrästä. Tällaista valintatoimenpidettä kutsutaan jalostamiseksi (refinement) ja tuloksena on profiili (profile). Yksi profiilityyppi on Refined Message Information Model (RMIM). RMIM esitetään graafisesti HL7 V3 -notaatiolla, josta muodostetaan XML-skeema. Käytäntö yhteisen tietomallin rajoittamisesta sovituksi osajoukoksi on laajalle levinnyt eri standardien keskuudessa. Profiilien avulla valvotaan, että asia tulkitaan samalla tavalla eri järjestelmissä. Strukturoiduilla attribuuteilla määritetään, mitä kukin luokka tarkoittaa 4

8 viestissä tai dokumentissa. Actin classcode kertoo millaisesta tapahtumasta on kyse, esimerkiksi havainnosta tai lääkkeen annosta ja moodcode kertoo aikamuodon, esimerkiksi että lääkettä annettiin. Standardi [6] määrittää, että jos CDA:ssa ei ole määritelty jotakin arvoa, käytetään standardin oletusarvoa. Esimerkiksi strukturoitua ClinicalDocument.classCode -attribuuttia ei tarvitse erikseen määrittää, sillä sen ainoa sallittu arvo on DOCCLIN ja se on samalla oletusarvo. 3.2 Tietotyypit ja sanastot RIM-mallissa Attribuuttien sallitut arvot määrittää tietotyyppi (Data Type), joita esitellään artikkelissa [5]. Tietotyypit ovat HL7 Version 3 -tietotyyppejä, jotka voivat olla yksinkertaisia, kuten kokonaislukuja tai aikaleimoja, tai ne voivat olla monimutkaisempia, kuten koodeja tuetuista sanastoista. Jokaisella RIM:n attribuutilla on aina yksi tietotyyppi. Dokumentin elementtien sisältö voidaan poimia määritetystä lähteestä eli sanastosta tai koodistosta [1]. Sanaston perusidea on yksinkertainen: sanasto määrittelee koodatun kentän sallitut arvot. Esimerkiksi siviilisääty-kentän sallitut arvot ovat erään sanaston mukaan naimaton, naimisissa, eronnut, leski ja asumuserossa. Sanaston käyttäminen vahventaa kenttien semantiikan ymmärtämistä ja konekäsiteltävyyttä. Jokainen RIM:n koodattu attribuutti vaatii sanaston määrityksen. Artikkelissa [15] mainitaan esimerkki sanaston käyttötapauksesta. Jotkut kirjoittavat kaliumin (englanniksi potassium) lyhenteeksi pot ja jotkut käyttävät sen kemiallista merkkiä K. Kirjoitusasuun sisältyy väärinkäsityksen vaara, jonka voi välttää valitsemalla kaliumin merkintätavan, tai tässä tapauksessa koodin, sanastosta. Yksiselitteinen kirjoitusasu on erityisen tärkeää tietokonejärjestelmissä. Osa sanastoista on sisäänrakennettuja. Tuettuja ulkoisia sanastoja ovat mm. Logical Observation Identifiers, Names and Codes (LOINC) sekä Systemized Nomenclature of Medicine Clinical Terms (SNOMED CT). Koodatusta tietotyypeistä selitetään kirjassa [2]. HL7 Version 3 koodatut tietotyypit ovat CS, CV, CE ja CD. CS on yksinkertainen koodi mistä tahansa ja sen mukana voidaan antaa ihmisluettava muoto. CV on kuin CS, mutta käytetty sanasto on mainittava. CE on kuin CV, mutta termi voidaan määrittää usealla eri sanastolla. CD sallii post-koordinoitujen koodien käytön. Standardissa [6] mainitaan, että koodattu attribuutti voi olla muodoltaan CWE (Coded With Exceptions), jolloin koodi poimitaan mieluusti sanastosta, mutta vapaa teksti sallitaan, tai attribuutin muoto voi olla CNE (Coded, No Extensions), jolloin koodi on poimittava sanastosta. Jokaisella sanastolla on HL7:n määrittämä tunniste ja jokaisella koodilla sanastossa on tunniste. Logical Observation Identifier Names and Codes (LOINC) -sanasto koostuu yli nimestä ja koodista [12]. Koodeja käytetään havaintojen tunnistamiseen viesteissä eri tietojärjestelmien välillä. LOINC-sanastoa käytetään 5

9 muissakin standardeissa kuin HL7:n standardeissa. Sanasto on saanut kiitosta myös siitä, että se on ilmaiseksi käytettävissä. CDA:ssa LOINC-sanastoa käytetään esimerkiksi Section.code:ssa. Systematized Nomenclature of Medicine Clinical Terms (SNOMED CT) on maailman laajin kliininen termistö [2]. Se koostuu konsepteista, eli yksittäisistä tarkoituksista (kuten nuha), kuvauksista konsepteille (kuten nuha, flunssa) ja yhteyksistä (esimerkiksi umpilisäkkeen poisto on leikkaus). Vuonna 2009 SNOMED CT kattoi konseptia, englanninkielistä selitettä konsepteille ja 1,38 miljoonaa yhteyttä konseptien välillä. Vertailun vuoksi ICD-10, toinen suorittu termistö, kattaa vain konseptia vastaavaa luokkaa. Valmiiksi määriteltyjen, pre-koordinoitujen, konseptien lisäksi SNOMED CT -konsepteja voi yhdistää post-koordinoiduiksi konsepteiksi, esimerkiksi vakava ja astma voidaan yhdistää vakavaksi astmaksi. Jos standardissa ei mainita, mitä sanastoa tulisi käyttää, niin sanasto voidaan valita vapaasti. Kirjassa [3] on esitelty sanastojen käyttöä. Varsinaisen koodiarvon lisäksi merkitään codesystem- ja valinnaisesti myös codesystemname-attribuutit. CodeSystem on sanaston OID-yksilöintitunnus (object identifier), jolla käytetty sanasto tunnistetaan. OID:n avulla tiedetään sanastoa hallinnoiva organisaatio ja sanasto tunnistetaan yksikäsitteisesti. CodeSystemName merkitään ihmistä varten esimerkiksi vianetsintää helpottamaan. Jos sanastosta on useita versioita, voidaan käytettävä sanastoversio määrittää codesystemversion-attribuutilla. 3.3 Mallintaminen Kirjassa [3] annetaan ohjeet mallinnukseen. RIM esitetään UML:n kaltaisessa muodossa, jossa pääluokat ja liitosluokat ovat väritetty eri värein. Act-luokka on punainen, Role-luokka keltainen, Entity-luokka vihreä, ActRelationshipluokka vaaleanpunainen, Participation-luokka sininen ja RoleLink-luokka vaaleankeltainen. Act-luokkaan voi liittää ainoastaan ActRelationship ja Participation -luokkia, Participation-luokkaan voi liittää vain Role-luokan ja Role-luokan voi liittää vain Entity-luokkaan. Pääluokat esitetään HL7-kaavioissa suorakulmioina ja liitosluokat nuolen muotoisina. Nuolet poikkeavat UML-esitystavasta. Luokkien attribuutit merkitään HL7:n omalla tavalla. Merkinnän ensimmäinen osa on attribuutin nimi. Jos nimen perässä on tähti, attribuutti on sisällytettävä, mutta se voi olla tyhjä, ellei nimi ole lihavoitu. Kaksoispisteen jälkeinen osa kertoo tietotyypin ja muodon. Hakasulkujen sisälle merkitään kardinaalisuusrajoite. Viimeinen osa kertoo joko oletusarvon tai käytettävän sanaston. Malli muodostuu RMIM-kaaviosta, johon valitaan luokkia RIM-tietomallista. Samaa luokkaa voi käyttää useamman kerran. Kaikkia luokan attribuutteja ei tarvitse valita, vaan ainoastaan tarvittavat. Attribuuttien tietosisältöä voi kaventaa, esimerkiksi CD-tietotyyppi voidaan rajoittaa CE-tietotyypiksi ja käytettävä sanasto voidaan määrittää. 6

10 Kuva 2: Yksinkertaistettu CDA RMIM. RMIM-kaaviossa luokan strukturoidut attribuutit määräävät luokan nimen. Esimerkiksi CDA-dokumentin Act-luokan classcode on DOCCLIN ja moodcode on EVN, joista muodostuu luokan nimeksi ClinicalDocument. Jokaisella luokalla on strukturoitujen attribuuttien määräämä nimi, jota käytetään XML-esitysmuodossa. XML Schema -kielestä johtuen kahdella saman nimisellä elementillä on oltava sama rakenne, joten elementin nimi ei voi olla yleisesti esimerkiksi act, vaan esimerkiksi observation. Kuvassa 2 on esitetty yksinkertaistettu versio CDA RMIM-kaaviosta, joka on jalostettu kuvan 1 yksinkertaistetusta RIM-tietomallista. Malli voidaan esittää myös taulukkomuodossa, jota kutsutaan Hierarchial Message Descriptioniksi (HMD). CDA:n vastaavaa muotoa kutsutaan Hierarchial Descriptioniksi, sillä CDA ei ole viesti. 4 Kliinisten dokumenttien CDA-arkkitehtuuri CDA-standardin ensimmäinen versio (Release 1, R1) standardoitiin vuonna 2000 ja toinen versio (Release 2, R2) vuonna Molemmissa versioissa perusajatus on sama, eli dokumentti koostuu otsakkeesta (header) ja runkoosasta (body). 4.1 Dokumentin otsake CDA-dokumentti alkaa otsakkeella. Otsakkeen tietosisältö ja tarkoitus on selitetty artikkeleissa [4] ja [5]. Otsakkeessa on metadataa dokumentista, kuten sen kirjoittajan ja kohteena olevan potilaan tiedot tunnistusta sekä 7

11 luokittelua varten. Otsake mahdollistaa dokumenttien hallinnan, säilytyksen, siirron laitosten välillä sekä potilaan sairauskertomuksen kokoamisen. Otsakkeessa määritetään mm. dokumentin uniikki tunnistenumero, dokumentin tyyppi (esimerkiksi kotiuttamisraportti), luontiaika, salassapidon taso ja kieli. Runko-osan oletetaan noudattavan otsakkeen asetuksia ellei muuta asetettu, mutta esimerkiksi kieltä voi vaihtaa tietyn osion kohdalla. Artikkelissa [4] on esitetty otsakkeen rakenne. Näitä tietoja on päivitetty CDA Release 2:n mukaisiksi. Otsake koostuu neljästä loogisesta osasta. Document information yksilöi dokumentin ja sen suhteet muihin dokumentteihin. Encounter data kuvaa tapahtuman miljöötä, kuten klinikan sijaintia. Service actors sisältää dokumenttiin liittyvät terveydenhuollon toimijat. Service targets sisältää potilaan ja esim. perheenjäsenten tiedot. Document information sisältää tiedon, että onko dokumentti alkuperäinen dokumentti, liite toiseen dokumenttiin vai uusi versio vanhasta dokumentista. Viittaus tapahtuu relateddocument-elementillä. Jos dokumentti korvaa toisen dokumentin, sen uniikki id-elementti vaihtuu, mutta setidelementin arvo on sama kuin alkuperäisellä dokumentilla ja versionnumberelementin arvo kasvaa yhdellä. Vanha dokumentti säilytetään. Dokumentilla on pakollinen code-elementti, joka luokittelee dokumentin ja jonka arvo saadaan LOINC-sanastosta. Dokumentille määritetään confidentialitycodeelementissä tietosuojataso. Jos tietosuojataso määritetään otsakkeessa, se pätee koko dokumentille, mutta dokumentin eri osat voidaan määrittää eritasoisiksi päällekirjoittamalla otsakkeen arvo halutussa kohdassa rungossa. Encounter data sisältää tapahtuman tunnisteen, aikaleiman ja sijainnin. Myös muita vapaavalintaisia tietoja voi määrittää. Service actors -osaan kuuluvat kaikki henkilöt ja organisaatiot, jotka liittyvät dokumentoidun palvelun tuottamiseen. Näitä ovat esimerkiksi dokumentin todentajat, kopion vastaanottajat, dokumentin laatija ja puhtaaksikirjoittajat sekä muut ammattihenkilöt. He ovat vastuussa itsenäisistä päätöksistään. Todennus tehdään mm. kun paikallisen järjestelmän dokumentti muutetaan CDA-dokumentiksi. Dokumentin laatija voi olla ihminen ja/tai kone. Laatija on pakollinen tieto, joka kirjataan authorelementtiin, ja typecode-attribuutilla ilmoitetaan, onko kyseessä ihminen vai kone. Custodian-elementtiin määritetään organisaatio, joka on vastuussa sen säilytyksestä. Potilaan ja muiden tärkeiden osallistujien tiedot kuvataan Service targets -osassa. Nämä ovat dokumentoitavan asian kohteita ja ne ovat eläviä kohteita tai fyysistä materiaalia. RecordTarget-elementtiin kirjataan tiedot potilaasta, jonka sairauskertomukseen dokumentti kuuluu, ja joka on pääasiallisesti hoidon kohteena. Patient-elementtiin kuuluu person-luokalta perittävät tiedot sekä syntymäpäivä ja sukupuolitieto. Yksinkertaisimmillaan otsake on lyhyt. Pakollisia tietoja ovat tiedoston tyyppi (CDA-dokumentti), dokumentin tunnistenumero, dokumentin tyyppi 8

12 (LOINC-koodi), luontipäivä, turvallisuustaso sekä potilaan, kirjoittajan ja säilyttäjän tiedot. Potilaasta täytyy kirjata ainoastaan tunnistenumero, kirjoittajasta kirjausaika sekä tunnistenumero ja säilyttäjästäkin ainoastaan tunnistenumero. 4.2 Dokumentin runko-osa Dokumentin runko-osassa on varsinainen sisältö ja runko-osa on kuvattu artikkelissa [5]. Otsakkeen tietosisältö ja rakenne on johdettu RIM-tietomallista ja CDA R2 -versiossa myös rungon sisältö voidaan johtaa RIM-tietomallista. Dokumentin runko-osa voi olla yksi NonXMLBody-elementti, jossa on vain ihmisen käsiteltäväksi tarkoitettua tietoa, tai se voi koostua sectionelementeistä. NonXMLBody voi viitata ulkoiseen tiedostoon, mutta StructuredBody sisältää XML-rakenteet samassa tiedostossa [6]. Jokaisessa sectionelementissä on oltava sitä kuvaava ihmisen luettavaksi tarkoitettu textelementti, kuten Ota captopril 25mg PO aina 12 tunnin välein. Valinnaisia konekäsiteltäviä elementtejä voi olla useita ja ne voi olla johdettu RIM-tietomallista. Äskeiseen text-esimerkkiin liittyvät elementit olisivat mm. effectivetime (aika), dosequantity (määrä) ja consumable (valmiste). Ohjelmistojen on siten helppo tuottaa CDA-dokumentteja esimerkiksi pelkillä text-elementeillä varustettuna ja myöhemmin dokumenteista voidaan tehdä pitkälle konekäsiteltäviä. Artikkelissa [4] on esitelty myös rungon rakenne. Näitäkin tietoja on päivitetty CDA Release 2:n mukaisiksi. Runko koostuu rakenteista (structures), kuten Section-elementeistä, kappaleista, listoista ja taulukoista. Näillä osilla on otsikot ja osia voi laittaa sisäkkäin. Osat sisältävät kirjauksia (entries), jotka sisältävät tekstiä, multimediaa ja sanastoista poimittuja koodeja. Rakenteilla on konteksti, jonka attribuutit, kuten kieli, periytyvät sisemmille rakenteille ellei attribuuttia päällekirjoiteta. Kirjaukset kootaan Section-elementteihin. Sectionilla on otsakkeena titleelementti. Section voidaan koodata yhdellä LOINC-sanaston koodilla, joka toimii koneelle otsikkona aivan kuten title-elementti ihmiselle. Rakenteen sisältö voi olla vapaamuotoista tekstiä paragraph-elementissä. Sisältö voi olla myös taulukko tai lista. Yleisesti ottaen rakenteet ovat samankaltaisia kuin HTML-rakenteet ja muunnos HTML-muotoon katselua varten on suoraviivaista. Rakenteiden sisällä kirjaukset voivat olla content-elementeissä. Contentelementtejä voi laittaa sisäkkäin ja näin teksti voidaan paloitella pieniin täsmällisesti viitattaviin paloihin. Kirjauksia voidaan koodata entry-elementein, joilla sisällytetään koodeja sanastoista content-elementteihin. Koodien sisällyttämisellä tavoitellaan dokumentin indeksointia, hakua ja standardoidaan tapa, jolla merkityksellisiä koodeja sisällytetään dokumenttiin. Esimerkkirakenne näkyy kuvassa 3 ja se on kuvan 2 yksinkertaiste- 9

13 Kuva 3: Esimerkkirakenne [5]. tun RMIM-mallin mukainen. Rakenne on yksi dokumentin runko-osan, StructuredBody-elementin, lapsista. Text-elementti on rakenteen ainoa pakollinen osa ja se sisältää ihmisen luettavaksi tarkoitetun kuvauksen kirjauksista, joiden visualisoinnissa voi hyödyntää edellä mainittuja HTML:n kaltaisia rakenteita. Rakenteeseen on merkitty LOINC-sanastolla, että kyse on potilaan elintoimintojen mittauksista. Esimerkissä on vain yksi kirjaus, joka on tallennettu konekäsiteltävään entry-elementtiin. Kirjauksen classcode on OBS (Observation, eli havainto), jonka moodcode on EVN (Event, eli tapahtunut). Se mitä on tapahtunut, on esitetty SNOMED CT -sanastolla. Mittauksen aikaleima on effectivetime-elementissä ja mittauksen tulos sekä mittayksikkö value-elementissä. 4.3 Mallineet Kirjassa [2] esitellään CDA:n mallineet (Templates), joilla CDA:n laajaa käyttöaluetta rajoitetaan tiettyyn käyttötapaukseen, kuten kotiutusraporttiin. Malline on kokoelma rajoituksia CDA RMIM-malliin. Mallineita on erilaisia: toteutusohjeessa voidaan kertoa sanallisesti esimerkiksi legalauthenticatorelementin pakollisuudesta, pakollisuus voidaan esittää Schematron-tarkistuksella tai voidaan tehdä uusi RMIM, jossa legalauthenticator-elementti on merkitty pakolliseksi. Mallinetta käyttävä dokumentti on validi CDA-dokumentti. Mallineelle voidaan antaa UUID- tai paikallisesti määritetty tunniste, jota käytetään templateid-elementeissä. templateid on yksi RIM:n piilotetuista attribuuteista ja sitä voi käyttää kaikissa RIM-luokissa. Malline voidaan asettaa koko dokumentille otsakkeen alussa tai vain sen osalle, kuten section- ja entry-elementille. Dokumentissa voi käyttää useaa eri mallinetta samanaikaisesti. Kokoelmaa mallineita, jotka yhdessä määrittelevät tietyn dokumenttityypin, kutsutaan profiiliksi. 10

14 Kirjan mukaan useimmat mallineet on toteutettu Schematronilla ja niitä käytetään pääasiassa CDA-dokumenttien ilmentymien validointiin. Continuity of Care Document (CCD), Consolidated CDA (C-CDA) [10] ja Suomessa käytetyn Kanta-järjestelmän dokumentit [13] ovat esimerkkejä mallineiden käytöstä. CCD:n tarkoitus on kertoa tarvittavat tiedot potilaan hoidon jatkamiselle toisessa hoitopaikassa. C-CDA:n tarkoitus on luoda yksinkertaisempi toteutustapa sen määrittelemille dokumenttityypeille sekä toimia yksiselitteisenä lähteenä mallineille. 4.4 Allekirjoitus Yksi kliinisten dokumenttien perusvaatimuksista on allekirjoitettavuus. Digitaalisille dokumenteille sopii digitaalinen allekirjoitus. Aihe esitellään dokumentissa [10], joka käsittelee C-CDA:ssa käytettyä allekirjoitustapaa. CDA-dokumentin allekirjoitus on toteutettu XML Advanced Electronic Signatures (XAdES) -tekniikalla. Tarkempi tekniikan versio on XAdES Extended Long-term (XAdES-X-L), joka lisää tuen pitkäaikaiselle allekirjoituksen tarkistukselle. Tarkistukseen käytetään muun muassa aikaleimoja, varmenteita ja peruutuslistoja. Allekirjoitustieto sijaitsee otsakkeen legalauthenticator ja/tai authenticator -elementtien lapsessa, sdtc:signaturetext -elementissä. Tällaisista eri nimiavaruuteen kuuluvista elementeistä mainitaan tarkemmin kappaleessa 4.6. Allekirjoitustapoja on kaksi: valtuutettu henkilö voi allekirjoittaa dokumentin tai hän voi antaa allekirjoitusoikeuden kolmannelle osapuolelle, joka voi allekirjoittaa dokumentin hänen puolestaan. Keskitymme pääasiassa ensimmäiseen tapaukseen. Saman dokumentin voi allekirjoittaa useampikin henkilö. Valtuutettu allekirjoittaja todistaa dokumentin sisällön oikeaksi allekirjoituksellaan. Allekirjoitettu dokumentti lähetetään vastaanottajalle, joka voi tarkistaa allekirjoituksen. Allekirjoituksen oikeellisuudella varmistuu, että allekirjoittaja on hyväksynyt dokumentin sisällön eikä dokumenttia ei ole muutettu sen jälkeen. Allekirjoittajalla on oltava X.509v3-varmenne allekirjoitusta varten. Varmenne hankitaan varmenteita myöntävältä organisaatiolta (Certificate Authority, CA). Allekirjoittaja luo allekirjoitusrakenteen (Digital Signature artifact), johon sisältyy hänen roolinsa, allekirjoituksen tarkoitus sekä allekirjoitusaika. Rakenne sijoitetaan sdtc:signaturetext-elementtiin. Mikäli dokumentin allekirjoittaa kolmas osapuoli, valtuutettu allekirjoittaja luo toisenlaisen allekijoitusrakenteen (Delegation of Rights assertion) ja varmistaa sen oikeellisuuden ennen allekirjoitusta ja välitystä kolmannelle osapuolelle. Tämän avulla kolmas osapuoli voi allekirjoittaa dokumentin. Allekirjoitus koskee koko dokumenttia, dokumentin ClinicalDocumentaloitus- ja lopetuselementit mukaan lukien, paitsi otsakkeen legalauthen- 11

15 ticator ja authenticator -tietoja. Ne jätetään pois tiivistettä laskiessa. Näin dokumentti voidaan allekirjoittaa useampaan kertaan ilman, että edelliset allekirjoitukset muuttavat tiivistettä. Jos tiiviste muuttuu, edellisiä allekirjoituksia ei pystytä tarkistamaan. Allekirjoitukseen sisältyy aikaleima, jonka avulla allekirjoitusjärjestys on havaittavissa. XAdES-X-L -allekirjoitukseen sisällytetään allekirjoittajan julkinen X.509- v3-varmenne sekä tiiviste dokumentista ilman legalauthenticator ja authenticator -tietoja. Yksityisellä avaimella allekirjoitetaan tiiviste, aikaleima, rooli, allekirjoituksen tarkoitus sekä peruutuslista. Allekirjoituksen rooli poimitaan Healthcare Taxonomy Data Set tai Personal and Legal Relationship Role Type -sanastoista. Allekirjoituksen tarkoitus on esimerkiksi dokumentin laatijan, todistajan, tulkin tai hallinnollisen henkilön allekirjoitus. sdtc:signaturetext-elementti on määritelty Consolidated-CDA R2:ssa. Elementti sisältää teksti- tai multimediamuotoisen esityksen allekirjoituksesta. Luettavaksi tarkoitetun tekstimuotoisen allekirjoituksen tulisi sisältää tieto digitaalisesta allekirjoituksesta, allekirjoittajan nimi, aikaleima, allekirjoittajan rooli sekä allekirjoituksen tarkoitus. Allekirjoitus kuvaa vastuuta dokumentin sisällöstä. Esimerkiksi allekirjoitus olisi Digitally signed by Authorized Signer John Doe on 4/21/2013 at 15:30 EDT as Physician for the purpose of Author s signature.. Kun allekirjoituksen oikeellisuus tarkistetaan, ensimmäisenä tutkitaan allekirjoittajan julkista X.509v3-varmennetta. Varmenteesta tarkistetaan muun muassa sen voimassaolo allekirjoitushetkellä, varmenneketjun oikeellisuus sekä peruutuslistat. Seuraavaksi tarkistetaan allekirjoitusaika, allekirjoittajan rooli ja allekirjoituksen syy. Viimeiseksi puretaan allekirjoitettu tiiviste allekirjoittajan julkisella avaimella, lasketaan uusi tiiviste dokumentista ja verrataan tiivisteitä keskenään. Tiivisteiden vertailulla todetaan, että dokumentin sisältöä ei ole muutettu ja että allekirjoittajan henkilöllisyys on oikein. Jos jokin kohdista epäonnistuu, allekirjoitusta ei voi todentaa oikeaksi. Useampi henkilö voi allekirjoittaa dokumentin, jolloin otsakkeeseen lisätään useampi authenticator-elementti. Esimerkiksi leikkauksessa kirurgi, nukutuslääkäri ja hoitaja voivat allekirjoittaa dokumentin. Tällöin kirurgin tiedot tulevat legalauthenticator-elementtiin ja nukutuslääkärin ja hoitajan tiedot authenticator-elementteihin. LegalAuthenticator allekirjoittaa viimeisenä ja hän on laillisessa vastuussa dokumentista. 4.5 Dokumenttien lukeminen Dokumentti on hyödyllinen vain jos se luetaan, mainitaan kirjassa [3]. Yleinen tapa on luoda koneen muistiin CDA-olio, jonka tietueet täytetään CDAdokumentin tiedoilla ja sen jälkeen käyttää oliota metodikutsuilla. Tarkoitukseen on tehty esimerkiksi avoimen lähdekoodin CDAPI-projekti. Myös ohjelmointikielten yleisillä XML-työkaluilla voi käsitellä CDA-dokumentteja. 12

16 XML Path Language (XPath) on työkalu navigointiin XML-dokumentissa. XPath-kyselyillä voi poimia tietoja elementtien attribuuteista ja sisällöstä. Haasteena XPathin käytössä on kontekstin levittäytyminen, eli esimerkiksi section-elementissä määritetty author-tieto koskee myös entrylapsielementtejä. Läpikäyntiä varten vaaditaan monimutkainen kysely. Esimerkiksi kysely ancestor-or-self::*[cda:author][1]/cda:author kohdistettuna entry-elementtiin tarkoittaisi, että etsi lähin elementti, joka sisältää vähintään yhden author-elementin ja listaa sen sisältö. Kysely ei kuitenkaan toimi, jos kontekstin levittäytyminen on dokumentissa erikseen kielletty, jolloin täytyy tehdä useampi XPath-kysely, käyttää XPath 2.0 -kyselyä tai käyttää XQuery-kyselyä. XML Stylesheet Language for Transformation (XSLT) on tekniikka, jota käytetään CDA-dokumenttien näyttämiseen, sisällöntarkistukseen sekä muunnoksiin. Muunnokset voivat olla muista XML-muotoisista tiedostoista CDA-dokumenteiksi tai toisin päin, esimerkiksi CDA-dokumentti (X)HTML-muotoon. Yleisin tapa näyttää CDA-dokumenttia onkin muuttaa se (X)HTML-muotoiseksi. Text-elementeissä käytetty HTML:n kaltainen syntaksi on helposti muutettavissa HTML-syntaksiksi. Kuva 4: Section-elementin muunnos XSLT-tekniikalla HTML-muotoon [3]. 13

17 XSLT:llä määritetään kaavoja elementeille, joiden ilmentymät etsitään XPath-kyselyillä, ja kerrotaan niiden haluttu lopputulosmuoto. Kuvassa 4 on XSLT-esimerkki, joka muuttaa section-elementin HTML-muotoon ihmiselle näytettäväksi. xsl:template-elementti sisältää kaavan tehtävistä toimenpiteistä, kun match-attribuutissa annettu elementti tulee vastaan dokumentissa. Esimerkissä HL7 V3 -elementit ovat cda-nimisessä nimiavaruudessa. xsl:variable-elementissä lasketaan tunnistenumero HTML div-elementille, mikä on valinnaista. Koodi luo ensin div-elementin jokaiselle sectionille, minkä sisään luodaan erilliset div-elementit otsikolle ja sisällölle. Sisällössä tulostetaan ensin sectionin text-elementin sisältö ja sen jälkeen kutsutaan rekursiivisesti kaavaa lapsielementeille. Esimerkin jälkimmäinen kaava kutsuu erillisiä kaavoja text-elementin sisältämille HTML:n kaltaisille rakenteille niiden muuttamiseksi HTML-muotoon, mutta näitä muunnoksia esimerkki ei käsittele. 4.6 Dokumentit paikallisissa järjestelmissä Paikallisessa järjestelmässä CDA:ta voi käyttää eri tavoin, kuten artikkelissa [4] kuvataan. Dokumentit voidaan tallettaa suoraan CDA-muodossa tai järjestelmän omassa muodossa, josta dokumentti muutetaan CDA-muotoon siirtoa varten. Jos dokumentit tallennetaan suoraan CDA-muodossa, CDA:n on tuettava kaikkia paikallisia vaatimuksia. Tätä varten CDA-dokumenttiin voi lisätä paikallista semantiikkaa. Standardissa [6] selvitetään teknisesti, että on sallittua sisällyttää ylimääräisiä elementtejä ja attribuutteja, joita ei ole CDA:n skeemassa. Nämä eivät kuitenkaan saa muuttaa tavallisien elementtien ja attribuuttien merkitystä. Erotteluun voi käyttää eri nimiavaruutta. Paikallisia lisäyksiä ei kuitenkaan saa laittaa ED-tietotyypin kenttiin, kuten text-elementtiin, sillä sen sisältö oletetaan olevan HL7:n nimiavaruudessa. Paikallinen sisältö on kirjattava siten, että dokumenttia näytettäessä ihmiselle paikalliset merkinnät on voitava jättää näyttämättä. Jos paikalliset dokumentit muutetaan CDA-muotoon, kaikki vaadittava tieto on löydyttävä paikallisista dokumenteista. Paikallinen semantiikka tulisi siirtää myös CDA-dokumenttiin aina kun se on mahdollista. Muunnosta varten voi käyttää tehtävään tarkoitettuja muunnoskieliä tai muunnoksen voi tehdä perinteisillä ohjelmointikielillä. Muunnoskielissä on aina rajoituksia. Esimerkkejä helpoista muunnoksista ovat erilaiset elementtien järjestykset ja nimet sekä sanastot ja tietotyypit. Vaikeampia muutoksia ovat vaadittujen tietojen puuttuminen (esimerkiksi dokumentin tunnisteen), ja tiedon suurirakeisuus (esimerkiksi paikallisessa järjestelmässä talletetaan potilaan nimi yhteen kenttään ja CDA:ssa pitäisi tallettaa erikseen etunimi ja sukunimi). 14

18 CDA-dokumentteja luovat lisääntyvissä määrin erilaiset ohjelmistot ja laitteet. Esimerkiksi sanelimet, potilastietojärjestelmät ja XML-lomakeohjelmistot voivat tuottaa CDA-dokumentteja. CDA-dokumentin luomisen uuden tai muunnoksen alkuvaiheessa täytyy selvittää, miten mallinnettava tieto suhtautuu RIM:n rakenteisiin, sanastoihin ja tietotyyppeihin. Koska CDA on niin monipuolinen ja laaja, tiettyyn tarkoitukseen tulevaa dokumenttia varten voidaan tehdä malline. Standardi ei määrittele, miten dokumentit luodaan tai miten niitä hallitaan, vaan ainoastaan niiden sisällön merkkaustavan. 4.7 Vaatimustasot Artikkelissa [5] on esitelty lyhyesti CDA:n historiaa ja tasoja. CDA R1 julkaistiin vuonna 2000 ja se sisälsi tasot 1 ja 2. Vuonna 2005 julkaistun ja tason 3 sisältävän CDA R2:n tavoite on koodata dokumentin sisältöä koneellisesti käsiteltävämpään muotoon [2]. Artikkeli [4] kertoo CDA:n tasoajatuksesta. CDA:ssa on hierarkkisia tasoja, mitä nimitetään arkkitehtuuriksi (architecture, CDA:n A-kirjain). R1- dokumentissa ainoastaan otsake perustuu RIM-tietomalliin ja rungon sisältö on enimmäkseen ihmisen käsiteltäväksi tarkoitettua. R2-dokumentin otsake ja runko perustuvat RIM-tietomalliin. Runko voi olla taaksepäin yhteensopivaa ihmisen käsiteltävää dataa, tai se voi koostua section-elementeistä, joissa voi olla koneellisesti käsiteltävää tietoa. CDA R3 on kehityksen alla ja se kattaa ihmisten lisäksi mm. eläimet [3]. Tasoilla saadaan aikaiseksi hellävarainen johdatus RIM-tietomalliin ja standardin käyttöönotto on helppoa. Konekäsiteltävää tietoa voi lisätä omaan tahtiin. Itse dokumenttien sisältö on sama eri tasoilla. Dokumentista voidaan tehdä eritasoisia, samasisältöisiä, versioita, joiden ainoa ero on konekäsiteltävän tiedon ja rajoitteiden määrä. Esimerkkejä tasoista on esitelty kirjassa [2]. Tason 1 runko voi olla esimerkiksi PDF-dokumentti, valokuvatiedosto tai tekstiä. Tason 2 runko-osa koostuu section-elementeistä, joille on määritetty koodi sanastosta. Elementtien luonnollisella kielellä kuvatun sisällön tyyliin ei puututa. Tasossa 3 section-elementin sisältämät kirjaukset on myös HL7 V3 -tyylisesti koodattuna. Taso voidaan ylittää, eli tason 2 dokumentissa on sallittua koodata yksittäisiä kirjauksia tarkastikin. 4.8 Versioiden eroavuudet CDA R2:n standardissa [6] mainitaan järjestelmien päivitystä silmälläpitäen eroja R1-versioon nähden. Erojen tietäminen helpottaa eri-ikäisten artikkeleiden lukemista. Muutamat elementit ovat muuttaneet nimeä. Esimerkiksi section-elementtien otsikko on R1:ssä caption-elementti ja R2:ssa se on title-elementti. R1:ssä 15

19 ihmisen luettavaksi tarkoitettu tekstisisältö kirjoitetaan suoraan sectionelementin sisälle ja R2:ssa teksti kirjoitetaan section-elementin lapsen, pakollisen text-elementin, sisälle. Elementtinimet kirjoitetaan R1:ssä snake_case:lla ja R2:ssa CamelCase:lla. Kehitystä on tapahtunut mm. tietotyypeissä. R2 käyttää HL7 Version 3 tietotyyppejä, kun taas R1 käyttää abstrakteja sekä XML:n tietotyyppejä. 4.9 Kritiikki ja parannusehdotukset HL7:n kehittämät ratkaisut kohtaavat myös kritiikkiä. Artikkelissa [8] kritisoidaan HL7:n käyttämää mallinnustapaa. Artikkelin mukaan HL7-organisaatiossa ei ole kattavaa osaamista mallinnuksesta tai UML-kielestä (Unified Modeling Language). HL7 käyttää UML:n kaltaisia malleja, jotka eivät ole yhteensopivia muiden UML:llä kehitettyjen mallien ja ohjelmistojen kanssa. RIM:n Entity-luokka ei sovellu käsitemallinnukseen, sillä kaikki luokat ovat entiteettejä. Myöskään ihmisten ja esineiden yhdistäminen samaan luokkaan ei ole semanttisesti kovin tarkkaa. Olion tila on piilotettu moodcodeattribuuttiin, joka olisi voitu esittää selvemmin UML:n tiladiagrammilla. Luokkien väliset yhteydet ovat monimutkaisia esittää yhteysluokkien avulla ja UML:llä yhteydet olisi voitu esittää paljon pienemmällä luokkamäärällä. Tietoturvan mallinnus, esimerkiksi että lääkärit saisivat muuttaa potilaidensa tietoja ja potilaiden tulisi saada ilmoitus kun heidän tietojaan katsellaan, on UML:llä suoraviivaista, mutta RIM-tietomallilla esitettynä vaikeaa. Dokumentaatiota moititaan monimutkaiseksi ja vaikeaselkoiseksi. Vaikka kirjassa [2] seikkaa ei esitetä kritiikkinä, mainitaan, että HL7 Version 3:n dokumentaatio on valtava. Standardin perustadokumentit, jotka käsittelevät muun muassa tietotyyppejä, RIM-tietomallia ja XML-tekniikoita, sisälsivät vuonna 2008 yhteensä sanaa. Näiden lukemiseen menisi noin 30 tuntia, jos lukee 200 sanaa minuutissa. Perustadokumenttien lisäksi on 30 tai yli toimialakohtaista standardia, joihin lukeutuu myös CDA. Kirjassa [3] mainitaan, että kun dokumentin runko-osana käytetään vain ihmisen käsiteltäväksi tarkoitettua dataa, on elementin nimi NonXML- Body kuvaava, sillä se ei saa sisältää XML-sisältöä. Rajoitus on kirjattu standardiin siksi, että XML-sisältö on muutettavissa koneen käsiteltäviksi section-elementeiksi. NonXMLBody-elementtiin saa kuitenkin tallentaa HTML-muotoista tietoa, vaikka se on muunnettavissa XML-muotoiseksi. Sen sijaan XML-muotoon voi tallentaa muitakin kuin dokumentteja, kuten Scalable Vector Graphics (SVG) -kuvatiedostoja, joille muunnos ei ole helppoa. Täten esimerkiksi SVG-muotoista sydänsähkökäyräkuvaa ei standardin mukaan saa tallentaa NonXMLBody-elementtiin, mutta binäärimuotoisen pakatun SVG-tiedoston (SVGZ) voisi tallentaa. Kehitysehdotuksena rajoittimeksi voisi laittaa, että ainoastaan tiedostoja MIME-tyypillä text/xml ei saisi tallentaa NonXMLBodyyn. 16

20 Artikkelissa [5] muistutetaan, että työ on vielä kesken. Esimerkiksi yksi vaiva voidaan kertoa eri tavoilla ja koodistoilla, mutta tietokone ei välttämättä ymmärrä eri koodien tarkoittavan samaa asiaa. 5 Sovellus: Kansallinen Terveysarkisto (Kanta) Artikkeli [16] esittelee Suomessa käytettyä Kansallinen Terveysarkisto (Kanta) -järjestelmää. Suomessa julkisia terveydenhoitopalveluita tuotetaan paikallisissa hoitopaikoissa ja terveydenhoitojärjestelmä on pääosin maantieteellisesti organisoitua. Erityisosaajien tulisi tehdä yhteistyötä maantieteellisestä sijainnista huolimatta, joten potilaan tietojen jako on keskeisessä osassa. Potilaiden terveystiedot ovat pääosin sähköisessä muodossa ja niitä säilytetään hoitoyksiköiden paikallisissa järjestelmissä. Eri alueiden järjestelmät eroavat toisistaan, sillä ne ovat eri toimittajien eri ohjelmistoja. Nämä ohjelmistot ovat usein semanttisesti yhteensopimattomia ja yhteistyö Internetin välityksellä on harvinaista. Suomessa on kehitetty järjestelmiä terveystiedon jakamiseen jo vuodesta 1998 alueellisilla ratkaisuilla. Näissä ratkaisuissa keskitettyyn rekisteriin tallennetaan metadataa varsinaisen dokumentin hakuun paikallisesta järjestelmästä. Vuonna 2007 Sosiaali- ja terveysministeriö aloitti projektin keskitetyn terveystietoarkiston rakentamiseksi. Järjestelmän tarkoituksena on luoda helppokäyttöinen, ajantasainen ja semanttisesti yhteensopiva arkisto potilastiedoille. Järjestelmä pohjautuu HL7 CDA R2 -standardiin. Projektia koordinoi Sosiaali- ja terveysministeriö ja projektin toteutuksesta vastaa Kela. Kanta-konseptin keskeinen ajatus on varastoida ja hallita kansallista terveystietoa keskitetysti. Järjestelmää käyttävät paikalliset potilasrekisteriohjelmat, lääkejärjestelmät sekä kansalaiset web-portaalin välityksellä. Kolme ensimmäistä käyttökohdetta ovatkin potilastietojen arkisto, sähköinen resepti ja kansalaisten käytettävä verkkoportaali terveystiedon noutoon. Arkistoidut tiedot ovat pääosin katsottavissa koko potilaan eliniän. Koska potilaan historiatieto on myös ammattihenkilöiden nähtävissä, aiemmin tehtyjä tutkimuksia ei enää turhaan toisteta. Kanta-järjestelmällä semanttinen yhteentoimivuus saavutetaan keskitetyllä tietomallilla. Tallennettavan dokumentin täytyy noudattaa Kantan CDA R2-pohjaista tietomallia, eli mallinetta. Tallennuksen yhteydessä dokumentti tarkistetaan ja tallennus onnistuu vain jos tieto on mallin mukaista. Näin toimien Kantaan tallennettu tieto on yhdenmukaista. Kanta-järjestelmä perustuu SOA-malliin, eli hajautettuun järjestelmään, jossa ominaisuudet/kyvyt on hajautettu osiin, joita ohjaavat mahdollisesti eri tahot. Näin saadaan modulaarisuutta, uudelleenkäytettävyyttä ja skaalautuvuutta. Kokoelma ohjelmistomoduuleita on järjestetty itsenäisiksi osiksi, 17

21 jotka koteloidaan palveluiksi tarjoamaan varsinaista toiminnallisuutta. Esimerkiksi käyttäjän tunnistaminen, arkistointi ja lokikirjanpito on koteloitu erillisiksi palveluiksi. Palvelut pohjautuvat Web Service -tekniikkaan. Web Service:t on määritelty Web Services Description Languagella (WSDL) ja siihen liittyvällä XML Schema Definitionilla (XSD) Web Services Interoperability Organizationin Basic Profile 1.1 -standardin mukaisesti. WSDL kuvaa Web Servicesin käytön ja XSD viestin sisällön, mukaan lukien CDA:n. Kanta-palvelut ovat arkkitehtuurin ydin. Viestirajapinta on toteutettu HL7 v3 -viesteillä, jotka kuljettavat CDA-dokumentteja. Turvallisuudesta huolehditaan tunnistautumisella ja pääsynvalvontakerroksella. Tunnistautuminen ja XML-dokumenttien allekirjoitus perustuu julkisen avaimen infrastruktuuriin (PKI) ja älykortteihin. Yhteydet on suojattu SSL-tekniikalla. Kun vastaanotettu dokumentti on tarkistettu sisällöllisesti ja todennettu, se tallennetaan potilastietoarkistoon tai reseptiarkistoon riippuen sen tyypistä. Kanta käyttää sanastoa koodien yhtenäistämiseksi ja kirjoitusvirheiden välttämiseksi. Koodit tarkistetaan koodipalvelussa. Kaikki viestit kirjataan keskitettyyn lokipalveluun, joka tallettaa yksityiskohtaista tietoa luonti-, muokkaus- ja lukutapahtumista. Suomessa potilastietoa voidaan lukea vain potilaan suostumuksella, joten palvelu suostumuksien hallintaa varten on olemassa. Kanta-järjestelmään kuuluu myös taustapalveluita koodistoja ja varmenteita varten. Taustapalveluita ylläpitävät itsenäiset kansalliset viranomaiset, jotka muun muassa myöntävät henkilökohtaiset varmenteet dokumenttien allekirjoitukseen sekä ylläpitävät estettyjen varmenteiden listaa. 5.1 Kanta-järjestelmän hyödyt On haaste luoda semanttista yhteensopivuutta potilastietojärjestelmiin kansallisella tasolla. Kantaan keskitetysti tallennettu tieto mahdollistaa sen. Semanttinen yhteensopivuus perustuu CDA-standardiin, joka kuvaa dokumentit rakenteisessa muodossa. Rakenteen kaikki elementit on selvästi määritetty. Esimerkiksi potilaan nimen elementit on määritelty dokumentaatiossa, joten kaikki järjestelmät tietävät sen tarkan sijainnin ja tarkoituksen Kantan mallineessa. Näin Kanta luo semanttista yhteentoimivuutta eri järjestelmien välille, sillä niiden on noudatettava yhteistä tietomallia. Koska CDA on kansainvälinen standardi, siihen on tehty monia muutoksia, jotta semantiikka on saatu vastaamaan Suomen terveydenhuoltoa. Myös Kantan tietomallia on päivitetty projektin kuluessa. CDA-standardi tarjoaa mahdollisuuden luoda dokumentit haluamallaan tarkkuudella. Kantassa dokumentit ovat hienorakeisia ja ihmisen luettavaksi tarkoitetut tekstiosiot ovat hyvin pieniä. Näin tiettyyn hoitoon tarvittavat tiedot on helposti haettavissa tavallisilla XML-jäsentimillä. Suuremmalla rakeisuudella, eli suuremmilla kirjausosioilla, tiedon haku koneellisesti hankaloituisi. Valittu taso mahdollistaa tietojen käytön myös tulevaisuudessa. 18

22 Keskustelua herättää, että onko tiedon keskitetty arkistointi oikea ratkaisu vai pitäisikö tietoja säilyttää paikallisissa potilastietojärjestelmissä. Toinen asia on dokumenttien hienorakeisuus. Jos kokonaisten dokumenttien haku riittää ilman automaattista käsittelyä, niin dokumenttien haku paikallisista järjestelmistä olisi helppoa. Automaattiseen käsittelyyn tarvitaan semanttista yhteensopivuutta sekä hienorakeisuutta. Tiedon hienorakeisuus mahdollistaa uusia mahdollisuuksia terveystiedon hyödyntämiseen. Kun tietoa kerätään kansallisesti, voidaan seurata koko kansan terveydentilaa ja sen kehitystä. Tilastollisin menetelmin voisi keskittyä tiettyjen parametrien seuraamiseen, kuten verenpaineeseen. Yksittäisiä kansalaisia voisi auttaa hänen omista tiedoistaan johdetut tautiriskit, mikä auttaisi tautien ennaltaehkäisyssä. Tällaisia tautien ennaltahavaitsemisjärjestelmiä on todennäköisesti tulossa lähitulevaisuudessa. Ne voivat käyttää Kantan tietoa terveydenhoidon kustannusten pienentämiseksi. Kantan tieto voi auttaa myös hoidon laadun parantamisessa sekä tutkimuksissa. 5.2 Dokumentin otsake Aivan kuten yleinen CDA-dokumenttikin, Kantan earkisto-dokumentti koostuu otsakkeesta ja runko-osasta. Tähän lukuun on koottu eroavaisuuksia yleiseen CDA-dokumenttiin verrattuna. Otsakkeen määrittely on kuvattu dokumentissa [13]. Otsake perustuu HL7:n määritelmään Yhdysvaltojen käyttämästä järjestelmästä, johon on tehty muutoksia huomioiden muun muassa Suomen lait ja asetukset. Dokumentteja on kahdenlaisia: palvelutapahtumia ja kertomusasiakirjoja. Palvelutapahtumassa ei ole varsinaista runko-osaa, vaan tieto koostetaan monesta asiakirjasta. Dokumenttia varten on tehty viralliset tyylitiedostot, joita ei ole tarkoitettu loppukäyttäjille, vaan dokumentin tarkastusta varten. Myös XML-skeema paikallisin elementein on tehty. XML-nimiavaruuksina käytetään tavallista XML Schemaa, yleistä HL7 v3-nimiavaruutta sekä paikallista hl7finlandnimiavaruutta. Dokumentin templateid:t kertovat, mihin määrityksiin otsake ja runkoosa perustuvat. Elementissä määritetään myös käytetty versio. Yhdellä dokumentilla on useampi templateid. Dokumentille on määritettävä potilasrekisteritunnus. Tunnus on codeelementti, joka kertoo mihin henkilörekisteriin dokumentti kuuluu. Henkilörekistereitä ovat esimerkiksi julkinen ja yksityinen terveydenhuolto sekä työterveyshuolto. Arvo noukitaan KanTa-palvelut Potilasasiakirjan rekisteritunnus -sanastosta. Sanastojen sisällöt löytyvät Terveyden ja hyvinvoinnin laitoksen (THL) ylläpitämästä kansallisesta koodistopalvelusta. Rekistereiden välisessä tiedonsiirrossa täytyy huomioida luovutukseen liittyvät seikat. Dokumentille annetaan otsikko, joka on joko Potilasasiakirja, Palvelutapahtuma-asiakirja tai tarkempi otsikointi. Potilasasiakirja-otsikkoa käytetään, kun dokumentti sisältää erinäistä tietoa, eli eri näkymiä. Jos 19

23 dokumentti sisältää yhdenlaista tietoa, käytetään kyseisen näkymän nimeä otsikossa, kuten Lääkärintodistus A. Dokumentin luottamuksellisuus, eli confidentialitycode-elementti, noudattaa Julkisen hallinnon tietohallinnon neuvottelukunnan JHS-suositusta 143. Dokumentin julkisuuden määrää lainsäädäntö. Salassa pidettävään tietoon liittyy käyttörajoituksia. Elementti saa arvon väliltä 1-5, eli erittäin salaisesta terveydenhuollon salassa pidettävään dokumenttiin. Kantaan tallennetun dokumentin copytime-elementti, joka ilmaisee dokumentin alkuperäisyyden, on tyhjä. Kun dokumentti kopioidaan paikalliseen järjestelmään, elementtiin sijoitetaan aikaleima. Kanta tarkistaa tiedon avulla, ettei samaa dokumenttia tallenneta uudelleen. RecordTarget-elementtiin kirjataan ainoastaan potilaan tiedot. Tunnistukseen käytetään ensisijaisesti henkilötunnusta ja varmennukseen nimeä, sukupuolta ja syntymäpäivää. Henkilötunnuksen asemesta voi käyttää tilapäistä yksilöintitunnusta, jolloin käytetään OID-tunnusta. Potilaan nimi merkitään oikeassa järjestyksessä ja kukin nimen osa omassa elementissään. Myös kutsumanimi voidaan kirjata. Potilaan syntymäpäivä on pakollinen kaikissa dokumenteissa. Toisen henkilön tunnistetiedot kirjataan participant-elementtiin, mutta he eivät näe dokumenttia omissa tiedoissaan Kanta-palvelussa. Author-elementtiin kirjataan henkilöt, jotka on merkitty runko-osaan MER-roolilla tai palvelutapahtumissa dokumentin luoja. Otsakkeessa on ainoastaan nimi ja tunnistenumero ja tarkemmat tiedot ovat runko-osassa. Tunnisteena käytetään henkilötunnusta, jos se on tiedossa. MER-rooli tarkoittaa merkinnän tekijää ja se on yksi roolitunnuksista, joka poimitaan roolisanastosta. Authenticator ja legalauthenticator -elementit eivät ole käytössä Suomessa. Allekirjoitus sijoitetaan hl7fi-osioon. Palvelutapahtumat kirjataan documentationof-elementtiin toistuvina serviceevent-elementteinä. Elementti koodataan THL:n Terveysalan palveluluokitussanastolla. relateddocument-elementtiä käytetään versiohallinnassa ja palvelutapahtumien linkitys on hl7fi-osiossa. Palvelutapahtumadokumentissa componentof-elementtiin kirjataan muun muassa palvelutapahtuman tunnus, aloitus- ja lopetusaikaleima, palvelun tuottajan tunnistetiedot sekä palvelutapahtumaan osallistuneiden hoitopaikkojen tiedot. Otsakkeeseen kootaan paikallista tietoa hl7fi-osioon, sillä kaikelle kerätylle tiedolle ei ole paikkaa CDA-standardissa. Tiedon avulla dokumentteja voi käyttää laajempaan käyttötarkoitukseen. Tieto kootaan otsakkeen loppuun hl7fi:localheader -elementtiin. Elementin validointiin on erillinen skeema. Elementti itse ja sen lapset ovat skeemassa vapaaehtoisia, mutta dokumentaatio määrittää osan niistä pakollisiksi. Tyylitiedoston avulla näytetään tarpeelliset elementit. JHS 143 -suositus asiakirjojen kuvailun ja hallinnan metatiedoista ohjaa osaa paikallisista elementeistä. Tällaisia elementtejä ovat muun muassa hl7fi:declaredtime (arkistointiaika) ja hl7fi:audittrail (muutoshistoria). 20

24 Potilastietojärjestelmän omille tiedoille on varattu tilaa hl7fi:productelementissä, jonka sisältöä muut järjestelmät eivät käytä. Allekirjoituksen paikka on hl7fi:signaturecollection-elementissä ja sähköisen allekirjoituksen määrittelee erillinen määritys ja soveltamisopas. hl7fi:encompassingencountermastercode-elementtiin kirjataan, onko dokumentti palvelutapahtuma- vai hoitodokumentti. Tietyt kuvailutiedot kirjataan ainoastaan palvelutapahtumadokumenttiin, joka arkistoidaan ensin. Arkistoinnin jälkeen Kanta kopioi palvelutapahtumadokumentista tietoja hoitodokumentteihin. Dokumentin katseluoikeutta web-portaalin kautta voi viivästyttää hl7fi:- releasedateforpatientviewing-elementillä. Joskus on tarvetta estää potilasta katselemasta tietoa, esimerkiksi jos siitä voi aiheutua vaaraa potilaan terveydelle. Eston toteuttamismahdollisuus on kirjattu lakiin. 5.3 Dokumentin runko-osa Kantaan talletettavan dokumentin runko-osa esitetään dokumenttissa [11]. Yleisen CDA-dokumentin tapaan pakollista on ihmisen luettavaksi tarkoitettu sisältö (tämän määrittelyn mukainen termi on näyttömuoto). Vain potilaskertomuksen keskeiset tiedot täytyy merkata koneen käsiteltävässä muodossa (määrittelyn termein rakenteisessa muodossa). Nämä tiedot kattavat toteutuneet sekä suunnitellut hoidot ja niiden tietosisältö on sovittu yhteisesti. CDA:n section-elementit koodataan kolmella sanastolla: Näkymät-koodistolla, Hoitoprosessin vaihe -koodistolla ja Otsikot-koodistolla. Jäsennys toteutetaan sisäkkäisillä section-elementeillä, jotka tulostuvat selaimella siististi sisennettyinä kuten kuvassa 5. Kuvassa näkymä (ylin section-elementti) on sisätaudit, jossa on hoitoprosesseina tulotilanne ja hoidon suunnittelu, joiden otsikoita ovat hoidon syy ja esitiedot. Kirjausrakenteessa jokainen eri asia, kuten lääkitys ja laboratoriotulos, kirjoitetaan eri rakenteisiin yksittäisten kirjausten kopiointia ja siirtoa varten. Kertomusasiakirja koostuu merkinnöistä, jotka koskevat samaa potilasta samassa palvelutapahtumassa. Merkintä on yksittäiseen näkymään kirjoitettu kirjaus, laitteen tuottama kuva tai mittaustulos, joka on ammattihenkilön arvioima ja tallentama. Merkintä koostuu näkymätiedosta, hoitoprosessin vaiheesta, otsikoista, ihmisen luettavaksi tarkoitetusta tekstistä sekä valinnaisesta rakenteisesta tiedosta. Merkintä ja sen osat on yksilöitävä OIDtunnuksilla. Potilaan tunniste on sijaittava ensimmäisessä section-elementissä allekirjoitusta varten. Tunniste kirjataan subject-elementtiin. Jos merkintöjä poimitaan esimerkiksi koostedokumenttia varten, tunniste on liitettävä siirrettäviin rakenteisiin. Dokumentin kirjoittajan (määrittelyn termein ammattihenkilö) tiedot periytyvät otsakkeesta, mutta tiedot kirjataan tarkemmin runko-osaan. Ot- 21

25 Kuva 5: Potilasarkiston dokumentti tyylitiedostolla muotoiltuna [11]. sakkeeseen merkittiin ainoastaan MER-roolissa toimineiden tunniste ja nimi. Rooleja ovat merkinnän tekijän (MER) lisäksi muun muassa lääkkeen määrääjä (MÄÄ) ja merkinnän hyväksyjä (HYV). Henkilöstä kirjataan palveluyksikön tiedot ja merkinnän aika. Tiedot eivät ole täysin pakollisia. Ylimmässä section-elementissä, eli näkymässä, on ainakin yksi hoitoprosessin vaihe, johon on kirjattu asiakokonaisuuksia. Hoitoprosessin vaihe sijoitetaan näkymän sisälle alempaan section-elementtiin. Hoitoprosessin vaiheeseen liittyvät asiakokonaisuudet sijoitetaan vielä alempiin section-elementteihin, joihin varsinaiset kirjaukset tehdään. Ihmisen luettavaksi tarkoitetussa sisällössä voi käyttää aiemmin kuvattuja HTML:n kaltaisia rakenteita. Käyttäjän kirjoittamat tekstiosiot merkataan attribuutilla stylecode="xunstructured". Kaikilla sectioneilla on code ja title -elementit. Koneen käsiteltäväksi tarkoitetut tiedot kirjataan tuttuun tapaan entryelementteihin, joita voi olla useita yhtä otsikkoa kohden. Kirjaukset voivat viitata tekstin osiin. Viittauksen voi tehdä dokumentin sisällä sekä myös erilliseen dokumenttiin, jonka täytyy olla tallennettuna Kantaan. Entryelementtiin kirjataan käytetyn mallineen tunniste. Eri kirjaustyypeille, kuten diagnooseille, toimenpiteille ja fysiologisille mittauksille on omat kirjausohjeet dokumentaatiossa. Potilastiedon arkisto tukee ainoastaan PDF-muotoisia kuvia. Palvelutapahtuma-asiakirjan runko-osa sisältää ainoastaan yhden section-elementin, jossa on potilaan tunnistetiedot. 22