HL7 Clinical Document Architecture

Transkriptio

1 hyväksymispäivä arvosana arvostelija HL7 Clinical Document Architecture Riku Niittymäki Helsinki HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos

2 HELSINGIN YLIOPISTO HELSINGFORS UNIVERSITET UNIVERSITY OF HELSINKI Tiedekunta Fakultet Faculty Laitos Institution Department Matemaattis-luonnontieteellinen tiedekunta Tekijä Författare Author Tietojenkäsittelytieteen laitos Riku Niittymäki Työn nimi Arbetets titel Title HL7 Clinical Document Architecture Oppiaine Läroämne Subject Tietojenkäsittelytiede Työn laji Arbetets art Level Seminaari Tiivistelmä Referat Abstract Aika Datum Month and year Sivumäärä Sidoantal Number of pages 15 sivua HL7 Clinical Document Architecture (CDA) on standardi potilasasiakirjojen välittämiseen eri terveydenhuollon järjestelmien välillä. CDA standardin tarkoitus on määritellä järjestelmien rajapintojen kautta välitettävien asiakirjojen rakenne. Tämä seminaarityö on yleiskatsaus CDA standardiin ja siihen liittyviin HL7 V3 standardiin sekä RIM viitemalliin, jotka käsitellään CDA standardin kannalta oleellisilta osin. Työssä käsitellään myös CDA standardin soveltamista Suomessa kansallisen terveysarkisto projektin yhteydessä. Avainsanat Nyckelord Keywords Clinical Document Architecture, HL7 V3, terveydenhuolto, yhteentoimivuus, potilasasiakirja. Säilytyspaikka Förvaringställe Where deposited Muita tietoja Övriga uppgifter Additional information

3 ii Sisältö 1 Johdanto 1 2 Potilasasiakirja 2 3 HL HL7 V RIM viitemalli CDA asiakirjastandardi 6 5 CDA asiakirjan rakenne CDA otsake CDA runko CDA käytännössä Kanta lähete ja hoitopalaute Kanta suun terveydenhuollon potilaskertomus CDA muissa maissa Yhteentoimivuus Yhteenveto 13 Lähteet 14

4 1 1 Johdanto Tiedonhallinnalla on suuri merkitys terveydenhuollossa [BEY04]. Tietoa pitää voida tallentaa pysyvästi ja tallennettua tietoa täytyy pystyä saattamaan takaisin ihmisten luettavaksi. Tallennettuja asiakirjoja pitää pystyä etsimään ja rajaamaan erilaisilla hauilla. Eri sidosryhmillä on erilaiset tietotarpeet, jotka tulee ottaa huomioon tiedonmallintamisessa sähköiseen muotoon. Lääkärien pitää pystyä näkemään muun muassa potilaan hoitohistoria ja hänelle määrätyt lääkkeet tehdessään päätöksiä potilaan tulevasta hoidosta. Terveydenhoitajat tarvitsevat tallennettua tietoa esimerkiksi jakaessaan sairaalan potilaille lääkkeitä. Toisaalta tietoa tarvitsee jakaa yli hallinnollisten organisaatioiden, kuten eri sairaanhoitopiirien välillä. Terveydenhuollossa syntyy jatkuvasti suuri määrä tietoa, joka pitää tai olisi hyvä tallentaa. Osalle tallennettavasta tiedosta on asetettu maakohtainen lainsäädäntö, mitä tietoa potilaista ja hoidoista tulee tallentaa. Lainsäädäntö voi myös asettaa rajoituksia, mitä ei saa tallentaa ja kenellä tallennettuun tietoon on pääsyoikeus. Yksi tavallisimmista dokumenteista, joita terveydenhuollossa kertyy, on potilaskertomus. Potilaskertomus voi olla esimerkiksi potilaan lääkärikäynnistä syntynyt dokumentti, jossa kuvataan potilaan vaivat, diagnoosi, määrätyt lääkkeet ja hoito. Näiden dokumenttien sähköistä tiedonvaihtoa ja tallentamista varten on kansainvälinen Health Level-7 (HL7) organisaatio kehittänyt Clinical Document Architecture (CDA) asiakirjastandardin. HL7 standardit ovat laajassa käytössä erilaisten terveydenhuollon järjestelmien välisessä yhteentoimivuudessa [THL07]. CDA asiakirjastandardi mahdollistaa potilastietojen välittämisen eri järjestelmien välillä. CDA pohjautuu HL7:n Reference Information Model (RIM) viitemalliin. CDA asiakirjassa käytetään RIM viitemallin käsitteitä, jolla pyritään kattavampaan yhteentoimivuuteen. Suomessa CDA asiakirjastandardi on osana Kansallista Terveysarkisto (Kanta) hanketta ja sen toteutusta [KAN07].

5 2 2 Potilasasiakirja Terveydenhuollossa potilas voi yhden sairauden tai käynnin yhteydessä tavata useita eri terveydenhuollon ammattilaista; lääkäreitä, terveydenhoitajia ja laborantteja [HOO04]. Näistä jokaisesta syntyy dokumentti tai potilasasiakirja, joka kuvaa mahdollisimman tarkasti mitä potilaalle on kerrottu, määrätty sekä mitä lääkäri on todennut ja mitä potilas on hänelle kertonut. Dokumentit voivat syntyä ajallisesti ja maantieteellisesti kaukana toisistaan. Dokumentteja voidaan myös tarvita potilaan jonkin toisen vaivan tai sairauden hoidossa. Onkin toivottavaa, että dokumentit on tallennettu siten, että niihin on pääsy nopeasti eri paikoista ja jopa samanaikaisesti. Tällöin dokumentit on loogista tallentaa sähköisesti, mutta sähköinen tallentaminen asettaa monia haasteita. Potilas voi hoidon aikana vierailla eri organisaatioissa. Näiden organisaatioiden tietotarve ja siitä johtuen myös tiedontallennus muoto voi erota toisistaan. Potilasasiakirjoja täytyy voida siirtää ja jakaa eri organisaatioiden välillä automatisoidusti, muuten potilaan hoitohistoriasta tulee pirstaloitunut ja epäjohdonmukainen [HOO04]. Organisaatioiden hallinnoimien tietojärjestelmien yhteentoimivuuden takaaminen on sähköisten potilasasiakirjojen tallentamisen tärkeimpiä haasteita. Beyer et al. [BEY04] raportoivat haastattelututkimuksen perusteella löydetyiksi ongelmiksi terveydenhuollon tietojärjestelmissä: Riittämätön tiedonkulku sairaalan ja terveydenhuollon ammattilaisten välillä. Riittämätön koordinointi. Pitkät odotusajat. Riittämätön henkilöiden välinen kommunikaatio. Tiedonkulkua voidaan parantaa järjestelmien yhteentoimivuuden parantamisella, sillä yhteentoimivuus auttaa tiedonsaannissa. Raportoidut henkilöiden väliset kommunikaatio ongelmat johtuivat vaikeudesta saada tietoa potilaan hoidosta vastuussa olevilta henkilöiltä. Potilasasiakirjojen jäljitettävyys koettiin heikoksi. CDA asiakirjatandari on laadittu vastamaan yhteentoimivuus ongelmiin ja tiedonkulun ongelmiin. Asiakirjastandardi on laadittu seuraavien ominaispiirteiden pohjalta: 1. Tiedon pysyvyys (persistence), jolla tarkoitetaan tallennettujen tietojen ajallista säilyvyyttä. 2. Omistajuus (stewardship) tai jäljitettävyys. Asiakirjan tulee olla

6 3 jäljitettävä, siten että kaikki asiakirjan muodostamiseen osallistuneet henkilöt (lääkäri, hoitaja, potilas, sairaala) tulee olla yksilöitävissä dokumentin avulla. 3. Mahdolisuus varmistukseen (potential for authentication). Asiakirja pitää olla mahdollista varmentaa siten, että sen laatijaa tai sisältöä ei voida muokata tai väärentää. Muokkaus pitää olla havaittavissa jälkikäteen. 4. Asiakirjan konteksi (context) tulee olla määritelty asiakirjassa. 5. Asiakirja on eheä (wholeness) ja se pätee kokonaisuutena, ei osina. Tällä tarkoitetaan että asiakirjan yksittäinen osa ei ole merkityksellinen ilman koko asiakirjan kontekstia. 6. Asiakirjan ihmisluettavuus (human readability). Asiakirja tulee olla sekä koneenluettava, että ihmisluettava. Tämä tulee esiin tiedon välityksessä käytettäväksi valitussa merkkauskielessä. CDA asiakirjat käyttävät XML-merkkauskieltä asiakirjojen esittämisessä. CDA asiakirjojen rakennetta käsitellään tarkemmin luvussa 5. 3 HL7 HL7 on voittoa tavoittelematon organisaatio, joka on keskittynyt tarjoamaan terveyshuollon yhteentoimivuutta edesauttavia standardeja [HL7A]. HL7 keskittyi alussa potilaskirjanpidon dokumenttien vaihtamiseen sairaaloiden välillä [BEN12, s.91]. HL7 V2 luotiin 1989 ja se on maailman laajimmin käytössä oleva terveydenhuollon yhteentoimivuus standardi. Vuonna 2012 yli 90% yhdysvaltalaisten sairaaloiden tietojärjestelmistä oli HL7 V2 standardi yhteensopivia [BEN12, s.91]. HL7 V2 standardin alkuperäisiä suunnitteluperiaate oli, että se suunniteltiin taaksepäin yhteensopivaksi. HL7 V2 standardista on julkaistu useita eri versioita, jotka kaikki ovat taaksepäin yhteensopivia, joista uusin on versio 2.6. Merkki Käyttötarkoitus Ohjausmerkki tekstissä Kenttien erotin \F\ ^ Komponentin erotin \S\ ~ Toiston erotin \R\ \ Ohjausmerkki \E\ & Alikomponentin erotin \T\ <CR> Segmentin erotin Taulukko 1: HL7 V2 viesteissä käytetyt erotinmerkit. HL7 V2 standardissa viestit syntyvät heräte tapahtumien (trigger events) lauetessa. Viestiin liittyy aina viestin tyyppi ja se laukaissut heräte tapahtuma. Heräte tapahtumia

7 esimerkiksi ADT (Admission, discharge and transfer) viestille voi olla potilaskäynti (A01) tai potilaan siirto (A02). Viesti koostuu segmenteistä ja segmentit kentistä. Kenttien erotteluun käytetään erotinmerkkejä (Taulukko 1) ja segmentit ovat eroteltu toisistaan rivinvaihdoilla. Rivin alussa on segmentti tunnus. Taulukossa 2 on vasemmalla kuvattu esimerkki HL7 V2 viestistä, joka kuvaa potilaan lääkärikäyntiä ja sen yhteydessä suoritettavaa toimenpidettä. Segmentti tunnukset ovat lihavoitu. Taulukossa 2 on oikealla kuvattuna yksi tapa esittää tämä viesti. Viesti on koneluettava, mutta ei kovinkaan ihmisluettava. Erotinmerkkien ja lyhyiden tunnusten käyttäminen takaa lyhyet viestit ja tätä kautta voidaan saavuttaa säästöjä tiedonvälityksessä ja tiedontallentamisessa. Jatkuvasti kasvava tiedonsiirto ja tallennus kapasiteetin kasvaminen tekee näistä säästöistä kuitenkin vähemmän merkitseviä. MSH ^~\& ^123457^Labs ORU^R P 2.4 PID ^^^SMH^PI MOUSE^MICKEY M 14 Disney Rd^Disneyland^^^ MM1 9DL PV1 5N G123456^DR SMITH OBR ^CULTURE^LN SW^^^FO OT^RT C OBX CE 0^ORG 01 STAU F OBX CE ^AMP 01 R F OBX CE ^SXT 01 S F OBX CE ^CIP 01 S F HL7 V2 standardi määrittelee siis järjestelmien välillä siirrettävien viestien välitysmuodon. Se määrittelee viestien sisällön, joidenkin kenttien tietotyypit sekä herätä tapahtumia, mutta se ei kuitenkaan määrittele tarkasti viestien tai niiden välistä merkitystä. Viestien nimi muodostuu viestin tyypistä ja heräte tapahtumasta. Koska V2 tarjoaa mahdollisuuden tehdä yksi asia monella tavalla [BEN12, s.107], on mahdollista, että eri järjestelmät tulkitsevat viestejä eri tavalla. Viesteissä on myös vaikeata viitata toiseen viestiin tai kenttään viestin sisällä. HL7 on kehittänyt uuden version 3 version 2 pohjalta, jossa on yritetty välttää näitä ongelmia. Raportti toimipaikasta Labs Potilas: Mickey Mouse, syntynyt Toimenpide: Swap, FOOT, Right Taulukko 2: HL7 V2 esimerkki viesti ja sen mahdollinen esitys [BEN12, s. 106]. 4

8 5 3.1 HL7 V3 HL7 versiota 3 aloitettiin kehittämään vuonna 1995 ja sen ensimmäinen versio julkaistiin Version 3 suunnittelu periaatteeksi valittiin hierarkkinen tiedonesitys ja olio-ohjelmoinnin periaatteet. Version 3 viestit käyttävät XML-merkkauskieltä. Version 3 tarkoituksena oli olla tarkemmin määritelty kuin sen edeltäjä, sillä version 2 katsottiin sisältävän liian paljon vapaita kenttiä, joka mahdollisti toteuttajan liian suuren vapauden ja tätä kautta aiheuttaa ongelmia yhteentoimivuudessa [BEN12, s ]. HL7 V3 on myös huomattavasti laajempi kuin aikaisempi versio. Se koostuu useasta eri standardista, joista jokainen pyrkii vastaamaan tiettyyn osa-alueeseen terveydenhuollon järjestelmien yhteentoimivuudessa. CDA asiakirjastandardi on yksi HL7 V3 standardeista, joka mahdollistaa kliinistä tietoa sisältävien asiakirjojen esittämisen kone- ja ihmisluettavassa muodossa [THL07]. CDA kuitenkin hyödyntää muita HL7 V3 standardeja, joista tärkein on RIM viitemalli. RIM viitemalli on HL7 V3 standardien semanttinen tietokokoelma ja sen on tarkoitus kattaa kaikki tieto, jota joudutaan siirtämään löyhästi yhteen kytkettyjen terveydenhuolto järjestelmien välillä [THL07]. RIM viitemallin luokat toimivat rakennuspalikoina, joista voidaan muodostaa mikä tahansa HL7 V3 standardin mukainen sanoma. 3.2 RIM viitemalli RIM viitemalli toimii HL7 V3 standardin sanomien ja asiakirjojen semanttisena kehyksenä. Olio pohjainen RIM on kaikkien HL7 V3 standardien ytimessä, sillä sen avulla voidaan esittää kaikki kliininen data sekä kaikkien asiakirjojen ja viestien elinkaari [DOL01]. RIM viitemallin ei ole tarkoitus mallintaa yksittäisen terveydenhuolto järjestelmän koko tietomallia [THL07]. RIM mallintaa ainoastaan tietoa, jota joudutaan siirtämään järjestelmien välillä yhteentoimivuuden toteuttamiseksi. Viitemalli sisältää kuusi pääluokkaa [THL07, BOO11]: Act, Entity, Role, Participation, ActRelationShip ja RoleLink.

9 6 Kuva 1: HL7 V3 RIM viitemallin pääluokat. Kuvassa 1 on kuvattu RIM pääluokat ja niiden väliset suhteet UML luokkakaaviona. Act luokka on kaikkien asiakirjojen ja viestin keskiössä. Se kuvaa tarkoituksellista tapahtumaa terveydenhuollossa [BOO11]. Entity on fyysinen entiteeti, joka voi Participation luokan kautta osallistua johonkin tapahtumaan (Act) tietyssä roolissa (Role). Rooli on entiteettiin liittyvä ominaisuus, kelpoisuus tai pätevyys [THL07]. Roolit ovat keskenään yhteydessä luokan RoleLink avulla, joka kuvastaa kahden entiteetin välistä riippuvuutta tietyissä rooleissa. Esimerkkiksi Entity luokan aliluokan Person ilmentymä Maija jolla on Role aliluokan LicensedEntity rooli, joka hoitaa potilas-lääkäri RoleLink ilmentymän kautta toista Person luokan ilmentymää Matti, jonka rooli on Patient. Kuitenkin RoleLink on hyvin harvoin käytetty V3 mallintamisessa [BOO11, s.114]. CDA asiakirjat ovat RIM viitemallissa Act luokan aliluokan ClinicalDocument ilmentymiä. 4 CDA asiakirjastandardi CDA asiakirja on määritelty ja kokoinen informaatio olio, joka voi sisältää tekstiä, kuvia tai muuta multimedia sisältöä [DOL01]. Asiakirjastandardi kuvaa potilasasiakirjojen rakenteen käyttäen HL7 RIM viitemallia [BOO11, s.127]. CDA standardista on julkaistu kaksi versiota, joista ensimmäinen CDA R1 julkaistiin vuonna 2000 ja toinen CDA R2 vuonna CDA R2 on myös muokatta ISO standardiksi ISO/HL :2009 [ISO09]. CDA asiakirjat on koodattu käyttäen XML merkkauskieltä. XML elementit ovat johdettu RIM viitemallista, mutta elementtien sisältö voi koostua tekstistä tai muusta ei XML sisällöstä. CDA XML olion juuri elementti on aina ClinicalDocument. Juuri elementin sisältö voidaan karkeasti jakaa kahteen osaan, otsakkeeseen ja runko osaan. Otsake ja runko eivät kuitenkaan ole erillisiä XML elementtejä vaan otsakkeeseen katsotaan kuuluvan kaikki ClinicalDocument elementin lapsi elementit

10 7 ennen component elementtiä [BOO11, s. 133]. Otsakkeen ja rungon sisältö on tarkemmin esitelty luvussa viisi. CDA julkaisu 2 ei juurikaan eroa julkaisusta 1 [DOL06]. Suurin ero versioiden väliltä löytyy rungon sisällössä. CDA R1 käyttää RIM viitemallista johdettua XML kieltä ainoastaan asiakirjan otsakkeessa. CDA R2 käyttää sitä myös asiakirjan rungossa. Näin ollen, julkaisusta yksi siirtyminen julkaisuun kaksi on tehty helpoksi, sillä R2 mahdollistaa R1 muotoisten asiakirjojen rungon liittämisen suoraan R2 muotoisen asiakirjan rungoksi. Edellyttäen, että viestin rungossa käytetään R1 muotoisen asiakirjan ympärillä oikeita RIM viitemallista johdettuja elementtejä. CDA asiakirja ei ota kantaa asiakirjojen tiedonvälitys muotoon, mutta koska niiden semantiikka on johdettu RIM viitemallista, on CDA standardin yhteentoimiva muiden HL7 V3 standardien kanssa, kuten tiedonvälitys standardien. CDA on tarkoitettu mahdollistamaan kaikkien kliinisen potilastiedon tallentaminen ja välittäminen. CDA määrittely on hyvin ilmaisuvoimaista ja laajennettavaa säilyttäen kuitenkin koneluettavuuden [DOL06]. RIM ja HL7 V3 tietotyypit yhdessä mahdollistavat muiden koodaus standardien kuten SNOMED CT ja LOINC käyttämisen CDA asiakirjoissa [DOL06]. Nämä CDA standardin ominaisuudet mahdollistavat sen käyttöönoton ja soveltamisen paikalliseen käyttötarkoitukseen ja lainsäädäntöön sopiviksi. Kuten aikaisemmin mainittiin luvussa 3.1 mainittiin, HL7 V3 standardien tarkoitus ei ole määritellä kuin järjestelmien välillä siirrettävien asiakirjojen rakenne ja merkitys. Täten CDA asiakirjojen käyttäminen ei ole pakollista järjestelmän sisäisenä tietomallina, ainoastaan sen muille rajapinnoille tarjoamissa rajapinnoissa. Tämä kuitenkin edellyttää, että paikallisen tietomallin ja CDA asiakirjan välille voidaan muodostaa kahden suuntainen muunnos. 5 CDA asiakirjan rakenne CDA asiakirja koostuu otsakkeesta (header) ja rungosta (body). Kumpikin osa koostuu CDA standardin määrittelemistä XML elementeistä. Otsakkeen tehtävänä on sisältää metatietoa itse varsinaisesta kliinisestä asiakirjasta, kuten tietoa varmennuksesta ja potilaasta [DOL06]. Metatiedon on tarkoitus myös helpottaa tiedonhakua, joka kohdistuu potilasasiakirjoihin. Otsake on XML enkoodattu CDA julkaisuissa R1 ja R2, joten se on aina koneluettavaa. Otsake sisältää tietyt pakolliset elementit ja useita vapaaehtoisia elementtejä.

11 8 Asiakirjan runko on huomattavasti vapaamuotoisempi kuin otsake. Vaikka CDA R2 vaatii, että myös runko on XML enkoodattu käyttäen RIM viitemallin luokkia elementteinä, mahdollistaa se kuitenkin toteuttajalle vapaammat kädet, kuinka esittää varsinainen kliininen potilastieto. Varsinainen kuvaus tapahtumista voidaan esimerkiksi sisällyttää PDF asiakirjana osaksi CDA asiakirjan runkoa. Tämä heikentää osaltaan esimerkiksi tiedonhaun suorittamista hajautetusti eri järjestelmissä. Seuraavissa aliluvuissa esitellään tarkemmin asiakirjan otsakkeen ja rungon rakenne CDA R2 standardin mukaisesti. 5.1 CDA otsake CDA asiakirjan otsake sisältää kuvailevaa tietoa asiakirjasta. Se sisältää esimerkiksi asiakirjan luontiajankohdan, tietoa asiakirja laatijasta ja yksilöivän asiakirja tunnisteen. Otsakkeen sisältämää tietoa käytetään muun muassa tietojen arkistoinnin apuna, sähköisten allekirjoitusten säilömiseen, tiedonhaussa ja eri sidosryhmien tarvitsemien tietojen koostamisessa, kuten laskutus reskontrassa. CDA standardi määrittelee tietyt otsakkeen elementit ja niiden attribuutit pakollisiksi, jotka esitellään taulukossa 3 Suomen terveyden huollossa [KAN15, THL07] käytössä olevien tulkintojen mukaisesti.

12 9 Elementti typeid id code effectivetime confidentialitycode recordtarget author custodian Selitys Asiakirjan pohjana olevan CDA R2 version numero. Suomessa käytännössä typeid root=' '. Asiakirjan yksikäsitteinen yksilöivä tunniste. Asiakirjan potilasrekisteritunnus, jolla ilmaistaan mihin henkilörekisteriin asiakirja kuuluu. Asiakirjan alkuperäinen luontiajankohta, jota käyttäjä ei saa tuottaa tai muokata. Asiakirjan luottamuksellisuuden turvaluokitus. 1 = 'erittäin salainen' ja 5='terveydenhuollon salassapidettävä' Asiakirjan kohteen tunniste on sen potilaskertomuksen tunniste, johon kyseinen asiakirja liityy. Suomessa asiakirja kuuluu aina potilaalle eli recordtarget sisältää potilaan tunnnistetiedot (Hetu). Asiakirjan laatija. Entiteetit ja niiden roolit jotka loivat asiakirjan. Asiakirjan ylläpidosta vastuussa oleva entiteetti. Eli organisaatio jonka vastuulla asiakirjan säilyttäminen on. Taulukko 3: CDA asiakirjan otsakkeessa vaaditut elementit [KAN15, THL07]. Pakollisia elementtejä ei ole montaa, mutta niiden avulla voidaan esimerkiksi hoitaa arkistointi. Näiden elementtien lisäksi on olemassa useita vapaaehtoisia elementtejä, joita voidaan sisällyttää otsakkeeseen. Mitä enemmän ja tarkempia otsakkeen tiedot ovat, sitä monimutkaisempiin tietotarpeisiin voidaan otsakkeiden avulla vastata.

13 CDA runko Runko sisältää varsinaisen potilasasiakirjan sisällön eli raportin terveydenhuollon kliinisestä tapahtumasta. CDA R1 muotoisessa asiakirjassa runko voi olla rakenteenneton BLOB olio. Rakenteellisen rungon juuri elementtinä käytetään StructuredBody elementtiä ja rakenteettoman juurena toimii NonXMLBody elementti. Rankenteellinen runko koostuu yhdestä tai useasta section elementistä, joista jokainen on yksittäinen kertomus [DOL07]. Section elementin tulee sisältää text elementti, joka on section osion ihmisluettava versio. Section on CDA asiakirjan kriittinen osa [DOL07], sillä se sisältää tiedon siitä mitä kaikkea yhdessä tapahtumassa on tapahtunut. CDA asiakirjan runko siis dokumentoi yhden terveydenhuollon tapahtuman. <section> <id root='..' extension='..' /> <code code='345' codesystem=' ' codesystemname='ar/ydin' displayname='yhos' /> <title>.. </title> <text>.. <content>ihmisluettava sisältö</content>.. </text> <subject>.. </subject> <author>.. </author> <!-- Mahdolliset aliosiot <component> <section>.. </section> </component> </section> Taulukko 4: CDA asiakirjan rungon section elementti esimerkki. Taulukossa 4 on esitetty karsittu esimerkki section elementistä. Section voi sisältää myös toisia section elementtejä, joten niistä muodostuu rekursiivinen hierarkkia. Muita section elementin sisältäviä elementtejä on esimerkiksi observation elementti, mutta text elementti on ainoa pakollinen. CDA standardi ei takaa että ihmisluettavan elementin (text elementti) sisältö vastaa mahdollista rakenteellista tietoa. Tämä on jätetty toteuttajan vastuulle. Text elementin sisällä voi käyttää tekstinjäsentämiseen tarkoitettuja elementtejä kuten yläindeksi (sub elementti) tai rivinvaihto (br elementti).

14 11 6 CDA käytännössä CDA on maailmanlaajuisesti eniten käytetty HL7 V3 sovellus [BEN12]. CDA on käytössä potilastietojen vaihdossa Suomessa, Kreikassa ja Saksassa sekä pilottiprojekteja on käynnissä Kanadassa, Japanissa, Koreassa, Meksikossa ja Argentiinassa [HL7CDA]. Suomessa CDA R2 valittiin asiakirjojen arkistointi muodoksi kansallisen terveysarkiston Kanta projektissa [KAN07]. Suomalainen sähköinen resepti, joka korvasi paperisen lääkemääräyksen lopullisesti vuonna 2015, on muodoltaan CDA asiakirja. Kanta projektin sivusto [KANW15] listaa useita kymmeniä CDA standardiin pohjautuvia asiakirja määrittelyjä. Seuraavassa kahdessa aliluvussa esitellään näistä kaksi. 6.1 Kanta lähete ja hoitopalaute Kanta lähetteen ja hoitopalautteen CDA R2-rakenne [KAN14] noudattaa CDA standardin potilaskertomus. Lähete asiakirjan runko osa koostuu kahdesta pääosiosta. Ensimmäinen on Määrittämätön hoitoprosessin vaihe, jonka sisällä on kuvattuna lähetteen tekniset ja osapuolitiedot ja hoidon priorisointi. Toinen pääosio on Tulotilanne, joka sisältää lähetteessä käytettävät otsikot. Tulotilanteessa kuvataan muun muassa hoidon syy, informointi, asiakirjat ja aikaisempi hoito. Hoitopalaute asiakirjan rakenne on muuten samanlainen, mutta rungon näkymätunnus on PAL tunnuksen LÄH sijasta ja Tulotilanne osion korvaa Hoidon arviointi osio. Hoidon arviointi osiossa kuvataan muun muassa loppuarvio, hoidon tarve, tutkimukset, toimenpiteet ja diagnoosi. 6.2 Kanta suun terveydenhuollon potilaskertomus Kanta suun terveydenhuollon CDA R2 potilaskertomusrakenne [KANS15] on kehitetty suun terveydenhuollon ominaispiirteet huomioiden. Sen määrittely on huomattavasti monimutkaisempi kuin edellä käsitellyn lähetteen, sillä sen on tarkoitettu kattavan kaikki suun terveydenhuoltoon liittyvät erilaiset toimenpiteet ja hoitotapahtumat. Asiakirjan rungossa on määritelty otsake hampaiston nykytilalle, jonka sisälle voidaan koodata jokaisen yksittäisen hampaan nykytila käyttäen erillistä STH01 tietosisältömäärittelyä. Asiakirjan muita pääosiota ovat muuan muassa purentastatus, pehmyt- ja kovakudoksen havainnot sekä suun terveydenhuollon indeksit ja mittaukset.

15 12 Näiden lisäksi potilaskertomus sisältää tavallisen terveydenhuollon potilaskertomuksessa myös esiintyviä otsikoita kuten diagnoosi, käyntisyy, laboratorio, toimenpiteet ja lääkehoito. 6.3 CDA muissa maissa CDA on Suomen lisäksi käytössä kansallisesti Kreikassa ja Saksassa [HL7CDA]. Yhdysvalloissa CDA ei ole sinällään käytössä. Sen sijaan käytössä on Continuity of Care Document (CCD), joka yhdistää ASTM CCR ja HL7 CDA standardit. CDA standardin näkökulmasta ASTM CCR on standardoitu tieto kokoelma, jota voidaan käyttää rajoittamaan CDA asiakirjoja erityisesti potilaskertomuksien kohdalla [CCD11]. Toinen tapa käsittää CCD on nähdä se kokelmana template:ja, jotka ovat semanttisesti yhtenäisiä CCR standardin kanssa [BEN12]. 6.4 Yhteentoimivuus CDA R1 standardissa esiteltiin CDA tasot. Tasot kuvaavat asiakirjojen vaihdon semanttisen yhteentoimivuuden astetta [BOO11, s.20]. Tasot eivät ole tarkasti määritelty CDA standardin yhteydessä. Tasolla 1 CDA asiakirjojen otsakkeen metatiedot ovat esitetty ihmis- ja koneluettavassa muodossa. Tasolla 2 ihmisluettavassa sisällössä käytetään HTML merkkauskielen tapaisia tekstinjäsennys elementtejä. Tasolla 3 ihmisluettava semanttinen sisältö on esitetty myös koneluettavassa semantisessa muodossa. CDA tukee yhteentoimivuutta usealla tasolla, joten sen käyttöönotto voidaan toteuttaa inkrementaalisesti [BOO11]. Paikalliset CDA standardin laajennokset vaikeuttavat eri järjestelmien yhteentoimivuudeen saavuttamista. Suomen terveydenhuoltoa varten on laadittu omat laajennokset CDA asiakirjan otsaketta varten, mutta laajennoksen määrittelevää skeema ei ole toteutettu [THL07]. Tällöin asiakirjojen vastaanottaja ja lähettäjä joutuu itse toteuttamaan asiakirjojen oikeellisuuden tarkistuksen, jotka eivät välttämättä ole keskenään yhdenmukaiset.

16 13 7 Yhteenveto Terveydenhuollossa syntyy paljon tietoa, joka tarvitsee tallentaa erilaisina asiakirjoina. Asiakirjojen sisältöön ja säilyttämiseen vaikuttaa paikallisen lainsäädännön lisäksi tietotarpeet, joiden mukaan asiakirjoja täytyy pystyä tulevaisuudessa hakemaan ja selaamaan. Terveydenhuollossa asiakasta hoidetaan usein monessa eri sairaalassa ja toimipisteessä. Potilaan tietoja täytyy pystyä välittämään näiden pisteiden välillä. Asiakirjoja säilötään sähköisessä muodossa, jolloin eri järjestelmien välinen yhteentoimivuus asettaa myös vaatimuksia asiakirjojen sisällölle. CDA asiakirjastandardi pyrkii parantamaan järjestelmien välistä yhteentoimivuutta määrittelemällä järjestelmien välillä siirrettävien asiakirjojen sisällön ja merkityksen. CDA on yksi HL7 V3 standardeista ja se pohjautuu RIM viitemalliin. CDA asiakirja voidaan jakaa kahteen osaan. Otsakkeessa on metatietoa varsinaisesta asiakirjasta, jota voidaan käyttää apuna tiedonhaussa ja arkistoinnissa. Otsakkeen tiedot ovat CDA asiakirjassa aina koneluettavissa. Toinen asiakirjan osa on runko, joka sisältää varsinaisen kliinisen hoidon asiakirjan. Se voi myös sisältää rakenteetonta dataa, kuten pdf asiakirjan. CDA R2 asiakirjassa, myös runko on rakenteellista ja se käyttää XML elementteinä RIM viitemallin luokkia. RIM viitemallin käyttö mahdollistaa tiedon jakamisen lisäksi myös merkityksen jakamisen eri järjestelmien välillä. CDA on eniten käytetty HL7 V3 sovellus ja se on käytössä Suomessa osana Kansallista Terveysarkisto hanketta. Kanta arkistoon säilöttävät asiakirjat ovat CDA asiakirjastandardin mukaisia. Suomalaisen sähköinen resepti on myös CDA asiakirja. CDA asiakirjastandardin eri julkaisut ovat taaksepäin yhteensopivia. Yhdessä CDA tasojen kanssa, eri julkaisut mahdollistavat CDA asiakirjastandardin käyttöönoton inkrementaalisesti.

17 14 Lähteet BEN12 BEY04 BOO11 CCD11 DOL01 DOL06 HL7A HL7CDA HOO04 ISO09 KAN07 Benson, Tim, Principles of health interoperability HL7 and SNOMED. Springer Science & Business Media, Beyer, M., Kuhn, K., Meiler, C., Jablonski, S., Lenz, R., Towards a Flexiple, Process-Oriented IT Architecture for an Integrated Healthcare Network. ACM Symposium on Applied Computing, 2004, sivut Boone, Keith, The CDA Tm Book. Springer Science & Business Media, Kalvosarja, Dolin B, CDA and CCD for Patient Summaries. Health Level Seven International, %20CCD%20for%20Patient%20Summaries.pdf [ ] Dolin, R et al., The HL7 Clinical Document Architecture. Journal of the American Medical Information Association, Volume 8, Number 6, lokakuu Dolin, R et al. The clinical document architechture, release 2. Journa of the American Medical Informatics Association, numero 13.1, 2006, sivut About Health Level Seven International. Health Level Seven International. [ ] HL7 Standards Product Brief CDA Release 2. Health Level Seven International. product_id=7 [ ]. Hoo, J., Dodgu, E., Sunderraman, R., Health Level-7 Compliant Clinical Patient Records System. ACM Symposium on Applied Computing, 2004, sivut ISO/HL :2009, Data Exchange Standards HL7 Clinical Document Architecture, Release 2. ISO, KANTA Arkistopalvelu Vaatimusmäärittely. Sosiaali- ja terveysministeriö,

18 [ ] 15 KAN14 KAN15 Lähetteen ja hoitopalautteen CDA R2-rakenne. Kansallinen terveysarkisto, %C3%A4hete+5.1/7fcea42e-cab9-4ccd-a815-7de46ff8995f [ ] Potilastiedon arkiston CDA R2 Header. Kansallinen terveysarkisto ja HL7 Finland ry, Versio 4.66, päivitetty viimeksi [ ] KANS15 Suun terveydenhuollon CDA. Kansallinen terveysarkisto, [ ] KANW15 HL7 Tietotekniikan ja yhteyksien toteuttajille kanta.fi. Kansallinen terveysarkisto. [ ] THL07 Taskinen, T et al., HL7-Standardien soveltuvuus sosiaalihuoltoon. Terveyden ja hyvinvoinnin laitos, lokakuu [ ]