Miika Alonen Paula Leinonen Virpi Hotti Tommi Ahonen Heli Lintula

Transkriptio

1 S OSIAALIHUOLLON A S I A- K A S TIETOMALLIN S OVE L- T A MISOPAS ASIAKASTIETO MALLI N SOV ELTAMI S SÄÄNNÖT JA TEKNISTE N ASIAKIRJO JEN M UODO ST AMINE N Miika Alonen Paula Leinonen Virpi Hotti Tommi Ahonen Heli Lintula

2 SISÄLTÖ Sisältö Johdanto Sosiaalihuollon asiakastietomalli Säännöt Sääntö 1. Asiakirja on yksittäinen tiedosto Sääntö 2. Asiakirjarakenteessa sallitut XHTML-moduulit Sääntö 3. Asiakirjarakenteessa kielletyt XHTML-moduulit Sääntö 4. Asiakirjarakenteissa ei-suositellut XHTML-moduulit Sääntö 5. Asiakirjojen merkkaaminen RDFa-attribuuteilla Sääntö 6. Asiakastietojen yksilöiminen RDF-resursseiksi Sääntö 7. Sosiaalihuollon asiakastietomallin soveltaminen Sääntö 8. Koodeihin viittaaminen Tekniset asiakirjamallit (XHTML+RDFa+CSS ASIAKIRJAPOHJAT) Sosiaalihuollon asiakirjojen arkistointi Liite 1 : Asiakirjapohja

3 1 JOHDANTO Sosiaalihuollon asiakastietomallin soveltamisopas sisältää ohjeita ja sääntöjä sosiaalihuollon asiakasasiakirjojen muodostamiseen ja arkistointiin. Sosiaalihuollon asiakastietomalli (sosmeta.fi) kuvaa sosiaalihuollossa käytettävät yhtenäiset tietorakenteet ja tietojen käyttötarkoituksen. Tämä opas ohjeistaa muodostamaan sosiaalihuollon asiakastietomallin mukaisia asiakirjoja ja soveltamaan valittuja asiakirjastandardeja. Tämä dokumentti korvaa dokumentin Sosiaalihuollon asiakasasiakirjojen tekniset rakenteet: XHTML+RDFa- ja CSSstandardien soveltamisopas 1. Sosiaalialan tietoteknologiahankkeessa (Tikesos 2 ) mallinnettiin sosiaalihuollon palvelutehtäviin liittyvien asiakastietojen yhtenäinen tietosisältö ja tietojen väliset keskinäiset suhteet. Sosiaalihuollon asiakasasiakirjojen ja niissä käytettävien tietokomponenttien mallintamista kuvataan Sosiaalihuollon asiakastietojen kehittämisoppaassa. Sosiaalihuollon tietokomponentit ja asiakirjarakenteet muodostavat yhdessä sosiaalihuollon asiakastietomallin. Sosiaalihuollon asiakastietomallin muodostamiseen on sovellettu kansainvälistä Core Component Technical Specification 3 (CCTS) -menetelmää, muodostamalla menetelmästä RDF-pohjainen metatietomalli, joka mahdollistaa asiakirjojen tietosisällön kuvailun XHTML+RDFa-asiakirjoista. Sosiaalihuollon kuvailutietojen nimeämissäännöissä on sovellettu Julkishallinnon XML-skeemat -suositusta (JHS 170) 4. Sosiaalihuollon asiakastietomallin ajantasaiset tietokomponentit ja asiakirjamäärittelyt löytyvät sosmeta.fi-sivustolta 5. Sosiaalihuollon asiakasasiakirjojen tekniset rakenteet esitetään seuraavien World Wide Web Consortium (W3C) -standardien avulla: The extensible HyperText Markup Language (XHTML) 6. XHTML-suositusta (recommendation) käytetään web-sivujen esittämiseen. XHTML on XML-pohjainen kieli, jota voidaan laajentaa moduuleilla tai muodostaa siitä osajoukkoja tarpeen mukaan. Myös kehitteillä olevaa HTML5-kieltä 7 käyttävät web-sivut ovat esitettävissä XHTML-syntaksin avulla. Resource Description Framework in attributes (RDFa)-standardi 8. RDFastandardi määrittelee rakenteet (attribuutit) RDF-muotoisen tiedon esittämiseen XML-rakenteessa. RDFa-attribuuttien avulla 9 voidaan merkata XHTML-dokumentin kohdat, jotka perustuvat yhteisesti sovittuihin sanastoihin. XHTML+RDFa:n avulla voidaan muodostaa ihmiselle helppolukuisia ja visuaalisesti rikkaita asiakirjoja, joiden tietosisällöt ovat myös koneellisesti käsiteltävissä. 1 Miika Alonen, Konstantin Hyppönen, Miika Heikkinen, Paula Leinonen, Virpi Hotti: Sosiaalihuollon asiakasasiakirjojen tekniset rakenteet: XHTML+RDFa- ja CSS-standardien soveltamisopas. Sosiaalialan tietoteknologiahanke, e3-a a8f2912/Sosiaalihuollon+asiakasasiakirjojen+tekniset+rakenteet.pdf United Nations, Centre for Trade Facilitation and Electronic Business. Core Components Technical Specification. Version JHS 170 Julkishallinnon XML-skeemat W3C. XHTML Module-based XHTML - Second Edition. W3C Recommendation 23 November W3C. RDFa 1.1 Primer. Rich Structured Data Markup for Web Documents. 9 Support for RDFa via XHTML Modularization 3

4 Cascading Style Sheet (CSS)-standardi 10. CSS-tyyliohjeilla voidaan määritellä XHTML-rakenteilla ilmaistujen tietojen sijainnit ja esitysmuodot kohdelaitteistosta riippumattomalla tavalla. CSS-tyyliohjeet voidaan sisällyttää suoraan XHTMLdokumenttiin. CSS-tyyliohjeiden avulla on mahdollista muokata asiakirjan ulkoasua esimerkiksi palveluntuottajakohtaisesti. Tällöin asiakirjojen ulkoasu voi hieman vaihdella kunnittain ja tietojärjestelmittäin. Valitut 11 standardit mahdollistavat asiakirjojen tietosisältöjen kuvaamisen, asiakirjan teknisen rakenteen ja näyttömuodon sisällyttämisen yhteen XHTML+RDFa-tiedostoon. Lisäksi muunnokset muihin muotoihin, esimerkiksi PDF-muotoon, voidaan automatisoida, koska kaikki asiakirjat noudattavat samaa XML-rakennetta 12. Luvussa 2 kuvataan asiakastietomalli eli tietokomponentit ja asiakirjat. Luvussa 3 esitellään teknisten asiakirjojen muodostamissäännöt. Luvussa 4 kuvataan tekniset asiakirjamallit ja niiden hyödyntäminen. Luvussa 5 kuvataan sosiaalihuollon asiakirjojen arkistointia. 2 SOSIAALIHUOLLON ASIAKASTIETOMALLI Sosiaalihuollon asiakirjoissa käytetään yleiskäyttöisiä tietokomponentteja ja asiakirjakohtaisia kenttiä. Tietokomponentit ovat semanttisia tietokokonaisuuksia, joita käytetään asiakirjojen tietosisällön kuvaamisessa. Sosiaalihuollon asiakastietomallin tietokomponentit kuvaavat reaalimaailman ilmiöitä joita käsitellään sosiaalihuollon asiakasasiakirjoissa. Tietokomponentit koostuvat yksinkertaisilla tietotyypeillä varustetuista kentistä ja viittauskentistä, jotka voivat viitata muihin tietokomponentteihin. Kuva 1 havainnollistaa tietokomponenttiin liittyviä käsitteitä Sosiaalialan tietoteknologiahanke - Johtoryhmän kokous , kokousmuistio, kohta Miika Alonen, Konstantin Hyppönen, Sami Korhonen. XHTML+RDFa-standardin soveltuvuus osaksi sosiaalihuollon asiakirjastandardia. Selvitysraportti. Sosiaalialan tietoteknologiahanke,

5 Kuva 1. Komponenttikirjastoon liittyvät käsitteet ja esimerkki tietokomponentista Luokalle määritellään kenttiä, jotka yhdessä muodostavat halutun tietokokonaisuuden. Tietokomponentti muodostetaan tiettyyn käyttötarkoitukseen, ja tietokomponentin kentät tarkentavat käyttötarkoitusta määritelmien ja huomautuksien kautta. Luokan kenttien määrittely edellyttää kuitenkin luokkien tavoin yhteisesti sovittuja kuvailutietoja (Kuva 2), koska kenttiä voidaan käyttää eri luokissa kuvaamaan samaa tietosisältöä. Kuva 2. Esimerkki kenttäkohtaisista kuvailutiedoista. Sosiaalihuollon tietokomponenteissa käytetään JHS tietotyyppejä, jotka vastaavat XML Schema Part 2: Datatypes Second Edition 14 -määritysten mukaisia XSD-tietotyyppejä:

6 xsd:decimal o o o o xsd.string xsd:date xsd:time o o o o o o xsd:datetime o xsd:boolean o Maara Numero Prosentti Lkm Nimi Tunnus Teksti Koodi Pvm Aika Hetki Kytkin JHS 170 tietotyypeille on kuitenkin määritelty xsd-tietotyyppejä tarkempi semanttinen merkitys: Aika. Kellonaika, ajankohta Koodi. Sallittujen arvojen luettelo, jonka jokainen yksittäinen arvo on merkkijono, jota käytetään korvaamaan tai edustamaan tiettyä koodatun tiedon arvoa tai määritelmää Kytkin. Kahdesta arvosta koostuva pari (boolean, kyllä/ei) Lkm. Muiden kuin rahayksikköjen lukumäärä Maara. Rahallinen arvo valuuttayksikköinä Nimi. Merkkijono, joka kuvaa tietyn asian nimeä. Numero. Tarkoittaa merkkiä, jolla luku kirjoitetaan Prosentti. Prosenttilukuna esitettävä numeroarvo Pvm. Päivä kalenterissa, ajankohta Hetki. Päivä kalenterissa ja kellonaika, ajankohta Teksti. Jonkin luonnollisen kielen merkkijono Tunnus. Merkkijono, jota käytetään muodostamaan jollekin objektin esiintymälle identiteetti tai erottamaan se muista yksiselitteisellä tavalla Tietokomponenttien kentille määritelty toistuvuus- ja pakollisuustiedot kertovat, voiko tietokenttä toistua ja onko sen käyttö pakollista (Taulukko 1). Esimerkiksi, jos kentän kardinaliteetti on 1..1, niin kenttä on pakollinen ja voi saada täsmälleen yhden arvon. 6

7 Taulukko 1. Kardinaliteetit Merkintä Selite 0..1 Valinnainen kenttä, joka saa enintään yhden arvon 1..1 Pakollinen kenttä, joka voi saada täsmälleen yhden arvon 0..* Valinnainen kenttä, joka voi saada useita arvoja 1..* Pakollinen kenttä, joka voi saada useita arvoja Sosiaalihuollon asiakirjarakenteet on muodostettu tarkentamalla sosiaalihuollon asiakastietomallissa määriteltyjä tietokomponentteja ja määrittelemällä asiakirjakohtaisia kenttiä. Asiakirja vastaa luokkaa, jonka kentät kuvaavat tiettyä tietokokonaisuutta. Asiakirjassa voidaan määritellä myös asiakirjakohtaisia kenttiä, jos tietosisällön katsotaan liittyvän vain kyseiseen asiakirjaan. Kuva 3 sisältää asiakasasiakirjaan liittyvät käsitteet. Asiakasasiakirja koostuu tietokomponenteista ja asiakirjakohtaisista kentistä. Kuva 3. Asiakasasiakirjaan liittyvät käsitteet ja esimerkki asiakasasiakirjasta Tietokomponenttien ja asiakirjojen rakennetta voidaan tarkastella graafisesti luokkakaavioiden avulla. Asiakastietomallin luokkakaavioissa käytetään koosterakennetta, jolla pystytään kuvaamaan monimutkaisia rakenteita kuten luokan käyttöä toisen luokan osana Tommi Ahonen, Miika Alonen, Jaana Nevalainen, Konstantin Hyppönen, Virpi Hotti, Erja Ailio, Sami Korhonen. Sosiaalihuollon graafiset tietomallit ja tietomallisovellus, Sosiaalialan tietoteknologiahanke. 7

8 Käytetty notaatio on lähellä UML-notaatiota, mutta notaatiossa on eroja muun muassa luokkien suhteiden esittämisessä. Myöskään kaikkia UML-notaation ominaisuuksia ei ole otettu huomioon, koska niitä ei tarvita tietomallin esittämisessä. UPCC UML- CoreComponent -spesifikaatio 16 on huomioitu luokkakaaviota suunniteltaessa. Tietokomponenteista eli luokista luokkakaavio kuvaa tietokomponentin nimen sekä ominaisuudet eli kentät. Kentät koostuvat nimestä, tyypistä ja toistuvuusmääreistä. Esimerkiksi tietokomponentti Organisaatio koostuu kentistä Nimi, Y-tunnus, OID-tunnus ja Yhteystiedot, joista Yhteystiedot-kenttä on viittaus samannimiseen tietokomponenttiin (Kuva 4). Kuva 4. Tietokomponentit Organisaatio ja Yhteystiedot sekä niiden välinen suhde Tietokomponenteista ja asiakirjakohtaisista kentistä koostuvia asiakasasiakirjoja havainnollistetaan luokkakaavioiden (Kuva 5), sisällöllisten asiakirjarakenteiden (Kuva 7) ja teknisten asiakirjarakenteiden (Kuva 8) avulla. Kuva 5 havainnollistaa Toimeentulotukihakemusasiakirjan rakennetta. Kuva 5. Esimerkki Toimeentulotukihakemus-asiakirjan luokkakaaviosta Asiakirjakohtaisesti määriteltyjä kuvailutietoja voidaan tarkastella esimerkiksi asiakirjojen luokkakaaviosta (Kuva 6). 16 UN/CEFACT, UML Profile for Core Components (UPCC), Version 1.0, Final Specification 8

9 Kuva 6. Esimerkki asiakirjakohtaisista kuvailutiedoista Sisällöllinen asiakirjarakenne (Kuva 7) havainnollistaa asiakirjan rakennetta näyttämällä asiakirjan tietokomponentit ja kentät rakenteisessa muodossa. Tietokomponenteista tulostetaan selväkielinen nimi, pakollisuus, toistuvuus ja määritelmä. Tietokomponentin kentistä tulostetaan näiden tietojen lisäksi kentän tyyppi, huomautus, esimerkki sekä mahdollinen koodi tai fraasi. Kuva 7. Sisällöllinen asiakirjarakenne Tekninen asiakirjarakenne (Kuva 8) on tarkoitettu teknisille asiantuntijoille, ja se kuvaa asiakirjan nimiavaruuden, asiakirjan nimen, kuvailutietojen tekniset nimet ja käytettävät tietotyypit. 9

10 Kuva 8. Tekninen asiakirjarakenne Tekninen asiakirjarakenne määrittelee XHTML+RDFa-asiakirjassa käytettävien tietokomponenttien ja kenttien tekniset tietorakenteet. Tietokomponenteista ja niiden kentistä tulostetaan tekninen nimi, selväkielinen otsikko, toistuvuus ja pakollisuus, määritelmä sekä kentän XSD-tietotyyppi. 3 SÄÄNNÖT Standardien käyttöön liittyvät säännöt koskevat kaikkia sosiaalihuollon asiakasasiakirjoja. Säännöissä käytetään seuraavia termejä niin kuin ne on määritelty Internet Engineering Task Force (IETF) -järjestön suosituksessa 17 : PITÄÄ (MUST, REQUIRED, SHALL). Säännön osa on ehdottomasti pakollinen ( the definition is an absolute requirement of the specification ). EI PIDÄ (MUST NOT, SHALL NOT). Säännön osa on ehdottomasti kielletty ( the definition is an absolute prohibition of the specification ). PITÄISI (SHOULD, RECOMMENDED). Säännön osa on pakollinen, jollei löydy erityistä syytä, miksi säännön osaa ei noudata ( there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course ). EI PITÄISI (SHOULD NOT, NOT RECOMMENDED). Säännön osa on kielletty, jollei löydy esityistä syytä, miksi säännön osaa noudatetaan ( there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label ). SAA (MAY, OPTIONAL). Säännön osa ei ole pakollinen, mutta sitä voi noudattaa. Jokaisesta säännöstä on kerrottu perustelut ja tarvittaessa annettu soveltamisohjeita ja/tai esimerkkejä. Sääntöjä tulee noudattaa asiakirjoissa, jollei löydy erityistä syytä poiketa säännöstä (eli sääntöjen osat, joissa termit PITÄISI tai EI PITÄISI)

11 Säännöissä esiintyy seuraavat käsitteet: Resurssi. Yksikäsitteisen tunnuksen (kuten URI-osoitteen) omaava kohde, joka sisältää esimerkiksi tiedon kentän arvosta. Asiakirjassa oleva resurssi voi olla esimerkiksi tietokomponentti. Asiakirjan ulkopuolinen resurssi voi olla esimerkiksi koodisto tai organisaation www-sivut. Ilmentymä. Kun asiakasasiakirjaan täydennetään esimerkiksi tietokomponentin Yksityishenkilö kenttien arvot, niin syntyy tietokomponentin Yksityishenkilö ilmentymä. URI-viittaus. Viittaus resurssiin joka on määritelty asiakirjassa tai asiakirjan ulkopuolella. SÄÄNTÖ 1. ASIAKIRJA ON YKSITTÄINEN TIEDOSTO Asiakirjakohtaisen tiedon PITÄÄ sijaita yksittäisessä XHTML+RDFatiedostossa. Asiakirjan tietosisällön asettelussa PITÄÄ soveltaa W3C:n CSStyyliohjeita 18 ja asiakirjalle määriteltyä asiakirjapohjaa (LIITE 1). Asiakasasiakirjoihin SAA sisällyttää vain Base64-kuvia, jotka ovat samassa tiedostossa asiakirjasisällön kanssa. Asiakirjassa SAA olla URI-viittauksia asiakirjan liitteisiin ja muualla sijaitseviin ajallisesti pysyviin, yksilöityihin resursseihin kuten viittaus organisaation nettisivuille. Perustelu: Kun koko asiakirjan sisältö on samassa tiedostossa, se muodostaa selkeän kokonaisuuden, jonka arkistointi ja jälkikäsittely ovat helpompia kuin useasta eri tiedostosta muodostuvan kokonaisuuden. Asiakirjaan voidaan sisällyttää Base64-kuvia, koska sosiaalihuollossa käytetään usein palvelunantajien logoja. Myös viivakoodeja voi käyttää asiakirjoissa esimerkiksi tulosteiden yksilöintiin. Asiakirjojen tietosisällön yhtenäinen asettelu helpottaa asiakirjojen ymmärtämistä. Soveltamisohje: Asiakastietojärjestelmästä voidaan muodostaa yksittäisiä sosiaalihuollon asiakasasiakirjoja teknisten asiakirjamallien (Luku 4) ja sosmeta.fi-asiakastietomallin avulla. Asiakirjojen tietosisällön yhtenäinen asettelu koskee asiakirjojen tunnistetietoja, asiatietojen esiintymisjärjestyksestä ja asiakirjan yleistä asettelua. Teknisten asiakirjamallien rakenne koostuu seuraavasta rakenteesta, joka on määritelty div-elementeillä ja CSS-luokilla (Kuva 10). 18 W3C. Cascading Style Sheets Level 2 Revision 1 (CSS 2.1) Specification. W3C Recommendation 07 June luku

12 document header logo hdr1 hdr2 hdr3 main-wrapper meta list item fulltitle / fullcontent title content field ftr1 footer ftr2 ftr3 Kuva 9: Asiakirjarakenteessa käytettävät CSS-luokat Asiakirjarakenteessa käytettäville div-elementeille voidaan määritellä Jokaisella CSS-luokalla on tietty käyttötarkoitus (Taulukko 2) ja oma asettelunsa asiakirjassa, joka muodostaa näyttömuodon ulkoasun asiakirjapohjan (Liite 1) mukaisesti. Taulukko 2: CSS-luokat teknisissä asiakirjamalleissa classattribuutti document header logo Attribuutin käyttötarkoitus asiakirjan perusasettelu, kuten palstan leveys ja marginaalit ylätunniste palveluntuottajan logon formatointia varten varattu luokka 12

13 hdr1...hdr3 main-wrapper meta list item title content field fulltitle fullcontent footer ftr1...ftr3 ylätunnisteen sarakkeet luokka, jonka sisälle tulee varsinainen asiakirjan sisältö luokka asiakirjan metatietoja varten luokka, jonka sisälle sijoitetaan asiakirjan kohdat. Jokaisessa kohdassa on otsikko ja siihen kuuluva sisältö (pl. fulltitle ja fullcontent) luokka, jolla esitetään yksi asiakirjan kohta, eli otsikko ja sisältö otsikon alla asiakirjan kohdan otsikko asiakirjan kohdan sisältö yksittäinen kenttä otsikko, jonka leveys on sama kuin palstan leveys kohdan sisältö, joka tulee koko palstan leveydelle asiakirjan alatunniste alatunnisteen sarakkeet Asiakirjojen tulostumista yleisimmillä Internet-selaimilla pitää testata. Asiakirjassa olevaan CSS-tyyliohjeeseen voidaan tarvittaessa sisällyttää esimerkiksi mediakohtaisia ohjeita CSSstandardissa 19. SFS standardin mukainen palstan leveys voidaan määritellä esimerkiksi seuraavalla print { body {width=182.88mm} } Asiakirjaan voidaan lisätä Base64-kuvia, kuten logoja. Teknisissä asiakirjamalleissa on käytetty img-tagia, jolla base64/gif-kuvaformaatissa oleva logo on lisätty asiakirjaan. Logo tulostuu näyttömuotomääritysten mukaiselle paikalle asiakirjaan (Kuva 10). <div class="logo"><img src="data:image/gif;base64,ivborw0kggoaaaansuheugaaa CkAAAAmCAIAAADWVCV0AAAAAXNSR0IArs4c6QAAAARnQU1BAACxjwv8YQUAAAAJcEhZcwAADsMA AA7DAcdvqGQAAAQwSURBVFhH7VfbThNRFOUrjFcgSqKU+OYPaIwxvquP/oD6qNxDi0CVQjuFTlu ofrrbub5mrcix8yjeig8suvcrsfqeuc6lhdqzcc8502gmnbzdcvlimcltz+5zz6299zpnmst9uz L2D1r8j51afF4Q4U8QUkcai9ih5kLE2LSGohJiK/yAJr7RxRua1VhQLHa8pIMfP9kI1+OOToYNK XPuivL62MrUa+ubBNlQXd9YYXOOjk9hbDyaPnyKfFM0621qtdhcVsIz830hRss04eN4b6dWBlr8 vfxuahhiykknlcyqnlqhd/y8slffqj3mcukxnzw861zvwuvgwxc4ta4psnxd/5s3aszx3k/fpy1 NWjIWdBkzjB1E6ffYz6XllvbOaqfH7Wv6PDYZbym7shS9fIuir6WtknBXe5qsdV57vWdpeSXeTN KH16+1GidZ4/HXuqXbandNf5vDTq6nO+xuyOil3PAoAt7iZlF+Ir+J+bm+pza3P7tT67a5fFUOl 8PTuLK6rgaWu1w2WAQn7W88z4f5EC3wYTwCC5E3IWldaDWCPJTQW2DgzzrV8byb8Pr8j9oQadVW BjBoF8ckEDAPH7aG/Cx5Keg8z9Rd5PqrRXYtioeCkDoQZajHIHZlbTXIqfauqOYIV7YgzCzcZWF vhw4wzjkloxrjfp1/gpnd5zlnrd9apyzxqt7rqwf2ikqcfnjoty9tx0dgx8hhlxrcznzkl1v4jc 07xZTnUeY8eGXLTdStQ1u9VpBEUR4JpTHNZJ6KF4zV/T634PU/rHK4K+2kw33/w/BIRJ6HD7XfZ 19 W3C. Cascading Style Sheets Level 2 Revision 1 (CSS 2.1) Specification. W3C Recommendation 07 June luku

14 AuOMpZcptwEr6wljy7LpUtzWOIsz0KhSBmRRU+BHdVInWM4Nbj9LVaCxJUP23mlvX5mdh5VlMD5 rtbf2vt5aczsaszoexlm2qn27hlxbcva/svfouq4fn8jcbyzbdbwzyog2kkf3lwezuj+7r4bvl6 tj9dp4g02awtqnetbthczjcczxzkxigxrau7tcc/qwteqcfqrdybkkd4qhfofehf19gmokcmeyh EWVXZSYgw3LMJsovMPhl8TuHRQ6lD/q6tcd//WBkifKIoiH7Teq2sA6jaEDYYzGZiNRvKR9x6qO JOBiivJposy6YIj3NMbYjik4GH4mJkN8YbfTEzP2uq8FQ4S1K6qrX/V91Y6rat8NTL+kmm6xjov hbovh4db+ai0mriz+xchjaxktrunjcoocez5h4u9bwzf9a2mtqwgddalluvusfqvtyfgaen1jbf CGh9UsTfKW2MmWm9B7onXISdVkhrTjc9fijrX36qxIeP5JO1Uk2ARgB/6L0Tk2paXmPBxwthZUY WkPcnIBYxYS09rUbXl2k5OPcWzQYxmUULbAii7hBKpEkTeXhMJbzzfSVMXN5g80zh8r7CNPDXuL Xbyc9VeYWMT0bUzJT9/ATIQfoh8Gm2wAAAAAElFTkSuQmCC"/> Kuva 10: Näyttömuotomäärittelyiden mukainen ylätunniste varustettuna logolla selainnäkymässä SÄÄNTÖ 2. ASIAKIRJARAKENTEESSA SALLITUT XHTML-MODUULIT Seuraavien XHTML-moduulien elementtejä ja attribuutteja SAA käyttää sosiaalihuollon asiakirjoissa: Structure Module, Metainformation Module, Text Module, Hypertext Module, List Module, Presentation Module, Basic Tables Module, Tables Module, Image Module, Target Module, Style Sheet Module, Style Attribute Module. Perustelu: Moduulit määrittelevät elementtejä ja attribuutteja, joiden avulla sosiaalihuollon asiakirjoihin saa XHTML-perusrakenteet: Structure Module sisältää merkittävimmät XHTML-kielen rakenteelliset elementit body, head, html ja title. Metainformation Module määrittelee esimerkiksi käytettävän merkistön ja tekstin tyypin Text Module määrittää tekstiä sisältävät peruselementit kuten div, em ja strong. Hypertext Module määrittää elementin a, jonka avulla voidaan määritellä hyperteksti-linkit ulkopuolisiin tiedostoihin. List Module sisältää listatyyppisten elementtien määritykset. Text Extension Modules on joukko tekstin merkkaukseen tarkoitettuja moduuleja. Niistä käytetään Presentation Module -moduulia, joka määrittää esitystapaan liittyviä elementtejä kuten hr, sup ja sub Basic Tables Module ja Tables Module määrittävät taulukoiden merkkaamisessa käytettävät elementit. Image Module määrittää kuvan liittämiseen käytettävän img-elementin. Target Module määrittelee jota käytetään muun muassa siihen, että annetaan selaimelle ohje avata linkki uuteen selainikkunaan.style Shyle Sheet Module ja Style Attribute Module määrittelevät style-elementin ja samannimisen attribuutin, joiden avulla voidaan määritellä sisäisiä tyylitiedostoja. Soveltamisohje: Jos käytetään teknisiä asiakirjamalleja, niin säännössä esiintyviä moduuleja on käytetty seuraavasti: 14

15 Structure Module o body o head o html o title Metainformation Module o meta Text Module o div o span o br Image Module o img Style Sheet Module o style Säännössä esiintyviä moduuleja voidaan käyttää täydentämään teknisiä asiakirjamalleja seuraavasti: Esimerkki: Seuraava esimerkki on yksinkertaistettu, osittainen XHTML+RDFa+CSS -asiakirja. Dokumentin rakenne määritellään div-elementtien class-attribuuttien arvojen avulla. CSS-tyyliohje on head-osiossa. <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML+RDFa 1.1//EN" " <html xmlns=" <head> <title>rahalaitostiedustelupäätös</title> <meta http-equiv="content-type" content="text/html; charset=utf-8"></meta> <style type="text/css"> div.document { margin-top:10mm; margin-left:20mm; width: 212mm;}... </style> </head> <body prefix= ak: typeof="ak:rahalaitostiedustelupaatos"> <div class="document"> <div class="header" rel="as:header" resource="as:header_1"> <div class="meta"> <div property="ak:asiakirjatunnus" content=" ">... <div class="main-wrapper"> <div class="list"> <div class="item"> <div class="title">rahalaitostiedustelupäätös <!--Tietokomponentti alkaa: Asiakas--> <!--Määritelmä: henkilö, jota tiedustelu koskee--> <!--Huomautus: Sosiaalihuollon palveluprosessin näkökulmasta yksityishenkilö ajatellaan toimijana, joka osallistuu sosiaalihuollon palveluprosessiin muuna kuin ammattihenkilönä--> <!--HUOMIOI! Tämä viite on pakollinen!--> <!--HUOMIOI! Tämä viite voi toistua!--> <div class="item" rel="ak:asiakasyksityishenkilo"> <div class="title"><b>asiakas</b> <div typeof="ak:asiakas" about="ak:asiakas_d5e36"> <!--Kenttä: Sukunimi--> <!--Määritelmä: pääasiallisesti sukuun viittaava rekisteröidyn henkilönnimen osa--> <!--Huomautus: Sukunimi voi olla esimerkiksi Virtanen.--> <!--Esimerkki: Esimerkki--> <!--HUOMIOI! Tämä kenttä on pakollinen--> 15

16 <div class="content"> <div class="inline"> <div class="label">etunimet <div class="field" property="ak:etunimetnimi"> <div class="inline"> <div class="label">sukunimi <div class="field" property="ak:sukunimi">... <!--Tietokomponentti päättyy: Asiakas-->... <div class="footer"> <div class="f1" rel="sos:osoite" resource="ak:asiakirjanperustiedot. Yhteystiedot.Postiosoite_1"><b>Postiosoite</b><br></br>... </body> </html> SÄÄNTÖ 3. ASIAKIRJARAKENTEESSA KIELLETYT XHTML-MODUULIT Seuraavien moduulien sisältämiä elementtejä ja attribuutteja EI PIDÄ käyttää asiakirjoissa: Basic Forms Module, Object Module, Server-side Image Map Module, Frames Module, Iframe Module, Intrinsic Events Module, Scripting Module, Link Module. Perustelu: Säännössä lueteltuja moduuleja ei saa käyttää, koska ne voivat ulkopuolisiin lähteisiin viittaamalla muodostaa riskin asiakirjan eheydelle tai kokonaisuudelle sekä aiheuttaa tietoturvariskin. Moduulikohtaiset perustelut ovat seuraavat: Basic Forms Module määrittelee suppean joukon elementtejä lomakkeiden merkkaamiseen. Vaikka moduulissa määriteltyjä elementtejä voidaan käyttää käyttöliittymissä, arkistoitavissa asiakirjoissa niiden käyttöä ei sallita, koska ne voivat mahdollistaa asiakirjan tekstin editoinnin selaimessa. Huomaa, että toisen samankaltaisen moduulin, Forms Module, käyttö on sallittu tietyin varauksin, koska sen elementeille voidaan määritellä Object Module mahdollistaa viittaukset ulkopuolisiin objekteihin, joten tietoturvasyistä sitä ei saa käyttää. Server-side Image Map Module määrittelee elementit kuvakarttojen tekemiseen niin, että kuvakarttojen käyttö edellyttää kommunikointia asiakirjassa määritellyn palvelimen kanssa. Moduulin käyttö voi olla ristiriidassa arkistointikäytäntöjen kanssa, koska asiakirjan toiminnallisuus tulee riippuvaiseksi ulkopuolisesta palvelimesta. Frames Module mahdollistaa kehyksiin jaettujen sivujen tekemisen. Asiakirja jaetaan osiin, joihin viitataan eri URL-tunnuksilla. Moduulin käyttö ei ole sallittua, koska asiakirja jakautuu eri tiedostoihin. Iframe Module määrittelee inline-kehykset eli kehykset, jotka voivat esiintyä keskellä muuta asiakirjan sisältöä. Niiden käyttö on suunniteltu asiakirjan osan hake- 16

17 miseen toisesta tiedostosta. Moduulin käyttöä ei sallita, koska asiakirja jakautuu eri tiedostoihin. Intrinsic Events Module määrittää lomakkeiden käyttöön liittyviä attribuutteja. Moduulin käyttö lisää tarpeetonta dynaamisuutta arkistoituihin asiakirjoihin. Lisäksi se viittaa skripteihin, joiden käyttö on sosiaalihuollon asiakirjoissa kielletty. Scripting Module määrittää elementin script, joka mahdollistaa viittaukset ulkopuolisiin suoritettaviin tiedostoihin. Tietoturvasyistä sitä ei saa käyttää. Link Module määrittää elementin link, jonka avulla voidaan viitata ulkopuolisiin lähteisiin, joten sen käyttöä ei sallita. Soveltamisohje: Asiakirjassa ei saa käyttää viittauksia ulkopuolisiin lähteisiin, tai sisällyttää asiakirjaan mahdollisesti haitallista sisältöä. Käytännössä voidaan toimia siten, että mahdollisesti haitalliset elementit, kuten script-elementti, poistetaan asiakirjasta ennen arkistointia. SÄÄNTÖ 4. ASIAKIRJARAKENTEISSA EI-SUOSITELLUT XHTML-MODUULIT Seuraavien moduulien sisältämiä elementtejä ja attribuutteja EI PITÄISI käyttää sosiaalihuollon asiakirjoissa: Edit Module, Bi-directional Text Module, Forms Module, Metainformation Module, Client-side Image Map Module, Base Module. Perustelu: Säännössä on listattu ne moduulit, joiden käyttö ei ole arkistoitavissa asiakirjoissa ehkä tarpeellista. Moduuleja saa kuitenkin käyttää tarvittaessa perustellusti tietyin moduulikohtaisin rajauksin, jos tietojärjestelmän toteutus sitä edellyttää. Moduulikohtaiset rajaukset ovat seuraavat: Edit Module määrittelee tekstin editointia merkkaavat elementit del ja ins. Sosiaalihuollossa arkistoidaan vain valmiita asiakirjoja. Mikäli asiakirjan sisältöön tehdään korjauksia, asiakirjasta tehdään uusi versio, joka korvaa arkistossa vanhan version. Tehdyt korjaukset pitää perustella päivitetyn asiakirjan tekstissä, jolloin elementtien del ja ins käyttö ei riitä. Bi-directional Text Module määrittelee elementin bdo, jonka avulla voidaan merkata tekstin kirjoitussuunta. Elementin käyttö ei ole tarpeellista, koska sosiaalihuollon asiakirjat laaditaan aina suomen tai ruotsin kielellä. Forms Module määrittelee laajan joukon elementtejä lomakkeiden merkkaamiseen. Moduulia voidaan hyödyntää käyttöliittymissä, mutta arkistoitavissa asiakirjoissa moduulissa määriteltyjen elementtien käyttö ei välttämättä ole tarpeellista. Jos moduulia käytetään arkistoitavissa asiakirjoissa, elementeille input, select, textarea ja button PITÄÄ määritellä arvoksi disabled. Metainformation Module määrittää metatiedon lisäämiseen käytettävän metaelementin. Sosiaalihuollon metatiedot ilmaistaan tietokomponentin Header avulla, joten moduulin käyttö sosiaalihuollon metatietojen esittämiseen ei ole tarpeellista. Moduulia voidaan kuitenkin hyödyntää tarvittaessa muihin tarpeisiin. Client-side Image Map Module määrittelee elementit kuvakarttojen tekemiseen niin, että kuvakartan eri pisteistä viitataan eri URL-osoitteissa sijaitseviin resursseihin. Moduulille ei ole tunnistettu käyttöä sosiaalihuollon asiakirjoissa. 17

18 Base Module määrittää elementin base, jota käytetään määrittämään asiakirjan URI-osoite, johon asiakirjassa mahdollisesti käytettävät suhteelliset osoitteet perustuvat. Moduulille ei ole tunnistettu käyttöä sosiaalihuollon asiakirjoissa. Soveltamisohje: Kyseisiä moduuleja käyttävät elementit suositellaan poistettavaksi ennen asiakirjan arkistointia. SÄÄNTÖ 5. ASIAKIRJOJEN MERKKAAMINEN RDFA-ATTRIBUUTEILLA Asiakirjoissa esiintyvät sosiaalihuollon asiakastietomallin mukaiset asiakastiedot ja resurssit PITÄÄ merkata RDFa-attribuuteilla. Perustelu: Sosiaalihuollon asiakirjojen kansallinen rakenne ja resurssien merkkaus mahdollistaa tietosisällön yhdenmukaisuuden, arkistoinnin ja tietojen hyödyntämisen eri asiakastietojärjestelmissä. Soveltamisohje: Tekniset asiakirjamallit sisältävät seuraavat RDFa-attribuutit: typeof-attribuutin avulla määritellään asiakirjassa käytettävän rakenteen tyyppi. Attribuutin arvona voi olla esimerkiksi viittaus tiettyyn asiakirjatyyppiin tai tietokomponenttiin. resource-attribuutilla viitataan asiakirjassa tai asiakirjan ulkopuolelle yksilöityihin resursseihin, kuten koodistoihin, tai organisaation verkkosivuille. joka sisältää tiedot rakenteen arvosta. Sosiaalihuollon asiakirjoissa resource-attribuuttia käytetään about-attribuutilla nimettyihin resursseihin viittaamiseen. rel-attribuutin avulla ilmaistaan suhteet eri resurssien välillä. Sosiaalihuollon asiakasasiakirjoissa attribuuttia käytetään tietokomponentteihin perustuvien rakenteiden välisten suhteiden (käytännössä assosiaatiosuhteiden) esittämiseen. Attribuuttia ei käytetä yksinkertaisiin tietotyyppeihin perustuvien kenttien merkkaamiseen, vaan siihen soveltuu property-attribuutti. rel-attribuuttia käytetään vain silloin kun tietokomponentin tai asiakirjan kenttä viittaa toiseen tietokomponenttiin. property-attribuuttia käytetään merkitsemään kenttiä, joiden esitysmuoto on yksinkertainen tietotyyppi kuten Teksti. Esimerkiksi attribuuttia property on käytetty muun muassa siihen, että ilmaistaan henkilön etunimet (kenttä sos:etunimetnimi, jonka arvona on "Essi"). about-attribuutilla voidaan yksilöidä asiakirjassa esiintyvä ilmentymä. Attribuutin arvoksi muodostetaan yksilöllinen tunnus. Attribuutti on hyödyllinen silloin, kun asiakirjassa käytetyn tietokomponentin kentät eivät ole XHTML-rakenteessa peräkkäin. Tässä tapauksessa tietokomponentin ilmentymä yksilöidään aboutattribuutilla, ja tiedot ilmentymästä täydennetään siinä vaiheessa, kun ne tulevat XHTML-rakenteessa esille. content-attribuuttia käytetään property-attribuutin kanssa tilanteissa, joissa tiedon tallennusmuoto ei sovellu näyttömuotoon. Esimerkiksi, kun ISO standardin mukaisesti esitetty päivämäärä on ilmaistu xsd:date-muodossa. Esimerkki: Asiakirja, jossa on käytetty RDFa-attribuutteja ilmaisemaan tiedot asiakkaan nimestä ja yhteystiedoista. Esimerkkiä vastaava selaimen muodostama näyttömuoto on esitetty kuvassa Virhe. Viitteen lähdettä ei löytynyt.. 18

19 <?xml version="1.0" encoding="utf-8"?> <html version="xhtml+rdfa 1.1" xml:lang="fi" xmlns=" <head> <title>esimerkkiasiakirja</title> <style type="text/css">... </style> </head> <body prefix="ak: 1/10/15/ak# sos: <div class="document" typeof="ak:esimerkkiasiakirja"> <div class="header"> <div class="logo"><img src="data:image/png;base64,..." /> <div class="hdr1"><h1>organisaatio</h1> <div class="hdr2"><h1>esimerkkiasiakirja</h1> <div class="hdr3"> <div class="main-wrapper"> <div class="list"> <div class="item" rel="ak:asiakasyksityishenkilo"> <div class="title"> <h1>asiakas</h1> <div class="content"> <div property="sos:etunimetnimi">essi <div property="sos:sukunimi">esimerkki <div class="content" rel="sos:yhteystiedot"> <div property="sos:puhelinnumeroteksti"> <div rel="sos:osoite"> <div property="sos:lahiosoiteteksti">esimerkkikatu Esimerkkilä... <div class="footer"> <div class="ftr1"><h1>postiosoite</h1> <div class="ftr2"><h1>käyntiosoite</h1> <div class="ftr3"><h1>yhteystiedot</h1> </body> </html> 19

20 Kuva 11: Esimerkin mukainen näyttömuoto SÄÄNTÖ 6. ASIAKASTIETOJEN YKSILÖIMINEN RDF-RESURSSEIKSI Kun asiakastietoa kuvaavan tietokomponentin ilmentymä esiintyy eri paikoissa asiakirjan rakenteissa, niin ilmentymästä PITÄISI muodostaa yksilöity RDF-resurssi. Perustelu: Asiakastietojen yksilöiminen mahdollistaa yksilöityjen RDF-resurssien muodostamisen asiakirjan sisällöstä. Kun asiakastiedon ilmentymät on yksilöity, asiakirjasta muodostuu kokonaisuus, jossa ei ole useita kopioita samasta tietosisällöstä. Soveltamisohje: Yksilöi tietokomponentin kenttä about-attribuuutilla ja viittaa siihen resource-attribuutilla. Esimerkki: Jos kahdella eri asiakkaalla on sama osoite, niin kahden eri yksityishenkilön yhteystiedoista viitataan samaan osoitteeseen, jonka nimeksi on valittu Osoite_1. <div typeof="ak:asiakasyksityishenkilo"> <div property="sos:etunimetnimi">essi <div property="sos:sukunimi">esimerkki <div rel="sos:yhteystiedot"> <div property="sos:puhelinnumeroteksti"> <div rel="sos:osoite" resource="osoite_1"/> <div typeof="ak:asiakasyksityishenkilo"> <div property="sos:etunimetnimi">esa <div property="sos:sukunimi">esimerkki <div rel="sos:yhteystiedot"> <div property="sos:puhelinnumeroteksti"> <div rel="sos:osoite" resource="osoite_1"/> <div typeof="sos:osoite" about="osoite_1"> <div property="sos:lahiosoiteteksti">esimerkkikuja 1 <div property="sos:postinumerokoodi">1234 <div property="sos:postitoimipaikkanimi">espoo <div rel="sos:voimassaolo"> <div property="sos:alkamispaivapvm" content=" ">

21 <div property="sos:paattymispaivapvm" content=" "> SÄÄNTÖ 7. SOSIAALIHUOLLON ASIAKASTIETOMALLIN SOVELTAMINEN Asiakirjan tietosisällön PITÄÄ noudattaa sosiaalihuollon asiakastietomallissa määriteltyjä tietokomponentteja ja asiakirjarakenteita. Jokaiselle sosiaalihuollossa muodostettavalle asiakirjalle on määritelty tietosisällöt sosmeta.fi asiakastietomallissa. Asiakirjoissa käytettyjä nimiavaruuksia ja kuvailutietoja SAA lisätä, jos tarvittavia tietomäärityksiä ei ole määritelty kansallisella tasolla. Laajennukset PITÄISI sijoittaa nimiavaruuksiin, joissa käytetään päivämääriin perustuvaa versiointijärjestelmää. Perustelu: Sosiaalihuollon asiakirjojen kansallinen arkistointi ja semanttinen yhteentoimivuus edellyttää yhdenmukaisia asiakastietoja. Sosiaalihuollon kansallinen asiakastietomallin lisäksi, asiakastietojen laajennusten mahdollistaminen on katsottu hyödylliseksi keinoksi seurata tietotarpeiden kehittymistä. Laajennukset, esimerkiksi kunta- ja tietojärjestelmäkohtaiset rakenteet, sijoitetaan omaan nimiavaruuteensa ja niistä ilmoitetaan sosiaalihuollon tietomäärityksiä hallinnoivalle taholle. Soveltamisohje: Täydennä tekniseen asiakirjamalliin asiakastietoja asiakastietojärjestelmästä soveltuvalla menetelmällä (Luku 4). Teknisissä asiakirjamalleissa käytetään seuraavia nimiavaruuksia: ak: Asiakirjakohtaisten rakenteiden nimet kuuluvat seuraavalla tavalla muodostettuihin nimiavaruuksiin: vv/kk/pp/ak# sos: Viittaa tietokomponenttikirjastoon eli jokaisella tietokomponenttikirjastoon kuuluvalla resurssilla on oma URI-tunnus. Tietokomponenttikirjastossa määritellyt rakenteet (tietokomponentit ja niiden kentät) sijaitsevat nimiavaruudessa Esimerkki: Tietojärjestelmäkohtaiset laajennukset ovat nimiavaruudessa Esimerkiksi XHTML+RDFaasiakirjan lähdekoodissa voitaisiin käyttää tietojärjestelmäkohtaista kenttää tj:pikaviestiohjelmatunnus henkilön yhteystiedoissa. <?xml version="1.0" encoding="utf-8"?> <html version="xhtml+rdfa 1.1" xml:lang="fi" xmlns=" <head>... </head> <body prefix="ak: 21

22 1/10/15/ak# sos: tj: <div class="main-wrapper"> <div class="list"> <div class="item" rel="ak:asiakasyksityishenkilo"> <div class="title"> <h1>asiakas</h1> <div class="content"> <div property="sos:etunimetnimi">essi <div property="sos:sukunimi">esimerkki <div class="content" rel="sos:yhteystiedot"> <div property="sos:puhelinnumeroteksti"> <div rel="sos:osoite"> <div property="sos:lahiosoiteteksti">esimerkkikatu Esimerkkilä <div property="tj:pikaviestiohjelmatunnus"> </body> </html> SÄÄNTÖ 8. KOODEIHIN VIITTAAMINEN Koodit ovat muualla (esimerkiksi koodistopalvelussa) määriteltyjä resursseja, joihin PITÄISI viitata koodityyppisistä kentistä URI-tunnuksella. Perustelu: Koodistot ovat asiakirjan ulkopuolella sijaitsevia resursseja, joihin pitää viitata RDFa-standardin mukaan URI-tunnuksella. Koodisto muodostaa nimiavaruuden, jossa koodit sijaitsevat. Koodistossa määritelty yksilöllinen koodi muodostaa resurssin. Resurssit erotetaan nimiavaruudesta semanttisen webin teknologioissa yleensä #-merkillä 20. Soveltamisohje: Tällä hetkellä THL:n ylläpitämässä kansallisessa koodistopalvelussa oleviin koodistoihin ei voi viitata suoraan URI-tunnuksilla. Koodistoilla on olemassa OID-tunnukset, joiden avulla koodistoihin tulisi viitata osana URI-tunnuksia. Jos koodistolle on määritelty oma URI-tunnus, niin sitä pitää käyttää asiakirjoissa. Koodistoihin pitäisi pystyä viittaamaan esimerkiksi seuraavan URI-rakenteen mukaisesti (suluissa < ja > olevat arvot ovat muuttuvia, sulut eivät kuulu URI-tunnukseen): OID-tunnus>/<koodiston versio>#<koodiarvo> Esimerkki: Fimean ATC-luokituksen URI-tunnus on 20 Resource Description Framework (RDF): Concepts and Abstract Syntax. W3C Recommendation 10 February Luku

23 Esimerkiksi tietokomponentissa Lääke olevan kentän ATC-koodi arvo esitetään näin: <div rel="sos:atckoodi" resource= " 6.32/ #N05BA01">Diatsepaami 4 TEKNISET ASIAKIRJAMALLIT (XHTML+RDFA+CSS ASIAKIR- JAPOHJAT) Tekninen asiakirjamalli sisältää kaikki sosiaalihuollon asiakastietomallissa määritellyt kuvailutiedot. Kuvailutiedot määrittelevät ne asiakastiedot, joita kyseisessä asiakirjassa käytetään. Asiakirjamallit toteuttavat teknisissä asiakirjarakenne-taulukoissa (esim. Kuva 9) kuvatut asiakirjat ja sisältävät taulukossa määritellyt kuvailutiedot. Teknisten asiakirjamallien hyödyntämisen päävaiheet ovat seuraavat: 1. Määrittele asiakastietojärjestelmän tietomallin ja sosiaalihuollon asiakastietomallin tietomäärityksien vastaavuus palvelutehtäväkohtaisesti. Tietojen vastaavuutta voidaan tarkastella sisällöllisten asiakirjarakenteiden ja asiakirjojen luokkakaavioiden avulla. 2. Muodosta sosiaalihuollon asiakastietomallin mukainen tietokannan rakenne. Hyödynnä sosiaalihuollon asiakastietomallin tietokomponenttikirjastoa ja asiakirjojen luokkakaavioita. 3. Määrittele sosiaalihuollon asiakirjassa käytettävät fraasit ja otsikot. 4. Muodosta sosiaalihuollon asiakirjalle asiakirjapohja, hyödyntäen sosiaalihuollon asiakastietomallissa kuvattuja teknisiä asiakirjarakenteita ja teknisiä asiakirjamalleja. Yhdistä asiakirjapohjassa käytetyt kentät (RDFa-attribuutit) asiakastietojärjestelmän asiakastietoihin. 5. Tarkasta, että asiakirjamallin mukaiset asiakirjat ovat validointipalvelun 21 mukaan valideja (muodostettuja asiakirjaesimerkkejä pitää tarkistaa validointipalvelujen avulla, esimerkiksi W3C tarjoaa XHTML-validointipalvelun 22 sekä CSSvalidointipalvelun 23 ). Teknisen asiakirjamallin käyttäjä voi poistaa osan rakenteesta, jollei se ole asiakastietomallin mukaan pakollinen. Osa kuvatusta rakenteesta voidaan myös toistaa asiakirjassa asiakastiedoista riippuen. Esimerkkinä, jokaisessa asiakirjamallissa on kuvattu vain yksi asiakas, kun käytännössä asiakasta tai asiakaan toistuvia tietoja toistetaan riittävän monta kertaa, saatavilla olevasta tietomäärästä riippuen. 21 Atte Roppola, Konstantin Hyppönen, Miika Alonen, Juha Mykkänen, Heli Viinikainen, Esa Paakkanen, Marko Suhonen, Heli Lintula. Sosiaalihuollon yhteiset tietojärjestelmäpalvelut: Asiakirjojen validointipalvelu. Toiminnallinen rajapintakuvaus. Sosiaalialan tietoteknologiahanke, f481f72dad76/asiakirjojen+validointipalvelu.pdf

24 Esimerkki: Teknisen asiakirjamallin rakenteen muuttaminen. Asiakirjan asiakas-tietokomponentilla (Kuva 13) on valinnainen, korkeintaan kerran esiintyvä ([0..1]) kenttä siviilisaatykoodi sekä valinnainen, mahdollisesti toistuva ([0..*]) kenttä ammattiteksti. Kuva 12: Asiakas tietokomponentti Asiakirjalle määritelty alkuperäinen tekninen asiakirjamallipohja on seuraavanlainen: <!--Kenttä: Siviilisääty--> <!--Määritelmä: henkilön parisuhdeasema--> <!--Huomautus: Siviilisäätyjä ovat avioliitto, naimaton, rekisteröidyssä parisuhteessa, eronnut, leski, asumuserossa. Avoliitto ei ole siviilisääty. Viittaus: Valtioneuvoston asetus väestötietojärjestelmästä 128 tai > <!--Esimerkki: 1 (Naimaton)--> <div class="item"> <div class="title">siviilisääty <div class="content"> <div class="field" property="ak:siviilisaatykoodi" content=" ">1 (Naimaton) <!--Kenttä: Ammatti--> <!--Määritelmä: toiminta tai työ, jota yksityishenkilö tekee saadakseen tuloa--> <!--Esimerkki: Tehtaanjohtaja--> <!--HUOMIOI! Tämä kenttä voi toistua--> <div class="item"> <div class="title">ammatti <div class="content"> <div class="field" property="ak:ammattiteksti">tehtaanjohtaja 24

25 Tietylle asiakkaalle halutaan poistaa siviilisäätykoodin määrittävä kenttä sekä tallentaa kaksi ammattia. Teknistä asiakirjamallia muokataan poistamalla siviilisäätykoodin määrittävä div-elementti ja kopioimalla ammatti-kentän määrittävä div-elementti muokattuun pohjaan: <!--Kenttä: Ammatti--> <!--Määritelmä: toiminta tai työ, jota yksityishenkilö tekee saadakseen tuloa--> <!--Esimerkki: Tehtaanjohtaja--> <!--HUOMIOI! Tämä kenttä voi toistua--> <div class="item"> <div class="title">ammatti <div class="content"> <div class="field" property="ak:ammattiteksti"> <div class="item"> <div class="title">ammatti <div class="content"> <div class="field" property="ak:ammattiteksti"> Tekniset asiakirjamallit löytyvät palvelutehtävittäin jaoteltuna osoitteesta sosmeta.fi. Asiakirjan lähdekoodi avataan hiiren oikean puoleisella näppäimellä avautuvasta valikosta. Asiakastiedoilla täydennetyn sosiaalihuollon asiakirjan voi muodostaa soveltamalla alla olevaa prosessia: 1. Tallenna tekninen asiakirjamalli omaan projektiisi ja muokkaa asiakirjamallin lähdekoodiin haluamasi ulkoasu, otsikot ja fraasit. 2. Viittaa asiakirjamallin kuvailutiedoilla (property, rel, about) asiakastietojärjestelmän keräämiin asiakastietoihin järjestelmälle parhaiten soveltuvalla menetelmällä. 3. Tarkista muodostetun asiakirjan oikeellisuus Sosiaalihuollon asiakirjojen validointipalvelussa Teknisiä asiakirjamalleja voidaan hyödyntää sosiaalihuollon asiakirjoja muodostavissa asiakastietojärjestelmissä monella eri tavalla: Asiakirjan XHTML+RDFa-rakennetta voidaan käsitellä esimerkiksi eri ohjelmointikielillä, jotka tukevat W3C:n määrittelemää XML-DOM 24 -oliomallia. Teknistä asiakirjamallia voidaan käyttää pohjana asiakastietojärjestelmäkohtaiselle asiakirjapohjalle (esim. jsp-, scala- tai php-template), jonka avulla tekniseen asiakirjamalliin lisätään sosiaalihuollon asiakastietoja. Asiakastiedoilla varustetun valmiin asiakirjan voi muodostaa XSLT 25 -muunnoksella tai XQuery 26 -kyselykielellä asiakastietojärjestelmäkohtaisesta XML-muodosta, jolloin teknisiä asiakirjamalleja voidaan käyttää pohjana asiakastiedoilla varustetun XHTML+RDFa-muodon kehittämiselle

26 Täydentämällä teknisen asiakirjamallin sisältöä suoraan W3C DOM ja RDFajavascript jäsentimillä, kuten VIE JS ja Create JS 27 5 SOSIAALIHUOLLON ASIAKIRJOJEN ARKISTOINTI Sosiaalihuollon asiakasasiakirjat tallennetaan sosiaalihuollon KanSa-arkistoon Health Level 7 Clinical Document Architecture Release 2 (HL7 CDA R2) -mukaisesti muodostetussa kääreessä 28. Kuvassa 13 on esitetty CDA-kääreessä olevan sosiaalihuollon asiakasasiakirjan tärkeimmät sisältöosiot. HL7 CDA R2 - asiakirja (kääre) Metatiedot (kaikki) ja sähköiset allekirjoitukset ClinicalDocument.component.nonXMLBody.text Asiakirja ( XHTML+RDFa+CSS ) Base64 - koodattuna Metatiedot (muuttumattomat) Asiakirjan varsinainen sisältö Kuva 13: Sosiaalihuollon asiakasasiakirja CDA-kääreessä CDA-kääre sisältää asiakirjan metatiedot ja asiakirjan, joka on tallennettu CDA-kääreeseen Base64-koodattuna 29 merkkijonona. PDF/A-asiakirjojen kääriminen toimii samalla tavalla. Sosiaalihuollon asiakasasiakirjojen metatiedot 30 tallennetaan kahteen eri paikkaan. Kaikki metatiedot tallennetaan CDA Header -osioon metatietotaulukon 31 osoittamalla tavalla (Taulukko 3). Lisäksi muuttumattomat (ei-päivitettävät) metatiedot tallennetaan myös asiakirjaan käyttämällä Header-nimistä tietokomponenttia. Sähköiset allekirjoitukset 32 sijaitsevat vain CDA-tasolla ja noudattavat XML Signature -standardia VIE JS Create JS 28 Marko Suhonen, Mika Tuomainen, Esa Paakkanen, Juha Mykkänen, Konstantin Hyppönen. Sosiaalihuollon viestinvälitys arkistoon. Sosiaalialan tietoteknologiahanke Network Working Group. RFC The Base16, Base32, and Base64 Data Encodings. October Esa Paakkanen, Maarit Laaksonen, Pekka Kortelainen, Juha Mykkänen, Marko Suhonen, Heli Viinikainen, Erja Ailio, Konstantin Hyppönen, Mika Tuomainen. Sosiaalihuollon asiakasasiakirjojen metatiedot. Sosiaalialan tietoteknologiahanke, Metatiedot taulukkomuodossa, , versio Atte Roppola, Jani Komulainen, Mika Tuomainen, Aki Miettinen, Veli-Matti Lammentausta, Marko Suhonen, Konstantin Hyppönen, Juha Mykkänen, Tommi Ahonen, Heli Luostarinen, Esa Paakkanen, Lauri Väätäinen, Jatta Aholainen. Sosiaalihuollon yhteiset tietojärjestelmäpalve- 26

27 Taulukko 3. Taulukoissa kuvataan sosiaalihuollon metatietojen mappaus asiakirjojen kuvailutietoihin ja edelleen CDA R2 headeriin Metatieto Asiakirjojen kuvailutieto CDA R2 header -tietokenttä Identifiointitunnus asiakirjatunnus ClinicalDocument.id Alkuperäisen asiakirjan identifiointitunnus alkuperainenasiakirjatunnus ClinicalDocument.setId Julkisuusluokka julkisuusluokkakoodi ClinicalDocument.confidentialityCode Rekisterinpitäjä ClinicalDocument.custodian.assignedCustodian.representedCustodia norganization.id Laatimisaika laatimisaikahetki ClinicalDocument.effectiveTime Versio versionumero ClinicalDocument.versionNumber Kieli kielikoodi ClinicalDocument.languageCode Palvelun tuottajan organisaatiokoodi palveluntuottajanorganisaatiokooditunnus ClinicalDocument.componentOf.encompassingEncounter.responsibl eparty.assignedentity.representedorganization.id Palvelun tuottajan nimi palveluntuottajanimi ClinicalDocument.componentOf.encompassingEncounter.responsibl eparty.assignedentity.representedorganization.name Ammattihenkilön etunimi etunimetnimi ClinicalDocument.author.assignedAuthor.assignedPerson.name.give n sukunimi Ammattihenkilön sukunimi ClinicalDocument.author.assignedAuthor.assignedPerson.name.fami ly Ammattihenkilön rooli roolikoodi ClinicalDocument.author.functionCode Ammattihenkilön tunniste varmennetunnus ClinicalDocument.author.assignedAuthor.id Virka- / tehtävänimike virkanimiketeksti ClinicalDocument.author.assignedAuthor.assignedPerson.name.suffi x Ammattihenkilön palveluyksikön nimi palveluyksikkotunnus palveluyksikkonimi Ammattihenkilön palveluyksikkö ClinicalDocument.author.assignedAuthor.representedOrganization.i d ClinicalDocument.author.assignedAuthor.representedOrganization.n ame Asiakkaan henkilötunnus henkilotunnus ClinicalDocument.recordTarget.patientRole.id Etunimet etunimetnimi ClinicalDocument.recordTarget.patientRole.patient.name.given Sukunimi sukunimi ClinicalDocument.recordTarget.patientRole.patient.name.family Sukupuoli sukupuolikoodi ClinicalDocument.recordTarget.patientRole.patient.administrativeGe ndercode Syntymäaika syntymaaikapvm ClinicalDocument.recordTarget.patientRole.patient.birthTime Prosessin (Asian) tunnus palveluprosessitunnus ClinicalDocument.componentOf.encompassingEncounter.id Asiakirjan nimi asiakirjanimikoodi ClinicalDocument.title Palvelutehtävä palvelutehtavakoodi ClinicalDocument.documentationOf.serviceEvent.code lut: Allekirjoituspalvelu. Vaatimukset, toiminnallinen ja tekninen määrittely. Sosiaalialan tietoteknologiahanke, W3C. XML Signature Syntax and Processing (Second Edition). W3C Recommendation 10 June