Terveydenhuollon dokumenttien arkkitehtuuri

Iivo Raitahila

Kandidaatin tutkielmaHELSINGIN YLIOPISTOTietojenkäsittelytieteen laitos

Helsinki, 8. toukokuuta 2016

Matemaattis-luonnontieteellinen Tietojenkäsittelytieteen laitos

Iivo Raitahila

Terveydenhuollon dokumenttien arkkitehtuuri

Tietojenkäsittelytiede

Kandidaatin tutkielma 8. toukokuuta 2016 26

Kliininen dokumentti, HL7, CDA, Kansallinen Terveysarkisto

Terveydenhuollossa käytetään monenlaisia dokumentteja, joita kutsutaan kliinisiksi dokumen-teiksi, kuten hoitopalautteita ja lääkärin muistiinpanoja. Tutkielmassa selvitetään perinteisestipaperisten ja vapaamuotoisesti kirjoitettujen dokumenttien nykytilaa tietokonejärjestelmissä.Tutkielmassa keskitytään Suomessa käytettyyn HL7 CDA -standardiin. Esitietoina käydäänläpi kliinisten dokumenttien vaatimukset, HL7 RIM-tietomalli ja sanastot. CDA-dokumenttikoostuu loogisesti kahdesta osasta: metadataa sisältävästä otsakkeesta sekä runko-osasta, jossaon varsinainen tietosisältö. Runko-osan tieto on kirjoitettava ihmisen luettavassa muodossaja 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, jotentutkielmassa esitellään muutama XML-tekniikka. Tutkielman lopuksi perehdytään, kuinkaKansallinen Terveysarkisto (Kanta) hyödyntää CDA-standardia.

ACM Computing Classification System (CCS):Information systems → Document representationApplied computing → Health informatics

Tiedekunta — Fakultet — Faculty Laitos — Institution — Department

Tekijä — Författare — Author

Työn nimi — Arbetets titel — Title

Oppiaine — Läroämne — Subject

Työn laji — Arbetets art — Level Aika — Datum — Month and year Sivumäärä — Sidoantal — Number of pages

Tiivistelmä — Referat — Abstract

Avainsanat — Nyckelord — Keywords

Säilytyspaikka — Förvaringsställe — Where deposited

Muita tietoja — Övriga uppgifter — Additional information

HELSINGIN YLIOPISTO — HELSINGFORS UNIVERSITET — UNIVERSITY OF HELSINKI

Sisältö1 Johdanto 1

2 Kliiniset dokumentit 2

3 Terveydenhuollon viitemalli RIM 33.1 RIM-luokkakaavion rakenne . . . . . . . . . . . . . . . . . . . 43.2 Tietotyypit ja sanastot RIM-mallissa . . . . . . . . . . . . . . 53.3 Mallintaminen . . . . . . . . . . . . . . . . . . . . . . . . . . 6

4 Kliinisten dokumenttien CDA-arkkitehtuuri 74.1 Dokumentin otsake . . . . . . . . . . . . . . . . . . . . . . . . 74.2 Dokumentin runko-osa . . . . . . . . . . . . . . . . . . . . . . 94.3 Mallineet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104.4 Allekirjoitus . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114.5 Dokumenttien lukeminen . . . . . . . . . . . . . . . . . . . . 124.6 Dokumentit paikallisissa järjestelmissä . . . . . . . . . . . . . 144.7 Vaatimustasot . . . . . . . . . . . . . . . . . . . . . . . . . . . 154.8 Versioiden eroavuudet . . . . . . . . . . . . . . . . . . . . . . 154.9 Kritiikki ja parannusehdotukset . . . . . . . . . . . . . . . . . 16

5 Sovellus: Kansallinen Terveysarkisto (Kanta) 175.1 Kanta-järjestelmän hyödyt . . . . . . . . . . . . . . . . . . . . 185.2 Dokumentin otsake . . . . . . . . . . . . . . . . . . . . . . . . 195.3 Dokumentin runko-osa . . . . . . . . . . . . . . . . . . . . . . 215.4 Esimerkkidokumentti . . . . . . . . . . . . . . . . . . . . . . . 23

6 Yhteenveto 23

Lähteet 24

ii

1 JohdantoTerveydenhuollossa käytetään monenlaisia dokumentteja, kuten hoitopalaut-teita ja lääkärin muistiinpanoja. Näitä kutsutaan kliinisiksi dokumenteiksi.Perinteiset kliiniset dokumentit ovat ihmiselle luettavaksi tarkoitettuja vapaa-muotoisella kirjoitustavalla kirjoitettuja kertomuksia, joita siirretään muunmuassa postitse ja faxilla.

Tutkielman aiheena on selvittää kliinisten dokumenttien käsittelyn ny-kytilaa tietokonejärjestelmissä keskittyen Suomessa käytettyyn HL7 CDA-standardiin.

Terveydenhuollon viestintä- ja dokumenttistandardeja kehittävä HealthLevel 7 (HL7) -organisaatio on tehnyt standardin kliinisten dokumenttienkäsittelyyn tietokonejärjestelmissä [4]. Artikkelissa [5] esitellään HL7 Cli-nical Document Architecture (CDA) -standardi, joka määrittelee kliinistendokumenttien merkkaustavan, rakenteen ja semantiikan. CDA:n kehityksenideana on luoda koneellisesti käsiteltävä muoto perinteisesti ihmisten luet-tavaksi tarkoitetuista dokumenteista. Koneellisesti käsiteltävän muodon ontarkoitus mahdollistaa dokumenttien sisällön vertailu, tallennus, tiedonsiirtoja hyötykäyttö esimerkiksi päätöksentekoon, vaikka dokumentit on luotuerilaisissa 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öä kattaenkliinisten dokumenttien tarpeet. Semantiikka sekä termistö saadaan HL7 Re-ference Information Model (RIM) -tietomallista, jolloin tietokone voi käsitelläsisältöä, mutta dokumentti voi sisältää vain ihmisen luettavaksi tarkoitettuatietoakin. Täten käyttöönotto ja myöhempi päivitys tietokonekäsiteltäväm-pään muotoon on helppoa. CDA-dokumentti voidaan lähettää viestissä sekäsitä voi säilyttää sellaisenaan.

Tutkielmassa käsitellään ensin kliinisten dokumenttien ominaispiirteetja vaatimukset. Esitietovaatimuksina varsinaiselle sisällölle käsitellään RIM-viitemalli, joka on koko terveydenhuollon kattava tietomalli. RIM:n tieto-tyyppejä varten tutustutaan sanastojen eli koodistojen käsitteeseen. CDA-dokumentti koostuu loogisesti kahdesta osasta, otsakkeesta ja runko-osasta,jotka käsitellään neljännen kappaleen aluksi. Muita olennaisesti CDA-doku-mentteihin liittyviä tekniikoita käsitellään alikappaleissa. Kappaleen lopuksiesitellään lyhyesti CDA:n vanhemman Release 1 ja uudemman Release 2-versioiden eroja sekä CDA:n kohtaamaa kritiikkiä. Tutkielman viimeinenosa esittelee Suomessa käytettyä Kansallista Terveysarkistoa.

1

2 Kliiniset dokumentitKliiniset dokumentit ovat terveydenhuollossa käytettyjä dokumentteja, kutenhoitopalautteita, 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 ovatolleet paperisia ja ihmisen luettavaksi tarkoitettuja kertomuksia.

Kliinisten dokumenttien digitaalisointiin on useita järjestelmiä. Artikkeli[9] kertoo Japanissa vuodesta 1996 alkaen kehitetyistä Medical Markup Lan-guage (MML) -standardeista. MML on CDA:n tapaan XML-pohjainen muotokliinisen tiedon siirtoon. MML:n versio 3.0 perustuu kuitenkin HL7 CDA-standardiin. Kirjassa [2] mainitaan Digital Imaging and Communicationsin Medicine (DICOM) -standardista, jota käytetään kuvien siirtoon. HL7:nstandardit ja DICOM olivat päällekäisiä, sillä myös CDA:ssa voi siirtää kuvia.Nykyään CDA tukee myös DICOM-kuvien siirtoa. Muita dokumenttistandar-deja ovat muun muassa CDISC ODM [7] ja EN13606/OpenEHR [2], muttatutkielmassa keskitytään Suomessa käytettävään HL7 CDA -standardiin. Do-kumentti 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 vaatimuk-set. Kliinisellä dokumentilla on tiettyjä ominaispiirteitä. Kliiniset dokumentitovat pysyviä, eli dokumenttia säilytetään muuttumattomana säädöksienmääräämän ajan (Persistence) ja säilytyksestä vastaa määrätty henkilö taiorganisaatio (Stewardship). Kliinisten dokumenttien kokonaisuus ja oikeel-lisuus on voitava varmistaa lainvoimaisella allekirjoituksella (Potential forauthentication). Dokumentista ei voida irrottaa osia huomaamatta, eli niitäon säilytettävä kokonaisina (Wholeness). Allekirjoitus pätee vain koko do-kumentille. Dokumenttien on oltava muutettavissa ihmiselle lukukelpoiseenmuotoon (Human readability).

CDA:n perusperiaatteisiin kuuluu myös teknisiä seikkoja. Painoarvoannetaan dokumenteille, jotka hoidon antanut ammattihenkilö on tehnyt.Esimerkiksi tutkimukseen ja raportointiin käytetyt dokumentit ovat johdet-tavissa näistä dokumenteista. Standardin käyttöönotto on tehty helpoksimäärittelemällä eri tasoja dokumenteille. Tasojen avuin käyttöönotosta saa-daan helppoa ja teknistä hienostuneisuutta voidaan lisätä myöhemmin. Stan-dardissa on otettu huomioon paikalliset vaatimukset, kuten lainsäädäntö,ilman standardin muokkausta. Tiedon säilymistä tuetaan siten, että CDA-dokumentit ovat ohjelmisto- ja alustariippumattomia, jotta niitä voidaankäsitellä myös tulevaisuudessa. Dokumentteja voi luoda ohjelmointikielienyleisillä XML-työkaluilla tai vaikka tekstinkäsittelyohjelmalla. Myös tiedon-siirto on ohjelmisto- ja alustariippumatonta. CDA-standardi ei ota kantaatiedonsiirtotapaan [6] eikä tiedonsiirtoa juuri käsitellä tutkielmassa. KoskaCDA-dokumentit ovat XML-tiedostoja, niitä voi käsitellä tiedostojärjestel-mässä normaaleina tiedostoina. Siten dokumentteja voi siirtää esimerkiksi

2

tiedostonjakoprotokollilla, muistitikuilla, levykkeillä ja sähköpostissa. HL7on kehittänyt standardin myös tiedonsiirtoa varten.

Dokumentteja voidaan päivittää ja niitä voidaan liittää toisiin dokument-teihin. 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 omattietokannat. Kun ohjelmaan B tehdään liittymä ohjelmaan A, se tehdäänlukemalla 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 senvalitsemassaan kohdassa ja asiayhteydessä käyttöliittymässään. Ongelmiasyntyy 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 suunniteltavayksitellen, 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äyhteenso-pivuus näiden kahden järjestelmän välillä kuin muuttaa organisaation kaikkiajärjestelmiä.

Yleisesti ottaen tietomallia ja tietoarkkitehtuuria voidaan yksinkertaistaa,jotta tietoon päästään helpommin käsiksi ja tiedonjakoa helpotetaan. Tie-tomalli määrittää tiedon, jota järjestelmään voidaan tallettaa. Tietomallinluonti vaatii erityisosaamista koko organisaation tarpeista ja järjestelmistä.Semanttisesti yhteensopivan mallin on katettava organisaation kaikkien tie-tojärjestelmien tarpeet. Esimerkiksi laskutusjärjestelmällä on hyvin erilaisettarpeet kuin tuotetietojärjestelmällä. Yleisen tietomallin vuoksi saatetaanjoutua tekemään kompromisseja ja se saattaa monimutkaistaa vanhojenliittymien käyttöä.

3 Terveydenhuollon viitemalli RIMStandardissa [6] esitelty HL7 Reference Information Model (RIM) on HL7 ver-sio 3 -standardeissa, kuten CDA:ssa, käytetty tietomalli (shared informationmodel). RIM on täsmällisesti määritelty lähde luokille ja attribuuteille. RIMon tekninen kaavio, joka esitetään HL7:n käyttämässä UML:n tapaisessamuodossa. Osa RIM-tietomallia on esitetty kuvassa 1.

Standardissa ja kirjassa [2] RIM esitetään kattavasti. RIM:n tavoite onkattaa koko terveydenhuollon alue yhteentoimivuutta varten. RIM perustuuidealle, jossa kaikki dokumentoitava liittyy tapahtumiin (happenings) jaasioihin, kuten ihmisiin, jotka ovat erilaisissa tekemisissä toistensa kanssa.

3

Kuva 1: Osa RIM-tietomallia.

Tapahtumilla on aikamuoto ja asiat voivat olla erilaisissa rooleissa, kutenihminen 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 ActRe-lationship, Participation ja RoleLink -liitosluokat. Kaikki tapahtumat ovatverbejä vastaavia Act:eja, joihin liittyy Participation-liitosluokan avulla subs-tantiiveja vastaavia Role:ja ja Entity:itä. Tapahtumat voivat liittyä toisiinsaActRelationship-liitosluokan avulla. Pääluokilla on aliluokkia ja esimerkiksiPerson on Living Subject:in aliluokka, joka on Entity:n aliluokka – tätenPerson perii sekä Entity:n että Living Subject:in attribuutit.

RIM määrää jokaiselle luokalleen attribuutit, joita voi käyttää, ja jokai-sella attribuutilla on tietotyyppi. Attribuuteista ja tietotyypeistä muodostuuXML-elementit. Viesti tai dokumentti koostuu attribuuttien osajoukosta,niiden rajoituksista, käytetyistä elementeistä ja toistojen määrästä. Tällaistavalintatoimenpidettä kutsutaan jalostamiseksi (refinement) ja tuloksena onprofiili (profile). Yksi profiilityyppi on Refined Message Information Model(RMIM). RMIM esitetään graafisesti HL7 V3 -notaatiolla, josta muodoste-taan XML-skeema. Käytäntö yhteisen tietomallin rajoittamisesta sovituksiosajoukoksi on laajalle levinnyt eri standardien keskuudessa. Profiilien avullavalvotaan, että asia tulkitaan samalla tavalla eri järjestelmissä.

Strukturoiduilla attribuuteilla määritetään, mitä kukin luokka tarkoittaa

4

viestissä tai dokumentissa. Actin classCode kertoo millaisesta tapahtumastaon kyse, esimerkiksi havainnosta tai lääkkeen annosta ja moodCode kertoo ai-kamuodon, esimerkiksi että lääkettä annettiin. Standardi [6] määrittää, ettäjos CDA:ssa ei ole määritelty jotakin arvoa, käytetään standardin oletusar-voa. Esimerkiksi strukturoitua ClinicalDocument.classCode -attribuuttia eitarvitse erikseen määrittää, sillä sen ainoa sallittu arvo on ”DOCCLIN” jase on samalla oletusarvo.

3.2 Tietotyypit ja sanastot RIM-mallissa

Attribuuttien sallitut arvot määrittää tietotyyppi (Data Type), joita esitel-lään artikkelissa [5]. Tietotyypit ovat HL7 Version 3 -tietotyyppejä, jotkavoivat olla yksinkertaisia, kuten kokonaislukuja tai aikaleimoja, tai ne voi-vat olla monimutkaisempia, kuten koodeja tuetuista sanastoista. JokaisellaRIM:n attribuutilla on aina yksi tietotyyppi.

Dokumentin elementtien sisältö voidaan poimia määritetystä lähteestä elisanastosta tai koodistosta [1]. Sanaston perusidea on yksinkertainen: sanastomäärittelee koodatun kentän sallitut arvot. Esimerkiksi siviilisääty-kentänsallitut arvot ovat erään sanaston mukaan ”naimaton”, ”naimisissa”, ”eron-nut”, ”leski” ja ”asumuserossa”. Sanaston käyttäminen vahventaa kenttiensemantiikan ymmärtämistä ja konekäsiteltävyyttä. Jokainen RIM:n koodattuattribuutti vaatii sanaston määrityksen.

Artikkelissa [15] mainitaan esimerkki sanaston käyttötapauksesta. Jotkutkirjoittavat kaliumin (englanniksi potassium) lyhenteeksi ”pot” ja jotkutkäyttävät sen kemiallista merkkiä ”K”. Kirjoitusasuun sisältyy väärinkäsi-tyksen vaara, jonka voi välttää valitsemalla kaliumin merkintätavan, taitässä tapauksessa koodin, sanastosta. Yksiselitteinen kirjoitusasu on erityisentärkeää tietokonejärjestelmissä.

Osa sanastoista on sisäänrakennettuja. Tuettuja ulkoisia sanastoja ovatmm. Logical Observation Identifiers, Names and Codes (LOINC) sekä Syste-mized Nomenclature of Medicine Clinical Terms (SNOMED CT).

Koodatusta tietotyypeistä selitetään kirjassa [2]. HL7 Version 3 koodatuttietotyypit 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 voidaanmäärittää usealla eri sanastolla. CD sallii post-koordinoitujen koodien käytön.

Standardissa [6] mainitaan, että koodattu attribuutti voi olla muodoltaanCWE (Coded With Exceptions), jolloin koodi poimitaan mieluusti sanastosta,mutta vapaa teksti sallitaan, tai attribuutin muoto voi olla CNE (Coded, NoExtensions), jolloin koodi on poimittava sanastosta. Jokaisella sanastolla onHL7:n määrittämä tunniste ja jokaisella koodilla sanastossa on tunniste.

Logical Observation Identifier Names and Codes (LOINC) -sanasto koos-tuu yli 10 000 nimestä ja koodista [12]. Koodeja käytetään havaintojen tunnis-tamiseen viesteissä eri tietojärjestelmien välillä. LOINC-sanastoa käytetään

5

muissakin standardeissa kuin HL7:n standardeissa. Sanasto on saanut kiitos-ta myös siitä, että se on ilmaiseksi käytettävissä. CDA:ssa LOINC-sanastoakäytetään esimerkiksi Section.code:ssa.

Systematized Nomenclature of Medicine Clinical Terms (SNOMED CT)on maailman laajin kliininen termistö [2]. Se koostuu konsepteista, eli yksit-täisistä tarkoituksista (kuten nuha), kuvauksista konsepteille (kuten nuha,flunssa) ja yhteyksistä (esimerkiksi umpilisäkkeen poisto on leikkaus). Vuon-na 2009 SNOMED CT kattoi 310 000 konseptia, 990 000 englanninkielistäselitettä konsepteille ja 1,38 miljoonaa yhteyttä konseptien välillä. Vertailunvuoksi ICD-10, toinen suorittu termistö, kattaa vain 10 760 konseptia vastaa-vaa luokkaa. Valmiiksi määriteltyjen, pre-koordinoitujen, konseptien lisäksiSNOMED 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 sanastovoidaan valita vapaasti. Kirjassa [3] on esitelty sanastojen käyttöä. Var-sinaisen koodiarvon lisäksi merkitään codeSystem- ja valinnaisesti myöscodeSystemName-attribuutit. CodeSystem on sanaston OID-yksilöintitunnus(object identifier), jolla käytetty sanasto tunnistetaan. OID:n avulla tiedetäänsanastoa hallinnoiva organisaatio ja sanasto tunnistetaan yksikäsitteisesti.CodeSystemName merkitään ihmistä varten esimerkiksi vianetsintää helpot-tamaan. Jos sanastosta on useita versioita, voidaan käytettävä sanastoversiomäärittää codeSystemVersion-attribuutilla.

3.3 Mallintaminen

Kirjassa [3] annetaan ohjeet mallinnukseen. RIM esitetään UML:n kaltaisessamuodossa, jossa pääluokat ja liitosluokat ovat väritetty eri värein. Act-luokkaon punainen, Role-luokka keltainen, Entity-luokka vihreä, ActRelationship-luokka vaaleanpunainen, Participation-luokka sininen ja RoleLink-luokkavaaleankeltainen. Act-luokkaan voi liittää ainoastaan ActRelationship jaParticipation -luokkia, Participation-luokkaan voi liittää vain Role-luokan jaRole-luokan voi liittää vain Entity-luokkaan.

Pääluokat esitetään HL7-kaavioissa suorakulmioina ja liitosluokat nuo-len muotoisina. Nuolet poikkeavat UML-esitystavasta. Luokkien attribuutitmerkitään HL7:n omalla tavalla. Merkinnän ensimmäinen osa on attribuutinnimi. Jos nimen perässä on tähti, attribuutti on sisällytettävä, mutta sevoi olla tyhjä, ellei nimi ole lihavoitu. Kaksoispisteen jälkeinen osa kertootietotyypin 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-tietomal-lista. Samaa luokkaa voi käyttää useamman kerran. Kaikkia luokan attribuut-teja ei tarvitse valita, vaan ainoastaan tarvittavat. Attribuuttien tietosisältöävoi kaventaa, esimerkiksi CD-tietotyyppi voidaan rajoittaa CE-tietotyypiksija käytettävä sanasto voidaan määrittää.

6

Kuva 2: Yksinkertaistettu CDA RMIM.

RMIM-kaaviossa luokan strukturoidut attribuutit määräävät luokan ni-men. Esimerkiksi CDA-dokumentin Act-luokan classCode on ”DOCCLIN” jamoodCode on ”EVN”, joista muodostuu luokan nimeksi ”ClinicalDocument”.Jokaisella luokalla on strukturoitujen attribuuttien määräämä nimi, jotakäytetään XML-esitysmuodossa. XML Schema -kielestä johtuen kahdellasaman nimisellä elementillä on oltava sama rakenne, joten elementin nimi eivoi olla yleisesti esimerkiksi ”act”, vaan esimerkiksi ”observation”. Kuvassa 2on esitetty yksinkertaistettu versio CDA RMIM-kaaviosta, joka on jalostettukuvan 1 yksinkertaistetusta RIM-tietomallista.

Malli voidaan esittää myös taulukkomuodossa, jota kutsutaan Hierarc-hial Message Descriptioniksi (HMD). CDA:n vastaavaa muotoa kutsutaanHierarchial Descriptioniksi, sillä CDA ei ole viesti.

4 Kliinisten dokumenttien CDA-arkkitehtuuriCDA-standardin ensimmäinen versio (Release 1, R1) standardoitiin vuonna2000 ja toinen versio (Release 2, R2) vuonna 2005. Molemmissa versioissaperusajatus on sama, eli dokumentti koostuu otsakkeesta (header) ja runko-osasta (body).

4.1 Dokumentin otsake

CDA-dokumentti alkaa otsakkeella. Otsakkeen tietosisältö ja tarkoitus onselitetty artikkeleissa [4] ja [5]. Otsakkeessa on metadataa dokumentista,kuten sen kirjoittajan ja kohteena olevan potilaan tiedot tunnistusta sekä

7

luokittelua varten. Otsake mahdollistaa dokumenttien hallinnan, säilytyksen,siirron laitosten välillä sekä potilaan sairauskertomuksen kokoamisen.

Otsakkeessa määritetään mm. dokumentin uniikki tunnistenumero, do-kumentin tyyppi (esimerkiksi kotiuttamisraportti), luontiaika, salassapidontaso ja kieli. Runko-osan oletetaan noudattavan otsakkeen asetuksia elleimuuta asetettu, mutta esimerkiksi kieltä voi vaihtaa tietyn osion kohdalla.

Artikkelissa [4] on esitetty otsakkeen rakenne. Näitä tietoja on päivitettyCDA Release 2:n mukaisiksi.

Otsake koostuu neljästä loogisesta osasta. Document information yksilöidokumentin ja sen suhteet muihin dokumentteihin. Encounter data kuvaatapahtuman miljöötä, kuten klinikan sijaintia. Service actors sisältää doku-menttiin liittyvät terveydenhuollon toimijat. Service targets sisältää potilaanja esim. perheenjäsenten tiedot.

Document information sisältää tiedon, että onko dokumentti alkuperäi-nen dokumentti, liite toiseen dokumenttiin vai uusi versio vanhasta doku-mentista. Viittaus tapahtuu relatedDocument-elementillä. Jos dokumenttikorvaa toisen dokumentin, sen uniikki id-elementti vaihtuu, mutta setId-elementin arvo on sama kuin alkuperäisellä dokumentilla ja versionNumber-elementin arvo kasvaa yhdellä. Vanha dokumentti säilytetään. Dokumentillaon pakollinen code-elementti, joka luokittelee dokumentin ja jonka arvosaadaan LOINC-sanastosta. Dokumentille määritetään confidentialityCode-elementissä tietosuojataso. Jos tietosuojataso määritetään otsakkeessa, sepä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, jotkaliittyvät dokumentoidun palvelun tuottamiseen. Näitä ovat esimerkiksi do-kumentin todentajat, kopion vastaanottajat, dokumentin laatija ja puh-taaksikirjoittajat sekä muut ammattihenkilöt. He ovat vastuussa itsenäi-sistä päätöksistään. Todennus tehdään mm. kun paikallisen järjestelmändokumentti muutetaan CDA-dokumentiksi. Dokumentin laatija voi ollaihminen ja/tai kone. Laatija on pakollinen tieto, joka kirjataan author-elementtiin, ja typeCode-attribuutilla ilmoitetaan, onko kyseessä ihminenvai kone. Custodian-elementtiin määritetään organisaatio, joka on vastuussasen säilytyksestä.

Potilaan ja muiden tärkeiden osallistujien tiedot kuvataan Service targets-osassa. Nämä ovat dokumentoitavan asian kohteita ja ne ovat eläviä kohteitatai fyysistä materiaalia. RecordTarget-elementtiin kirjataan tiedot potilaasta,jonka sairauskertomukseen dokumentti kuuluu, ja joka on pääasiallisestihoidon kohteena. Patient-elementtiin kuuluu person-luokalta perittävät tiedotsekä syntymäpäivä ja sukupuolitieto.

Yksinkertaisimmillaan otsake on lyhyt. Pakollisia tietoja ovat tiedostontyyppi (CDA-dokumentti), dokumentin tunnistenumero, dokumentin tyyppi

8

(LOINC-koodi), luontipäivä, turvallisuustaso sekä potilaan, kirjoittajan jasäilyttäjän tiedot. Potilaasta täytyy kirjata ainoastaan tunnistenumero, kir-joittajasta kirjausaika sekä tunnistenumero ja säilyttäjästäkin ainoastaantunnistenumero.

4.2 Dokumentin runko-osa

Dokumentin runko-osassa on varsinainen sisältö ja runko-osa on kuvattu ar-tikkelissa [5]. Otsakkeen tietosisältö ja rakenne on johdettu RIM-tietomallistaja CDA R2 -versiossa myös rungon sisältö voidaan johtaa RIM-tietomallista.

Dokumentin runko-osa voi olla yksi NonXMLBody-elementti, jossa onvain ihmisen käsiteltäväksi tarkoitettua tietoa, tai se voi koostua section-elementeistä. NonXMLBody voi viitata ulkoiseen tiedostoon, mutta Structu-redBody sisältää XML-rakenteet samassa tiedostossa [6]. Jokaisessa section-elementissä on oltava sitä kuvaava ihmisen luettavaksi tarkoitettu text-elementti, kuten ”Ota captopril 25mg PO aina 12 tunnin välein”. Valin-naisia konekäsiteltäviä elementtejä voi olla useita ja ne voi olla johdettuRIM-tietomallista. Äskeiseen text-esimerkkiin liittyvät elementit olisivat mm.effectiveTime (aika), doseQuantity (määrä) ja consumable (valmiste). Oh-jelmistojen 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 onpäivitetty CDA Release 2:n mukaisiksi.

Runko koostuu rakenteista (structures), kuten Section-elementeistä, kap-paleista, listoista ja taulukoista. Näillä osilla on otsikot ja osia voi laittaasisäkkäin. Osat sisältävät kirjauksia (entries), jotka sisältävät tekstiä, multi-mediaa ja sanastoista poimittuja koodeja. Rakenteilla on konteksti, jonkaattribuutit, kuten kieli, periytyvät sisemmille rakenteille ellei attribuuttiapäällekirjoiteta.

Kirjaukset kootaan Section-elementteihin. Sectionilla on otsakkeena title-elementti. Section voidaan koodata yhdellä LOINC-sanaston koodilla, jokatoimii koneelle otsikkona aivan kuten title-elementti ihmiselle. Rakenteensisältö voi olla vapaamuotoista tekstiä paragraph-elementissä. Sisältö voiolla myös taulukko tai lista. Yleisesti ottaen rakenteet ovat samankaltai-sia kuin HTML-rakenteet ja muunnos HTML-muotoon katselua varten onsuoraviivaista.

Rakenteiden sisällä kirjaukset voivat olla content-elementeissä. Content-elementtejä voi laittaa sisäkkäin ja näin teksti voidaan paloitella pieniin täs-mällisesti viitattaviin paloihin. Kirjauksia voidaan koodata entry-elementein,joilla sisällytetään koodeja sanastoista content-elementteihin. Koodien sisäl-lyttämisellä tavoitellaan dokumentin indeksointia, hakua ja standardoidaantapa, jolla merkityksellisiä koodeja sisällytetään dokumenttiin.

Esimerkkirakenne näkyy kuvassa 3 ja se on kuvan 2 yksinkertaiste-

9

Kuva 3: Esimerkkirakenne [5].

tun RMIM-mallin mukainen. Rakenne on yksi dokumentin runko-osan,StructuredBody-elementin, lapsista. Text-elementti on rakenteen ainoa pakol-linen osa ja se sisältää ihmisen luettavaksi tarkoitetun kuvauksen kirjauksista,joiden visualisoinnissa voi hyödyntää edellä mainittuja HTML:n kaltaisiarakenteita. Rakenteeseen on merkitty LOINC-sanastolla, että kyse on po-tilaan elintoimintojen mittauksista. Esimerkissä on vain yksi kirjaus, jokaon tallennettu konekäsiteltävään entry-elementtiin. Kirjauksen classCodeon OBS (Observation, eli havainto), jonka moodCode on EVN (Event, elitapahtunut). 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äyt-töaluetta rajoitetaan tiettyyn käyttötapaukseen, kuten kotiutusraporttiin.Malline on kokoelma rajoituksia CDA RMIM-malliin. Mallineita on erilaisia:toteutusohjeessa voidaan kertoa sanallisesti esimerkiksi legalAuthenticator-elementin pakollisuudesta, pakollisuus voidaan esittää Schematron-tarkistuk-sella tai voidaan tehdä uusi RMIM, jossa legalAuthenticator-elementti on mer-kitty 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 piilo-tetuista attribuuteista ja sitä voi käyttää kaikissa RIM-luokissa. Mallinevoidaan asettaa koko dokumentille otsakkeen alussa tai vain sen osalle, kutensection- ja entry-elementille. Dokumentissa voi käyttää useaa eri mallinettasamanaikaisesti. Kokoelmaa mallineita, jotka yhdessä määrittelevät tietyndokumenttityypin, kutsutaan profiiliksi.

10

Kirjan mukaan useimmat mallineet on toteutettu Schematronilla ja niitäkäytetään pääasiassa CDA-dokumenttien ilmentymien validointiin. Continui-ty of Care Document (CCD), Consolidated CDA (C-CDA) [10] ja Suomessakäytetyn Kanta-järjestelmän dokumentit [13] ovat esimerkkejä mallineidenkäytöstä. CCD:n tarkoitus on kertoa tarvittavat tiedot potilaan hoidonjatkamiselle toisessa hoitopaikassa. C-CDA:n tarkoitus on luoda yksinker-taisempi toteutustapa sen määrittelemille dokumenttityypeille sekä toimiayksiselitteisenä lähteenä mallineille.

4.4 Allekirjoitus

Yksi kliinisten dokumenttien perusvaatimuksista on allekirjoitettavuus. Digi-taalisille dokumenteille sopii digitaalinen allekirjoitus. Aihe esitellään doku-mentissa [10], joka käsittelee C-CDA:ssa käytettyä allekirjoitustapaa.

CDA-dokumentin allekirjoitus on toteutettu XML Advanced ElectronicSignatures (XAdES) -tekniikalla. Tarkempi tekniikan versio on XAdES Exten-ded Long-term (XAdES-X-L), joka lisää tuen pitkäaikaiselle allekirjoituksentarkistukselle. Tarkistukseen käytetään muun muassa aikaleimoja, varmentei-ta ja peruutuslistoja. Allekirjoitustieto sijaitsee otsakkeen legalAuthenticatorja/tai authenticator -elementtien lapsessa, sdtc:signatureText -elementissä.Tällaisista eri nimiavaruuteen kuuluvista elementeistä mainitaan tarkemminkappaleessa 4.6.

Allekirjoitustapoja on kaksi: valtuutettu henkilö voi allekirjoittaa do-kumentin tai hän voi antaa allekirjoitusoikeuden kolmannelle osapuolelle,joka voi allekirjoittaa dokumentin hänen puolestaan. Keskitymme pääasiassaensimmäiseen tapaukseen. Saman dokumentin voi allekirjoittaa useampikinhenkilö.

Valtuutettu allekirjoittaja todistaa dokumentin sisällön oikeaksi allekirjoi-tuksellaan. Allekirjoitettu dokumentti lähetetään vastaanottajalle, joka voitarkistaa allekirjoituksen. Allekirjoituksen oikeellisuudella varmistuu, ettäallekirjoittaja on hyväksynyt dokumentin sisällön eikä dokumenttia ei olemuutettu sen jälkeen.

Allekirjoittajalla on oltava X.509v3-varmenne allekirjoitusta varten. Var-menne hankitaan varmenteita myöntävältä organisaatiolta (Certificate Aut-hority, CA).

Allekirjoittaja luo allekirjoitusrakenteen (Digital Signature artifact), jo-hon sisältyy hänen roolinsa, allekirjoituksen tarkoitus sekä allekirjoitusai-ka. Rakenne sijoitetaan sdtc:signatureText-elementtiin. Mikäli dokumentinallekirjoittaa kolmas osapuoli, valtuutettu allekirjoittaja luo toisenlaisenallekijoitusrakenteen (Delegation of Rights assertion) ja varmistaa sen oikeel-lisuuden ennen allekirjoitusta ja välitystä kolmannelle osapuolelle. Tämänavulla kolmas osapuoli voi allekirjoittaa dokumentin.

Allekirjoitus koskee koko dokumenttia, dokumentin ClinicalDocument-aloitus- ja lopetuselementit mukaan lukien, paitsi otsakkeen legalAuthen-

11

ticator ja authenticator -tietoja. Ne jätetään pois tiivistettä laskiessa. Näindokumentti voidaan allekirjoittaa useampaan kertaan ilman, että edellisetallekirjoitukset muuttavat tiivistettä. Jos tiiviste muuttuu, edellisiä allekir-joituksia ei pystytä tarkistamaan. Allekirjoitukseen sisältyy aikaleima, jonkaavulla allekirjoitusjärjestys on havaittavissa.

XAdES-X-L -allekirjoitukseen sisällytetään allekirjoittajan julkinen X.509-v3-varmenne sekä tiiviste dokumentista ilman legalAuthenticator ja authen-ticator -tietoja. Yksityisellä avaimella allekirjoitetaan tiiviste, aikaleima, rooli,allekirjoituksen tarkoitus sekä peruutuslista. Allekirjoituksen rooli poimi-taan Healthcare Taxonomy Data Set tai Personal and Legal RelationshipRole Type -sanastoista. Allekirjoituksen tarkoitus on esimerkiksi dokumentinlaatijan, todistajan, tulkin tai hallinnollisen henkilön allekirjoitus.

sdtc:signatureText-elementti on määritelty Consolidated-CDA R2:ssa.Elementti sisältää teksti- tai multimediamuotoisen esityksen allekirjoituk-sesta. Luettavaksi tarkoitetun tekstimuotoisen allekirjoituksen tulisi sisältäätieto digitaalisesta allekirjoituksesta, allekirjoittajan nimi, aikaleima, allekir-joittajan rooli sekä allekirjoituksen tarkoitus. Allekirjoitus kuvaa vastuutadokumentin sisällöstä. Esimerkiksi allekirjoitus olisi ”Digitally signed by Aut-horized Signer John Doe on 4/21/2013 at 15:30 EDT as Physician for thepurpose of Author’s signature.”.

Kun allekirjoituksen oikeellisuus tarkistetaan, ensimmäisenä tutkitaan al-lekirjoittajan julkista X.509v3-varmennetta. Varmenteesta tarkistetaan muunmuassa sen voimassaolo allekirjoitushetkellä, varmenneketjun oikeellisuussekä peruutuslistat. Seuraavaksi tarkistetaan allekirjoitusaika, allekirjoitta-jan rooli ja allekirjoituksen syy. Viimeiseksi puretaan allekirjoitettu tiivisteallekirjoittajan julkisella avaimella, lasketaan uusi tiiviste dokumentista javerrataan tiivisteitä keskenään. Tiivisteiden vertailulla todetaan, että doku-mentin 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 li-sätään useampi authenticator-elementti. Esimerkiksi leikkauksessa kirurgi,nukutuslääkäri ja hoitaja voivat allekirjoittaa dokumentin. Tällöin kirurgintiedot tulevat legalAuthenticator-elementtiin ja nukutuslääkärin ja hoitajantiedot authenticator-elementteihin. LegalAuthenticator allekirjoittaa viimei-senä ja hän on laillisessa vastuussa dokumentista.

4.5 Dokumenttien lukeminen

Dokumentti on hyödyllinen vain jos se luetaan, mainitaan kirjassa [3]. Yleinentapa on luoda koneen muistiin CDA-olio, jonka tietueet täytetään CDA-dokumentin tiedoilla ja sen jälkeen käyttää oliota metodikutsuilla. Tarkoi-tukseen on tehty esimerkiksi avoimen lähdekoodin CDAPI-projekti. Myösohjelmointikielten yleisillä XML-työkaluilla voi käsitellä CDA-dokumentteja.

12

XML Path Language (XPath) on työkalu navigointiin XML-dokumentissa.XPath-kyselyillä voi poimia tietoja elementtien attribuuteista ja sisällös-tä. Haasteena XPathin käytössä on kontekstin levittäytyminen, eli esi-merkiksi section-elementissä määritetty author-tieto koskee myös entry-lapsielementtejä. Läpikäyntiä varten vaaditaan monimutkainen kysely. Esi-merkiksi kysely ancestor-or-self::*[cda:author][1]/cda:author kohdistettunaentry-elementtiin tarkoittaisi, että etsi lähin elementti, joka sisältää vähin-tään yhden author-elementin ja listaa sen sisältö. Kysely ei kuitenkaan toimi,jos kontekstin levittäytyminen on dokumentissa erikseen kielletty, jollointä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 se-kä muunnoksiin. Muunnokset voivat olla muista XML-muotoisista tiedos-toista CDA-dokumenteiksi tai toisin päin, esimerkiksi CDA-dokumentti(X)HTML-muotoon. Yleisin tapa näyttää CDA-dokumenttia onkin muuttaase (X)HTML-muotoiseksi. Text-elementeissä käytetty HTML:n kaltainensyntaksi on helposti muutettavissa HTML-syntaksiksi.

Kuva 4: Section-elementin muunnos XSLT-tekniikalla HTML-muotoon [3].

13

XSLT:llä määritetään kaavoja elementeille, joiden ilmentymät etsitäänXPath-kyselyillä, ja kerrotaan niiden haluttu lopputulosmuoto. Kuvassa 4 onXSLT-esimerkki, joka muuttaa section-elementin HTML-muotoon ihmisellenäytettäväksi. xsl:template-elementti sisältää kaavan tehtävistä toimenpi-teistä, kun match-attribuutissa annettu elementti tulee vastaan dokumen-tissa. 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 re-kursiivisesti kaavaa lapsielementeille. Esimerkin jälkimmäinen kaava kutsuuerillisiä kaavoja text-elementin sisältämille HTML:n kaltaisille rakenteilleniiden muuttamiseksi HTML-muotoon, mutta näitä muunnoksia esimerkkiei 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 taijärjestelmän omassa muodossa, josta dokumentti muutetaan CDA-muotoonsiirtoa varten.

Jos dokumentit tallennetaan suoraan CDA-muodossa, CDA:n on tuettavakaikkia 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ätkuitenkaan saa muuttaa tavallisien elementtien ja attribuuttien merkitystä.Erotteluun voi käyttää eri nimiavaruutta. Paikallisia lisäyksiä ei kuitenkaansaa laittaa ED-tietotyypin kenttiin, kuten text-elementtiin, sillä sen sisältöoletetaan olevan HL7:n nimiavaruudessa. Paikallinen sisältö on kirjattava si-ten, että dokumenttia näytettäessä ihmiselle paikalliset merkinnät on voitavajättää näyttämättä.

Jos paikalliset dokumentit muutetaan CDA-muotoon, kaikki vaadittavatieto on löydyttävä paikallisista dokumenteista. Paikallinen semantiikka tulisisiirtää myös CDA-dokumenttiin aina kun se on mahdollista.

Muunnosta varten voi käyttää tehtävään tarkoitettuja muunnoskieliä taimuunnoksen voi tehdä perinteisillä ohjelmointikielillä. Muunnoskielissä onaina rajoituksia. Esimerkkejä helpoista muunnoksista ovat erilaiset element-tien järjestykset ja nimet sekä sanastot ja tietotyypit. Vaikeampia muutoksiaovat vaadittujen tietojen puuttuminen (esimerkiksi dokumentin tunnisteen),ja tiedon suurirakeisuus (esimerkiksi paikallisessa järjestelmässä talletetaanpotilaan nimi yhteen kenttään ja CDA:ssa pitäisi tallettaa erikseen etunimija sukunimi).

14

CDA-dokumentteja luovat lisääntyvissä määrin erilaiset ohjelmistot jalaitteet. Esimerkiksi sanelimet, potilastietojärjestelmät ja XML-lomakeoh-jelmistot voivat tuottaa CDA-dokumentteja. CDA-dokumentin luomisen –uuden tai muunnoksen – alkuvaiheessa täytyy selvittää, miten mallinnettavatieto suhtautuu RIM:n rakenteisiin, sanastoihin ja tietotyyppeihin. KoskaCDA on niin monipuolinen ja laaja, tiettyyn tarkoitukseen tulevaa doku-menttia varten voidaan tehdä malline. Standardi ei määrittele, miten do-kumentit luodaan tai miten niitä hallitaan, vaan ainoastaan niiden sisällönmerkkaustavan.

4.7 Vaatimustasot

Artikkelissa [5] on esitelty lyhyesti CDA:n historiaa ja tasoja. CDA R1julkaistiin vuonna 2000 ja se sisälsi tasot 1 ja 2. Vuonna 2005 julkaistunja 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 hierarkkisiatasoja, 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 jarunko perustuvat RIM-tietomalliin. Runko voi olla taaksepäin yhteensopivaaihmisen käsiteltävää dataa, tai se voi koostua section-elementeistä, joissa voiolla koneellisesti käsiteltävää tietoa. CDA R3 on kehityksen alla ja se kattaaihmisten lisäksi mm. eläimet [3].

Tasoilla saadaan aikaiseksi hellävarainen johdatus RIM-tietomalliin jastandardin käyttöönotto on helppoa. Konekäsiteltävää tietoa voi lisätä omaantahtiin. Itse dokumenttien sisältö on sama eri tasoilla. Dokumentista voidaantehdä 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 esi-merkiksi PDF-dokumentti, valokuvatiedosto tai tekstiä. Tason 2 runko-osakoostuu section-elementeistä, joille on määritetty koodi sanastosta. Element-tien luonnollisella kielellä kuvatun sisällön tyyliin ei puututa. Tasossa 3section-elementin sisältämät kirjaukset on myös HL7 V3 -tyylisesti koodat-tuna. Taso voidaan ylittää, eli tason 2 dokumentissa on sallittua koodatayksittäisiä kirjauksia tarkastikin.

4.8 Versioiden eroavuudet

CDA R2:n standardissa [6] mainitaan järjestelmien päivitystä silmälläpi-täen eroja R1-versioon nähden. Erojen tietäminen helpottaa eri-ikäistenartikkeleiden lukemista.

Muutamat elementit ovat muuttaneet nimeä. Esimerkiksi section-element-tien otsikko on R1:ssä caption-elementti ja R2:ssa se on title-elementti. R1:ssä

15

ihmisen luettavaksi tarkoitettu tekstisisältö kirjoitetaan suoraan section-elementin sisälle ja R2:ssa teksti kirjoitetaan section-elementin lapsen, pakolli-sen text-elementin, sisälle. Elementtinimet kirjoitetaan R1:ssä snake_case:llaja R2:ssa CamelCase:lla.

Kehitystä on tapahtunut mm. tietotyypeissä. R2 käyttää HL7 Version 3tietotyyppejä, 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] kriti-soidaan HL7:n käyttämää mallinnustapaa. Artikkelin mukaan HL7-organisaa-tiossa ei ole kattavaa osaamista mallinnuksesta tai UML-kielestä (UnifiedModeling Language). HL7 käyttää UML:n kaltaisia malleja, jotka eivät oleyhteensopivia muiden UML:llä kehitettyjen mallien ja ohjelmistojen kanssa.RIM:n Entity-luokka ei sovellu käsitemallinnukseen, sillä kaikki luokat ovatentiteettejä. Myöskään ihmisten ja esineiden yhdistäminen samaan luok-kaan ei ole semanttisesti kovin tarkkaa. Olion tila on piilotettu moodCode-attribuuttiin, joka olisi voitu esittää selvemmin UML:n tiladiagrammilla.Luokkien väliset yhteydet ovat monimutkaisia esittää yhteysluokkien avullaja UML:llä yhteydet olisi voitu esittää paljon pienemmällä luokkamäärällä.Tietoturvan mallinnus, esimerkiksi että lääkärit saisivat muuttaa potilaiden-sa tietoja ja potilaiden tulisi saada ilmoitus kun heidän tietojaan katsellaan,on UML:llä suoraviivaista, mutta RIM-tietomallilla esitettynä vaikeaa. Do-kumentaatiota moititaan monimutkaiseksi ja vaikeaselkoiseksi.

Vaikka kirjassa [2] seikkaa ei esitetä kritiikkinä, mainitaan, että HL7Version 3:n dokumentaatio on valtava. Standardin perustadokumentit, jotkakäsittelevät muun muassa tietotyyppejä, RIM-tietomallia ja XML-tekniikoita,sisälsivät vuonna 2008 yhteensä 359 000 sanaa. Näiden lukemiseen menisinoin 30 tuntia, jos lukee 200 sanaa minuutissa. Perustadokumenttien lisäksion 30 tai yli toimialakohtaista standardia, joihin lukeutuu myös CDA.

Kirjassa [3] mainitaan, että kun dokumentin runko-osana käytetään vainihmisen käsiteltäväksi tarkoitettua dataa, on elementin nimi ”NonXML-Body” kuvaava, sillä se ei saa sisältää XML-sisältöä. Rajoitus on kirjattustandardiin siksi, että XML-sisältö on muutettavissa koneen käsiteltävik-si section-elementeiksi. NonXMLBody-elementtiin saa kuitenkin tallentaaHTML-muotoista tietoa, vaikka se on muunnettavissa XML-muotoiseksi.Sen sijaan XML-muotoon voi tallentaa muitakin kuin dokumentteja, kutenScalable Vector Graphics (SVG) -kuvatiedostoja, joille muunnos ei ole help-poa. Täten esimerkiksi SVG-muotoista sydänsähkökäyräkuvaa ei standardinmukaan saa tallentaa NonXMLBody-elementtiin, mutta binäärimuotoisenpakatun SVG-tiedoston (SVGZ) voisi tallentaa. Kehitysehdotuksena rajoit-timeksi voisi laittaa, että ainoastaan tiedostoja MIME-tyypillä text/xml eisaisi tallentaa NonXMLBodyyn.

16

Artikkelissa [5] muistutetaan, että työ on vielä kesken. Esimerkiksi yksivaiva 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 tuotetaanpaikallisissa hoitopaikoissa ja terveydenhoitojärjestelmä on pääosin maan-tieteellisesti organisoitua. Erityisosaajien tulisi tehdä yhteistyötä maantie-teellisestä sijainnista huolimatta, joten potilaan tietojen jako on keskeisessäosassa.

Potilaiden terveystiedot ovat pääosin sähköisessä muodossa ja niitä säily-tetään hoitoyksiköiden paikallisissa järjestelmissä. Eri alueiden järjestelmäteroavat toisistaan, sillä ne ovat eri toimittajien eri ohjelmistoja. Nämä ohjel-mistot ovat usein semanttisesti yhteensopimattomia ja yhteistyö Internetinvälityksellä on harvinaista. Suomessa on kehitetty järjestelmiä terveystiedonjakamiseen jo vuodesta 1998 alueellisilla ratkaisuilla. Näissä ratkaisuissa kes-kitettyyn rekisteriin tallennetaan metadataa varsinaisen dokumentin hakuunpaikallisesta järjestelmästä.

Vuonna 2007 Sosiaali- ja terveysministeriö aloitti projektin keskitetynterveystietoarkiston rakentamiseksi. Järjestelmän tarkoituksena on luodahelppokäyttöinen, ajantasainen ja semanttisesti yhteensopiva arkisto poti-lastiedoille. Järjestelmä pohjautuu HL7 CDA R2 -standardiin. Projektiakoordinoi Sosiaali- ja terveysministeriö ja projektin toteutuksesta vastaaKela.

Kanta-konseptin keskeinen ajatus on varastoida ja hallita kansallistaterveystietoa keskitetysti. Järjestelmää käyttävät paikalliset potilasrekis-teriohjelmat, lääkejärjestelmät sekä kansalaiset web-portaalin välityksellä.Kolme ensimmäistä käyttökohdetta ovatkin potilastietojen arkisto, sähköi-nen resepti ja kansalaisten käytettävä verkkoportaali terveystiedon noutoon.Arkistoidut tiedot ovat pääosin katsottavissa koko potilaan eliniän. Koska po-tilaan historiatieto on myös ammattihenkilöiden nähtävissä, aiemmin tehtyjätutkimuksia ei enää turhaan toisteta.

Kanta-järjestelmällä semanttinen yhteentoimivuus saavutetaan keskitetyl-lä tietomallilla. Tallennettavan dokumentin täytyy noudattaa Kantan CDAR2-pohjaista tietomallia, eli mallinetta. Tallennuksen yhteydessä dokumenttitarkistetaan ja tallennus onnistuu vain jos tieto on mallin mukaista. Näintoimien Kantaan tallennettu tieto on yhdenmukaista.

Kanta-järjestelmä perustuu SOA-malliin, eli hajautettuun järjestelmään,jossa ominaisuudet/kyvyt on hajautettu osiin, joita ohjaavat mahdollisestieri tahot. Näin saadaan modulaarisuutta, uudelleenkäytettävyyttä ja skaalau-tuvuutta. Kokoelma ohjelmistomoduuleita on järjestetty itsenäisiksi osiksi,

17

jotka koteloidaan palveluiksi tarjoamaan varsinaista toiminnallisuutta. Esi-merkiksi käyttäjän tunnistaminen, arkistointi ja lokikirjanpito on koteloituerillisiksi palveluiksi. Palvelut pohjautuvat Web Service -tekniikkaan. WebService:t on määritelty Web Services Description Languagella (WSDL) jasiihen liittyvällä XML Schema Definitionilla (XSD) Web Services Interopera-bility Organizationin Basic Profile 1.1 -standardin mukaisesti. WSDL kuvaaWeb Servicesin käytön ja XSD viestin sisällön, mukaan lukien CDA:n.

Kanta-palvelut ovat arkkitehtuurin ydin. Viestirajapinta on toteutettuHL7 v3 -viesteillä, jotka kuljettavat CDA-dokumentteja. Turvallisuudestahuolehditaan tunnistautumisella ja pääsynvalvontakerroksella. Tunnistautu-minen ja XML-dokumenttien allekirjoitus perustuu julkisen avaimen infra-struktuuriin (PKI) ja älykortteihin. Yhteydet on suojattu SSL-tekniikalla.Kun vastaanotettu dokumentti on tarkistettu sisällöllisesti ja todennettu, setallennetaan potilastietoarkistoon tai reseptiarkistoon riippuen sen tyypis-tä. Kanta käyttää sanastoa koodien yhtenäistämiseksi ja kirjoitusvirheidenvälttämiseksi. Koodit tarkistetaan koodipalvelussa. Kaikki viestit kirjataankeskitettyyn lokipalveluun, joka tallettaa yksityiskohtaista tietoa luonti-,muokkaus- ja lukutapahtumista. Suomessa potilastietoa voidaan lukea vainpotilaan suostumuksella, joten palvelu suostumuksien hallintaa varten onolemassa.

Kanta-järjestelmään kuuluu myös taustapalveluita koodistoja ja varmen-teita varten. Taustapalveluita ylläpitävät itsenäiset kansalliset viranomaiset,jotka muun muassa myöntävät henkilökohtaiset varmenteet dokumenttienallekirjoitukseen sekä ylläpitävät estettyjen varmenteiden listaa.

5.1 Kanta-järjestelmän hyödyt

On haaste luoda semanttista yhteensopivuutta potilastietojärjestelmiin kan-sallisella tasolla. Kantaan keskitetysti tallennettu tieto mahdollistaa sen.Semanttinen yhteensopivuus perustuu CDA-standardiin, joka kuvaa doku-mentit rakenteisessa muodossa. Rakenteen kaikki elementit on selvästi määri-tetty. Esimerkiksi potilaan nimen elementit on määritelty dokumentaatiossa,joten kaikki järjestelmät tietävät sen tarkan sijainnin ja tarkoituksen Kantanmallineessa. Näin Kanta luo semanttista yhteentoimivuutta eri järjestelmienvä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ösKantan tietomallia on päivitetty projektin kuluessa.

CDA-standardi tarjoaa mahdollisuuden luoda dokumentit haluamallaantarkkuudella. Kantassa dokumentit ovat hienorakeisia ja ihmisen luettavaksitarkoitetut tekstiosiot ovat hyvin pieniä. Näin tiettyyn hoitoon tarvittavattiedot on helposti haettavissa tavallisilla XML-jäsentimillä. Suuremmallarakeisuudella, eli suuremmilla kirjausosioilla, tiedon haku koneellisesti han-kaloituisi. Valittu taso mahdollistaa tietojen käytön myös tulevaisuudessa.

18

Keskustelua herättää, että onko tiedon keskitetty arkistointi oikea rat-kaisu vai pitäisikö tietoja säilyttää paikallisissa potilastietojärjestelmissä.Toinen asia on dokumenttien hienorakeisuus. Jos kokonaisten dokumenttienhaku riittää ilman automaattista käsittelyä, niin dokumenttien haku pai-kallisista järjestelmistä olisi helppoa. Automaattiseen käsittelyyn tarvitaansemanttista yhteensopivuutta sekä hienorakeisuutta.

Tiedon hienorakeisuus mahdollistaa uusia mahdollisuuksia terveystiedonhyödyntämiseen. Kun tietoa kerätään kansallisesti, voidaan seurata kokokansan terveydentilaa ja sen kehitystä. Tilastollisin menetelmin voisi keskit-tyä 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är-jestelmiä on todennäköisesti tulossa lähitulevaisuudessa. Ne voivat käyttääKantan tietoa terveydenhoidon kustannusten pienentämiseksi. Kantan tietovoi auttaa myös hoidon laadun parantamisessa sekä tutkimuksissa.

5.2 Dokumentin otsake

Aivan kuten yleinen CDA-dokumenttikin, Kantan eArkisto-dokumentti koos-tuu otsakkeesta ja runko-osasta. Tähän lukuun on koottu eroavaisuuksiayleiseen CDA-dokumenttiin verrattuna. Otsakkeen määrittely on kuvattudokumentissa [13]. Otsake perustuu HL7:n määritelmään Yhdysvaltojen käyt-tämästä järjestelmästä, johon on tehty muutoksia huomioiden muun muassaSuomen lait ja asetukset. Dokumentteja on kahdenlaisia: palvelutapahtumiaja kertomusasiakirjoja. Palvelutapahtumassa ei ole varsinaista runko-osaa,vaan tieto koostetaan monesta asiakirjasta.

Dokumenttia varten on tehty viralliset tyylitiedostot, joita ei ole tarkoitet-tu loppukäyttäjille, vaan dokumentin tarkastusta varten. Myös XML-skeemapaikallisin elementein on tehty. XML-nimiavaruuksina käytetään tavallistaXML Schemaa, yleistä HL7 v3-nimiavaruutta sekä paikallista hl7finland-nimiavaruutta.

Dokumentin templateId:t kertovat, mihin määrityksiin otsake ja runko-osa perustuvat. Elementissä määritetään myös käytetty versio. Yhdellä do-kumentilla on useampi templateId.

Dokumentille on määritettävä potilasrekisteritunnus. Tunnus on code-elementti, joka kertoo mihin henkilörekisteriin dokumentti kuuluu. Henki-lörekistereitä ovat esimerkiksi julkinen ja yksityinen terveydenhuolto sekätyöterveyshuolto. Arvo noukitaan ”KanTa-palvelut – Potilasasiakirjan rekiste-ritunnus” -sanastosta. Sanastojen sisällöt löytyvät Terveyden ja hyvinvoinninlaitoksen (THL) ylläpitämästä kansallisesta koodistopalvelusta. Rekistereidenvälisessä tiedonsiirrossa täytyy huomioida luovutukseen liittyvät seikat.

Dokumentille annetaan otsikko, joka on joko ”Potilasasiakirja”, ”Pal-velutapahtuma-asiakirja” tai tarkempi otsikointi. Potilasasiakirja-otsikkoakäytetään, kun dokumentti sisältää erinäistä tietoa, eli eri näkymiä. Jos

19

dokumentti sisältää yhdenlaista tietoa, käytetään kyseisen näkymän nimeäotsikossa, kuten ”Lääkärintodistus A”.

Dokumentin luottamuksellisuus, eli confidentialityCode-elementti, nou-dattaa Julkisen hallinnon tietohallinnon neuvottelukunnan JHS-suositusta143. Dokumentin julkisuuden määrää lainsäädäntö. Salassa pidettävään tie-toon liittyy käyttörajoituksia. Elementti saa arvon väliltä 1-5, eli erittäinsalaisesta terveydenhuollon salassa pidettävään dokumenttiin.

Kantaan tallennetun dokumentin copyTime-elementti, joka ilmaisee do-kumentin alkuperäisyyden, on tyhjä. Kun dokumentti kopioidaan paikalli-seen järjestelmään, elementtiin sijoitetaan aikaleima. Kanta tarkistaa tiedonavulla, ettei samaa dokumenttia tallenneta uudelleen.

RecordTarget-elementtiin kirjataan ainoastaan potilaan tiedot. Tunnis-tukseen käytetään ensisijaisesti henkilötunnusta ja varmennukseen nimeä,sukupuolta ja syntymäpäivää. Henkilötunnuksen asemesta voi käyttää ti-lapäistä yksilöintitunnusta, jolloin käytetään OID-tunnusta. Potilaan nimimerkitään oikeassa järjestyksessä ja kukin nimen osa omassa elementis-sään. Myös kutsumanimi voidaan kirjata. Potilaan syntymäpäivä on pa-kollinen kaikissa dokumenteissa. Toisen henkilön tunnistetiedot kirjataanparticipant-elementtiin, mutta he eivät näe dokumenttia omissa tiedoissaanKanta-palvelussa.

Author-elementtiin kirjataan henkilöt, jotka on merkitty runko-osaanMER-roolilla tai palvelutapahtumissa dokumentin luoja. Otsakkeessa onainoastaan nimi ja tunnistenumero ja tarkemmat tiedot ovat runko-osassa.Tunnisteena käytetään henkilötunnusta, jos se on tiedossa. MER-rooli tar-koittaa merkinnän tekijää ja se on yksi roolitunnuksista, joka poimitaanroolisanastosta. Authenticator ja legalAuthenticator -elementit eivät olekäytössä Suomessa. Allekirjoitus sijoitetaan hl7fi-osioon.

Palvelutapahtumat kirjataan documentationOf-elementtiin toistuvinaserviceEvent-elementteinä. Elementti koodataan THL:n Terveysalan palvelu-luokitussanastolla. relatedDocument-elementtiä käytetään versiohallinnassaja palvelutapahtumien linkitys on hl7fi-osiossa. Palvelutapahtumadokumen-tissa componentOf-elementtiin kirjataan muun muassa palvelutapahtumantunnus, aloitus- ja lopetusaikaleima, palvelun tuottajan tunnistetiedot sekäpalvelutapahtumaan osallistuneiden hoitopaikkojen tiedot.

Otsakkeeseen kootaan paikallista tietoa hl7fi-osioon, sillä kaikelle kerätyl-le tiedolle ei ole paikkaa CDA-standardissa. Tiedon avulla dokumentteja voikäyttää laajempaan käyttötarkoitukseen. Tieto kootaan otsakkeen loppuunhl7fi:localHeader -elementtiin. Elementin validointiin on erillinen skeema.Elementti itse ja sen lapset ovat skeemassa vapaaehtoisia, mutta dokumen-taatio määrittää osan niistä pakollisiksi. Tyylitiedoston avulla näytetääntarpeelliset elementit.

JHS 143 -suositus asiakirjojen kuvailun ja hallinnan metatiedoista ohjaaosaa paikallisista elementeistä. Tällaisia elementtejä ovat muun muassahl7fi:declaredTime (arkistointiaika) ja hl7fi:auditTrail (muutoshistoria).

20

Potilastietojärjestelmän omille tiedoille on varattu tilaa hl7fi:product-elementissä, jonka sisältöä muut järjestelmät eivät käytä. Allekirjoituksenpaikka on hl7fi:signatureCollection-elementissä ja sähköisen allekirjoituksenmäärittelee erillinen määritys ja soveltamisopas.

hl7fi:encompassingEncounterMasterCode-elementtiin kirjataan, onko do-kumentti palvelutapahtuma- vai hoitodokumentti. Tietyt kuvailutiedot kir-jataan ainoastaan palvelutapahtumadokumenttiin, joka arkistoidaan ensin.Arkistoinnin jälkeen Kanta kopioi palvelutapahtumadokumentista tietojahoitodokumentteihin.

Dokumentin katseluoikeutta web-portaalin kautta voi viivästyttää hl7fi:-releaseDateForPatientViewing-elementillä. Joskus on tarvetta estää potilastakatselemasta tietoa, esimerkiksi jos siitä voi aiheutua vaaraa potilaan tervey-delle. 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 tarkoi-tettu sisältö (tämän määrittelyn mukainen termi on näyttömuoto). Vainpotilaskertomuksen keskeiset tiedot täytyy merkata koneen käsiteltävässämuodossa (määrittelyn termein rakenteisessa muodossa). Nämä tiedot kat-tavat toteutuneet sekä suunnitellut hoidot ja niiden tietosisältö on sovittuyhteisesti.

CDA:n section-elementit koodataan kolmella sanastolla: Näkymät-koodis-tolla, Hoitoprosessin vaihe -koodistolla ja Otsikot-koodistolla. Jäsennys toteu-tetaan sisäkkäisillä section-elementeillä, jotka tulostuvat selaimella siististisisennettyinä 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 jokai-nen eri asia, kuten lääkitys ja laboratoriotulos, kirjoitetaan eri rakenteisiinyksittäisten kirjausten kopiointia ja siirtoa varten.

Kertomusasiakirja koostuu merkinnöistä, jotka koskevat samaa potilastasamassa palvelutapahtumassa. Merkintä on yksittäiseen näkymään kirjoitet-tu kirjaus, laitteen tuottama kuva tai mittaustulos, joka on ammattihenkilönarvioima ja tallentama. Merkintä koostuu näkymätiedosta, hoitoprosessinvaiheesta, otsikoista, ihmisen luettavaksi tarkoitetusta tekstistä sekä valin-naisesta rakenteisesta tiedosta. Merkintä ja sen osat on yksilöitävä OID-tunnuksilla.

Potilaan tunniste on sijaittava ensimmäisessä section-elementissä alle-kirjoitusta varten. Tunniste kirjataan subject-elementtiin. Jos merkintöjäpoimitaan esimerkiksi koostedokumenttia varten, tunniste on liitettävä siir-rettäviin rakenteisiin.

Dokumentin kirjoittajan (määrittelyn termein ammattihenkilö) tiedotperiytyvät otsakkeesta, mutta tiedot kirjataan tarkemmin runko-osaan. Ot-

21

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 palvelu-yksikön tiedot ja merkinnän aika. Tiedot eivät ole täysin pakollisia.

Ylimmässä section-elementissä, eli näkymässä, on ainakin yksi hoitopro-sessin vaihe, johon on kirjattu asiakokonaisuuksia. Hoitoprosessin vaihe sijoite-taan näkymän sisälle alempaan section-elementtiin. Hoitoprosessin vaiheeseenliittyvät asiakokonaisuudet sijoitetaan vielä alempiin section-elementteihin,joihin varsinaiset kirjaukset tehdään. Ihmisen luettavaksi tarkoitetussa sisäl-lössä voi käyttää aiemmin kuvattuja HTML:n kaltaisia rakenteita. Käyttäjänkirjoittamat tekstiosiot merkataan attribuutilla styleCode="xUnstructured".Kaikilla sectioneilla on code ja title -elementit.

Koneen käsiteltäväksi tarkoitetut tiedot kirjataan tuttuun tapaan entry-elementteihin, joita voi olla useita yhtä otsikkoa kohden. Kirjaukset voivatviitata tekstin osiin. Viittauksen voi tehdä dokumentin sisällä sekä myöserilliseen dokumenttiin, jonka täytyy olla tallennettuna Kantaan. Entry-elementtiin kirjataan käytetyn mallineen tunniste. Eri kirjaustyypeille, kutendiagnooseille, toimenpiteille ja fysiologisille mittauksille on omat kirjausohjeetdokumentaatiossa.

Potilastiedon arkisto tukee ainoastaan PDF-muotoisia kuvia. Palvelu-tapahtuma-asiakirjan runko-osa sisältää ainoastaan yhden section-elementin,jossa on potilaan tunnistetiedot.

22

Kuva 6: Hoidon tarve koodattuna kirjauksena [14].

5.4 Esimerkkidokumentti

Hoitopalaute on yksi Kanta-dokumentti, joka on kuvattu dokumentissa [14].Hoitopalaute on profiili. Moni rakenne on vapaaehtoinen hoitopalautteessa,sillä tietosisältö kopioidaan aiemmista dokumenteista.

Dokumentin otsake ja runko-osa noudattavat yleistä CDA-rakennetta.Runko-osa koostuu yhdestä näkymätason section-elementistä, joka on koo-dattu PAL-näkymäksi. Tämä section-elementti sisältää tiedon osallistujistaja potilaasta. Elementin sisällä on kaksi sectionia: ”Määrittämättömän hoito-prosessin vaihe” ja ”Hoidon arviointi” -sectionit. Näiden sisällä on varsinaisetkirjaukset sisältävät sectionit, kuten ”Loppuarvio”. Kirjaukset sisältäviensectioneiden kirjausohjeet ovat dokumentaatiossa.

Osa kirjauksista, kuten ”Kuntoutus” ja ”Toimintakyky” sisältävät ai-noastaan koodatun otsikon ja kirjaukset ainoastaan ihmisen luettavassamuodossa. Kuvassa 6 on ”Hoidon tarve” -kirjauksen konekäsiteltävä versio,johon liittyy myös tekstimuotoinen seloste, jota ei ole kuvassa. Kyseessä onhavaittu tapahtuma. Code-elementissä kerrotaan, mistä tapahtumasta onkyse lähete/hoitopalaute-kenttäkoodistolla. Havainnon aika on effectiveTime-elementissä, joka on yksinkertaista tyyppiä. Varsinainen havainto ilmoitetaanvalue-elementissä koodilla, joka on poimittu Hilmo-sanastosta.

6 YhteenvetoTavoitteena oli siirtää paperimuotoinen, vapaamuotoisella tekstillä selostettu,kliininen dokumentti tietokonejärjestelmään. Health Level 7 (HL7) on ke-hittänyt tarkoitukseen Clinical Document Architecture (CDA) -standardin,joka täyttää kliinisten dokumenttien vaatimukset. Dokumenttia ei tarvitsetallentaa CDA-muodossa, vaan se voidaan siirtoa varten muodostaa toisestatiedostomuodosta.

CDA on mallinnettu HL7 Reference Information Model (RIM) -tietomal-lilla, joka kattaa koko terveydenhuollon alueen. CDA:n mallinnus on tehty

23

valitsemalla RIM:stä vain tarpeelliset luokat ja attribuutit. Attribuutti voiolla yksinkertaista tyyppiä tai saada arvon sanastosta. Luokkien ilmentymiäon sallittua toistaa valinnassa ja attribuuttien sallittuja arvoja voi rajoittaasuppeammaksi. Tuloksena on Refined Message Information Model (RMIM),josta muodostetaan XML-skeema.

CDA-dokumentti on XML-muotoinen tiedosto, joka koostuu loogisestiotsakkeesta ja runko-osasta. Otsakkeessa on metadataa dokumentista hal-lintaa ja siirtoa varten, kuten potilaan ja dokumentin kirjoittajan tiedot.Varsinainen tietosisältö on runko-osassa, joka voi olla yksi tiedosto (kutenkuvatiedosto, PDF taikka video) tai sisältää rakenteista tietoa. Rakenteinentieto kirjataan section-elementteihin, joiden ainoa pakollinen tieto on ihmisenluettavaksi tarkoitettu teksti. Näin alkuun pääsee helposti ja konekäsiteltäväätietoa voi lisätä joustavasti järjestelmän kehittyessä.

Koska CDA:n käyttöalue on laaja, aluetta rajataan tiettyyn käyttötar-koitukseen mallineella. Mallineella määritetään muun muassa halutun doku-mentin pakolliset tiedot ja lisärajoitteet. Dokumentissa voi käyttää useaa erimallinetta samanaikaisesti. Suomessa käytössä oleva Kansallinen Terveysar-kisto (Kanta) tallettaa dokumentit CDA-muodossa käyttäen useaa mallinetta,jotka sisältävät Suomen lainsäädännön vaatimat seikat. Jos dokumentti ei olemallineen muotoinen, sitä ei tallenneta. Käytössä on muun muassa mallineyleiselle dokumenttirakenteelle sekä yksittäisille dokumenttityypeille, joistatutkielmassa käsiteltiin hoitopalautetta.

Ohjelmistot voivat lukea CDA-dokumentteja erilaisin tekniikoin, kutenvarta vasten kehitetyllä CDAPI-projektilla tai ohjelmointikielten yleisilläXML-työkaluilla. XSLT on tekniikka, jota käytetään muun muassa doku-mentin näyttämiseen ihmiselle selaimessa.

HL7:n kehittämät ratkaisut ovat saaneet osakseen myös kritiikkiä. Osaaheidän itsekehittämistään ratkaisuista on kritisoitu, sillä käyttökohteeseenolisi ollut tarjolla valmiita standardeja. Lisäksi heidän standardiensa doku-mentaatio on valtavan pitkä, joten oppimiskäyrä voi olla jyrkkä. Järjestelmäei ole vielä valmis, vaan uusia versioita on tulossa, joissa mahdollisesti korja-taan nykyisen järjestelmän vikoja ja puutteita.

Lähteet[1] Bakken, S, Campbell, K. E., Cimino, J. J., Huff, S. M. ja Hammond, W.

E.: Toward Vocabulary Domain Specifications for Health Level 7—codedData Elements. Journal of the American Medical Informatics Association,7(4):333–342, 2000, ISSN 1067-5027. http://jamia.oxfordjournals.org/content/7/4/333.

[2] Benson, T.: Principles of health interoperability HL7 and SNOMED.Springer Science & Business Media, 2012.

24

[3] Boone, K.W.: The CDA TM book. Springer London, 2011,ISBN 9780857293367. https://books.google.fi/books?id=rwa6DDB4jY8C.

[4] Dolin, R. H., Alschuler, L., Beebe, C., Biron, P. V., Boyer, S. L., Es-sin, D., Kimber, E., Lincoln, T. ja Mattison, J. E.: The HL7 Cli-nical Document Architecture. J Am Med Inform Assoc, 8(6):552–569, 2001. http://www.ncbi.nlm.nih.gov/entrez/query.fcgi?cmd=Retrieve&db=pubmed&dopt=Abstract&list_uids=11687563.

[5] Dolin, R. H., Alschuler, L., Boyer, S., Beebe, C., Behlen, F. M., Biron, P.V. ja Shvo, A. S.: Model Formulation: HL7 Clinical Document Architec-ture, Release 2. JAMIA, 13(1):30–39, 2006. http://dblp.uni-trier.de/db/journals/jamia/jamia13.html#DolinABBBBS06.

[6] Dolin, R. H., Alschuler, L., Boyer, S., Beebe, C., Behlen, F. M., Biron,P.V. ja Shabo, A.: HL7 Clinical Document Architecture, Release 2.0,2005. http://www.hl7.org/, viitattu 04.03.2016.

[7] El Fadly, A., Daniel, C., Bousquet, C., Dart, T., Lastic, P. ja Degoulet,P.: Electronic Healthcare Record and Clinical Research in CardiovascularRadiology. HL7 CDA and CDISC ODM Interoperability. Teokses-sa AMIA 2007, American Medical Informatics Association AnnualSymposium, Chicago, IL, USA, November 10-14, 2007, 2007. http://knowledge.amia.org/amia-55142-a2007a-1.623841/t-001-1.624626/f-001-1.624627/a-037-1.625019/a-038-1.625016.

[8] Fernandez, E. ja Sorgente, T.: An Analysis of Modeling Flaws in HL7and JAHIS. Teoksessa Proceedings of the 2005 ACM Symposium onApplied Computing, SAC ’05, sivut 216–223, New York, NY, USA, 2005.ACM, ISBN 1-58113-964-0. http://doi.acm.org/10.1145/1066677.1066732.

[9] Guo, J., Takada, A., Tanaka, K., Sato, J., Suzuki, M., Suzuki, T., Nakas-hima, Y. ja Araki, K., Yoshihara H.: The Development of MML (MedicalMarkup Language) Version 3.0 as a Medical Document Exchange For-mat for HL7 Messages. Journal of Medical Systems, 28(6):523–533, 2004,ISSN 1573-689X. http://dx.doi.org/10.1023/B:JOMS.0000044955.51844.c3.

[10] Health Level Seven International: HL7 Implementation Guide for CDARelease 2: Digital Signatures and Delegation of Rights, Release 1, oct2014. http://www.hl7.org/.

[11] HL7 Finland ry: Kanta - Kertomus ja lomakkeet CDA R2-rakenne.WWW, 2015. http://www.hl7.fi/hl7-rajapintakartta/kanta-%

25

E2%80%93-earkiston-kertomus-ja-lomakkeet-cda-r2/, viitattu27.04.2016.

[12] Huff, S. M., Rocha, R. A., McDonald, C. J., De Moor, G. J. E., Fiers, T.,Bidgood, W. D., Forrey, A. W., Francis, W. G., Tracy, W. R., Leavelle,D., Stalling, F., Griffin, B., Maloney, P., Leland, D., Charles, L., Hutc-hins, K. ja Baenziger, J.: Development of the Logical Observation Iden-tifier Names and Codes (LOINC) Vocabulary. Journal of the AmericanMedical Informatics Association, 5(3):276–292, 1998, ISSN 1067-5027.http://jamia.oxfordjournals.org/content/5/3/276.

[13] Kela ja ry, HL7 Finland: KanTa eArkiston CDA R2 Hea-der. WWW, 2015. http://www.hl7.fi/hl7-rajapintakartta/kanta-earkiston-cda-r2-header/, viitattu 27.04.2016.

[14] ry, HL7 Finland ja Kela: Kanta - Lahetteen ja hoitopalautteen CDA R2-rakenne. WWW, 2014. http://www.hl7.fi/hl7-rajapintakartta/kanta-%E2%80%93-lahetteen-ja-palautteen-cda-r2-rakenne/,viitattu 27.04.2016.

[15] Ryan, A.: Towards Semantic Interoperability in Healthcare: On-tology Mapping from SNOMED-CT to HL7 Version 3. Teok-sessa Proceedings of the Second Australasian Workshop on Ad-vances in Ontologies - Volume 72, AOW ’06, sivut 69–74, Dar-linghurst, Australia, Australia, 2006. Australian Computer Society,Inc., ISBN 1-920-68253-8. http://dl.acm.org.libproxy.helsinki.fi/citation.cfm?id=1273659.1273668.

[16] Suna, T.: Finnish national archive of health information(KanTa): General concepts and information model. Fujit-su Scientific and Technical Journal, 47(1):49–57, 2011. http://www.scopus.com/inward/record.url?eid=2-s2.0-79551597041&partnerID=40&md5=41e66e01980c7233e1e93a1b7397b38d, cited By2.

26