XHTML+RDFa-standardin soveltuvuus osaksi sosiaalihuollon asiakirjastandardia

Transkriptio

1 XHTML+RDFa-standardin soveltuvuus osaksi sosiaalihuollon asiakirjastandardia Selvitysraportti Miika Alonen Konstantin Hyppönen Sami Korhonen

2 Versio Päiväys Kohdat Muutoksen sisältö Tekijät Kaikki Dokumentin runko KH Kaikki Ensimmäinen luonnos KH, MA, SK Kaikki Kaikki Lisää vertailutekstiä, tekstien yhtenäistäminen Muokkaus TAKO-ryhmän kommenttien pohjalta KH KH SOSIAALIALAN TIETOTEKNOLOGIAHANKE SOSIAALI- JA TERVEYSMINISTERIÖ Suomen kuntaliitto Terveyden ja hyvinvoinnin laitos Itä-Suomen sosiaalialan osaamiskeskus 2

3 Sisältö 1 Johdanto Johdanto määrityksiin ja standardeihin SosXML XHTML RDF XHTML+RDFa Kysely Standardien vertailu Muutostenhallinta määritysten ja toteutusten kannalta Muutostarpeet Muutostenhallinta skeemapohjaisessa SosXML:ssä Muutostenhallinta XHTML+RDFa-tapauksessa Muutostenhallinnan vertailu Toteutuskynnys ja tarvittava osaaminen Näyttömuodot Erilliset SosXML-näyttömuodot XHTML+RDFa-näyttömuoto Näyttömuodot: yhteenveto Arkistointi Asteittainen rakenteistaminen Asiakirjojen validointi Muunnokset muihin formaatteihin Koodistot Sähköiset allekirjoitukset Kielituki Yhteenveto Esitys jatkotoimenpiteiksi Liite A - Kyselyn vastaanottajat

4 Liite B - Kysely Liite C - Toimeentulotukihakemus SosXML-muodossa Liite D - SosXML näyttömuoto Liite E - Toimeentulotukihakemus XHTML+RDFa-muodossa (KUVA) Liite F - XHTML+RDFa-muotoisen toimeentulotukihakemuksen tekninen sisältö Liite G - kyselyn vastausten yhteenveto

5 1 Johdanto Sosiaalialan tietoteknologiahankkeessa (Tikesos) yhtenäistetään sähköisten asiakasasiakirjojen sisältöjä ja rakenteita sekä asiakirjahallintoa. Hankkeessa kehitetään kansallisesti ylläpidettävää asiakasasiakirjojen sähköistä arkistoa (KanSa). Vuonna 2007 hankkeessa selvitettiin eri asiakirjastandardien soveltuvuutta kansalliseksi sosiaalihuollon asiakirjastandardiksi 1. Tarkastelussa oli mukana seuraavat standardit: ODF (Open Document Formant), OOXML (Office Open XML), PDF/A sekä terveydenhuollossa käytettävä CDA R2 (Clinical Document Architecture) -standardi. Standardivertailun yhteydessä järjestettiin myös kaksi kyselyä ohjelmistotoimittajille sekä muille tärkeille sidosryhmille. Ensimmäisen kyselyn vastauksissa XML-tietorakenteiden tuottaminen sai korkeimmat pisteet. Asiakirjastandardin toivottiin olevan XML-pohjainen ja kansainvälisesti hyödynnetty. Suurimman tuen sai HL7 CDA R2. Toisessa kyselyssä esitettiin kysymys siitä, tulisiko sosiaalihuollon asiakasasiakirjoille laatia oma XML-standardi vai pyrkiä hyödyntämään terveydenhuollon CDA R2 - asiakirjastandardia. CDA R2 sai enemmän kannatusta, mutta suuri osa vastaajista ehdotti tarkempaa soveltuvuusvertailua CDA R2 ja sosiaalihuollon oman asiakirjastandardin välillä. Tarkempi vertailu 2 tehtiin vuonna 2008, ja vertailun pohjalta hankkeessa tehtiin päätös 3 lähteä kehittämään omaa sosiaalihuollon asiakirjastandardia. Päätöksen mukaan rakenteistettaville asiakirjoille määritellään XML-rakenne, joka perustuu sosiaalihuollon asiakirjoille tehtyihin sisällöllisiin ja rakenteellisiin määrityksiin. Rakenteistamattomien asiakirjojen esitysmuodoksi valittiin PDF/A. Vuonna 2009 julkaistiin määritys 4 XML-rakenteiden suunnitteluperiaatteista, nimeämiskäytännöistä, yksilöinnistä ja näyttömuodoista. Suunnittelu perustuu UN/CEFACT (United Nations Centre for Trade Facilitation and Electronic Business) -järjestön kehittämään CCTS (Core Components Technical Specification) -menetelmään. Menetelmän avulla hankkeessa kehitettiin sosiaalihuollon asiakastietomallia 5 sekä siihen perustuvia asiakirjarakenteita 6. Sosiaalihuollossa käytetään noin 200 eri asiakirjatyyppiä. Asiakirjarakenteiden toteuttaminen nykyisten skeemapohjaisten SosXML-määritysten mukaan tarkoittaa, että ylläpidettäviä teknisiä asiakirjarakenteita (XML-skeemoja) on toista sataa. Asiakastietomalliin tehtävät muutokset 1 Vaihtoehdot sosiaalihuollon asiakasasiakirjojen tekniseksi standardiksi. Versio 1.0. Tammikuu Asiakirjastandardin implementointisuunnitelman taustaselvitys. Versio 1.0. Helmikuu Sosiaalialan tietoteknologiahanke - johtoryhmän kokous ca-b9a0-3f1d8c5ac1fb/Tikesos+johtoryhm%c3%a4n+kokousmuistio doc 4 Sosiaalihuollon asiakasasiakirjojen tekniset määritykset: Suunnitteluperiaatteet, nimeämiskäytännöt, yksilöinti ja näyttömuoto Tikesos-hankkeen nettisivut, Asiakastietomalli. FI/tikesos/aineistot/maaritykset/teknisetmaaritykset/sosiaalihuollon-asiakastietomalli/ 6 Esim. toimeentulotuen asiakirjarakenteet, FI/tikesos/aineistot/maaritykset/teknisetmaaritykset/sosiaalihuollon-asiakasasiakirjat/toimeentulotuki/ 5

6 tulevat vaikuttamaan myös asiakirjarakenteisiin, jolloin ylläpidettävien skeemojen määrä voi kasvaa entisestään. Sosiaalihuollon asiakirjat voi esittää myös W3C:n kehittämän XHTML+RDFa-standardin 7 avulla. Standardin soveltuvuutta sosiaalihuollon tarpeisiin ei ole arvioitu vuonna 2007, koska se saavutti standardiaseman vasta syksyllä Syksyllä 2010 hankkeessa kehitettiin RDF 8 -versio sosiaalihuollon asiakastietomallista mm. graafisten tietomallien tuottamiseen. RDF-versiota asiakastietomallista voidaan käyttää myös sosiaalihuollon asiakasasiakirjojen esittämiseen XHTML+RDFa-muodossa. Tämän dokumentin tarkoituksena on arvioida XHTML- ja RDFa-standardien soveltuvuutta osaksi sosiaalihuollon asiakirjastandardia. Luvussa 2 kuvataan lyhyesti SosXML-määrityksiä sekä standardeja XHTML, RDF ja RDFa. Luvussa 3 on esitetty tiedot kyselystä, jolla pyrittiin arvioimaan XHTML+RDFa-standardin soveltuvuutta sosiaalihuollon asiakasasiakirjoihin. Luvussa 4 SosXML-määrityksiä ja XHTML+RDFastandardia vertaillaan tarkemmin sekä tarkastellaan vertailun havaintoja suhteessa kyselyn tuloksiin. Luvussa 5 esitetään ehdotukset jatkotoimenpiteiksi. 7 W3C. RDFa in XHTML: Syntax and Processing. A collection of attributes and processing rules for extending XHTML to support RDF. 8 W3C. RDF Primer. W3C Recommendation 10 February / 6

7 2 Johdanto määrityksiin ja standardeihin Tässä luvussa kerrotaan lyhyesti kansallisten SosXML-määritysten sekä kansainvälisten standardien XHTML, RDF ja RDFa määrittelytilanteesta, standardiasemasta ja levinneisyydestä. 2.1 SosXML SosXML on Tikesos-hankkeessa kehitetty joukko XML-rakenteita, niiden suunnitteluperiaatteita, teksti- ja taulukkomuotoisia määrityksiä ja käyttöohjeita. SosXML sisältää seuraavia osia: - CCTS-menetelmän mukaisesti muodostetut tietokomponentit, jotka koostuvat kentistä - Sisällölliset asiakirjarakenteet - Koodistot - Tietokomponenttikirjaston XML-skeemat - Asiakirjakirjojen XML-skeemat, jotka hyödyntävät tietokomponenttikirjaston skeemoja - Asiakirjojen näyttö/tulostusmuotojen määritykset Tietokomponenttikirjasto muodostaa sosiaalihuollon asiakastietomallin. Malli on tarkasteltavissa muun muassa graafisten työkalujen avulla 9,10. XML-rakenteiden suunnitteluperiaatteet on hyväksytty Tikesos-johtoryhmän kokouksessa hyödynnettäväksi SosXML-asiakirjamäärittelyjen kehityksessä. SosXMLasiakirjamäärityksiä on ehdotettu hyödynnettäväksi kaikissa asiakastietojärjestelmissä, joiden kesken jaetaan rakenteisia asiakasasiakirjoja. Määrittelyjä on ehdotettu käytettäväksi myös sähköisessä arkistossa rakenteisten asiakasasiakirjojen formaattina 11. SosXML ei ole kansainvälinen standardi, mutta sen suunnitteluperiaatteet pohjautuvat UN/CEFACT CCTS-menetelmään 12, joka on kansainvälisesti hyödynnetty ISO-standardi (standardiasema on määrityksen versiolla 2.01). Lisäksi on huomionarvoista, että skeemapohjainen SosXML perustuu erittäin laajassa käytössä olevaan kansainväliseen XML 13 -standardiin. Myös Suomen julkishallinnon JHS XML -suositus 14 on huomioitu SosXML:ssä Tikesos: Standardisalkku v United Nations. Centre for Trade Facilitation and Electronic Business. Core Components Technical Specification. Version September Extensible Markup Language (XML) 1.0 (Fifth Edition). W3C Recommendation 26 November JHS 170 Julkishallinnon XML-skeemat. 7

8 Tällä hetkellä SosXML:ssä on noin 200 tietokomponenttia, 1000 kenttää tietokomponenteissa, 14 yleistä asiakirjatyyppiä, 200 tarkennettua asiakirjatyyppiä, 70 koodistoa. SosXML:n käyttöä on testattu hankkeessa toimeentulotukiprotoilun yhteydessä. Skeemat on julkaistu hankkeen nettisivuilla. Ainakin yksi järjestelmätoimittaja on esittänyt tarkentavia kysymyksiä skeemoista ja tietomallista sekä käyttänyt skeemoja oman järjestelmänsä toteutuksessa. Osa määrityksistä on hyväksytty Tikesos-hankkeen johtoryhmässä. Niitä ei kuitenkaan ole asetettu pakollisiksi ministeriön asetuksella tms. menetelmällä. Asiakirjaesimerkki SosXML-muodossa löytyy liitteestä C ja sen näyttömuoto liitteestä D. 2.2 XHTML XHTML (extensible HyperText Markup Language) 15 on W3C-järjestön kehittämä kansainvälinen suositus (W3C Recommendation), jota käytetään web-sivujen esittämiseen. XHTML on laajassa käytössä kansainvälisesti. HTML-kielestä poiketen XHTML on XML-pohjainen kieli (HTML-kieli on SGML-pohjainen). XHTML- ja HTML-kielillä on muitakin eroja. XHTML-kieltä voi laajentaa moduuleilla tai muodostaa siitä osajoukkoja tarpeen mukaan. Kehitteillä olevaa HTML5-kieltä käyttävät web-sivut ovat esitettävissä XHTML-syntaksin avulla. XHTML-mukaisten web-sivujen muotoilua voi säätää CSS-tyylien avulla. Tyylit voidaan sijoittaa eri tiedostoon ja linkittää se varsinaiseen web-sivuun, tai ne voivat olla integroituna sivun lähdekoodiin. XHTML-kielen mukaisia asiakirjoja voi tuottaa ja jäsentää ohjelmallisesti käyttämällä XMLkirjastoja kuten Xerces, libxml2, MSXML. Kirjastot ovat helposti saatavilla ja hyvin ylläpidettyjä. W3C ylläpitää validointipalvelua 16, jonka avulla voi tarkistaa asiakirjan standardinmukaisuus. XHTML on osa W3C:n XML-standardiperhettä. XHTML-asiakirjoja voi muuntaa muihin formaatteihin esimerkiksi XSLT-muunnostiedostojen avulla tai käyttämällä XQuery-kyselykieltä. 2.3 RDF XML on laajennettavissa oleva metakieli tiedonvälitykseen. Tieto voidaan esittää XMLmuodossa hyvin monella eri tavalla, joten yksiselitteisen semantiikan määritteleminen pelkästään XML-kielellä on mahdotonta. RDF (Resource Description Framework) on W3C:n kehittämä tietomalli tietosisältöjen ja semanttisien suhteiden esittämiseen. RDF esitetään usein XMLmuodossa, mutta on käytännössä laajennettavissa oleva abstrakti tietomalli, jolla on useita eri esitystapoja ja tiedostomuotoja. 17 RDF-tietomallin olennaisin periaate on se, että kaikki tieto voidaan esittää subjektipredikaatti-objekti -lausekkeina (Triple-statement). Lauseke sisältää resursseja, jotka on iden- 15 XHTML Module-based XHTML - Second Edition. W3C Recommendation 23 November RDF PRIMER: 8

9 tifioitu URI-tunnisteilla (Unified Resource Identifier). URI-tunniste voi olla web-osoite tai jokin muu tunniste kuten ISBN. Subjekti on resurssi, jonka ominaisuutta tai suhdetta lauseke kuvaa. Myös predikaatti on resurssi, joka kuvaa resurssien välistä suhdetta tai suhdetta resurssin ja arvon välillä. Objekti voi olla joko resurssi tai literaali. Literaalit ovat arvoja, joille voidaan määritellä tietotyyppi. Esimerkkejä RDF-lausekkeista: Yksityishenkilön nimi on essi: essi Yksityishenkilö asuu osoitteessa: Molemmat esimerkit RDF/XML-muodossa: <?xml version="1.0" encoding="utf-16"?> <rdf:rdf xmlns:rdf=" xmlns:sos=" <rdf:description rdf:about=" <sos:asuu rdf:resource="#osoite"/> <sos:etunimi>essi</sos:etunimi> </rdf:rdf> RDF määrittelee tietomallin tiedon esittämiseen. XML määrittelee puolestaan syntaksin, jolla voidaan rakentaa sopiva kielioppi tiedon esittämiseen. RDF ei kuitenkaan kuvaa tietosisältöjen semantiikkaa. Semantiikka voidaan määritellä RDF-sisällölle RDFS- ja OWL-kielillä. RDFS (RDF Schema) ja OWL (Web Ontology Lanquage) ovat RDF-tietomallilla määriteltyjä kieliä semantiikan kuvaamiseen. RDFS määrittelee yksiselitteisen kieliopin luokille ja luokkien välisille suhteille. RDFS-kielen tärkeimpiä käsitteitä ovat rdfs:class ja rdfs:subclassof. Esimerkiksi voidaan määritellä yksityishenkilöä kuvaava luokka, joka on ihmistä kuvaavan luokan osajoukko. <rdfs:class rdf:about="#yksityishenkilö"> <rdfs:subclassof rdf:resource="#ihminen"/> </rdfs:class Tämän jälkeen voidaan lisätä luokka #Yksityishenkilö aiempaan esimerkkiin ja muuttaa aiemmin määritelty resurssi yksityishenkilön ilmentymäksi. <?xml version="1.0" encoding="utf-16"?> <rdf:rdf xmlns:rdf= xmlns:rdfs=" xmlns:sos=" <rdfs:class rdf:about="#yksityishenkilö"> <rdfs:subclassof rdf:resource="#ihminen"/> 9

10 </rdfs:class> <rdf:description rdf:about=" <rdf:type rdf:resource="#yksityishenkilo"/> <sos:asuu rdf:resource="#osoite"/> <sos:etunimi>essi</sos:etunimi> </rdf:rdf> Esimerkin pohjalta on koneellisesti pääteltävissä, että yksityishenkilön ilmentymä essi on myös luokan ihminen ilmentymä. RDFS-kielen ilmaisuvoima on kuitenkin hyvin rajallinen, koska kieli keskittyy lähinnä luokkien ja predikaattien hierarkioiden kuvaamiseen. OWL-kieli määrittelee joukon lisärakenteita, joilla voidaan ilmaista lisää käsitteiden välisiä suhteita. OWL-rakenteiden avulla voidaan esimerkiksi: Luokitella ilmentymiä ja johtaa luokittelujen perusteella uutta tietoa ilmentymistä Määritellä ekvivalenssiluokkia Määritellä kardinaliteetteja Havaita epäjohdonmukaisuuksia OWL perustuu avoimeen maailmankuvaan (Open world assumption), jonka pohjalta voidaan tehdä päätelmiä tietosisällöstä. Avoimella maailmankuvalla tarkoitetaan sitä, että päätelmiä voidaan tehdä olemassa olevan tiedon perusteella vaikka kaikkea tietoa ei olisi saatavilla. Puuttuvan tiedon ei siis katsota olevan virhe ja esimerkiksi kardinaliteetteja käytetään uuden tiedon johtamiseen validoinnin sijaan. OWL-kielen tärkeimpiä luokkia ovat owl:class, owl:datatypeproperty, owl:objectproperty, owl:restriction sekä owl:cardinality. RDF/RDFS/OWL-kieliperhe on helposti laajennettavissa ja on alun perinkin tarkoitettu laajennettavaksi. Tikesos-hankkeessa kehitetty sosiaalihuollon ontologia on muodostettu laajentamalla RDF/RDFS/OWL-kieliperhettä uusilla kielirakenteilla, jotka tukevat CCTS-pohjaisten asiakirjojen muodostamista ja sisällön validointia. CCTS-mukaiset tietokomponentit muutetaan RDF-kuvauksiksi: Kuva 1: Tietokomponentit esitettynä RDF tietomallin avulla Uuden tason lisääminen RDF-kieliperheeseen mahdollistaa asiakirjojen validoinnin suljetun maailmankuvan (Closed world assumption) mukaisesti. Kun käsitteet määritellään ontologiaan 10

11 tyyppeinä cwa:component ja predikaatit cwa:componentproperty, voidaan näihin käsitteisiin kohdistaa sääntöjä, joilla komponenttien ja tietosisältöjen eheys voidaan varmistaa. Semanttisten teknologioiden käyttö on levinnyt hyvin laajalle ja RDF/RDFS/OWL-suosituksiin perustuville teknologioille on hyvä ohjelmistotuki sekä avoimen lähdekoodin että kaupallisten toimijoiden puolesta. Semanttisen Webin teknologioihin on lukuisia kirjoja ohjelmoijan ja käsitemallintajan näkökulmasta. Tunnettuja ontologiaeditoireita ja ohjelmointialustoja ovat muun muassa: Topbraid Composer Protégé Neon Toolkit Semanttisen Webin teknologioille on myös monia avoimen lähdekoodin viitekehyksiä, jotka mahdollistavat teknologian nopean käyttöönoton. Tunnetuin viitekehys on Jena Java Framework joka on HP Labs:n kehittämä ja Apache Foundationin ylläpitämä avoimen lähdekoodin ohjelmointiympäristö RDF-muotoisen tiedon käsittelyyn. Lisätietoa semanttisen webin työkaluista löytyy muun muassa W3C:n sivuilta osoitteesta Ohjelmakirjastoja ja työkaluja voi selata myös Taulukkona. 2.4 XHTML+RDFa RDFa on vuonna 2008 julkaistu W3C suositus 18. RDFa:n määrittelee rakenteet (attribuutit) RDF-muotoisen tiedon esittämistä varten. Attribuutit voidaan liittää mihin tahansa rakenteiseen kieleen, mutta tällä hetkellä vain XHTML+RDFa-yhdistelmä on määritelty tarkasti ja standardoitu. RDFa on kehitetty XHTML-muotoisten dokumenttien tietosisältöjen rakenteistamiseen ja yhtenäistämiseen, jotta tieto olisi tietojärjestelmien käytettävissä ja ymmärrettävissä. RDFa-attribuuttien avulla voidaan merkata XHTML-dokumentin kohdat, jotka perustuvat yhteisesti sovittuihin sanastoihin. XHTML+RDFa:n avulla voidaan muodostaa ihmiselle helppolukuisia ja visuaalisesti rikkaita asiakirjoja, jotka ovat myös koneellisesti käsiteltävissä. Esimerkissä 1 on esitetty yksityishenkilön nimi ja osoite. XHTML+RDFa-merkkauksessa on mukana sekä asiakirjan näyttömuoto että sen tekninen sisältö. Essi Esimerkki Esimerkkikuja Espoo <html xmlns=" xmlns:sos=" xmlns:dc=" 18 RDFa in XHTML: Syntax and Processing. A collection of attributes and processing rules for extending XHTML to support RDF. W3C Recommendation 14 October

12 <head> <title>esimerkki dokumentti</title> <meta property="dc:creator" content="miika Alonen" /> </head> <body> <div typeof= sos:yksityishenkilo > <span property= sos:etunimi >Essi</span> <span property= sos:sukunimi >Esimerkki</span> <span property= sos:asuu resource= sos:osoite_1 /> </div> <div typeof= sos:osoite about= sos:osoite_1 > <span property= sos:katuteksti >Esimerkkikuja 1</span><br/> <span property= sos:postinumero >1234</span> <span propert= sos:kunta >Espoo</span> </div> </body> </html> Esimerkki sosiaalihuollon asiakasasiakirjasta (toimeentulotukihakemuksesta) XHTML+RDFamuodossa on liitteessä E. Asiakirjan rakenteinen (RDF-)sisältö perustuu sosiaalihuollon asiakastietomalliin ontologiamuodossa. XHTML+RDFa-muotoisten dokumenttien käsittelyyn on olemassa avoimen lähdekoodin työkaluja ja käsittelykielen implementointi pseudokoodilla on hyvin dokumentoitu suositustekstissä. Tikesos-hankkeessa on toteutettu W3C-standardin mukainen Java-pohjainen toteutus 19 RDFsisällön poimimiseen rakenteisista asiakirjoista. RDFa-attribuuttien käsittelyyn on lukuisia työkaluja, joista löytyy lista esimerkiksi osoitteesta 19 RDFa Core 1.1 implementation in Java 12

13 3 Kysely Maaliskuussa 2011 järjestettiin kyselykierros XHTML- ja RDFa-standardeista. Kysely toimitettiin järjestelmätoimittajille sekä muille tärkeille sidosryhmille (ks. liite A) sähköpostitse. Osa viesteistä lähetettiin henkilökohtaisiin ja osa organisaatiokohtaisiin sähköpostiosoitteisiin. Kysely on liitteessä B. Kyselyn mukana toimitettiin seuraavat liitteet: Kysely Kyselyn taustatiedot (sama teksti kuin tämän dokumentin johdannossa) sekä ohjeet SosXML Toimeentulotukihakemus SosXML-muodossa (Liite C) SosXML-näyttömuoto Hakemuksen näyttömuoto (PDF/A) (Liite D) XHTML+RDFa Toimeentulotukihakemus XHTML+RDFa-muodossa (Liite E) XHTML+RDFa-sisältö Hakemuksen tekninen sisältö (Liite F). Kyselyn mukana oli ns. Turtle-muotoinen versio samasta sisällöstä. Liitteessä F on esitetty sisällön RDF/XML-versio, koska se on koettu helpompilukuisemmaksi. Kyselyyn vastasi 7 henkilöä, joista 5 oli järjestelmätoimittajien edustajia, ja 2 sosiaalitoimen järjestelmäasiantuntijoita. Vastausprosentti oli 23 %. Pieni vastausprosentti selittynee osittain sillä, että kyselyn aihe oli hyvin tekninen. Yhteenveto kyselyn tuloksista löytyy liitteestä G. Vastauksia on käytetty luvussa 4 standardien vertailun apuna. 13

14 4 Standardien vertailu Skeemapohjaiset SosXML-määritykset ja XHTML+RDFa-standardi eivät ole suoraan vertailtavissa sellaisenaan, koska SosXML-skeemat muodostavat joukon sosiaalihuollon tarpeisiin määriteltyjä XML-rakenteita, kun taas XHTML+RDFa on tarkoitettu minkä tahansa tietosisällön esittämiseen. SosXML-skeemat perustuvat sosiaalihuollon asiakastietomalliin eli tietokomponentteihin ja asiakirjarakenteisiin. Asiakastietomalli voidaan esittää ontologiamuodossa niin, että ontologian luokkiin voidaan viitata XHTML+RDFa-asiakirjoista. Vertailussa tarkastellaan siis kahta skenaariota: 1. Asiakirjojen esittäminen pohjautuu suoraan SosXML-mukaisiin XML-skeemoihin, jotka perustuvat sosiaalihuollon asiakastietomalliin. 2. Asiakirjojen esittämiseen käytetään XHTML+RDFa-standardia, ja asiakirjoissa hyödynnetään ontologiamuodossa olevaa sosiaalihuollon asiakastietomallia. Vertailussa otetaan huomioon seuraavat seikat: 1. Muutostenhallinta. Miten hyvin standardi reagoi asiakastietomalliin tapahtuviin muutoksiin. 2. Toteutuskynnys ja tarvittava osaaminen. Miten vaikeaa on toteuttaa järjestelmät, jotka tuottavat ja lukevat standardinmukaisia asiakirjoja. Mitä osaamista tarvitaan asiakirjastandardin hallitsemiseen. 3. Näyttömuodot. Miten asiakirjat voidaan näyttää ihmiselle, mitä tekniikoita ja määrityksiä siihen tarvitaan, ja miten näyttömuotojen hallinta on toteutettu. 4. Arkistointi. Miten hyvin standardi soveltuu arkistomuodoksi ja mitä muunnoksia tarvitaan mikäli tähdätään asiakirjojen pysyväis- tai määräaikaissäilytykseen. 5. Asteittainen rakenteistaminen. Miten hyvin standardi soveltuu sosiaalihuollon asiakastietomallin asteittaiseen käyttöönottoon. 6. Asiakirjojen validointi. Miten asiakirjojen oikeellisuus pystytään tarkistamaan ennen asiakirjan hyväksymistä kansalliseen arkistoon. 7. Muunnokset muihin formaatteihin. Miten voidaan toteuttaa standardinmukaisten asiakirjojen muunnokset muihin formaatteihin (esimerkiksi PDF/A). 8. Koodistot. Miten hyvin standardi soveltuu tietosisällössä esiintyvien koodien ja luokitusten tallentamiseen. 9. Sähköiset allekirjoitukset. Miten standardi vaikuttaa sähköisten allekirjoitusten toteuttamiseen. 10. Kielituki. Miten standardi soveltuu erikielisten asiakirjojen tallentamiseen. 14

15 4.1 Muutostenhallinta määritysten ja toteutusten kannalta Sosiaalihuollon asiakastietomalli on kehittynyt Tikesos-hankkeessa nopeasti, ja uusia tietorakenteita on tullut koko ajan lisää sisällöllisten asiakirjarakenteiden valmistumisen myötä. Kantavana ajatuksena asiakirjarakenne- ja tietokomponenttityössä on ollut sisällön yhtenäistäminen 20. Samat tietosisällöt pyritään esittämään aina samojen tietorakenteiden avulla, ja tietosisällöt yhtenäistetään tarvittaessa. Yhtenäistämistyöllä on selkeä vaikutus tietorakenteisiin. Yhtenäistämistyötä tehdään hyvin todennäköisesti hankkeen jälkeenkin. Tietorakenteetkin tulevat muuttumaan, ja asiakirjastandardin tulee reagoida näihin muutoksiin riittävän nopeasti ja kustannustehokkaasti Muutostarpeet Muutostarpeiden tarkka kuvaus valmistuu hankkeessa vuonna 2011 työpaketissa Sisällöllisten ja teknisten tietomääritysten hallintamalli. Tässä kuvauksessa on listattu tärkeimmät muutostarpeet, joilla voi olla vaikutusta asiakirjastandardiin ja jotka asiakirjastandardin pitää hallita. Kenttien lisääminen. Uuden kentän lisäämisen aiheuttajana on uusien tietotarpeiden ilmestyminen työmenetelmien kehittymisen tai lainsäädäntömuutosten takia. Kentän lisääminen voi aiheuttaa myös muiden kenttien poistamisen. Esimerkkinä on tilanne, jossa uuden kentän tarkoituksena on tietosisältöjen yhtenäistäminen, eli jos uusi kenttä toteuttaa tietotarpeen, joka on toteutettu usealla eri tavalla eri asiakirjoissa. - Uuden kentän lisääminen ydintietokomponenttiin. Koska ydintietokomponentti on käytössä useassa palvelutehtävässä ja useassa asiakirjassa, lisääminen voi vaikuttaa näihin asiakirjoihin. Lisäyksellä voi olla vaikutusta myös muihin ydintietokomponentteihin ja palvelutehtäväkohtaisiin tietokomponentteihin, jotka hyödyntävät täydennettyä komponenttia. Uuden kentän käyttöä pitää ohjeistaa kaikissa näissä kohteissa, eli tietokomponenttikirjastossa sekä sisällöllisissä asiakirjarakenteissa. - Uuden kentän lisääminen palvelutehtäväkohtaiseen tietokomponenttiin. Lisäyksellä voi olla vaikutusta useaan asiakirjaan sekä muihin tietokomponentteihin, joita käytetään kyseisessä palvelutehtävässä. Kentän käyttöä pitää ohjeistaa sekä asiakirjarakenteet päivittää. - Uuden kentän lisääminen yleisen asiakirjatyypin rakenteeseen. Sisällöllinen asiakirjarakenne muuttuu, koska uuden kentän käyttöä tulee ohjeistaa. Kentän lisääminen voi aiheuttaa myös sen, että täydennetyn rakenteen avulla voi toteuttaa joitakin tarkennettuja asiakirjatyyppiä, jotka on aikaisemmin toteutettu erillisillä rakenteilla. - Uuden kentän lisääminen tarkennetun asiakirjatyypin rakenteeseen. Asiakirjan sisällöllinen asiakirjarakenne muuttuu kentän käytön ohjeistamiseksi. Kenttien poistaminen. Kentän poistamisen aiheuttajana voi olla työmenetelmien kehittyminen (tietotarve lakkaa olemasta), lainsäädännön tai tietosuojakäytänteiden muutokset (tietoa ei saa 20 Sosiaalihuollon asiakastietojen ja -asiakirjojen tietomallinnus: Prosessi, suunnitteluperiaatteet ja työkalut. 15

16 enää kerätä tai tallentaa) tai tietojen yhtenäistäminen (tietotarve toteutetaan uudella yhtenäisellä tavalla). - Kentän poistaminen ydintietokomponentista. Maininta kentästä tulee poistaa kaikista niistä paikoista, missä sitä on käytetty. - Kentän poistaminen palvelutehtäväkohtaisesta tietokomponentista. Maininta kentästä tulee poistaa kyseisen palvelutehtävän asiakirjoista, joissa poistettavaa kenttää on käytetty. - Kentän poistaminen yleisen asiakirjatyypin rakenteesta. Aiheuttaa sisällöllisen ja teknisen asiakirjarakenteen päivittämistä. - Kentän poistaminen tarkennetun asiakirjatyypin rakenteesta. Aiheuttaa sisällöllisen ja teknisen asiakirjarakenteen päivittämistä. Tietokomponenttien lisääminen. Uutta tietokomponenttia voidaan tarvita, jos tulee uusia tietotarpeita, tai jos tietosisältöjä yhtenäistetään. - Uuden ydintietokomponentin lisääminen. Tietokomponenttikirjasto päivittyy. Lisäyksellä voi olla vaikutusta palvelutehtäväkohtaisiin tietokomponentteihin sekä asiakirjarakenteisiin. Uuden tietokomponentin käyttöä pitää ohjeistaa sekä yleisesti että kontekstisidonnaisesti niissä paikoissa missä sitä tarvitaan. - Uuden palvelutehtäväkohtaisen tietokomponentin lisääminen. Voi aiheuttaa muutoksia muihinkin tietokomponentteihin kyseisessä palvelutehtävässä sekä asiakirjarakenteisiin. Tietokomponenttien poistaminen. Tietokomponentin poistamisen aiheuttajat ovat samat kuin kentän poistamisen aiheuttajat. Maininta tietokomponentista tulee poistaa kaikista niistä paikoista, missä sitä on käytetty: muista tietokomponenteista sekä asiakirjarakenteista. Palvelutehtäväkohtaisen tietokomponentin muuttaminen ydintietokomponentiksi. Muutoksen aiheuttajana voi olla se, että tietokomponentille löytyy käyttöä muissakin palvelutehtävissä. Tässä tapauksessa tietokomponentti siirtyy ydintietokomponenttikirjastoon. Tietokomponenttikirjasto päivitetään. Myös asiakirjarakenteissa voi tapahtua muutoksia. Asiakirjatyyppien lisääminen. Työmenetelmien tai lainsäädännön kehittymisen myötä sosiaalihuollossa voidaan tarvita uusia asiakirjoja. Uuden asiakirjan tietosisältö kannattaa yhtenäistää jo olemassa olevien asiakirjojen kanssa, kehittää asiakirjalle tarkat rakenteet tai toteuttaa se käyttämällä yleisen asiakirjatypin rakennetta. Asiakirjatyyppien poistaminen. Poistamisen aiheuttajana voi olla sosiaalihuollon työprosessien muuttuminen. Jos päivitetyissä prosesseissa ei enää tarvita tiettyä asiakirjaa, sen rakennetta ei tarvitse enää ylläpitää aktiivisesti. Arkistossa voi tosin olla valmistuneita asiakirjoja, jotka noudattavat tarpeettomaksi tullutta rakennetta, sen takia koko rakennetta ei saa poistaa. Asiakirjatyypin poistaminen voi aiheuttaa sellaisten kenttien tai kokonaisten tietokomponenttien poistamista, joita käytettiin vain poistettavassa asiakirjatyypissä. Kenttien ja tietokomponenttien muokkaukset (esimerkiksi kentän nimen muutos) voidaan toteuttaa kentän/tietokomponentin poistamisen ja uuden kentän/tietokomponentin lisäämisen kautta. Pienemmät muutokset, kuten kommenttien tai ohjeistuksen lisääminen, voidaan toteut- 16

17 taa ilman tietorakenteiden muuttamista. Pienempien ja isompien muutosten raja tarkentuu hankkeessa vuonna 2011 työpaketissa Sisällöllisten ja teknisten tietomääritysten hallintamalli. Muutosten käsittelyprosessi voidaan karkeasti jakaa kolmeen eri vaiheeseen: 1. Muutoksen sisällöllinen käsittely. Vaihe pitää sisällään muutosehdotuksen hallinnollisen käsittelyn, asiakastietomallin päivittämisen ja ohjeistuksen, kuten sisällöllisten asiakirjarakenteiden, laatimisen. 2. Tekninen käsittely kansallisella tasolla. Muutos toteutetaan asiakastietomallin teknisessä esityksessä eli tietomallin fyysisellä tasolla. Lisäksi tehdään tarvittavat muutokset yhteisten tietojärjestelmäpalveluiden 21 kuten näyttömuotopalvelun, asiakirjojen validointipalvelun ja arkiston toteutukseen. 3. Muutokset asiakastietojärjestelmissä. Muutokset voivat sisältää tarvittavat päivitykset asiakastietojärjestelmien tietomalleihin, toimintalogiikkaan sekä rajapintatoteutuksiin. Muutoksen sisällöllinen käsittely ja tekniset päivitykset yhteiseen infrastruktuuriin tehdään keskitetysti kansallisella tasolla. Muutokset asiakastietojärjestelmissä tapahtuvat hajautetusti niiden omien ylläpitokäytänteidensä mukaisesti. Asiakirjastandardin valinta ei vaikuta muutosten sisällölliseen käsittelyyn, koska kumpikin standardi käyttää samaa loogisen tason asiakastietomallia. Muutosten tekninen käsittely kansallisella tasolla ja asiakastietojärjestelmien tasolla on erilainen. Nykyinen skeemapohjainen SosXML- ja XHTML+RDFa-asiakirjastandardit käyttäytyvät hieman eri tavalla ja aiheuttavat eri toimenpiteitä muutosten sattuessa Muutostenhallinta skeemapohjaisessa SosXML:ssä Sosiaalihuollon asiakastietomalli sisältää runsaasti linkkejä ja riippuvuuksia tietorakenteiden välillä. Skeemapohjainen SosXML vie suurimman osan näistä riippuvuuksista tietomallin fyysiselle tasolle eli skeemoihin. Esimerkiksi jos ydintietokomponenttiin lisätään uusi kenttä, tämä voi aiheuttaa runsaasti muutoksia palvelutehtäväkohtaisiin skeemoihin ja asiakirjaskeemoihin. Tässä luvussa muutosten aiheuttamat toimenpiteet käydään tarkemmin läpi. Kenttien lisääminen Uuden pakollisen kentän lisääminen ydintietokomponenttiin aiheuttaa seuraavat toimenpiteet: 1. Kansallisella tasolla - Tietokomponentin päivitys tietokomponenttikirjaston hallintatyökalun avulla. - Uudessa nimiavaruudessa olevan skeeman tuottaminen ydintietokomponenttikirjastosta. - Uusilla nimiavaruuksilla varustettujen skeemojen tuottaminen niiden palvelutehtävien palvelutehtäväkohtaisista tietokomponenttikirjastoista, joiden asiakirjatyypeissä uutta kenttää tarvitaan välittömästi. 21 Yhteiset tietojärjestelmäpalvelut sosiaalihuollossa. v b82963f092ab/Yhteiset+tietoj%c3%a4rjestelm%c3%a4palvelut+sosiaalihuollossa.pdf 17

18 - Uusilla nimiavaruuksilla varustettujen skeemojen tuottaminen niistä asiakirjatyypeistä, joissa uutta kenttää tarvitaan välittömästi. - Muista palvelutehtäväkohtaisista tietokomponenttikirjastoista sekä asiakirjatyypeistä, joissa käytetään kyseistä ydintietokomponenttia on hyvä tuottaa mahdollisimman nopeasti uusissa nimiavaruuksissa olevat skeemat sisällön yhtenäistämisen varmistamiseksi. Skeemojen tuottaminen voi tapahtua esimerkiksi tietyin väliajoin. - Ydintietokomponenttikohtaisen näyttömuotomäärityksen päivitys. - Näyttömuotomääritysten päivitys kaikkien niiden palvelutehtäväkohtaisten tietokomponenttikirjastojen ja asiakirjatyyppien kohdalla, joista on generoitu uusilla nimiavaruuksilla varustetut skeemat. - Uusien skeemojen lisääminen validointipalveluun. - Uusien skeemojen ja näyttömuotomääritysten lisääminen näyttömuotopalveluun. 2. Asiakastietojärjestelmien tasolla - Uuden kentän huomioiminen asiakastietojärjestelmän tietomallissa ja käyttöliittymässä. - Uuden kentän huomioiminen niissä asiakastietojärjestelmän osissa, jotka vastaavat asiakirjojen muodostamisesta ja lukemisesta (jäsentämisestä). - Vanhojen nimiavaruuksien korvaaminen uusilla nimiavaruuksilla asiakastietojärjestelmän osassa, joka vastaa asiakirjojen muodostamisesta. - Uusien nimiavaruuksien lisääminen vanhojen rinnalle asiakastietojärjestelmän osassa, joka vastaa asiakirjojen lukemisesta. Vanhoja nimiavaruuksia ei voi korvata uusilla, koska arkistossa on edelleen vanhoilla nimiavaruuksilla varustettuja asiakirjoja, joita pitää pystyä lukemaan. - Mikäli järjestelmässä on toteutettu asiakirjojen näyttö/tulostusmuotojen tuottaminen, uusi kenttä ja uudet skeemojen nimiavaruudet pitää huomioida tässä moduulissa. Jos uusi pakollinen kenttä lisätään palvelutehtäväkohtaiseen tietokomponenttiin, ydintietokomponenttikirjastoa, sen skeemaa ja näyttömuotomääritystä ei tarvitse päivittää. Muuten muutokset ovat samat. Jos pakollinen kenttä lisätään tiettyyn asiakirjatyyppiin, tietokomponenttikirjastoja, niiden skeemoja tai näyttömuotomäärityksiä ei tarvitse päivittää. Uuden valinnaisen kentän lisääminen ydintietokomponenttiin aiheuttaa seuraavat toimenpiteet: 1. Kansallisella tasolla - Tietokomponentin päivitys tietokomponenttikirjaston hallintatyökalun avulla. - Uuden skeeman tuottaminen ydintietokomponenttikirjastosta. Skeema on samassa nimiavaruudessa kuin edellinen versio. Skeeman ns. Minor-versio muuttuu. - Ydintietokomponenttikohtaisen näyttömuotomäärityksen päivitys. - Uuden skeeman lisääminen validointipalveluun. - Uuden skeeman ja näyttömuotomäärityksen lisääminen näyttömuotopalveluun. 2. Asiakastietojärjestelmien tasolla - Uuden kentän huomioiminen asiakastietojärjestelmän tietomallissa ja käyttöliittymässä. 18

19 - Uuden kentän huomioiminen asiakastietojärjestelmän osissa, jotka vastaavat asiakirjojen muodostamisesta ja lukemisesta. - Mikäli järjestelmässä on toteutettu asiakirjojen näyttö/tulostusmuotojen tuottaminen, uusi kenttä pitää huomioida tässä moduulissa. Pakollisen tai valinnaisen kentän poistaminen aiheuttaa samanlaiset toimenpiteet kuin vastaavanlaisen kentän lisääminen. Kentän muuttaminen valinnaisesta pakolliseksi tai pakollisesta valinnaiseksi aiheuttaa samanlaiset toimenpiteet kuin pakollisen kentän lisääminen. Uuden tietokomponentin lisääminen aiheuttaa samanlaiset toimenpiteet kuin uuden valinnaisen kentän lisääminen. Tietokomponentin poistaminen johtaa samanlaisiin toimenpiteisiin kuin uuden pakollisen kentän lisääminen. Poistamisen sijasta tietokomponentin käyttöä voidaan suositella vältettäväksi, jolloin muutokset jäävät ohjeistuksen tasolle. Palvelutehtäväkohtaisen tietokomponentin muuttaminen ydintietokomponentiksi aiheuttaa seuraavat toimenpiteet: 1. Kansallisella tasolla - Tietokomponentin siirto tietokomponenttikirjaston hallintatyökalun avulla. - Uudessa nimiavaruudessa olevan skeeman tuottaminen ydintietokomponenttikirjastosta. - Uusilla nimiavaruuksilla varustettujen skeemojen tuottaminen niiden palvelutehtävien palvelutehtäväkohtaisista tietokomponenttikirjastoista, joiden asiakirjatyypeissä uutta ydintietokomponenttia tarvitaan välittömästi. - Uusilla nimiavaruuksilla varustettujen skeemojen tuottaminen niistä asiakirjatyypeistä, joissa uutta ydintietokomponenttia tarvitaan välittömästi. - Ydintietokomponenttikohtaisen näyttömuotomäärityksen päivitys. - Näyttömuotomääritysten päivitys kaikkien niiden palvelutehtäväkohtaisten tietokomponenttikirjastojen ja asiakirjatyyppien kohdalla, joista on generoitu uusilla nimiavaruuksilla varustetut skeemat. - Uusien skeemojen lisääminen validointipalveluun. - Uusien skeemojen ja näyttömuotomääritysten lisääminen näyttömuotopalveluun. 2. Asiakastietojärjestelmien tasolla - Vanhojen nimiavaruuksien korvaaminen uusilla nimiavaruuksilla asiakastietojärjestelmän osassa, joka vastaa asiakirjojen muodostamisesta. - Uusien nimiavaruuksien lisääminen vanhojen rinnalle asiakastietojärjestelmän osassa, joka vastaa asiakirjojen lukemisesta. Vanhoja nimiavaruuksia ei voi korvata uusilla, koska arkistossa on edelleen vanhoilla nimiavaruuksilla varustettuja asiakirjoja, joita pitää pystyä lukemaan. - Mikäli järjestelmässä on toteutettu asiakirjojen näyttö/tulostusmuotojen tuottaminen, tietokomponentin siirto ja uudet skeemojen nimiavaruudet pitää huomioida tässä moduulissa. Uuden asiakirjatyypin lisääminen aiheuttaa seuraavat toimenpiteet: 1. Kansallisella tasolla 19

20 - Uuden sisällöllisen asiakirjarakenteen mukaisen skeeman tuottaminen. - Asiakirjan näyttömuotomäärityksen kehittäminen. - Uuden skeeman lisääminen validointipalveluun. - Uusien skeeman ja näyttömuotomäärityksen lisääminen näyttömuotopalveluun. 2. Asiakastietojärjestelmien tasolla - Uuden asiakirjatyypin tietosisällön huomiointi asiakastietojärjestelmän tietomallissa ja käyttöliittymässä. - Uuden asiakirjatyypin huomiointi niissä asiakastietojärjestelmän osissa, jotka vastaavat asiakirjojen muodostamisesta ja lukemisesta. - Mikäli järjestelmässä on toteutettu asiakirjojen näyttö/tulostusmuotojen tuottaminen, uusi asiakirja pitää huomioida tässä moduulissa. Jos olemassa olevista tietokomponenteista puuttuu uuden asiakirjatyypin kannalta tärkeät kentät, ne pitää ensin lisätä, eli suorittaa kenttien ja tietokomponenttien lisäämiset tarvittavine toimenpiteineen. Asiakirjatyypin poistaminen voi aiheuttaa paljon työtä tietomallin loogisella tasolla, eli sisällöllistä käsittelyä. Sisällöllinen käsittely voi johtaa joidenkin kenttien tai tietokomponenttien poistamisen tietokomponenttikirjastosta, mikä aiheuttaa vastaavia toimenpiteitä teknisellä tasolla. Niiden lisäksi pitää suorittaa seuraavat tekniset toimenpiteet: 1. Kansallisella tasolla - Asiakirjaskeeman poistaminen validointipalvelusta. 2. Asiakastietojärjestelmien tasolla - Asiakirjan poiston huomioiminen tietojärjestelmän tietomallissa ja käyttöliittymässä. - Poiston huomioiminen asiakastietojärjestelmän osassa, joka vastaa asiakirjojen muodostamisesta. Muutostenhallinta skeemapohjaisen SosXML:n tapauksessa johtaa siihen, että skeemoista muodostuu useita eri versioita. Jokainen eri asiakirjatyyppi perustuu omaan skeemaan, ja asiakirjan rakenteen muutokset johtavat uusiin skeemaversioihin. Ydintietokomponenttikirjastoon tehtävät muutokset voivat heijastua moneen palvelutehtävään ja niissä käytettäviin asiakirjatyyppeihin, aiheuttaen muutoksia skeemoissa, näyttömuotomäärityksissä ja yhteisissä tietojärjestelmäpalveluissa. Vanhoja skeemojen versioita ei voi poistaa kaikista tietojärjestelmistä kansallisella tasolla tai asiakastietojärjestelmien tasolla, koska arkistossa voi olla edelleen vanhan skeemaversion mukaisia asiakirjoja. Etenkin näyttömuotopalvelu ja asiakastietojärjestelmien asiakirjojen lukumoduulit voivat joutua käsittelemään suuria joukkoja nimiavaruuksia ja skeemojen versioita. 20

21 4.1.3 Muutostenhallinta XHTML+RDFa -tapauksessa XHTML+RDFa-asiakirjastandardissa asiakirjasisältö linkitetään tietorakenteisiin ontologiaviittausten avulla. Tietomallin fyysinen esitysmuoto on joukko ontologioita. Kaikki asiakirjat noudattavat samaa skeemaa (XHTML+RDFa 22 ). Muutokset tietorakenteissa eivät vaikuta tähän skeemaan, vaan jäävät ontologian tasolle. Kansallisissa tietojärjestelmissä ja asiakastietojärjestelmissä muutokset pitää kuitenkin huomioida. Uuden pakollisen kentän lisääminen ydintietokomponenttiin aiheuttaa seuraavat toimenpiteet: 1. Kansallisella tasolla - Tietokomponentin päivitys tietokomponenttikirjaston hallintatyökalun avulla. - Uuden ontologiaversion tuottaminen ydintietokomponenttikirjastosta. - Uuden ontologiaversion tuottaminen niiden palvelutehtävien palvelutehtäväkohtaisista tietokomponenttikirjastoista, joiden asiakirjatyypeissä uutta kenttää tarvitaan välittömästi. - Uusien ontologiaversioiden tuottaminen niistä asiakirjatyypeistä, joissa uutta kenttää tarvitaan välittömästi. - Muista palvelutehtäväkohtaisista tietokomponenttikirjastoista sekä asiakirjatyypeistä joissa käytetään kyseistä ydintietokomponenttia on hyvä tuottaa mahdollisimman nopeasti uusia ontologiaversioita sisällön yhtenäistämisen varmistamiseksi. Niiden tuottaminen voi tapahtua esimerkiksi tietyin väliajoin. - Uusien ontologiaversioiden lisääminen validointipalveluun. 2. Asiakastietojärjestelmien tasolla - Uuden kentän huomioiminen asiakastietojärjestelmän tietomallissa ja käyttöliittymässä. - Uuden kentän huomioiminen niissä asiakastietojärjestelmän osissa, jotka vastaavat asiakirjojen muodostamisesta ja jäsentämisestä. Koska asiakirjojen muodostus sisältää myös näyttömuotoihin liittyvät toiminnot, muutokset kohdistuvat niihinkin. - Ontologioiden versionumeroiden päivitys asiakastietojärjestelmän osassa, joka vastaa asiakirjojen muodostamisesta. Jos uusi pakollinen kenttä lisätään palvelutehtäväkohtaiseen tietokomponenttiin, ydintietokomponenttikirjaston ontologiaversiota ei tarvitse päivittää. Muuten muutokset ovat samat. Jos pakollinen kenttä lisätään tiettyyn asiakirjatyyppiin, mitään tietokomponenttikirjastojen ontologiaversioita ei tarvitse päivittää. Uuden valinnaisen kentän lisääminen ydintietokomponenttiin aiheuttaa seuraavat toimenpiteet: 1. Kansallisella tasolla - Tietokomponentin päivitys tietokomponenttikirjaston hallintatyökalun avulla tai vastaava DTD. 21

22 - Nykyisen ydintietokomponenttikirjaston ontologian päivittäminen ilman uuden version muodostamista. - Ydintietokomponenttikirjaston ontologian päivittäminen validointipalveluun. 2. Asiakastietojärjestelmien tasolla - Uuden kentän huomioiminen asiakastietojärjestelmän tietomallissa ja käyttöliittymässä. - Uuden kentän huomioiminen asiakastietojärjestelmän osissa, jotka vastaavat asiakirjojen muodostamisesta ja lukemisesta. Koska asiakirjojen muodostus sisältää myös näyttömuotoihin liittyvät toiminnot, muutokset kohdistuvat niihinkin. Pakollisen tai valinnaisen kentän poistaminen aiheuttaa samanlaiset toimenpiteet kuin vastaavanlaisen kentän lisääminen. Kentän muuttaminen valinnaisesta pakolliseksi tai pakollisesta valinnaiseksi aiheuttaa samanlaiset toimenpiteet kuin pakollisen kentän lisääminen. Uuden tietokomponentin lisääminen aiheuttaa samanlaiset toimenpiteet kuin uuden valinnaisen kentän lisääminen. Tietokomponentin poistaminen johtaa samanlaisiin toimenpiteisiin kuin uuden pakollisen kentän lisääminen. Poistamisen sijasta tietokomponentin käyttöä voidaan suositella vältettäväksi, jolloin muutokset jäävät ohjeistuksen tasolle. Palvelutehtäväkohtaisen tietokomponentin muuttaminen ydintietokomponentiksi aiheuttaa seuraavat toimenpiteet: 1. Kansallisella tasolla - Tietokomponentin siirto tietokomponenttikirjaston hallintatyökalun avulla. - Uuden ontologiaversion tuottaminen ydintietokomponenttikirjastosta. - Uuden ontologiaversion tuottaminen niiden palvelutehtävien palvelutehtäväkohtaisista tietokomponenttikirjastoista, joiden asiakirjatyypeissä uutta kenttää tarvitaan välittömästi. - Uusien ontologiaversioiden tuottaminen niistä asiakirjatyypeistä, joissa uutta ydintietokomponenttia tarvitaan välittömästi. - Uusien ontologiaversioiden lisääminen validointipalveluun. 2. Asiakastietojärjestelmien tasolla - Vanhojen ontologiaviitteiden (URI) korvaaminen uusilla viitteillä asiakastietojärjestelmän osassa, joka vastaa asiakirjojen muodostamisesta. Koska asiakirjojen muodostus sisältää myös näyttömuotoihin liittyvät toiminnot, muutokset kohdistuvat niihinkin. - Uusien ontologiaviitteiden lisääminen vanhojen rinnalle asiakastietojärjestelmän osassa, joka vastaa asiakirjojen lukemisesta. Vanhoja viitteitä ei voi korvata uusilla, koska arkistossa on edelleen asiakirjoja, joissa kyseiseen tietokomponenttiin viitattiin eri tavalla. Uuden asiakirjatyypin lisääminen aiheuttaa seuraavat toimenpiteet: 1. Kansallisella tasolla 22

23 - Uuden sisällöllisen asiakirjarakenteen mukaisen ontologian lisääminen. - Uuden ontologian lisääminen validointipalveluun. 2. Asiakastietojärjestelmien tasolla - Uuden asiakirjatyypin tietosisällön huomiointi asiakastietojärjestelmän tietomallissa ja käyttöliittymässä. - Uuden asiakirjatyypin huomiointi niissä asiakastietojärjestelmän osissa, jotka vastaavat asiakirjojen muodostamisesta ja lukemisesta. - Asiakirjan näyttömuodon tuottamisen toteutus. Jos olemassa olevista tietokomponenteista puuttuu uuden asiakirjatyypin kannalta tärkeät kentät, ne pitää ensin lisätä, eli suorittaa kenttien ja tietokomponenttien lisäämiset tarvittavine toimenpiteineen. Asiakirjatyypin poistaminen voi aiheuttaa paljon työtä tietomallin loogisella tasolla, eli sisällöllistä käsittelyä. Sisällöllinen käsittely voi johtaa joidenkin kenttien tai tietokomponenttien poistamisen tietokomponenttikirjastosta, mikä aiheuttaa vastaavia toimenpiteitä teknisellä tasolla. Niiden lisäksi pitää suorittaa seuraavat tekniset toimenpiteet: 1. Kansallisella tasolla - Asiakirjaontologian poistaminen validointipalvelusta. 2. Asiakastietojärjestelmien tasolla - Asiakirjan poiston huomioiminen tietojärjestelmän tietomallissa ja käyttöliittymässä. - Poiston huomioiminen asiakastietojärjestelmän osassa, joka vastaa asiakirjojen muodostamisesta. Muutostenhallinta XHTML+RDFa-tapauksessa johtaa siihen, että näyttömuotojen toteutus ja ylläpito siirtyvät asiakastietojärjestelmien tasolle. Nimiavaruuksien sijasta joutuu hallinnoimaan ontologiaversioita Muutostenhallinnan vertailu Nykyinen täysin skeemapohjainen SosXML ja XHTML+RDFa-asiakirjastandardi reagoivat muutoksiin hieman eri tavalla. Koska skeemapohjainen SosXML perustuu vahvasti skeemoihin ja RDFa ontologioihin, skeemapohjaisessa SosXML:ssä hallinnoidaan skeemaversioita, ja RDFa:ssa ontologiaversioita. Niiden hallinnoinnissa ei ole suuria eroja. Näyttömuotomääritysten hallinta on erilainen. Skeemapohjaisen SosXML:n tapauksessa riittää, että asiakastietojärjestelmät tuottavat XML-asiakirjat, joissa on kaikki tarvittavat tiedot ilman näyttömuotoja. Näyttömuotojen kehitys jää kansalliselle tasolle, vaikka niitä voi kehittää ja ylläpitää myös kuntakohtaisesti ja tietojärjestelmäkohtaisesti. XHTML+RDFa-tapauksessa asiakastietojärjestelmät joutuvat tuottamaan sekä tietosisällön että näyttömuodon, eli tuottamaan täydellisen XHTML- sekä RDFamerkkauksen. Pakollisuuksien määrä on sosiaalihuollon asiakastietomallissa hyvin pieni. Kummassakin asiakirjastandardivaihtoehdossa muutostenhallinta kevenee jonkin verran, jos pakollisuudet pois- 23

24 tetaan tietokomponenteista kokonaan ja käytetään niitä vain asiakirjojen tasolla. Pakollisuuksien tarkistuksen toteutus validointipalvelussa on erilainen eri asiakirjastandardeissa. Skeemapohjaisessa SosXML:ssä osan pakollisuuksista voi tarkistaa tavallisella validoinnilla asiakirjaskeemaa vasten. Tietokomponenttien kenttien asiakirjakohtaiset pakollisuudet voi toteuttaa Schematron-säännöillä. XHTML+RDFa-tapauksessa asiakirjoissa olevien pakollisuuksien tarkistaminen validointipalvelussa voidaan toteuttaa asiakirjakohtaisten sääntöjen lisäämisellä. Toteutetun kyselyn kohdassa 3.3 kysyttiin kumpi muutostenhallintatapa vaikuttaa helpommalta. Neljä vastaajaa kannatti XHTML+RDFa-mukaista muutostenhallintatapaa, loput vastaajat eivät osanneet tai halunneet vastata tähän kysymykseen. Vastaukset voidaan tulkita niin, että kukaan ei kannattanut skeemapohjaisen SosXML:n mukaista muutostenhallintatapaa. Kysymyksessä 3.4 kysyttiin, onko skeemojen nimiavaruuksien sekä nimiavaruuskohtaisten näyttömuoto- ja muiden määritysten hallinta kohtuullinen vaatimus tietojärjestelmille. Neljä vastaajaa vastasi, että vaatimus on kohtuullinen, yksi vastaaja totesi vaatimuksen olevan kohtuuton. Kaksi vastaajaa ei halunnut tai osannut vastata kysymykseen. Vastaukset voidaan tulkita niin, ettei skeemojen määrä ole iso este järjestelmien kehittämiselle. 4.2 Toteutuskynnys ja tarvittava osaaminen SosXML-skeemat ja XHTML+RDFa-standardi sekä niiden avulla toteutetut asiakirjainstanssit perustuvat XML-kieleen. Skeemapohjainen SosXML ei nykyisten määritysten mukaan tue asteittaista rakentamista (ks. luku 4.5), joten sen käyttöönoton aiheuttamat välittömät vaikutukset järjestelmän tietomalliin ovat huomattavasti XHTML+RDFa-standardia laajemmat. Kuva 2: SosXML-mukaisen asiakirjan muuntaminen järjestelmän ymmärtämään muotoon Asiakirjojen versioiden hallinta on toteutuksen kannalta jonkin verran vaikeampaa skeemapohjaisessa SosXML:ssä. Kuvassa 2 on esitetty eräs vaihtoehto, jolla uutta asiakirjaskeeman versiota (versio 3) tukeva asiakastietojärjestelmä pystyy jäsentämään arkistosta poimittua vanhempaa asiakirjaversiota (versio 1) noudattavaa asiakirjaa. SosXML-skeemoja noudattavien asiakir- 24

25 jojen lukeminen vaatii tässä tapauksessa muunnospalvelun, joka muuntaa esimerkiksi XSLTmuunnoksien avulla asiakirjan tietomallin version järjestelmän tukemaksi versioksi. Toisena vaihtoehtona on kaikkien eri skeemaversioiden lukumoduulien ylläpito asiakastietojärjestelmässä. Lisäksi asiakirjojen näyttämistä varten tarvitaan näyttömuotopalvelu, joka osaa tuottaa muuttumattomat näyttömuodot tietomallin eri versioiden mukaisista asiakirjoista. Mikäli asiakastietojärjestelmä ymmärtää vain vanhempia skeemaversioita kuin se, jota on käytetty arkistosta haetussa asiakirjassa, järjestelmä ei välttämättä pysty jäsentämään asiakirjan sisältämää tietoa. Järjestelmä ei myöskään voi näyttää asiakirjaa käyttäjälle muutoin paitsi käyttämällä näyttömuotopalvelua. XHTML+RDFa-standardin mukaisten asiakirjojen versionhallinta on järjestelmän kannalta helpompaa. Järjestelmä poimii asiakirjasta tiedot RDF-muodossa ja käsittelee vain ne tiedot, joita se pystyy järjestelmässä olevan tietomallin mukaan hyödyntämään. Järjestelmä pystyy kuitenkin näyttämään koko asiakirjan. Jos käytetään XHTML+RDFa-standardin mukaisia asiakirjoja erillistä näyttömuotopalvelua ei tarvita. Kuva 3: XHTML+RDFa-standardin mukaisen asiakirjan muuntaminen järjestelmän ymmärtämään muotoon XHTML+RDFa-standardin toteuttaminen edellyttää XHTML-standardin, RDF-standardin sekä XHTML+RDFa-yhdistelmän osaamista. Kyselyyn vastanneista organisaatioista suurin osa on tutustunut XHTML-standardiin sekä semanttisen webin teknologioihin (kuten RDF), mutta XHTML+RDFa-yhdistelmän tuntemus osoittautui heikoksi. Skeemapohjaisen SosXML:n mukaisten asiakirjojen käsittely on toteutettavissa yleisesti käytössä olevilla ohjelmakirjastoilla kuten JAXB, Xalan ja Apache Xerces. XHTML+RDFa-standardin mukaisten asiakirjojen käsittely on toteutettavissa ohjelmakirjastoilla kuten jxbrowser, rdfacore-java, Jena, Jenabean ja Apache Xerces. Kyselyn vastaukset osoittavat, että osassa organisaatioita on jo tutustuttu SosXML-skeemoihin. Vastauksissa on myös kerrottu, että SosXMLskeemat vaikuttavat selkeiltä. Kummankin asiakirjastandardin käyttö edellyttää sosiaalihuollon asiakastietomalliin tutustumista, ja tämä muodostaakin suurimman osaamisvaatimuksen. 25

26 4.3 Näyttömuodot Näyttömuodolla tarkoitetaan asiakirjan tietojen asettelua ja asiakirjan yleistä ulkoasua, joka on helposti ihmisen luettavissa. Tietojen asettelussa on sovellettu SFS standardia. Esimerkit asiakirjan näyttömuodosta löytyvät liitteistä D ja E. Näyttömuotojen toteutus riippuu valitusta dokumenttistandardista. Skeemapohjaisissa SosXML-asiakirjoissa tarvitaan skeemaversiokohtaisia muunnostiedostoja, joissa on tarkkaan määritelty tietojen esittämisjärjestys. Skeemapohjaisen SosXML-asiakirjan tiedot tulostetaan oletusarvoisesti samassa järjestyksessä kuin tietojen ilmenemisjärjestys asiakirjan lähdekoodissa. Poikkeukset tästä säännöstä on toteutettava manuaalisesti jokaista skeemaversiota kohden. XHTML+RDFa perustuu yhteen skeemaan, joten erikseen ylläpidettäviä näyttömuotoja ei tarvita. Seuraavassa tarkastellaan näyttömuotojen toimivuus kummassakin asiakirjastandardissa tarkemmin Erilliset SosXML-näyttömuodot Skeemapohjaisen SosXML:n mukaiset asiakirjat muutetaan XSL-muunnoksella XSL-FOmuotoon (XSL Formatting Objects). XSL-FO on merkkauskieli, joka voidaan muuntaa puolestaan PDF-muotoon. Jokaista asiakirjaskeeman versiota kohden täytyy olla myös ajantasainen XSL-muunnostiedosto, joka sisältää muunnossäännöt rakenteisista asiakirjoista luettavaan muotoon. Kuva 4: Näyttömuotojen muodostaminen muunnostiedostojen pohjalta. Kuvassa 4 on esitetty ne näyttömuotomääritysten tyypit, joita käytetään SosXML-skeemoja noudattavien asiakirjojen muuntamiseen näyttömuotoon. Asiakirjakohtainen muunnostiedosto kertoo mitä tietoja rakenteisesta asiakirjasta näytetään ja asiakirjan muuttumaton rakenne (asiakirjojen yleinen näyttömuotokaava) määrittelee miten tiedot asetellaan näyttömuodossa. Asiakirjan muuttumaton rakenne sisältää SFS 2487 standardin mukaisen asiakirjan muotoilun ja tunnistetiedot. Asiakirjakohtainen muunnostiedosto sisältää asiakirjan otsikot ja tietokomponenttikohtaiset esitysmuodot. Muunnostiedostot liitetään yhteen näyttömuodon luomishetkellä. Muunnostiedostot hakevat vastaavuuksia rakenteisista asiakirjoista ja muuntavat ne näyttömuotoon rakenteisen asiakirjan ja asiakirjakohtaisen muunnostiedoston määräämässä järjestyksessä. Vaikka tietojen esittämisjärjestys määräytyy ensisijaisesti XML-rakenteen mukaisesti, on kuitenkin mahdollista 26

27 määritellä muunnostiedostokohtaisia esittämisjärjestyksiä. Tämä tehdään määrittelemällä versiokohtaiseen muunnostiedostoon tietokomponenttien tulostamisjärjestys. Asiakastietojärjestelmät voivat näyttää skeemapohjaisen SosXML:n mukaiset asiakirjat kolmella eri tavalla: 1. Asiakastietojärjestelmä jäsentää asiakirjan, poimii siitä asiakirjalliset tiedot, sijoittaa tiedot omaan tietokantaansa ja näyttää ne tietokantalomaketta tms. käyttöliittymää käyttämällä. 2. Asiakastietojärjestelmä muuntaa SosXML-asiakirja sopivaan muotoon (esimerkiksi PDF-, HTML- tai tekstimuotoon) käyttämällä XSLT-muunnostiedostoja. Muunnostiedostot ovat asiakirjaskeemakohtaisia. 3. Asiakastietojärjestelmä hakee asiakirjan näyttömuodon keskitetystä näyttömuotopalvelusta. Tapa 1 edellyttää, että järjestelmä osaa käsitellä kyseistä asiakirjaskeemaa, ja kaikille tiedoille löytyy vastaavuus järjestelmän tietokannasta ja käyttöliittymästä. Mikäli järjestelmä ei voi jäsentää tai hyödyntää joitakin asiakirjassa olevia tietoja, se ei välttämättä voi näyttää niitä käyttäjälle. Tapa 2 edellyttää, että järjestelmä ylläpitää omaa XSLT-muunnostiedostokirjastoa tai ylläpidetty kirjasto on keskitetyssä säilytyspaikassa, ja järjestelmä osaa hakea tarvittavat muunnostiedostot sieltä. Tapa 3 edellyttää, että järjestelmä osaa kommunikoida keskitetyn näyttömuotopalvelun kanssa (eli toteuttaa tarvittavat rajapintamäärittelyt). Keskitetyn näyttömuotopalvelun suorituskyvystä ja saatavuudesta on huolehdittava riittävän hyvin, muuten siitä voi muodostua pullonkaula, jos monet asiakastietojärjestelmät turvautuvat sen käyttöön XHTML+RDFa-näyttömuoto XHTML on laitteistoriippumaton dokumenttistandardi, jolla on laaja ohjelmistotuki. Näyttömuotomäärityksiä ei tarvitse erikseen ylläpitää. Näyttömuotojen yhtenäinen ulkoasu määritellään ohjeistavassa dokumentissa (Sosiaalihuollon näyttömuotomääritys). XHTML-syntaksi ei määrittele ulkoasua, jota käytetään silloin kun rakenteinen sisältö esitetään sovelluksessa. Yhtenäiset ulkoasut voidaan toteuttaa keskitetyllä tai asiakirjaan sisältyvällä CSS-määrityksellä. CSS (Cascade Style Sheet) on HTML-dokumenteille kehitetty tyylitiedosto. CSS-tyylitiedostolla voidaan määritellä XHTML-rakenteiden sijainti ja esitysmuoto kohdelaitteistosta riippumattomalla tavalla. CSS-tyylitiedosto voidaan sisällyttää XHTML-dokumenttiin, jolloin on myös mahdollista muokata asiakirjan ulkoasua esimerkiksi palveluntuottajakohtaisesti. Tällöin asiakirjojen ulkoasu voi vaihdella kunnittain ja tietojärjestelmittäin. XHTML+RDFa-standardi mahdollistaa asiakirjan tietosisällön esittämisen vapaassa järjestyksessä. XHTML-dokumentin rakenne voi perustua yhteiseen tai palveluntuottajakohtaiseen dokumenttipohjaan, johon tietosisällöt voidaan lisätä koneellisesti. 27

28 XHTML-näyttömuotojen tuki voidaan toteuttaa käyttöliittymiin valmiilla avoimen lähdekoodin kirjastoilla, kuten webkit 23. XHTML mahdollistaa myös asiakirjojen paremman integroitumisen nettikäyttöliittymiin. XHTML-dokumentit voi myös muuttaa PDF-muotoon esimerkiksi avoimen lähdekoodin Java-toteutuksella Näyttömuodot: yhteenveto Erillisten SosXML-näyttömuotomääritysten kehittäminen ja ylläpito on koettu hankkeessa työlääksi sen takia, että näyttömuotomääritykset ovat riippuvaisia tietokomponenttiskeemojen ja asiakirjaskeemojen versioista. Näyttömuotomääritysten ylläpitoon tuleekin varata riittävästi resursseja hankkeen jälkeen. XHTML+RDFa-tapauksessa erillistä näyttömuotopalvelua ei välttämättä tarvita, koska asiakastietojärjestelmiin on helppo lisätä selainkomponentit HTML-sivujen näyttämistä varten. Standardin haittapuolena on se, että asiakastietojärjestelmien pitää tuottaa myös asiakirjojen näyttömuodot (eli varustaa tiedot XHTML-merkkauksella) arkistoon tallentamista varten. Kyselyyn vastanneista kaksi henkilöä kannatti XHTML-mukaisia näyttömuotoja, ja kolme henkilöä kannatti näyttömuotojen generointia näyttömuotomääritysten avulla. Kaksi vastaajaa ei ottanut asiaan kantaa. Kunta- tai tietojärjestelmäkohtaisten näyttömuotojen sekä ulkoasujen mahdollistaminen on saanut kannatusta. 4.4 Arkistointi Kumpikaan asiakirjastandardi ei kelpaa Arkistolaitoksen Sähke 2 -määräyksen 25 mukaan arkistoitavaksi säilytysmuodoksi pysyväissäilytystä tai määräaikaissäilytystä varten. Kummastakin asiakirjastandardista voi tuottaa PDF/A-muotoisia asiakirjoja, jotka soveltuvat pysyväissäilytykseen ja määräaikaissäilytykseen. Myös Sähke 2 -määrityksessä hyväksyttyjä TIFF-muotoja voi tuottaa kummankin asiakirjastandardin mukaisista asiakirjoista. Kumpikin asiakirjastandardi mahdollistaa tarvittavien metatietojen lisäämisen arkistoitaviin asiakirjoihin. Skeemapohjaisen SosXML:n mukaiset asiakirjat sisältävät vain asiakirjalliset tiedot, mutta ei näyttömuotoja. Tämä ei ole toivottu ominaisuus arkistoinnin kannalta, koska varsinainen asiakirja muodostuu vain silloin kun asiakirjalliset tiedot yhdistetään näyttömuotoon. Koska samasta asiakirjasta voi muodostaa useita eri näyttömuotoversioita, voi olla vaikea määritellä mikä näistä versioista on alkuperäinen. Mikäli arkistoon tallennetaan skeemapohjaisen SosXML:n mukaiset asiakirjat, tämä johtaa siihen tilanteeseen, että arkistossa olevat asiakirjat noudattavat yli sataa eri skeemaa. Skeemat on määritelty kansallisella tasolla. Asiakirjojen näyttäminen ihmiselle edellyttää näyttömuotojen käyttöä tai asiakirjan sisällön jäsentämistä esimerkiksi kyseistä skeemaa tukevan asiakastieto- 23 Project Webkit: Arkistolaitos. Sähköisten asiakirjallisten tietojen käsittely, hallinta ja säilyttäminen. Määräys

29 järjestelmän avulla. Mikäli asiakirjat tallennetaan arkistoon XHTML+RDFa-muodossa, kaikki asiakirjat noudattavat yhtä skeemaa, joka on määritelty kansainvälisessä standardissa. Asiakirjat voidaan näyttää ihmiselle suoraan Internet-selaimen avulla ilman erillisiä näyttömuotoja. 4.5 Asteittainen rakenteistaminen Asteittaisella rakenteistamisella tarkoitetaan asiakirjan rakenteen muuntamista vaiheittain vapaasta tekstimuodosta tietojärjestelmien ymmärtämään tietorakenteista koostuvaan muotoon. Rakenteisuuden asteesta riippumatta tietojärjestelmien tulee lopulta tuottaa Tikesoshankkeessa määriteltyjä sisällöltään yhdenmukaisia asiakirjoja. Asteittain tapahtuvalla rakenteistamisella pyritään hallitsemaan tietojärjestelmiin kohdistuvien muutosten määrää. Lisäksi se mahdollistaa tietomallin kehittämisen esimerkiksi lakimuutosten tai käyttöönotossa ilmenneiden ongelmien vuoksi. Kyselyyn vastanneista neljä henkilöä kannatti asteittaista rakenteistamista. Kaksi vastaajaa kannatti asiakirjojen hyväksymistä arkistoon vain tarkoilla rakenteilla varustettuina heti alusta. Kaksi henkilöä jätti kysymyksen vastaamatta. XHTML+RDFa-muotoinen asiakirja on rakenteisen sekä rakenteistamattoman sisällön yhdistelmä ja näin ollen sitä voidaan hyödyntää asteittaisessa rakenteistamisessa. Asiakirja muodostaa RDF-rakenteita käyttäen ontologian, jonka sisällön oikeellisuus voidaan tarkastaa validointipalvelun avulla. Tietomallin muutoksien vaikutus kohdistuu yleensä järjestelmän tuottamiin uusiin asiakirjoihin, sillä ontologia pyritään pitämään taaksepäin yhteensopivana. Validointipalvelun esimerkkitoteutus tuotetaan osana Tikesos-hanketta. Skeemapohjainen SosXML-asiakirjastandardi ei nykyisten määrittelyjen mukaan mahdollista asteittaista rakentamista. Käytettäessä skeemapohjaista SosXML-standardia asteittaisessa rakenteistamisessa rakenteinen sisältö ja rakenteistamaton sisältö on toteutettava erillisinä kokonaisuuksina. Tämä edellyttää järjestelmältä kahden erillisen rakenteen allekirjoittamista ja säilyttämistä. Teknisesti ratkaisu on toteuttavissa esimerkiksi sijoittamalla rakenteistettu sisältö SosXML-muotoiseen osaan ja rakenteistamaton sisältö XSL-muotoiseen XHTML-pohjaan, jotka yhdistämällä muodostetaan asiakirjan näyttömuoto. XHTML+RDFa on kansainvälinen standardi, joten kansallisen standardin kehittäminen vaatii vahvat perustelut. 4.6 Asiakirjojen validointi Asiakirjojen validoinnilla varmistetaan, että asiakirjassa on käytetty oikeita rakenteita oikeassa järjestyksessä. Validoinnissa suoritettavat testit kohdistuvat muun muassa näihin sääntöihin. 29

30 Validoinnin päätarkoituksena on varmistaa, että asiakirjan vastaanottaja pystyy tulkitsemaan asiakirjassa olevia tietoja samalla tavalla, kuin asiakirjan laatija on tarkoittanut. 26 Skeemapohjaiset SosXML-muotoiset asiakirjat voidaan tarkistaa XML-validointia tukevalla tietojärjestelmällä, pohjautuen XML-skeemassa oleviin rakennemäärityksiin. XML-skeemoihin perustuvalla validoinnilla voidaan tarkistaa seuraavat asiakirjan ominaisuudet: Elementtien ja attribuuttien rakenteiden oikeellisuus. Elementtien järjestyksen oikeellisuus. Elementtien arvojen oikeellisuus. Elementtien kenttien pakollisuus, toistuvuus tai toistamattomuus Sosiaalihuollon asiakastietomallia kehittäessä on kuitenkin havaittu, että pakollisia kenttiä on vain vähän. Käytännössä tämä tarkoittaa sitä, että ydinkomponenteissa ei voida määritellä pakollisuuksia, joita asiakirjatasolla täytyy tarkistaa. Skeemapohjaista SosXML:ää noudattavia asiakirjoja voidaan validoida myös Schematron-kielellä. 27 XHTML+RDFa-rakenne validoidaan XHTML-skeemalla (tai DTD:llä) ja asiakirjan sisältö tarkistetaan sääntöpohjaisesti. XHTML-merkkauksen validointi varmistaa asiakirjarakenteen oikeellisuuden. RDF-sisällön validoinnilla voidaan varmistaa: Asiasisällön oikeellisuus Asiasisällön pakollisuus, toistuvuus tai toistamattomuus Korkeamman tason sisällön validointi (säännöt kuten jos yksityishenkilö on naimisissa, puoliso täytyy olla määritelty ). RDF-sisällön validointi eroaa XML-skeemoihin perustuvasta validoinnista siten, että elementtien järjestys XHTML-asiakirjoissa on valinnainen ja sääntöpohjainen validointi mahdollistaa myös korkeamman tason sisällön validoinnin samalla järjestelmällä. Vastaava toiminnallisuus täytyy toteuttaa XML-asiakirjoille erikseen vaihtoehtoisilla tavoilla, esimerkiksi käyttämällä Schematron-kieltä, XSLT-muunnoksia tai Relax NG -skeemoja. Tikesos-hankkeessa on toteutettu XHTML+RDFa-validointipalvelu (kuva 5). 26 Sosiaalihuollon teknisten asiakirjojen määritykset: 27 Schematron: 30

31 Kuva 5: XHTML+RDFa validointipalvelu XHTML+RDFa-asiakirja lähetetään SOAP-viestinä validointipalvelulle. Validointipalvelu tarkastaa XHTML-asiakirjan valittuja DTD-moduuleita vasten. DTD-moduuleilla voidaan rajoittaa tai laajentaa XHTML-asiakirjassa käytettyjä rakenteita. Tarkistetun XHTML-asiakirjan RDF-sisältö validoidaan sääntöpohjaisesti. Asiakirjan RDFsisältöä verrataan sosiaalihuollon ontologiaan. Validointipalvelu lähettää takaisin raportin asiakirjan sisällöstä. Jos asiakirja ei ole yhtenäinen sosiaalihuollon ontologiamäärittelyjen tai sääntöpohjaisten tarkistuksien kanssa, lähetetään asiasta virheraportti, joka sisältää virheiden tyypit ja sijaintitiedot. 4.7 Muunnokset muihin formaatteihin Kummankin asiakirjastandardin mukaisia asiakirjoja voidaan muuntaa muihin formaatteihin esimerkiksi XSLT-muunnostiedostoja käyttämällä. Skeemapohjaisen SosXML:n tapauksessa muunnostiedostot ovat asiakirjakohtaisia ja skeemaversiokohtaisia. Muunnostiedostoja on vähintään yhtä paljon kuin muunnettaviksi tarkoitettuja asiakirjatyyppejä. XHTML+RDFatapauksessa yksikin muunnostiedosto voi riittää. XHTML:n muuntamiseen yleisimpiin formaatteihin on olemassa valmiita työkaluja. 4.8 Koodistot Terveyden ja hyvinvoinnin laitos (THL) ylläpitää omia koodistojaan koodistopalvelimella. Myös muiden tahojen, kuten Kuntaliiton, tuottamia koodistoja löytyy koodistopalvelimelta. Koodistopalvelua käytetään laajasti terveydenhuollossa, jossa sillä on aktiivinen rooli potilastietojen rakenteiden kehittämisessä. 31