ASIAKIRJASTANDARDIN IMPLEMENTOINTI- SUUNNITELMAN TAUSTASELVITYS

Sosiaalialan tietoteknologiahanke ASIAKIRJASTANDARDIN IMPLEMENTOINTI- SUUNNITELMAN TAUSTASELVITYS Versio 1.0 Helmikuu 2008 Kuopion yliopisto, Tietojenkäsittelytieteen laitos Jari Savolainen Timo Tiihonen Teppo Taskinen Virpi Hotti Kuopion yliopisto, Tietotekniikkakeskus, HIStutkimusyksikkö Esa Paakkanen Juha Mykkänen

Sisällysluettelo 1 JOHDANTO... 4 2 VALIDOINTI... 9 2.1 XML Schema... 11 2.2 Relax NG... 12 2.3 Schematron... 13 2.4 Validointipalvelun toteuttamisen vaihtoehto... 17 2.5 Java Architecture for XML Binding... 19 3 CDA R2 -STANDARDIN SOVELTAMINEN SOSIAALIHUOLTOON... 22 3.1 CDA R2 -standardin taustat ja käyttö Suomessa... 22 3.2 Perusteita CDA R2 -standardin soveltamiselle sosiaalihuoltoon... 28 3.3 Metatietojen toteuttaminen CDA R2 -standardissa... 30 3.4 Asiakirjojen sisältöosien toteuttaminen CDA R2 -standardissa... 31 4 SOSIAALIHUOLLON OMA XML-POHJAINEN RATKAISU... 37 4.1 Metatietojen toteuttamisen lähtökohdat... 37 4.2 XML Schema -pohjainen ratkaisuvaihtoehto... 38 5 TIEDONSIIRTO... 43 5.1 Simple Object Access Protocol (SOAP)... 43 5.2 Medical Records... 44 5.3 KANTA-järjestelmän viestinvälitys... 46 5.3.1 Viestinvälitysarkkitehtuurin tekninen yleiskuvaus... 49 5.3.2 Viestinvälitysrajapinta... 51 5.3.3 Viestinvälitykseen liittyvät komponentit... 53 5.3.4 Käytettävät standardit... 55 6 MUITA RATKAISUUN LIITTYVIÄ OSIA... 59 6.1 Koodistot... 59 6.2 Sähköinen allekirjoitus... 62 6.3 Suostumuksenhallinta... 62 7 VERTAILUKEHYKSET... 66 8 JOHTOPÄÄTÖKSET... 71 8.1 Vaihtoehtoiset ratkaisumallit... 71 8.1.1 Rakenteiset metatiedot ja PDF/A -muotoinen sisältöosa... 71 8.1.2 Rakenteiset metatiedot ja sisältöosat... 72 8.1.3 Ratkaisuvaihtoehtojen toteuttamisen etenemisvaihtoehdot... 73 8.2 Tarvittavat päätökset ja tiedot... 75 LÄHTEET... 78 LIITE 1. XML Schema -esimerkkiskeemat LIITE 2. Esimerkkiasiakirja validointiin LIITE 3. Esimerkkiasiakirjan XML Schema LIITE 4. Esimerkkiasiakirjan Relax NG -skeema kompaktissa muodossa 2

LIITE 5. Esimerkkiasiakirjan Relax NG -skeema XML-muodossa LIITE 6. Esimerkkiasiakirjan ISO-Schematron -skeema LIITE 7. Yhteenveto Medical Records -sanomien sanomatyypin RCMR_MT000002 tietosisällöstä LIITE 8. CDA R2 -esimerkkiasiakirja 3

1 JOHDANTO Tämän selvityksen tarkoitus on tuottaa lisätietoa sosiaalihuollon asiakasasiakirjan teknisen standardin valintaa varten. Selvitys on jatkoa syksyllä 2007 julkaistuille Tikesoshankkeen raporteille HL7-standardien soveltuvuus sosiaalihuoltoon versio 1.0 [Tik07a] ja Vaihtoehdot sosiaalihuollon tekniseksi standardiksi versio 0.91 [Tik07c], jotka ovat saatavilla Tikesos-hankkeen internetsivuilta osoitteesta http://www.tikesos.fi. Selvityksessä huomioidaan Helsingissä 31.10.2007 pidetyssä Sosiaalihuollon asiakasasiakirjojen teknisten standardien valinta -työseminaarissa esitettyjä kommentteja. Tämä ja edellä mainitut selvitykset liittyvät aihealueeltaan Tikesos-hankesuunnitelmassa 2008 2011 [STM07a] esitettyyn sosiaalihuollon asiakasasiakirjojen sisällölliseen ja tekniseen standardointiin. Tarkastelun pääpaino on kohdistettu Clinical Document Architecture, Release 2 (CDA R2) -standardin ja oman Extensible Markup Language (XML) -pohjaisen ratkaisun tutkimiseen, koska edellisten selvitysten ja työseminaarin perusteella Open Document Format (ODF) ja Office Open XML (OOXML) -standardeja ei suositella käytettäväksi teknisenä asiakasasiakirjastandardina. Arkistointia varten kehitettyä Portable Document Format (PDF/A) -standardia ei myöskään suositeltu pääasialliseksi asiakasasiakirjastandardiksi. PDF/A standardin käyttöä voitaisiin pohtia tapauksissa, joissa sosiaalihuollossa ei haluta hyödyntää teknisesti rakenteistettuja asiakirjoja. Tällöin asiakasasiakirjojen sisällöille ei luotaisi teknisiä rakenteita, jolloin eri ohjelmistojen tuottamat asiakirjat samasta asiasta voisivat olla keskenään erilaisia. PDF/A -pohjainen ratkaisu soveltuisi myös vaiheittain tapahtuvan implementoinnin ensimmäiseksi vaiheeksi. Lähtökohtaisesti sosiaalihuoltoon halutaan mahdollisimman ilmaisuvoimainen ja ohjelmallisesti hyödynnettävä tekninen ratkaisu, jota eri ohjelmistotoimittajien ohjelmistot voivat käyttää. Muun muassa Tikesos-hankkeen vuosien 2008 2011 hankesuunnitelmaan [STM07a] on kirjattu, että "yhdenmukaiset rakenteet helpottavat tietojen hakua" ja "palvelun järjestäjästä ja tuottajasta riippumatta asiakastiedot ovat yhtenäisessä muodossa ja niiden siirtäminen toimijalta toiselle on mahdollista asiakkaan suostumuksella tai lain nojalla". Sosiaalihuollon asiakasasiakirjojen teknisen ratkaisun on sovelluttava myös keskitettyyn arkistointiin, koska tavoitteena on ollut, että sosiaalihuollon asiakasasiakirjat voidaan tulevaisuudessa tallentaa kansalliseen ja yhtenäiseen arkistoon. 4

Selvityksessä tarkastellaan CDA R2 -standardia ja omaa XML-pohjaista ratkaisua sosiaalihuollon metatieto-, ydintieto- ja palvelukohtaisten asiakirjamääritysten teknisen toteuttamisen kannalta. Näitä määrityksiä on toteutettu ja toteutetaan Tikesos-hankkeen eri projekteissa. Sosiaalihuoltoon valittavan standardin on mahdollistettava määritysten mukaiset tekniset toteutukset. Lisäksi toteutuksia pitää voida verrata määrityksiin mieluiten automaattisesti. Se mahdollistaisi niin sanotun validoinnin, jossa esimerkiksi ohjelmistojen tuottamien asiakirjojen oikeat rakenteet varmistetaan. Esimerkiksi ohjelmiston tuottama toimeentulotukipäätös-asiakirja voidaan todentaa oikeaksi, kun se sisältää kaikki määrittelyjen mukaiset pakolliset tiedot oikein toteutettuina. Määrittelyjen mukaisten asiakirjojen siirtäminen ohjelmistojen välillä tai arkiston välityksellä ohjelmistosta toiseen mahdollistaisi eri ohjelmistotoimittajien ohjelmistojen yhteentoimivuuden, koska sosiaalihuollon määrittelyt olisivat kaikille samat. Sosiaalihuoltoon valittavan standardin on mahdollistettava myös laajennettavuus, koska teknisiin määrityksiin on voitava tehdä lisäyksiä, jos niitä täytyy tehdä sosiaalihuollon määrityksiin. Tällöin täytyy varmistaa taaksepäin yhteensopivuus, jotta vanhojen määritysten mukaiset asiakirjat toimivat myös uusien määritysten mukaisesti. Suomen Standardisoimisliiton (SFS) standardissa SFS-ISO 23081-1 [SFS07, s. 11] esitetään vaatimuksia metatietorakenteiden toteuttamisesta. Standardin mukaan metatietoelementtien suhteiden ja merkitysten kuvaaminen edellyttää rakenteista esittämistapaa, ja tähän voidaan standardin mukaan käyttää esimerkiksi skeemoja. Skeemalla tarkoitetaan asiakirjan rakennekuvausta. SFS-ISO 23081-1 -standardissa toimijoita kehotetaan kehittämään skeemoja kuvaamaan asiakirjoja, joita luodaan, talletetaan ja hallitaan. Lisäksi näiden skeemojen pitäisi kuvata myös liiketoimintaprosesseja ja toimijoita kuvaavia kontekstitietoja. Skeemoja on ylläpidettävä, jotta ne vastaisivat organisaatio- ja liiketoimintakonteksteissa tapahtuneita muutoksia. Uusien ja aikaisempien skeemojen suhteet täytyy tunnistaa ja dokumentoida. SFS-ISO 23081-1 -standardin [SFS07, s. 12] mukaan skeemat myös tukevat dokumenttirakenteiden kuvausta esimerkiksi XML-kielellä. Skeemoja voidaan laatia esimerkiksi XML Schema ja Relax NG -kielillä. Standardin mukaan skeemat tukevat muun muassa seuraavia asioita: a) metatietojen integroitua ja johdonmukaista hallintaa 5

b) metatietomäärittelyjen keskinäistä vertailua, joka mahdollistaa erilaisten määrittelyjen yhteentoimivuuden c) elementtien ja niiden merkityssisällön keskinäisten suhteiden ilmaisemista d) metatietoelementtien suhteiden ja niiden merkityssisällön kontrollointia e) tietojärjestelmien, kuten asiakirjajärjestelmien, loogisuuden ja ristiriidattomuuden varmistamista ja ylläpitoa f) tietojärjestelmien modulaarista kehittämistä, jakamista tai yhdistämistä g) tietojärjestelmien tai tietokantojen kehittämistä Tämän (ja aikaisempien) selvityksen tekemisessä on otettu tavoitteeksi tarkastella XML-pohjaisia teknisiä ratkaisuja, joista voidaan valita kansallisesti käytettävä tapa sosiaalihuollon asiakasasiakirjojen tekniseen esittämiseen. Tarkastelu ei sisällä syvällistä pohdintaa tietomalleista, kuten HL7 RIM (Health Level Seven Reference Information Model), openehr (openehr Foundation, EHR = electronic health records) ja HISAstandardiin (Health Informatics Service Architecture, CEN-standardi EN 12967) sisältyvästä tietomallista, eikä ontologisista tai semanttisista malleista, koska selvityksessä on tarkoitus perehtyä nimenomaan asiakasasiakirjoja koskevan teknisen tason asioihin. Sosiaalihuollon tietomallin määritykset eivät ole vielä valmistuneet, joten esimerkiksi HL7 RIM:n soveltuvuutta sosiaalihuollon tietomallin mallintamiseen ei voida kattavasti arvioida. Kuitenkin voidaan arvioida HL7 RIM -mallista johdettua XML-muotoista teknistä toteutusta ja sen soveltuvuutta sosiaalihuollon tekniseksi asiakirjastandardiksi, koska tekniset yksityiskohdat asiakirjatasolla pysyvät jokseenkin samoina tietomallista huolimatta. Kuvassa 1 on havainnollistettu tämän työryhmän aihealuetta suuremmassa kokonaisuudessa. Katkoviivalla piirretty laatikko esittää aluetta, johon tämä selvitys ja johdannon alussa mainitut aikaisemmat selvitykset liittyvät. 6

Kuva 1. Selvityksen kohdealue laajemmassa kokonaisuudessa Kuvasta voidaan havaita, että tekniselle asiakasasiakirjastandardille kohdistuu vaatimuksia useasta suunnasta. Vaatimuksia ovat muun muassa sosiaalihuoltoon määriteltävät metatiedot, ydintiedot ja palvelukohtaiset asiakasasiakirjatiedot, jotka tulee toteuttaa teknisesti. Lisäksi asiakirjojen validointi asettaa vaatimuksia riippuen siitä, miten tarkalle tasolle validointi halutaan viedä. Myös kansallinen arkistointi asettaa omia vaatimuksia tekniselle asiakasasiakirjastandardille. Se voi esimerkiksi pakottaa joidenkin arkistoinnin hallinnan kannalta pakollisten metatietojen käyttöön. 7

Valittava tekninen asiakasasiakirjastandardi vaikuttaa teknisiin asiakasasiakirjamäärityksiin, koska standardi asettaa rajat, joiden puitteissa määrittelytyö on tehtävä. Kun tekniset määrittelyt on tehty, voivat sosiaalihuollon ohjelmistot periaatteessa alkaa toteuttamaan näiden mukaisia asiakasasiakirjoja, jotka voidaan tarkistaa määrityksiä vasten, mikäli validoitavuuteen on kiinnitetty riittävästi huomiota teknisissä ratkaisuissa ja määrityksissä. Mikäli validointiin ei haluta kiinnittää minkäänlaista huomiota, ei eri ohjelmistojen tuottamia asiakasasiakirjoja saada keskenään yhteensopiviksi. Mikäli ohjelmistot saadaan tuottamaan asiakasasiakirjat oikein, voidaan asiakasasiakirjat arkistoida esimerkiksi kansalliseen arkistoon, joka voi jakaa niitä suostumuksenhallinnan puitteissa siten, että toiset sovellukset osaavat niitä tulkita. Lisäksi arkiston ja sosiaalihuollon sovellusten välille on toteutettava tiedonsiirtoratkaisut, jotta arkistosta voidaan tehdä esimerkiksi hakuja ja kyselyjä. Valittava tiedonsiirtomenetelmä voi aiheuttaa tekniseen asiakasasiakirjastandardiin omia vaatimuksiaan, esimerkiksi metatietoihin. Luvussa 2 perehdytään validointiin, jota käsitellään yleisesti ja erilaisten teknisten menetelmien kautta. Luvussa 3 pohditaan CDA R2 -standardin käyttöä Suomessa ja mahdollista soveltamista sosiaalihuoltoon. Luvussa 4 tarkastellaan esimerkinomaisesti oman XML-pohjaisen ratkaisuvaihtoehdon kehittämistä sosiaalihuoltoon, koska CDA R2 - standardin soveltaminen, esimerkiksi asiakasasiakirjojen sisältöosiin, voi olla teknisesti mutkikas ratkaisu. Luvussa 5 käsitellään tiedonsiirtoon liittyviä asioita, jotka pitää ottaa huomioon, kun asiakasasiakirjoja aletaan siirtää esimerkiksi KANTA-järjestelmään. Luvussa 6 käsitellään asiakirjastandardin tekniseen toteutukseen liittyviä muita osia kuten koodistoja, sähköistä allekirjoitusta ja suostumuksenhallintaa. Luvussa 7 esitetään vertailukehys, jossa on tarkasteltu oman XML-pohjaisen ratkaisuvaihtoehdon ja CDA R2 -standardiin perustuvan ratkaisuvaihtoehdon eroavaisuuksia. Luvussa 8 esitetään johtopäätökset, jotka on tehty tämän ja aiempien selvitysten tekemisen yhteydessä. Johtopäätöksissä on analysoitu erilaisia ratkaisu- ja etenemisvaihtoehtoja. 8

2 VALIDOINTI Validointi, eli toteutusten tarkistaminen määrittelyjä vasten, on keskeinen asia, kun sosiaalihuollon asiakasasiakirjojen sähköistä käyttöä suunnitellaan. Tässä luvussa perehdytään tarkemmin validointiasioihin, jotka tuotiin esille aikaisemmassa Vaihtoehdot sosiaalihuollon tekniseksi standardiksi -raportissa [Tik07c]. Toteutettaessa sovelluksia, jotka tuottavat tietyn määritelmän mukaisia XMLasiakirjoja, pitää voida varmistua siitä, että yksittäinen XML-asiakirja vastaa asiakirjan rakennemäärityksiä. Erilaiset tekniset validointimenetelmät tarjoavat ratkaisuja tähän ongelmaan. Näitä tarvitaan, koska luonnollisella kielellä kirjoitetutut tarkatkin määritelmät sisältävät usein tulkinnanvaraisuuksia jo siitä syystä, että sama asia voidaan ymmärtää usealla eri tavalla. Tietokoneen ymmärtämään muotoon laaditut määritykset ovat yksiselitteisiä tietokoneen näkökulmasta. Tällaisissakin moniselitteisyys on mahdollista, mutta (ideaalitilanteessa) se on määritelmän ominaisuus eikä määrittelemässä käytettävän kielen ominaisuus. Nämä koneen ymmärtämään muotoon laaditut määritelmät mahdollistavat toteutuksien oikeaksi todentamisen asiakirjakohtaisesti, jolloin eri ohjelmistokehittäjien ohjelmistojen tuottamia asiakirjoja voidaan verrata niiden määrityksiin riippumatta ohjelmistojen toteutustavoista. XML-dokumenttien skeemoja (rakennemäärittelyjä) voidaan tehdä erilaisilla kaaviokielillä kuten XML Schema ja RelaxNG. XML-skeemoja voidaan laatia eri käyttötarkoituksia varten. On mahdollista luoda tietyn aihealueen, esimerkiksi sosiaalihuollon, kattava yleinen skeema, joka sisältää määritykset yleisille elementeille, joita voidaan käyttää mallintamaan koko aihealuetta kuten asiakirjarakenteita ja palvelutapahtumia. Tällöin skeemassa määritellyille elementeille annetaan tarkka merkitys riippuen elementtien käyttötarkoituksesta. Esimerkiksi lomake-elementti voi kuvata toimeentulotuki- tai päivähoitohakemusta riippuen käyttöyhteydestä. Validoinnin kannalta tämä lähestymistapa on ongelmallinen, koska esimerkiksi asiakirjan rakenne riippuu asiakirjatyypistä. Esimerkiksi toimeentulotukihakemuksen elementtisisältö eroaa ratkaisevasti päivähoitohakemuksesta, mutta yleiseksi laaditun skeeman täytyy hyväksyä molemmat asiakirjatyypit. Ongelmaksi muodostuu, kuinka voidaan varmistua, että toimeentulotukihakemus sisältää siltä vaadittavat ja vain siihen kuuluvat elementit. Tällaisesta yleisestä skeemasta voidaan käyttää myös nimitystä väljä skeema. 9

Vaihtoehtona väljille skeemoille voidaan määritellä myös niin sanottuja tiukkoja skeemoja, jotka voidaan toteuttaa esimerkiksi asiakirjatyyppikohtaisesti. Tällä tarkoitetaan, että jokaiselle asiakirjatyypille toteutetaan oma skeemamäärittely. Tällöin asiakirjojen toteutuksia voidaan helposti verrata niiden skeemamäärittelyjä vasten (validointi). Asiakirjatyyppikohtaisissa skeemoissa voidaan määritellä yksikäsitteisesti asiakirjoilta vaadittavat rakenteet. Skeemojen määrittelyssä, samoin kuin monien standardien kehittämisessä, etsitään jatkuvasti tasapainoa tarkan ja yleisen määrittelyn välillä. Näkökulmaeron voi tiivistää seuraavasti: tarkkojen asiakirjamäärittelyjen tai tarkkojen skeemamääritysten avulla saavutetaan dokumentteja käsittelevien sovellusten välillä tarkka yhteentoimivuus tiettyyn suhteellisen tarkasti määriteltyyn käyttötilanteeseen; toisaalta määritellään yleiskäyttöisiä asiakirjarakenteita tai skeemoja, joita pystytään soveltamaan hyvin erityyppisissä tilanteissa tai jotka voivat toimia kehyksenä erityyppisille asiakirjoille. Tarkan määrittelyn etuina ovat, että varsinaisten dokumenttien oikeellisuus voidaan validoida ohjelmallisesti yleisiä XML-välineitä käyttämällä, yhden määrittelyn koko säilyy suhteellisen pienenä ja dokumenttien yhteiskäytön toteutukseen eri sovelluksissa tarvitaan vähän sovitustyötä tai tarkennettuja soveltamisohjeita, koska tarkassa käyttötilanteessa voidaan määritellä pakolliseksi suuri osa käytettävistä tiedoista. Haittapuolena on, että tehty määrittely rajoittaa soveltamista uusissa tilanteissa tai sisältöjen muuttuessa, määrittelyjä tarvitaan useita erityyppisiin käyttötarkoituksiin tai asiakirjoihin ja yleensä määrittely vaatii osallistuvilta ohjelmistoilta suhteellisen tiukkaa yhteisesti määritellyn sisältömallin noudattamista. Toisaalta voidaan miettiä, miten muuttuvia sosiaalihuollon asiakirjat ovat. Muutokset laeissa tai toimintakäytännöissä voivat vaikuttaa asiakirjoihin tallennettaviin tietoihin. Lait muuttuvat hitaasti, ja käytännötkin ovat pitkälti vakiintuneita. Suurimmat muutokset toimintakäytäntöihin tulevat, jos sosiaalihuollon tietojärjestelmät kehittyvät prosessiohjaavaan suuntaan. Yleisen määrittelyn etuna on saman määrittelyn sovellettavuus ja laajennettavuus uusiin käyttötilanteisiin tekemättä teknisen tason muutoksia XML-rakenteiden määrittelyihin (skeeman muuttumattomuus) sekä usein helpompi sovitettavuus olemassa olevien sovellusten omiin tietomalleihin. Yleiskäyttöisessä määrittelyssä on jätettävä vapaaehtoiseksi suuri joukko tarkasti määriteltyjä tietoja tai tehtävä vain yleisen tason runko sisällölle. Tällöin tarkkoja käyttötilanteita varten tarvitaan ulkoisia soveltamisohjeita tai -oppaita, mikä taas johtaa siihen, että ratkaisujen ja asiakirjojen käyttötilannekohtaisen 10

oikeellisuuden validointiin ei voida käyttää yleisiä XML-työkaluja. Tämä, samoin kuin ymmärrettävyyttä haittaava skeemojen moniselitteisyys, voidaan nähdä yleiskäyttöisten skeemojen haittapuolena. Valinta tarkan ja yleisen määrittelyn välillä on keskeinen arkkitehtuuripäätös toteutettaessa järjestelmien välistä integraatiota tai muita XML-dokumentteihin pohjautuvia ratkaisuja tietojen sisällön osalta. Molempiin tavoitteisiin pyrkiminen johtaa helposti erittäin laajoihin skeemoihin, joita käsitteleviin sovelluksiin ei useinkaan ole järkevää toteuttaa kaikkien tarkalla tasolla määriteltyjen ominaisuuksien tukea. Luvussa 2.1 perehdytään XML Schema -kieleen. Luvussa 2.2 käsitellään Relax NG - kieltä ja luvussa 2.3 Schematron-kieltä. Luvussa 2.4 visioidaan mahdollisen validointipalvelun kehittämistä ohjelmistojen tuottamien asiakasasiakirjojen määritysten mukaisuuksien varmistamiseksi. Asiakirjastandardin tekniseen toteutukseen liittyen arvioidaan lisäksi automaattisten työkalujen mahdollisuuksia. Esimerkiksi kaaviokielisistä teknisistä määrittelyistä voidaan tietyin edellytyksin luoda sovellusten käyttöön valmiita rajapintoja. Näiden rajapintojen avulla voidaan huomattavasti helpottaa sovelluskehitystä. Luvussa 2.5 käsitellään Java-pohjaista toteutusta XML Schema -määritysten kannalta. 2.1 XML Schema XML Scheman kehitystyö alkoi vuonna 1999 W3C:n (World Wide Web Consortium) toimesta. XML Schemaa edeltäneet kaaviokielet eivät tukeneet tarpeeksi kattavasti muun muassa nimiavaruuksia ja vahvaa tietotyypitystä. XML Schema suunniteltiin täyttämään nämä puutteet ja kieleen lisättiin myös muita ominaisuuksia. XML Schema on laaja kieli ja sen täydellinen läpikäyminen tämän selvityksen puitteissa ei ole tarkoituksenmukaista. XML Schema -kieltä käytetään yleisesti määrittelemään XML-dokumenttien rakenne, elementit, attribuutit, attribuuttien tietotyypit ja tarvittaessa myös attribuuttien arvoille sallitut arvojoukot. XML Schema -kielessä on valikoima sisäänrakennettuja tietotyyppejä, ja sen avulla voidaan määritellä myös uusia tietotyyppejä. Toisin sanoen skeemalla tarkoitetaan XML:n soveltamistapaa ja "XML-kieltä" tiettyyn käyttötarkoitukseen. [FaW04] 11

XML Schema perustuu kielioppeihin ja se ei salli epädeterministisiä rakenteita. Tästä johtuen XML Schemalla ei voida toteuttaa muun muassa ehdollisia rakenteita. Esimerkiksi tilanne, jossa pitäisi päättää elementin sisällöstä attribuutin arvon perusteella, ei ole ilmaistavissa XML Schemalla. Liitteessä 3 on esitetty liitteessä 2 kuvatun asiakirjan rakennemäärittely XML Schema - kielellä. Liitteen 3 XML Schema -skeema on laadittu siten, että asiakirjan juurielementti tulee yksikäsitteisesti määrätyksi. Tästä johtuen alielementit on esitelty paikallisesti ylemmän tason elementtien sisällä. Skeema voitaisiin myös rakentaa siten, että kaikki elemetit määritellään globaaleiksi, jolloin niitä voitaisiin käyttää uudelleen viittaamalla niihin nimen perusteella. Näin toimittaessa juurielementti ei tule yksikäsitteisesti määrätyksi ja juurielementin oikeellisuuden varmistamiseen jouduttaisiin käyttämään jotain muuta mekanismia, esimerkiksi luvussa 2.3 käsiteltävää Schematronia. XML Schema tuottaa validoinnin tuloksena PSVI:n (Post Schema Validation Infoset), jossa on enemmän informaatiota kuin alkuperäisessä XML-dokumentissa, tämä voidaan nähdä sekä hyötynä että haittana. PSVI liittää jokaiseen alkuperäisen XML-asiakirjan solmuun, esimerkiksi elementteihin ja attribuutteihin tietotyypin. XML Schema - validoinnin tuloksena syntynyttä PSVI:tä voidaan hyödyntää ohjelmallisesti, esimerkiksi XPath 2.0 ja XQuery -kielten avulla valitsemaan rakenteita tietotyypin perusteella. PSVI:n yhtenä hyötynä voidaan pitää juuri tietotyyppien sidontaa XML-asiakirjan solmuihin. Haittapuolena voidaan pitää, että validointi on suoritettava aina, kun halutaan hyödyntää PSVI:n tarjoamaa informaatiota (jos PSVI:tä ei tallenneta validoinnin tuloksena). 2.2 Relax NG Relax NG perustuu kielioppeihin kuten XML Schema. Relax NG on kehitetty myöhemmin kuin DTD (Document Type Definition) ja XML Schema. Tästä syystä Relax NG -kielen kehittäjät ovat voineet ottaa kehitystyössä huomioon edellä mainittujen kaaviokielten ongelmia. Relax NG perustuu vahvoille matemaattisille malleille, jolloin skeemavalidaattoreiden kehitystyö yksinkertaistuu ja skeemojen kehittäjät voivat tehdä matemaattisia väitteitä kehittämistään skeemoista. [HRF07] Relax NG -kielen käytölle on olemassa kaksi vaihtoehtoista esitystapaa. Toisessa vaihtoehdoista Relax NG -skeema kirjoitetaan XML-muodossa, jolloin sen hyödyntäminen 12

on suoraviivaista olemassa olevilla XML-työkaluilla. Relax NG -skeemat voidaan myös kirjoittaa niin sanotussa kompaktissa muodossa. Kompaktimuoto muistuttaa enemmän ohjelmointikielten, esimerkiksi Javan, syntaksia. Relax NG -skeemojen laadinta kompaktissa muodossa on helpompaa kehittäjille, mutta geneeriset XML-työkalut, esimerkiksi XSLT, eivät pysty suoraan käsittelemään skeemoja tässä muodossa. Relax NG - skeemojen kompaktista muodosta pystytään automaattisesti generoimaan XML-muoto, jonka käsittely on mahdollista geneerisillä XML-työkaluilla. ISO-standardin mukainen Relax NG ei tuota validoinnin tuloksena PSVI:tä. Tämä tarkoittaa, että kaikki informaatio on varastoituna XML-asiakirjaan, eikä validointi tuota lisäinformaatiota asiakirjasta. Etuna tällaisesta lähestymistavassa on, että validointia ei ole tarpeen suorittaa aina kun asiakirjaa käsitellään, koska validointi ei tuota käsittelyn kannalta arvokasta lisäinformaatiota. Relax NG -validointi vastaa ainoastaan kysymykseen "onko XML-asiakirja määrittelyn mukainen". Liitteessä 4 on esitetty liitteessä 2 kuvattavan asiakirjan rakennemäärittely käyttäen Relax NG:n kompaktia syntaksia. Liitteessä 5 on esitetty sama rakennemäärittely käyttäen Relax NG:n XML-muotoa. XML-muoto on generoitu automaattisesti Java-työkalulla kompaktista muodosta. 2.3 Schematron Schematron on kehitetty täydentämään muita XML-menetelmiä. Schematron-validointi ei perustu kielioppeihin, joten se eroaa ratkaisevasti esimerkiksi XML Schemasta. Schematron-kielellä toteutettu validointi perustuu puurakenteiden etsimiseen jäsennetyn XML-dokumentin rakennepuusta. Rakenteet, jotka olisi vaikea toteuttaa kieliopein, voidaan validoida Schematronin tarjoamin menetelmin. [Sch04] Schematron-validointi voidaan toteuttaa teknisesti hyödyntäen XSLT-muunnoksia (Extensible Stylesheet Language Transformations, XSL Transformations) kahdessa vaiheessa. Kuvassa 2 on esitetty, kuinka Schematron-validointi tapahtuu vaiheittain käyttäen hyväksi XSLT-muunnoksia. 13

Kuva 2. Schematron-validointi käyttäen XSLT-muunnoksia [mukailtu Dod01] Kuvan vaiheessa 1 suoritetaan ensimmäinen muunnos, jossa ISO (International Organization for Standardization) standardin mukaisesta Schematron-rungosta ja Schematron-skeemasta muodostetaan Schematron-validaattori. Schematron-runko on XMLmuodossa oleva Schematronin ISO:n määritelmän mukainen XSLT-muunnostiedosto, jonka avulla Schematron-skeemasta voidaan tuottaa validaattori dokumentteja varten. Schematron-skeemassa määritellään säännöt, joiden mukainen validoitavan dokumentin tulisi olla. Vaiheessa 2 käytetään hyväksi vaiheessa 1 tuotettua validaattoria. XSLTmuunnoskielellä esitetty validaattori ottaa syötteenä sisään validoitavan XML-asiakirjan ja tuottaa muunnoksen tuloksena koko validoinnin tuloksen. [Dod01] Schematron-skeemoissa XML-dokumentin rakenteesta luodaan väittämiä. Väitteet eli väittämät (assertions) sisältävät testin, jonka täytyy olla tosi väitteen ollessa tosi. Väitteitä merkataan XML-elementeillä assert ja report. Assert-tyypin väittämien täytyy pitää paikkaansa, jotta XML-dokumentti olisi skeeman mukainen. Väittämiä voidaan niputtaa yhteen säännöiksi. Säännöt (rules) vaativat aina kontekstin (context). Säännön sisältämät väittämät arvioidaan säännön kontekstissa. Sääntöjä merkataan XML-elementillä rule. Rule-elementin on sisällettävä context-attribuutti, jos sääntö ei ole yleinen (abstract). Säännöt voidaan merkitä yleisiksi asettamalla abstract-attribuutin arvo todeksi (true). Yleisille säännöille ei määritellä kontekstia, vaan niitä käytetään osana muita sääntöjä, jolloin konteksti tulee määritellyksi. Yleisillä säännöillä voidaan lisätä skeeman yleiskäyttöisyyttä. [ISO04] Schematron vaatii toimiakseen kyselykielen. Kyselykielenä voidaan käyttää mitä tahansa kyselykieltä, jos se täyttää Schematronin sille asettamat vaatimukset. Yleisesti käytössä olevia XML-sovelluksiin tarkoitettuja kyselykieliä ovat muun muassa XPath 1.0, 14

XPath 2.0 ja XQuery. [ISO04.] Schematron toteutukset, jotka nojaavat XPath-kieleen, käyttävät XPath-kieltä esimerkiksi väittämien testien arviointiin. Schematronia on mahdollista käyttää täydentämään muita validointimenetelmiä. Tämä on suositeltavaa varsinkin silloin, kun kielioppeihin perustuvat validointimenetelmät eivät tehtävään sovi tai validoinnin toteuttaminen niillä on vaikeaa. Schematronin perustuessa kyselykieleen, kuten XPath, voidaan väittämien testeissä ilmaista moninaisia rakenteita, joilla voidaan toteuttaa erittäin tiukkoja tai yleisiä väittämiä. Seuraavassa esimerkissä on Schematron-väittämä, joka vaati, että kontekstisolmu sisältää vähintään kolme alielementtiä: <iso:assert test="count(element()) > 2">Kontekstisolmu ei sisällä vähintään kolmea alielementtiä!</iso:assert> Seuraavassa esimerkissä on esitetty tiukka ehto, jonka mukaan kaikkien alielementtien, joita täytyy olla vähintään yksi, tulee sisältää alielementti ali, jonka attribuutin nimi arvon pitää olla alinimi: <iso:assert test='(count(element()) > 0) and (count(element()) = count(element()/ali[@nimi = "alinimi"]))'>väite väärä</iso:assert> Esimerkin väite voi olla hankala luettava XPath-kieleen perehtymättömälle, mutta XPath- ja XSLT-kieliin tutustuneille Schematron-väitteiden lukeminen on suoraviivaista. Tämän vuoksi Schematronin käyttö validointityökaluna on mahdollista ilman suurta oppimiskynnystä. Kuvassa 3 on esitetty väitteen <assert test="count(element()) = 2"> </assert> rakennepuu. Väite tarkastaa, onko kontekstisolmulla tarkalleen kaksi alielementtiä. Kuvassa 4 on esitetty esimerkki-xml-dokumentin rakennepuu, johon kuvassa 3 esitettyä väitettä testataan esimerkin vuoksi. Kuva 3. Väitteen <assert test="count(element()) = 2"> </assert> rakennepuu 15

Kuva 4. Esimerkki-XML-dokumentin rakennepuu Kuvassa 3 esitettyä väitettä käytetään säännön testi yhteydessä elementti kontekstissa, jolloin väitettä testataan jokaista kuvan 4 rakennepuussa esitettyä solmua kohden: <rule id="testi" context="element()"> <assert test="count(element()) = 2"> </assert> </rule> Kuvassa 5 on esitetty ne tilanteet, joissa väite pitää paikkansa. Kirjain K tarkoittaa kontekstisolmua. Kuva 5. Tilanteet joissa kuvan 3 väite pitää paikkaansa kuvan 4 esimerkissä Huomionarvoista on, että väite huomioi vain kontekstielementin välittömät lapsielementit, eikä sisällytä lapsielementtien lapsielementtejä tulokseen. Väite voitaisiin muotoilla myös siten, että alielementtien kokonaismäärän tulisi olla kaksi, mutta sen havainnollistaminen kuvan keinoin olisi huomattavasti hankalampaa. Kuvassa 6 on esitetty osa tilanteista, joissa väite ei pidä paikkaansa. Kuva 6. Osa tilanteista, joissa kuvan 3 väite ei pidä paikkaansa kuvan 4 esimerkissä Edellä mainitun esimerkin mukaisen rakenteen määrittely kielioppeihin perustuvilla skeemakielillä olisi vaikeaa. Esimerkeistä voidaan havaita, kuinka Schematron-kielellä on mahdollista luoda puun rakenteita vertailevia väittämiä ilman, että otettaisiin kantaa 16

elementtien nimiin. Toisaalta myös nimiin perustuva validointi on mahdollista Schematron-kielellä. Schematronilla voidaan toteuttaa myös ehdollisia väittämiä kuten "jos elementillä x on ominaisuus y, täytyy elementillä x olla myös ominaisuus z". Liitteessä 6 on esitetty liitteessä 2 kuvatun asiakirjan rakennemäärittely Schematronkielellä. Huomionarvoista on, kuinka Schematronia käytettäessä joudutaan elementtien järjestys määräämään eksplisiittisesti, eikä esimerkiksi väittämien järjestys takaa elementtien esiintymisjärjestystä. Schematronia käytetään yleensä kielioppeihin perustuvien validointimentelmien lisänä, mahdollistamaan rakenteet, joita ei voida kieliopein esittää. Schematron yksin ei ole ideaalivaihtoehto validointimenetelmäksi, jos on tarpeen määritellä elementtien keskinäinen järjestys. 2.4 Validointipalvelun toteuttamisen vaihtoehto Mikäli sosiaalihuollossa määritellään asiakasasiakirjoja kuvaavia XML-skeemoja esimerkiksi XML Schema ja Schematron -kielillä tai mikäli standardiksi valitaan CDA R2, täytyy validointimahdollisuus toteuttaa jollakin tavalla. Yksi vaihtoehto on ottaa mallia Kanadan British Columbia -provinssin ratkaisusta [KAS06], jossa validointia varten on kehitetty web-pohjainen palvelu, joka validoi saamansa XML-dokumentin XML Schema ja Schematron -skeemoja vasten. Kuvassa 7 on havainnollistettu Kanadan ratkaisun validointiprosessin kulkua. 17

Kuva 7. Web-validointipalvelu [mukailtu KAS06] Kuvassa lähettävä ohjelmisto voi hyödyntää web-validointipalvelua tarkistaakseen, onko tuotettu XML-asiakirja sen määrittelyjen mukainen. Tässä esitetyn validointipalvelun ideana on tarjota ohjelmistokehittäjille mahdollisuus testata ohjelmistojen tuottamien asiakirjojen määritystenmukaisuus. Kuvan alussa ohjelmisto on hyödyntänyt implementointioppaita ja asiakirjan rakennetta kuvaavia XML Schema sekä Schematron -skeemoja asiakirjan tuottamisessa. Kun ohjelmisto on tuottanut asiakirjan, pitää tehdä päätös validoinnin tarpeellisuudesta. Mikäli validointia ei haluta suorittaa, voidaan siirtyä suoraan pakkaamaan asiakirja siirtokehykseen ja lähettämään tämä eteenpäin. Mikäli validointi halutaan suorittaa, lähetetään 18

asiakirja web-validointipalveluun, joka vertaa asiakirjaa sen määrittelyskeemoihin ja antaa lähettävälle ohjelmistolle palautteen tuloksista. Web-validointipalvelu suorittaa validoinnin kahdessa osassa. Asiakirja tarkistetaan XML Schema ja Schematron-skeemoja vasten. Mikäli asiakirja läpäisee molemmat tarkastukset, on se määrittelyjen mukainen ja web-validointipalvelu antaa lähettävälle ohjelmistolle "ok" -palautteen. Mikäli asiakirja ei läpäise molempia skeemoja, ei se ole määrittelyjen mukainen ja web-validointipalvelu antaa lähettävälle ohjelmistolle virheilmoituksen. Saatuaan palautteen, voi lähettävä ohjelmisto suorittaa tämän perusteella tarvittavat toimenpiteet. Mikäli asiakirja on läpäissyt validoinnin, voidaan se pakata siirtokehykseen ja lähettää eteenpäin. Mikäli validoinnissa on ilmennyt virheitä, täytyy ne korjata ja suorittaa validointi uudestaan. Luvussa esitetyn kaltainen web-pohjainen validointipalvelu voitaisiin toteuttaa myös sosiaalihuollon ohjelmistojen testausympäristöksi, jossa ohjelmistot voisivat varmistaa tuottamiensa asiakasasiakirjojen määritystenmukaisuuden. Validointipalvelun avulla ohjelmistot voitaisiin saada tuottamaan yhdenmukaisia asiakasasiakirjoja. Tällöin esimerkiksi keskitettyyn arkistoon tulisi ainoastaan määritysten mukaisia ja yhtenäisiä asiakasasiakirjoja, mikä mahdollistaisi niiden siirtämisen eri toimittajien ohjelmistojen välillä. 2.5 Java Architecture for XML Binding Java Architecture for XML Binding (JAXB) on kehittetty virtaviivaistamaan XMLasiakirjojen käsittelyä Java-sovelluksissa. JAXB tarjoaa mekanismin, jonka avulla XML Schema -määrittelyistä voidaan luoda Java-luokat ja -rajapinnat sovellusten käyttöön. JAXB tarjoaa myös mahdollisuuden luoda Java-luokista XML Schema -määrittelyt, mutta tätä vaihtoehtoa ei käsitellä tämän selvityksen puitteissa. Kuvassa 8 on kuvattu JAXB:n toimintaa. Scheman sidonta vaiheessa JAXB:n sitova kääntäjä (binding compiler) luo XML Schema -määrittelyistä Java-luokat. Syntyneet Java-luokat vastaavat XML Schemalla määriteltyjä tietotyyppejä (rakenteita). Sidonnan tuloksena syntyvät luokat ovat suoraan käytettävissä Java-sovelluksia kehitettäessä. 19

Kuva 8. JAXB:n toiminnan kuvaus [mukailtu OrM03] Sovellustasolla voidaan syntyneitä luokkia ja rajapintoja käyttää hyväksi käsiteltäessä XML-asiakirjaa. Vaihtoehdossa 1 luetaan XML-asiakirja sovelluksen käyttöön JAXBrajapinnan tarjoamien liittymien avulla. JAXB-rajapinta huolehtii XML-asiakirjan sisällön muuntamisesta sidonta-vaiheessa tuotettujen Java-luokkien mukaiseen rakenteeseen. Tarpeen vaatiessa JAXB-rajapinta myös tarkistaa XML-asiakirjan määritystenmukaisuuden (validointi) suorittaessaan muunnosta. Muunnoksen jälkeen XML-asiakirjan rakenne on sovelluksen käytettävissä XML Schema -määrittelyistä johdettujen luokkien mukaisessa muodossa. JAXB-rajapinta piilottaa XML-asiakirjan jäsentämisvaiheen sovellusten kehittäjiltä, jolloin säästytään usein työläältä ja monimutkaiselta matalan tason käsittelyltä, jolla ei usein ole suurta merkitystä käyttäjälle kehitettäessä korkean tason sovelluksia, esimerkiksi sosiaalihuollon tarpeisiin. JAXB-rajapinnan avulla on myös mahdollista tehdä sama prosessi kääntäen (kuvassa vaihe 2). Sovelluksen suoritettua tarpeelliset operaatiot, esimerkiksi tietojen muokkaus, voidaan Java-luokkien mukaisesta tietomallista luoda XML-asiakirja JAXB-rajapinnan avulla. Validointi on mahdollista suorittaa myös tässä vaiheessa. Tämä on hyödyllistä, jos esimerkiksi asiakirjaan on luotu uusia elementtejä, tai asiakirja on luotu alusta lähtien käyttämättä valmista pohjaa. 20

JAXB:n tai vastaavan rajapinnan käytöllä voidaan saavuttaa selviä kustannussäästöjä sovelluskehityksessä. JAXB:n käyttö edellyttää, että XML-asiakirjojen rakenne on määritelty käyttäen kaaviokieltä. JAXB tukee XML Schemaa ja vanhentunutta DTD:tä. Lisäksi Relax NG tuki on kehitteillä. JAXB:n avulla asiakirjojen käsittelyä ohjelmallisesti voidaan nopeuttaa, ja jos esimerkiksi XML Schema -määrityksiä on tarpeellista muuttaa myöhemmässä vaiheessa, hoitaa Scheman sidonta matalan tason muutokset sovellustasolla. Sosiaalihuollon asiakasasiakirjojen teknisen standardin valinta vaikuttaa JAXB:n kaltaiten tekniikoiden hyödynnettävyyteen sovelluskehityksessä. Jos valittulla standardilla ei voida mallintaa kuvattavia asioita kaaviokielillä, esimerkiksi XML Schema -kielellä, riittävän tarkasti, ei JAXB:n kaltaisten tekniikoiden soveltaminen tuo merkittävää lisähyötyä. Esimerkiksi CDA R2 -standardin tapauksessa generoitavat Java-luokat tulisivat olemaan RIM-mallista johdettuja yleisiä luokkia kuten Section ja Observation. Konkreettisia ylätason hahmoja, kuten toimeentulotukihakemus, ei syntyisi. Sen sijaan, esimerkiksi toimeentulotukihakemus, täytyy mallintaa käyttäen yleisiä komponentteja. CDA R2 -skeema ei luonteensa vuoksi voi tarjota tällaisia spesifisiä rakenteita, vaan rakenteet muodostetaan koostamalla ne pienemmistä osista skeeman sallimissa rajoissa. JAXB:n tai vastaavan toteutuksen kannalta tarkasteltuna tämä tarkoittaa, että valmiita rajapintoja ei voida luoda automaattisesti, vaikka sovelluskehittäjien tiedossa on tarkat määritykset toimeentulotukihakemuksen elementti sisällöstä käytettäessä CDA R2:sta. Luotaessa omat XML Schema -määrittelyt sosiaalihuollon asiakasasiakirjojen rakenteeksi, voidaan sovellusten käyttöön tarkoitetut rajapinnat generoida määritysten pohjalta automaattisesti. Näin toimittaessa esimerkiksi toimeentulotukihakemuksen rajapinta on tarkkaan määritelty, mikä nopeuttaa sovelluskehitystä. Toisaalta toimeentulotukihakemuksen määrittelyjen muuttuessa joudutaan XML Schema -määrittelyjä muuttamaan, jonka seurauksena myös rajapinta muuttuu. Yleisten komponenttejen kohdalla muutoksia ei välttämättä tarvitse kohdistaa komponentteihin, vaan muutokset toteutetaan sovelluslogiikkaan. Sovellus tarpeen vaatiessa lisää, poistaa tai muuttaa toimeentulotukihakemuksen komponentteja. 21

3 CDA R2 -STANDARDIN SOVELTAMINEN SOSIAALI- HUOLTOON Tässä luvussa käsitellään CDA R2 -standardin käyttöä Suomessa ja pohditaan, miten sitä voitaisiin soveltaa sosiaalihuollon tekniseksi asiakasasiakirjastandardiksi. Luvussa 3.1 käydään läpi CDA R2 -standardin taustoja ja käyttöä Suomen terveydenhuollossa. Luvussa 3.2 esitetään perusteita standardin soveltamiselle sosiaalihuoltoon. Luvussa 3.3 pohditaan, kuinka sosiaalihuollon metatiedot voidaan toteuttaa CDA R2 -standardissa. Luvussa 3.4 pohditaan, kuinka varsinainen asiakasasiakirjojen sisältöosa voidaan toteuttaa CDA R2 -standardissa. 3.1 CDA R2 -standardin taustat ja käyttö Suomessa Kansainvälinen Health Level Seven (HL7) -organisaatio on kehittänyt versio 3 (V3) - standardin, koska aikaisempi versio 2 (V2) -standardi ei suosiostaan huolimatta ollut riittävän järeä aidosti yhteensopivien järjestelmien tukemiseksi. HL7 V3 -standardi on mallipohjainen, ja se perustuu olio-ohjelmointisuuntautuneeseen sovelluskehitykseen. Standardissa käytetään XML-kieltä ja hyödynnetään sekä tarkennetaan ulkoisten teollisuusstandardien käyttämistä esimerkiksi sanomaliikenteessä. Kaikki HL7:n tekniset komiteat alkoivat käyttää V3-standardia keväällä 1997. Suomessa HL7-standardien paikallista soveltamista ohjaa HL7 Finland ry. [TuM06.] HL7 V3 -standardiin perustuva CDA R2 (Clinical Document Architecture, Release 2) [DAB06] on kliinisten asiakirjojen standardi, jota hyödynnetään esimerkiksi Suomen terveydenhuollon sähköisessä potilaskertomuksessa. HL7 V3 -standardi sisältää kehitysmenetelmän (HDF, HL7 Development Framework), jolla kehitetään mallipohjaisesti sanomastandardeja terveydenhuollon tietojärjestelmien väliseen yhteistoiminnallisuuteen. HDF on HL7:n käyttämien sanomamäärittelyjen prosessien, käytäntöjen ja tuotosten mallinnukseen ja hallinnointiin kehitetty menetelmä. HDF käyttää mallipohjaista lähestymistapaa ja yhdenmukaistaa HL7:ssa käytettyjä mallinnuskäytäntöjä. HDF:ssä käytetään ja laajennetaan UML-merkintä- ja kuvauskieltä (Unified Modeling Language) HL7-mallien tuottamiseen. HL7 V3 - standardimäärittelyjen kehittämistä tukevia välineitä on saatavilla, mutta ne ovat osin vanhentuneita. HL7 V3 -sanomamäärittelyjen tuottaminen on kuitenkin mahdollista 22

myös ilman näiden välineiden käyttöä. HDF-menetelmää kehitetään kuten muitakin HL7-standardeja, ja kehitys on osin kesken. Tammikuun 2007 HL7 V3 Ballot - julkaisussa HDF [SCD06] on vielä luonnoksen (draft) asteella. Tämän vuoksi HL7 V3:ssa on käytetty viestien kehittämiseen ja rakentamiseen HDF:ää vanhempaa mallipohjaista MDF-menetelmää (HL7 Message Development Framework). HL7 V3 -tietomallinnusprosessi tunnistaa kolme toisiinsa liittyvää tietomallityyppiä: RIM, D-MIM (Domain Message Information Model) ja R-MIM (Refined Message Information Model). Ne kaikki käyttävät samaa esitysmuotoa, ja jokaisella on sama perusrakenne. Mallit eroavat toisistaan tietosisällöltään, laajuudeltaan ja käyttötarkoitukseltaan. Tietomallilla tarkoitetaan rakenteellista määrittelyä kohteena olevan alueen tiedoista. Se määrittelee luokat, ominaisuudet, suhteet, rajoitukset ja tilat. HL7-standardi käsittää terveydenhuollon kokonaisuuden ja tarkemmat osa-alueet, joilla tietoa vaihdetaan. Standardi määrittelee tarkemmille osa-alueille erilaiset tietomallit, jotka perustuvat yhteiseen perusmalliin. [Hea06.] Kuvassa 9 on esitetty HL7 V3 -standardin tietomallityyppejä ja niiden välisiä yhteyksiä. Kuva 9. HL7 V3 -tietomallityypit [TuM06] RIM (Reference Information Model) -malli on koko HL7-sovellusalueen kattava tietomalli. Se on yhtenäinen ja yhteinen tietomalli, joka toimii lähteenä muille HL7 V3 - standardin tarkemmille tietomalleille ja rakenteille. [Hea06.] RIM on mallinnettu UMLesitystapaa käyttäen, ja se koostuu terveydenhuollon toimialan toimijoiden tai muiden toimialaan liittyvien asioiden yleiskäsitteistä muodostetuista luokista. RIM-mallin kuudesta perusluokasta (core classes) voidaan luoda tarkempia luokkia, joita tarvitaan eri- 23

laisissa sanomissa tai sanomaryhmissä. Perusluokkia ovat Entity, Role, Participation, Act, Act Relationship ja Relationship Link (Kuva 10). [TuM06] Kuva 10. RIM-mallin perusluokat [TuM06] D-MIM (Domain Message Information Model) on RIM-mallin osajoukko, joka sisältää kloonattuja luokkia, attribuutteja ja suhteita, joita voidaan käyttää luomaan viestejä terveydenhuollon tietyn osa-alueen piirissä. D-MIM -mallia käytetään perustana, josta kaikki tämän osa-alueen tarkemmat mallit muodostetaan. [Hea06] R-MIM (Refined Message Information Model) on D-MIM -mallin tarkennettu osajoukko, jota käytetään ilmaisemaan tietosisältöä sanomille tai sanomajoukoille. R-MIM - mallin sisältö on johdettu käyttöalueen D-MIM -mallista. R-MIM voi sisältää valittujen luokkien klooneja, jotka on nimetty mallinnettavalle alalle ominaisilla termeillä. R- MIM esittää yhden tai useamman abstraktin sanomarakenteen tietosisältöjä. Näistä käytetään nimeä HMD. [Hea06] HMD (Hierarchical Message Description) on R-MIM -mallista johdettu taulukkoesitys, joka määrittelee sanoman ilman viittauksia toteutusteknologiaan. HMD määrittelee yksittäisen perussanoman rakenteen, jota kutsutaan yleiseksi sanomatyypiksi. Tätä sanomarakennetta ei koskaan lähetetä, eikä sille ole määritelty sen käynnistäviä liipaisintapahtumia (trigger event). Yleinen sanomatyyppi on mallipohja, josta muut yksityiskohtaiset sanomatyypit johdetaan. HMD:stä voidaan johtaa XML-toteutus, jossa XMLelementit vastaavat D-MIM ja R-MIM -mallien luokkia. Luokkien attribuutteja vastaavat XML:ssä elementit ja attribuutit. Luokkia esittävien XML-elementtien nimet mää- 24

räytyvät mallien assosiaatioiden mukaisesti. Jokaiseen HL7-attribuuttiin liittyy tietotyyppi. Myös tietotyypeistä tehdään XML-toteutukset. [Hea06] Muiden HL7 V3 -standardien tapaan CDA R2 perustuu RIM-malliin, josta on johdettu CDA R2 R-MIM -malli. CDA R2 -standardille ei kuitenkaan näytä olevan ylemmän tason D-MIM -mallia, kuten HL7 V3 -tietomallinnusprosessissa yleensä on. CDA R2 R- MIM -mallista johdettu CDA R2 hierarkkinen kuvaus (Hierarchical Description) on lähde standardin yhdenmukaisuussäännöille. Varsinainen CDA R2 -standardin XMLskeema on johdettu tästä hierarkkisesta kuvauksesta. Suomen terveydenhuollossa käytettävien potilaskertomuksen ja erilaisten lomakkeiden mallinnuksessa CDA R2 -standardia käyttäen ei ole sovellettu RIM-pohjaista mallinnusta. Tätä perustellaan sillä, että tarkoituksena ei ole ollut tietosisällön "vaan lomakkeen rakenteen mallintaminen siirtoa varten". Tavoitteena on ollut toteuttaa paperiset lomakkeet sähköisessä muodossa. Lomakkeiden CDA R2 -mallinnus on teknisesti toteutettu käyttämällä RIM-mallin luokkaa observation lähes kaikkien tietojen rakenteiseen esittämiseen riippumatta siitä, mitä luokkia käyttäen tiedot olisi HL7-ajatusmaailman mukaisesti pitänyt esittää. Mallinnuksessa on kuitenkin annettu jokaisen lomakkeen kaikille kentille HL7-tietotyypit ja kenttäkoodit. Hyötynä tämän tyyppisessä mallintamisessa on ollut työn nopeus. RIM-pohjainen mallinnus olisi vaatinut paljon enemmän työtä, koska mallinnusprosessi olisi ollut raskaampi. [Tar07.] CDA R2 -standardin taustalla olevan RIM-tietomallin jättäminen lähes kokonaan hyödyntämättä voi tuntua kyseenalaiselta, mutta toisaalta CDA R2 -standardin XML-skeeman väljyys sallii tämän tyyppisen mallintamisen. Kuitenkin on huomattava, että Suomen terveydenhuollossa RIMpohjaista mallinnusta käytetään muun muassa lääkityslistan, lähetteen ja hoitopalautteen sekä laboratoriovastauksien CDA R2 -rakenteiden määrittelyissä [Tar07]. HL7 V3:n yksi päätavoite on olla tarkka ja testattavissa oleva standardi, joka antaa toimittajille mahdollisuuden todistaa, että heidän toteutuksensa ovat määritysten mukaisia (certification of conformance) [TuM06]. Tämä ei kuitenkaan aukottomasti toteudu esimerkiksi CDA R2 -standardissa, jossa todistamiseen tarvittavia mekanismeja mallipohjien (templates) ja niiden mukaisiksi sanottujen asiakirjojen väliseen vertailuun ei ole toteutettu. CDA R2 -dokumentteja ei voida standardin tarjoamilla menetelmillä verrata ohjelmallisesti asiakirjakohtaisiin määrityksiin, vaan ainoastaan laajaan ja sallivaan CDA R2 -perusskeemaan. Tällainen todistaminen (validointi) on hyödytöntä, kun halutaan tietää, onko jokin tietty toteutus tehty sitä vastaavan määrityksen mukaisesti. Esi- 25

merkiksi toimeentulotukipäätös-asiakirjaa pitäisi voida verrata toimeentulotukipäätöksen määrittelyjä eikä sosiaalihuollon korkean tason mallia vasten, kun halutaan varmistua, että esimerkiksi jokin tietty ohjelmisto on osannut tuottaa yhteisten määritysten mukaisen toimeentulotukipäätös-asiakirjan oikein. CDA R2 -standardin kohdalla tämän kaltaiset validointiongelmat täytyy ratkaista, mikäli standardia aiotaan soveltaa sosiaalihuoltoon. Toisaalta validointiongelmat pitäisi pystyä ratkaisemaan myös Suomen terveydenhuollon puolella, jossa standardia jo sovelletaan validoinnin puutteista huolimatta. Terveydenhuollon sähköisissä lomakkeissa validointi perustuu käytännössä manuaaliseen tarkasteluun, jossa toteutunutta tulosta voidaan verrata kirjoitettuihin määrittelyasiakirjoihin ja -taulukoihin. XML Scheman yhteydessä luvussa 2.1 lyhyesti mainittu PSVI (Post Schema Validation Infoset) muodostuu validoitaessa XML-asiakirjoja CDA R2 -skeemaa vasten. CDA:n tapauksessa ongelmaksi voidaan nähdä, että vaikka PSVI sitoo tietotyypit elementteihin, eivät RIM-mallista johdetut tietotyypit ole välttämättä riittävän kuvailevia, jotta niiden perusteella yksin voitaisiin suorittaa hakuja validoituun asiakirjaan. Esimerkiksi potilaan henkilötunnus esitetetään CDA:n metatiedoissa elementissä Id, II-tietotyypin avulla, jolloin root-attribuutin arvoksi asetetaan suomessa henkilötunnuksen yksilöivä OID ja extension-attribuutissa esitetään henkilötunnuksen arvo. <Id root=" 1.2.246.21" extension="123483-123k"/> XML Schema -validoinnin tuloksena syntyvän PSVI:n näkökulmasta elementille syntyvä lisäinformaatio näyttää tältä (ei vastaa todellisuutta, mutta esimerkin vuoksi): <Id psvi:type="ii" root=" 1.2.246.21" extension="123483-123k"/> XML-tekniikat, jotka kykenevät hyödyntämään PSVI:tä voivat suorittaa hakuja tietotyyppien perusteella. Huomataan, että henkilötunnus elementtien tunnistaminen CDAdokumenteista ei onnistu ilman tietoa ympäröivästä kontekstista, tässä tapauksessa patientrole-elementti. Esimerkiksi XPath 2.0:n mukainen polkulauseke (kontekstiksisolmuksi oletetaan XML-asiakirjan juurisolmu): //element(*, II) Palauttaa kaikki elementit, joiden tietotyyppi on II. Polkulauseketta voidaan tarkentaa lisäämällä nimitesti: 26

//element(id, II) Tässä tapauksessa saadaan kaikki elementit, joiden tietotyyppi on II ja nimi on Id. Valitettavasti tämä ei esimerkiksi CDA_Fi -skeeman yhteydessä riitä, sillä kyseisellä elementti-tietotyyppi -yhdistelmällä kuvataan lähes kaikkien elementtien yksilölliset tunnisteet. Jos halutaan valita CDA_fi -skeeman mukaisesta XML-asiakirjasta potilaan henkilötunnusta kuvaavat elementit metatieto-osasta, joudutaan käyttämään esimerkiksi seuraavan muotoista polkulauseketta: //recordtarget/patientrole/id/@extension Esimerkeistä havaitsemme, että yleiskäyttöisen skeeman tuoma lisäarvo koneelliseen käsittelyyn on kyseenalainen. Jos sen sijaan skeemoissa olisi määritelty tietotyyppi potilaan henkilötunnus, voisimme suorittaa haun seuraavasti: //element(*, potilaan_henkilötunnus) Esitetyt esimerkit ovat karkeita ja tulee muistaa, että operatiivisissa järjestelmissä haut joutuvat yleensä ottamaan huomioon muitakin reunaehtoja kuin tietotyypit. Esimerkkien on tarkoitus havainnollistaa sitä, kuinka tietyissä tilanteissa yleiskäyttöisen skeeman moniselitteisyys voi hankaloittaa tietojen käsittelyä algoritmisesti. CDA R2 -standardin validointiongelmia voidaan yrittää paikata Schematronvalidointimekanismien kehittämisellä. Schematronin käyttö validoinnissa ei tuota lisäinformaatiota XML-asiakirjasta (PSVI ei muutu). Schematronia on hyödynnetty CDA R2 -standardin soveltamisessa muun muassa Kanadan British Columbia -provinssissa, jossa on tehty implementointiopas [KAS06] CDA R2 -standardin käytölle e-ms - tarkoitukseen (Electronic Medical Summary). e-ms on joukko potilastietoa, jota käytetään kommunikoinnissa potilaan hoidon keskenään jakavien terveydenhuollon ammatinharjoittajien välillä. Schematronia on käytetty kaksiosaiseen validointiin perustuvan validointijärjestelmän osana. Ohjelmiston tuottamaa asiakirjaa verrataan CDA R2 - pohjaiseen paikallistettuun määrittelyskeemaan ja tarkempaan Schematron-skeemaan, jolla on mahdollistettu validointi asiakirjan osille, joille paikallistetun CDA R2 - pohjaisen skeeman mukaisuuden tarkastaminen ei ole riittänyt. e-ms CDA R2 -implementointioppaassa [KAS06] on kuvattu lähestymistapa, jolla CDA R2 -standardia on sovellettu Kanadan British Columbia -provinssissa. Perustaksi on otettu CDA R2:n R-MIM -malli, josta on HL7 R-MIM-Designer -työkalulla poistettu 27

toiminnallisuutta, jota e-ms:ssa ei ole tarvittu. Tämän jälkeen karsitusta CDA R2 R- MIM -mallista on luotu e-ms R-MIM -skeema HL7 Schema-Generator -työkalulla. Koska työkalun ominaisuudet eivät ole riittäneet, on e-ms R-MIM -skeemaa muokattu manuaalisesti vastaamaan e-ms -vaatimusten validointia. Tämän jälkeen on rakennettu e-ms R-MIM -skeeman mukainen esimerkkitoteutus. Lopuksi on rakennettu erillinen Schematron-skeema sellaisten e-ms -vaatimusten, joita ei ole voitu sisällyttää CDA R2 -pohjaiseen e-ms R-MIM -skeemaan, validointia varten. Myös Yhdysvalloissa on käytetty Schematron-määrittelyihin perustuvaa validointimekanismia CDA R2 -standardin soveltamisessa CRS-asiakirjoissa (Care Record Summary). Tämän implementointioppaan [BAB05] ensimmäisen tason versiossa, jossa määritellään CDA R2 header osan käyttö, määrittelyn mukaisten asiakirjojen tulee olla CDA R2 -skeeman ja tehtyjen Schematron-määrittelyjen mukaisia. 3.2 Perusteita CDA R2 -standardin soveltamiselle sosiaalihuoltoon CDA R2 -standardin mukainen ratkaisu edellyttää sosiaalihuollon määritysten sovittamista terveydenhuoltoa varten kehitettyyn CDA R2 -standardiin. Sosiaalihuollon tietomääritykset eivät ole vielä valmistuneet kokonaisuudessaan ja tietoarkkitehtuurin määritystyö käynnistyy vuonna 2008. Tästä johtuen CDA R2:n soveltuvuudesta sosiaalihuollon tarpeisiin on vaikea antaa paikkansa pitävää arviota. CDA R2 -standardin käyttöä puoltaisivat muun muassa terveydenhuollon puolella jo osittain tehty tietojärjestelmien vaatimusmäärittelytyö, jonka tuloksia voitaisiin todennäköisesti soveltaa sosiaalihuollossa ainakin metatietojen osalta, esimerkiksi suostumuksen hallinnan ja tiedonsiirron osalta. Myös yhteensopivuus terveydenhuollon kanssa olisi mahdollisesti suoraviivaisempaa, kuin kehitettäessä oma standardi sosiaalihuollon käyttöön. Avoimiksi kysymyksiksi jäävät muun muassa CDA R2 -standardin ja sen RIM-mallista periytyvän filosofisen perustan soveltuvuus sosiaalihuollon lähtökohdista kehitettävien tietomääritysten kuvailemiseen. Pitäydyttäessä CDA R2 -standardin mukaisessa asiakasasiakirjojen esitystavassa on sosiaalihuollon tietomääritysten ja CDA R2 -standardin välille luotava tarkasti määritelty silta, jonka toteuttamisen täytyy olla teknisesti mahdollista. Valmiin standardin käytöllä voidaan saavuttaa hyötyjä muun muassa kustannuspuolelle, mutta CDA R2:n käyttö ei poista tarvetta luoda räätälöityjä sosiaalityön prosesseja tukevia sovelluksia. Vertailtaessa oman standardin toteutuksen ja CDA R2 28