Open CDA Opas HL7 CDA R2 -lomakerakenteiden tuottamisesta koodistopalvelun latausmuotoon. Versio URN:OID:X

Transkriptio

1 Open CDA 2008 Opas HL7 -lomakerakenteiden tuottamisesta koodistopalvelun latausmuotoon Versio URN:OID:X

2 Versio (33) Versiohistoria Versio: Pvm: Laatijat: Muutokset: X TK,TS Luonnoksia & työversioita Käsittely projektiryhmässä ja HL7 teknisessä komiteassa TK,TS Luonnoksia & työversioita TK Käsittely projektiryhmässä ja versio lähetettäväksi HL7 TC:lle TK, TS Luonnoksia & työversioita TK,TS Versio projektiryhmälle kommentoitavaksi TK,TS Jari Lehtosen kommenttien perusteella täydennetty lukuja lomakerakenteen tietojen välttämättömyyksistä. Kirjoitettu luvut 3.5 ja 3.6. Versio koodistopalvelun johtoryhmälle lähetettäväksi TK Kimmo Rissanen / Mediconsult kommenttien pohjalta korjattu ja täydennetty lähes kaikkia lukuja TK Lausuntokierroksen kommenttien ja OpenCDAtyöryhmän käsittelyn pohjalta päivitetty TK HL7 työkokouksessa sovitut tarkennukset lomakerakenteen versionnissa Koodistopalvelun johtoryhmän käsittely ja hyväksyntä TK,TS TH Koodistopalvelutiimin kanssa läpikäynnin pohjalta viimeistely Tekstin korjaaminen, kirjoitusvirheet, yhdysmerkit, STAKES THL:ksi HL Oikoluenta TK = Timo Kaskinen, Salivirta Oy TS = Timo Siira, Salivirta Oy TH = Timo Hakala, THL HL = Hanna Lehto, THL

3 Versio (33) SISÄLLYSLUETTELO 1. JOHDANTO TYÖN TAUSTA MÄÄRITTELYN TAVOITE SUHDE MUUHUN HL7-DOKUMENTAATIOON JA -OHJEISTUKSEEN RAJAUKSET KOODISTOPALVELUN YLEISKUVAUS VIITATUT MÄÄRITTELYT YLEISOHJE LOMAKERAKENTEEN TUOTTAMISESTA LOMAKKEIDEN RAKENNEMÄÄRITTELYJEN ESITIETOVAATIMUKSET LOMAKKEIDEN RAKENNEMÄÄRITTELYT YLEISPERIAATTEET JA TAUSTA KOODISTOPALVELUN LATAUSFORMAATTI YLEISPERIAATTEET ja koodistopalvelun lomakemäärittelyjen tietokenttien yhteneväisyydet Koodistopalvelumuodon tietokenttien tarkemmat kuvaukset Hierarkian hyödyntäminen LOMAKKEEN RAKENNEMÄÄRITTELYN TUOTTAMINEN KOODISTOPALVELUMUOTOON Lomake, josta ei ole olemassa -rakennemäärittelyä Lomake, josta on olemassa -rakennemäärittely Lomakkeen XML -muodostusohjeistus ja näytettävät kenttänimet LOMAKKEEN ESITYSMUODON OHJEISTUS KOODISTOPALVELUMUODON TEKNISET RAJOITTEET RAKENNEKOHTAISET OHJEET YDINTIEDOT -LOMAKKEISSA LOMAKKEIDEN TÄYTTÖOHJEET LINJAUKSET LOMAKKEIDEN YLEISTEN TIETOKENTTIEN OSALTA HENKILÖTIEDOT PÄÄTTELYKETJUT LISTAT JA LUETTELOT LÄÄKÄRINLAUSUNTO C (KELA) ESIMERKKI HYVÄKSYMIS- JA YLLÄPITOPROSESSI HYVÄKSYMISPROSESSI MUUTOKSISTA TIEDOTTAMINEN PÄIVITTYNEIDEN RAKENTEIDEN HAKEMINEN KOODISTOPALVELUSTA JA LOMAKERAKENTEIDEN VERSIOINTI LIITTEET:... VIRHE. KIRJANMERKKIÄ EI OLE MÄÄRITETTY. LIITE: TOTEUTETUT LOMAKKEET

4 Versio (33) 1. JOHDANTO 1.1 Työn tausta Laki sosiaali- ja terveydenhuollon sähköisten asiakastietojen käsittelystä ( /159) ja siihen liittyvä asetus määräävät kansallisen sosiaali- ja terveydenhuollon tietoteknologia-arkkitehtuurin perusrakenteet. Eri organisaatioiden asiakirjoilla on oltava yhdenmukaiset sähköiset rakenteet, jotta eri organisaatioissa olevat potilaan hoidosta vastaavat voivat, potilaan suostumuksella, hakea toisen organisaation tietoja arkistosta. Terveyden ja hyvinvoinnin laitoksen, THL:n, ylläpitämän kansallisen koodistopalvelun ensisijaisena tehtävänä on jaella kansallisesti yhtenäiset sosiaali- ja terveydenhuollon sähköisten potilas- ja asiakasasiakirjajärjestelmien tarvitsemat koodistot, luokitukset, sanastot, rekisteritiedot ja muut koodirakenteet sosiaali- ja terveydenhuollon tietojärjestelmien edellyttämässä muodossa. Näistä tietorakenteista käytetään jatkossa yleisnimitystä koodisto. Koodistopalvelutoiminta tukee sosiaali- ja terveydenhuollon kirjaamisen rakenteistamista ja yhtenäistämistä, mikä on jo pitkään ollut keskeinen haaste. Yhtenäiset koodistot luovat lisäksi perustan tilastotoimelle ja toimivat hallinnon keskeisenä työkaluna. Luokitusten ja koodistojen kehittäminen ja käyttöönotton edistäminen sekä olemassa olevien luokitusten säännöllinen ylläpito ja tarvittaessa edelleen kehittäminen on koodistopalvelun perustehtävä, jota hoidetaan yhteistyössä eri luokitusten ylläpitäjien, terveydenhuollon ammattilaisten ja muiden toimijoiden kanssa. Edellä kuvattua koodistopalvelun perustoimintamallia laajennetaan koskemaan myös lomakerakenteiden jakelua. Koodistopalvelua tarvitaan asiakirjojen yhdenmukaisten rakenteiden jakamiseen terveydenhuollon toimijoiden tietojärjestelmille. Lomakerakenteiden sähköinen jakelu koodistopalvelimelta mahdollistaa osaltaan lomakelogistiikan sähköisen toiminnan, mikä tosin ei ratkaise kaikkia lomakkeiden käsittelyyn liittyviä haasteita. 1.2 Määrittelyn tavoite Kansallisen terveyshankkeen toimesta on vuodesta 2003 alkaen toteutettu lomakkeiden sähköisiä määrityksiä -muotoon. Projektin ensimmäisenä vuotena laadittiin yleiset periaatteet lomakkeiden saattamisesta sähköiseen muotoon sekä sovittiin lomakkeiden yhteiset tietosisällöt. Lomakkeiden tietosisällön tulee perustua kansallisiin ydintietoihin sekä kansallisiin koodistoihin. Mitä yhdenmukaisemmin lomakkeissa pystytään hyödyntämään terveydenhuollon ammattihenkilön potilaskertomukseen tekemien merkintöjen tietosisältöä, sitä varmemmin lomakkeiden virheetön täyttö onnistuu. Myös lomakkeita vastaanottavassa päässä täytyy olla valmiudet ottaa tiedot vastaan uusien rakenteiden mukaisesti. Lomakkeet voidaan jakaa esimerkiksi seuraaviin ryhmiin: [9] Potilaskertomuslomakkeet Potilaan lomakkeet Asiakirjahallinnon lomakkeet Todistukset ja lausunnot Erityislainsäädännön mukaiset todistukset Ilmoitukset terveydenhuollon valtakunnallisiin lakisääteisiin rekistereihin Kelan todistukset Muut lomakkeet

5 Versio (33) Tavoitteena tässä työssä on ohjeistaa kansalliseen arkistoon vietävien todistus- ja lausuntotyyppisten lomakkeiden -rakennemäärittelyt ja niiden hyväksymis- ja ylläpitoprosessi koodistopalvelusta jaeltavaksi tietojärjestelmille yhtenäisessä rakenteisessa muodossa. Potilaskertomuslomakkeita lukuunottamatta muidenkin lomakkeiden määrittelyissä on samaa problematiikka kuin todistuksissa ja lausunnoissa, joten oppaassa kuvattuja yleisiä periaatteita voi noudattaa mahdollisuuksien mukaan laajemminkin. Toisena tavoitteena on edistää rakennemäärittelyjen hyödynnettävyyttä ja ylläpidettävyyttä järjestelmätoimittajien näkökulmasta. Tässä ohjeessa on esimerkin luonteisesti käytetty Kelan hallinnoimaa lomaketta Lääkärinlausunto C. 1.3 Suhde muuhun HL7-dokumentaatioon ja -ohjeistukseen Määrittelyt perustuvat HL7 Finland ry:n aiempiin määrityksiin ja soveltamisoppaisiin ja täydentävät niitä. Kaikki tausta-aineistojen dokumentit ja niiden viimeisimmät versiot ovat saatavissa HL7- yhdistyksen dokumenttiarkistosta Dokumentti Sisältö ja suhde lomakeoppaaseen Open CDA Päädokumentti/johdanto v.3.0 Johdanto CDA:n käyttöön. Open CDA Header v.4.3 -Headerin tietojen käyttö Suomessa. Viralliset -skemat löytyvät header-määrityksen alta. Headerdokumentissa määritellään asiakirjojen kuvailutiedot ja niitä käytetään myös lomakkeiden yhteydessä. Open CDA Kertomus ja sähk. lomakkeet v.4.0 Sisältää kertomustietojen siirtoon ja Versio 4.1 on äänestysvaiheessa säilytykseen tarvittavan - muodon ja rakenteen sekä kertomuksen lomakkeet. Oppaassa on kuvattu lomakkeiden yleinen -rakenne, joka toimii pohjana tämän oppaan rakenteille. Open CDA 2008 Lomakkeiden jatkokehitys v.1.0 Sisältää laajemmin lomakkeisiin liittyviä jatkokehitystarpeita mm. lomakelogistiikkaan liittyen. Open CDA 2008 Tietotyypit v.1.2 Tietotyypit. Tietotyyppioppaassa on kuvattu tietotyyppien hyödyntämisen periaatteet sekä Suomessa käytössä olevat tietotyypit esimerkein. Lomakkeissa noudatetaan tietotyyppioppaan linjauksia, joihin tässä monin kohdin viitataan. Monissa kohdin CDA-rakennetta tukeudutaan ns. ydintietomäärittelyihin, joissa on määritelty esimerkiksi henkilötietojen rakenteinen esittämistapa. Ydintietomäärittelyt ovat osa kertomuksen ja sähköisten lomakkeiden -määrittelyjä, jotka ovat myös mukana tukidokumenteissa.

6 Versio (33) Olemassaolevat -lomakemäärittelyt löytyvät HL7:n dokumenttiarkistosta. Open CDA Kertomus ja sähk. lomakkeet -paketin sisällä on maaritystaulukot-hakemisto, johon tehdyt lomakemäärittelyt on kerätty Excel-taulukoina. Kertomus ja sähköiset lomakkeet - määrittelypaketissa ohjeistetaan kertomuksen lomakkeiden määrittelyt oppaan luvuissa Liitteenä olevassa taulukossa Toteutetut lomakemäärittelyt on lomakemäärittelyn tilanne kirjoitushetkellä. Taulukossa on kuvattu sarakkeissa HL7 -rakennemäärittelyjen tekoaika ja vastaava aika rakennemäärittelyjen tuottamiseksi koodistopalvelun latausmuotoon. Jatkossa tätä liitettä tullaan ylläpitämään sitä mukaa, kun lomakerakenteita viedään koodistopalveluun. 1.4 Rajaukset Opas HL7 lomakerakenteiden tuottamisesta koodistopalvelun latausmuotoon on ensisijaisesti tekninen opas. THL:lla on valmisteilla laajempi opas sähköisten lomakkeiden valmistamisesta ja käytöstä terveydenhuollossa, missä keskitytään sähköisten lomakkeiden suunnitellun ja käyttöönoton kokonaisprosessiin ja lomakelogistiikkaan. Tämän lauseen voisi ottaa pois tästä liitteenä olevasta versiosta?? Lomakeopas ohjeistaa kertomuksen peruslomakkeista todistus- ja lausuntotyyppisten lomakkeiden sekä itsenäisten lomakkeiden tuottamisen koodistopalvelumuotoon. Muita lomakerakenteita koskeva ohjeistus on kokonaisuudessaan Open CDA 2008 Kertomus ja sähk. lomakkeet - ohjeessa. Samoin kyseissä oppaassa on kuvattu CDA-teoria lomakkeisiin liittyen. Koodistopalvelun rakennemuotoon viedään ensisijaisesti lomakkeet, jotka on tarkoitettu organisaatioiden väliseen tiedonvaihtoon ja potilaan hoitoon. Nämä lomakkeet ovat tai tulevat jatkossa olemaan laajemmin eri organisaatioiden käytössä. Organisaatio voi tuottaa vain omassa käytössä olevien lomakkeiden määrittelyt koodistopalvelun rakennemuotoon mahdollista tulevaa laajempaa hyödynnettävyyttä ajatellen. Ensimmäisessä vaiheessa näitä ei kuitenkaan viedä koodistopalveluun, alussa kerätään kokemuksia muiden lomakkeiden osalta ja mahdollisesti laajennetaan näihin jatkossa. Lomakelogistiikan osalta virallinen versio lomakkeesta on monissa tapauksissa tulostettava paperinen versio lomakkeesta, mikä tuo omat rajoitteensa lomakerakenteisiin. Paperilomakkeiden kenttien tulee tietosisällön osalta olla yhtenevät sähköisen lomakkeen kenttien kanssa. Sähköisestä versiosta tulee olla mahdollista tulostaa samansisältöinen versio kun käytössä oleva paperilomake on. Muuten rakenteellisesti sähköinen ja paperinen versio voivat poiketa toisistaan, sillä paperilomakkeen ratkaisut eivät välttämättä ole hyviä sähköisessä versiossa ja sama toisinpäin. 1.5 Koodistopalvelun yleiskuvaus Koodistopalvelutehtävä perustuu voimaanastuneeseen lakiin /159, jossa koodistopalvelimella olevien koodistojen sisältövastuu on määritelty kuuluvaksi Terveyden ja hyvinvoinnin laitokselle. Koodistopalvelimen tekninen ylläpitotehtävä on puolestaan Kansaneläkelaitoksella. Koodistojen sisältövastuulla tarkoitetaan sitä, että THL vastaa tuotantokoodistopalvelimella olevien luokitusten ylläpidon ja päivittämisen koordinoinnista, ajantasaisten koodien saatavuudesta ja koodistojen teknisestä laadusta sekä eri koodistojen sisällöllisestä yhteensopivuudesta.

7 Versio (33) Koodistopalvelimen teknisellä ylläpitotehtävällä tarkoitetaan koodistojen teknisen sijoitusalustan ylläpitoa ja teknologia-alustan kehittämistä. Koodistopalvelimelta jaellaan yhtenäiset sosiaali- ja terveydenhuollon sähköisten asiakastietojärjestelmien tarvitsemat koodirakenteet. Koodistot ovat haettavissa kansallisiin ja paikallisiin sosiaali- ja terveydenhuollon sähköisiin asiakirjajärjestelmiin maksutta. Koodistopalvelun lakisääteisen tehtävän näkökulmasta tietorakenteiden yhdenmukaisuus on tärkeää, koska tiedot tallennetaan kansalliseen sähköiseen arkistoon ja niiden on oltava sieltä asiakkaan suostumuksella käytettävissä. Arkistokäsittelyn lisäksi rakenteisia potilastietoja voidaan hyödyntää potilaan hoidossa muullakin tavoin hoidon laadun ja potilasturvallisuuden varmistamiseen. Koodistopalvelu tarjoaa terveydenhuollon IT-järjestelmille HL7 Finland ry:n määrittelemän avoimen XML-sanomapohjaisen rajapinnan koodistojen kyselyyn ja päivittämiseen koodistopalvelimelta. Luokitusten muokkaus tehdään yhteen paikkaan, joka helpottaa kokonaisuuden ylläpitoa sekä parantaa tiedon laatua. Koodistopalvelimella olevia koodistopalvelumuotoja ovat luokituksen koodistopalvelumuoto, organisaatioluokituksen koodistopalvelumuoto ja viittauksen eli vastaavuuden koodistopalvelumuoto (=kahden luokituksen välinen koodien vastaavuustaulukko) sekä lomakkeen koodistopalvelumuoto. Koodistopalvelumuodolla tarkoitetaan käytännössä rakenne- ja kenttäkuvausta, mikä kuvaa koodistopalvelun tarjoamien rajapintojen kautta haettavissa olevien tietojen selitykset hyödyntämistä varten. Koodistopalveluun on tuotu sen rakentamisvaiheen, vuosien aikana, kansallisessa käytössä vakiintuneimmat sosiaali- ja terveydenhuollon luokitukset ja nimikkeistöt. Sähköisen potilasasiakirja-arkiston ja sähköisen reseptin määrittelyvaiheen tuotoksena sisältöä on vahvistettu näissä toiminnoissa tarvittavilla rakennekoodistoilla. Tarkempi kuvaus koodistopalvelun toiminnasta löytyy Terveyden ja hyvinvoinnin laitoksen ylläpitämästä koodistopalvelun käsikirjasta [3], sekä koodistopalvelun www-sivuilta [5]. 1.6 Viitatut määrittelyt [1] Open CDA Kertomus ja sähk. lomakkeet v.4.10 [2] Open CDA 2008 Tietotyypit v.1.2 [3] THL Koodistopalvelun käsikirja versio 0.2 [4] Laki sosiaali- ja terveydenhuollon asiakastietojen sähköisestä käsittelystä /159 [5] THL koodistopalvelun sivut: [6] Opas: Ydintietojen, otsikoiden ja näkymien toteuttaminen sähköisessä potilaskertomuksessa, Versio [7] THL. Koodistopalvelun tiedonsiirron tekninen ohje. Versio OID: [8] Kansaneläkelaitos, THL. Kansallisen koodistopalvelun (CodeServer) rajapinnat ja liittymisohje, , Versio 1.0 [9] Open CDA Lomakkeiden jatkokehitys v OID:

8 Versio (33) 2. YLEISOHJE LOMAKERAKENTEEN TUOTTAMISESTA 2.1 Lomakkeiden -rakennemäärittelyjen esitietovaatimukset Uusien lomakkeiden osalta prosessi etenee vaiheittain seuraavasti. Kokonaisprosessi on kuvattu laveammin auki prosessikuvineen Opas sähköisten lomakkeiden valmistamisesta ja käytöstä terveydenhuollossa -ohjeessa, 1. Tunnistetaan tarve uudelle lomakemäärittelylle. 2. Organisaation tai muun yhteenliittymän toimesta organisoidaan substanssiryhmä, joka tuottaa lomakkeen tietosisältövaatimukset ja suunnittelee toiminnallisesti ko. lomakkeeseen liittyvät prosessit. 3. Tietosisältöjen osalta ryhmän tulee ottaa kantaa myös tarvittaviin luokituksiin, tietojen pakollisuuksiin sekä raja-arvoihin. 4. Yhteydenotto Terveyden ja hyvinvoinnin laitoksen koodistopalveluun ja lomakemäärittelyn läpikäynti THL:n koodistopalvelutiimin asiantuntijan kanssa. 5. Käsittely koodistopalvelun johtoryhmässä. 6. Lomakkeissa käytettyjen ydintietojen ja luokitusten tunnistaminen, kiinnittäminen ja kooditukset. Tarpeen mukaan uusien luokitusten/koodistojen perustaminen. 7. Lomakerakenteen työstäminen koodistopalvelun latausmuotoon. Lomakerakenteen käsittely koodistopalvelun laaturyhmässä. 8. Tapauksen mukaan tehdään sovittavat jatkokäsittelyt. Käytännössä lähetetään lausuntokierros asianosaisille. 9. Yksi lausuntotahoista on aina HL7 Finland ry. Komitean tai sen vastuuttaman tahon teknisessä lausunnossa tarkistetaan sovittujen lomakerakenteiden periaatteiden ja tietotyyppiohjeistuksen käytön noudattaminen. 10. Lausuntojen käsittely. 11. Hyväksyminen koodistopalvelun johtoryhmässä. 12. Lomakemäärittely koodistopalvelun tuotantopuolelle. 13. Suositellaan, että viimeisenä vaiheena lomakkeen omistajataho tekee tai teetättää esimerkkilomakkeen CDA-muodon testaamisen ja toteutuksien tueksi. Esimerkissä tulee käsitellä kaikki kentät toistoineen riippumatta siitä, käytetäänkö niitä tavallisesti samanaikaisesti. Esimerkkilomakkeesta suositellaan myös tuotettavan vastaava näyttömuoto joko määriteltyä tyylitiedostoa tai PDF-mallia käyttäen tai molemmilla tavoilla. Tämä opas kuvaa edellisistä vaiheen 7 toteutuksen. 2.2 Lomakkeiden -rakennemäärittelyt yleisperiaatteet ja tausta Kansallisen terveyshankkeen toimesta on vuodesta 2003 alkaen toteutettu lomakkeiden sähköisiä määrityksiä -muotoon. Projektin ensimmäisenä vuotena laadittiin yleiset periaatteet lomakkeiden saattamisesta sähköiseen muotoon sekä sovittiin lomakkeiden yhteiset tietosisällöt. Lomakkeiden -määritys on perustunut tällä hetkellä käytössä olevaan paperiversioon. Nykyisin lomakkeet toimitetaan saajalle pääsäätöisesti paperilla, tarvittaessa ne siirretään sähköiseen muotoon joko katselua tai käsittelyä varten. Enenevässä määrin siirrytään kuitenkin sähköiseen tiedonsiirtoon, missä lomake siirretään rakenteisessa -muodossa sovellusten/palvelujen välillä.

9 Versio (33) Potilaskertomusohjelmistoihin on toteutettu useiden lomakkeiden osalta lomakkeiden syöttäminen ja tulostaminen paperille. Osalla toimittajista on myös saatavissa osa lomakkeista - muodossa ja valmiudet niiden sähköiseen siirtämiseen. Potilastietojärjestelmän tarkoituksena on tuottaa koko kertomuksen sisältö aina - näyttömuodossa. Näyttömuotoiset tiedot ovat kaikissa toteutuksissa yhtäläiset ja noudattavat tekstirivejä. Potilastietojärjestelmät tuottavat vähintään pakollisten ydintietojen osalta sisällön myös rakenteisessa muodossa (XML). Lomakkeen määrittely ja toteutus XML-rakenteeseen on kolmivaiheinen prosessi. Ensin lomakkeen tietosisältö määritellään ja yksittäiset tietokentät ja niiden ryhmittely kirjataan Excel-taulukkoon. Jokaiselle tietokentälle määritellään myös tietotyyppi, pakollisuus, raja-arvot ja käytettävät koodistot. Tietotyyppeinä käytetään HL7-yhdistyksen ohjetta tietotyyppien määrittelyyn. Kun kaikki tietokentät on kirjattu ja tyypitetty, määritellään rivinumerot ja yksilöidään kentät OIDkoodein. 2.3 Koodistopalvelun latausformaatti -yleisperiaatteet Koodistopalvelussa ei oteta suoraan kantaa lomakkeiden ulkoasuun, vaan määritellään lomakkeiden rakenteinen muoto, jossa tieto tallennetaan kansalliseen arkistoon. Käytännössä koodistopalvelumuoto tarkoittaa lomakerakenteen viemistä sellaiseen Exceltaulukkoon, jossa koodistopalvelimella tarvittavat tiedot on laitettu oikeisiin tietokenttiinsä. Esimerkiksi luokituksen hierarkia rakennetaan taulukkoon siten, että hierarkiatasot ilmaistaan tasoa ilmaisevassa tietokentässä. Lomakkeen tarkoitus -kohdassa koodistopalvelussa lomakkeen kuvailutiedoissa kuvataan, mihin kyseistä lomaketta käytetään ja koodistopalvelun lomakemäärittelyjen tietokenttien yhteneväisyydet Koodistopalvelussa lomakkeiden rakenteinen muoto on laajempi kuin -määrittelyssä, ja se sisältää seuraavassa luvussa hyödyntämistä helpottamaan kuvatut uudet tietokentät. Varsinaisessa CDA-siirtomuodossa lomakkeen tietosisältö on samantasoinen kuin aikaisemminkin. Jos lomake on jo määriteltynä -muotoon, on tätä määrittelyä täydennettävä lisäämällä koodistopalvelussa tarvittavat tietokentät. Mikäli lomakkeesta ei ole aikaisemmin tuotettu rakennemäärittelyä, se tehdään jatkossa suoraan koodistopalvelumuotoon. Taulukko 1. -lomakemäärittelyn tietokentät Taulukko 1 kuvaa tietokentät siinä järjestyksessä, jossa ne ovat -määrittelyssä. Taulukko 1. -lomakemäärittelyn tietokentät -lomakemäärittelyn tietokenttä rivi tietokenttätunnus oid Selitys Järjestys, jossa tiedot siirretään tai näytetään lomakkeella. Lomakkeen juuri OID, mikä on sama kuin lomakkeen yksilöintunnus näkymäkoodistossa tunnus Kentän tunnus (annetaan juoksevasti 1, 2, 3,...). Uudet tietokentät saavat seuraavan vapaan

10 Versio (33) numeron. tietotyyppi Tietotyypin pitkä nimi tietotyyppi Tietotyyppi lyhenne kentän pituus kentän pituus (merkkien lkm) min kentän minimiarvo max kentän maksimiarvo pakollisuus pakollisuus (mikäli kenttä on pakollinen, niin se on täytettävä). toistuma toistuma (käytössä, jos tietoryhmä tai kenttä on toistuva) koodistopalvelun koodisto koodiston nimi koodistopalvelun koodiston OID-tunnus koodiston OID huom. huomautukset kentän nimi kentän nimi täyttöohje täyttöohje Taulukko 2. Koodistopalvelun ja -tietokenttien yhteneväisyydet Taulukko 2 kuvaa koodistopalvelun lomakemäärittelyn tietokentät. Oikeaan sarakkeeseen on laitettu vastaavuudet, jotka löytyvät -lomakemäärittelystä.

11 Versio (33) Taulukko 2. Koodistopalvelun ja -tietokenttien yhteneväisyydet Koodistopalvelun lomakemäärittelyn tietokenttä Välttämätön * CodeId X tunnus LongName X kenttänimi ParentId X HierarchyLevel X Abbreviation ShortName Description BeginningDate X Vastaava -lomakemäärittelyn tietokenttä ExpiringDate A:Järjestys X rivi A:Tietokentän oid tunniste X tietokenttätunnus OID A:Tietotyyppi X tietotyyppi A:Tietotyypin tunniste X tietotyyppi A:Kentän pituus kentän pituus A:Kentän minimi arvo min A:Kentän Maksimi arvo max A:Kentän pakollisuus X pakollisuus A:Kentän toistuma X toistuma Along: Koodilista A:Koodistoviittaus koodistopalvelun koodisto A:Koodiston oid koodistopalvelun koodiston OID-tunnus A:Täytettävä kenttä huom. A:Kentän lisätieto Along:Kentän täyttöohje täyttöohje A:Ydintieto tunniste A:Henkilötieto tunniste *) luettelo välttämättömistä tiedoista, jotka tarvitaan minimissään lomakerakenteen versioon, joka lähetetään koodistopalvelun käsittelyyn. Loput tiedoista ovat kuvailevia, koskevat vain tiettyjä tietotyyppejä tai tieto johdetaan muista kentistä, joten lomakerakkennemäärittelijän ei niitä tarvitse välttämättä tuottaa.

12 Versio (33) Kuva 1. -Excel-lomakkeen vastaavuuksia koodistopalvelimen Excel-lomakkeeseen nähden on esimerkkinä kuvakaappaus Lääkärinlausunto C:n -Excel-taulukosta (ylempi taulukko) ja koodistopalvelun Excel-taulukosta (alempi taulukko). Nuolilla on osoitettu kaksi sarakkeiden vastaavuutta (vertaa yllä Taulukko 2. Koodistopalvelun ja -tietokenttien yhteneväisyydet ).

13 Versio (33)

14 Versio (33) Kuva 1. -Excel-lomakkeen vastaavuuksia koodistopalvelimen Excel-lomakkeeseen nähden Lomakkeet kuvataan koodistopalvelumuotoon Excel- tai CSV-taulukoissa, ne toimitetaan Terveyden ja hyvinvoinnin laitokselle, josta ne jaellaan valtakunnallisen koodistopalvelimen kautta Koodistopalvelumuodon tietokenttien tarkemmat kuvaukset CodeId (kentän tunnus), annetaan juoksevasti 1, 2, 3, jne. Uudet tietokentät saavat seuraavan vapaan numeron. Lomakerakenteen päivitysten yhteydessä kentälle annettu CodeId ei ikinä muutu. CodeID 0 on varattu lomakkeen nimelle ja lomakkeen koodistolle. Välttämätön LongName (kentän pitkä nimi), esim. Lääkärinlausunto C Vammais- ja hoitotukea varten. Välttämätön ParentId (ylempi koodi), jos HierarchyLevel on 0, niin tämä jää tyhjäksi. Jos HierarchyLevel ei ole 0, niin arvoksi annetaan ylemmän tason CodeId (esim. henkilötunnus saa arvon 3, joka on henkilötietokentän CodeId). Välttämätön HierarchyLevel (hierarkiataso), kuvaa tietokentän sijaintia lomakkeen hierarkiarakenteessa. Hierarkiatasot lasketaan ylhäältä alkaen eli lomakkeen arvo on 0 ja oletuksena päätaso arvo on 1, ensimmäinen alataso arvo 2 jne. Hierarkiatieto kuvaa samaa asiaa, kuin PartentID perusteella voi päätellä, joten käyttäminen on hyödyntäjän päätettävissä. Hierarkiatieto on koodistopalvelussa myös teknisistä syistä vaadittava pakollinen tieto. Välttämätön Abbreviation (lyhenne), käytetään kentän lyhennettä, jos sellainen on yleisesti käytössä. Kyseessä on koodistopalvelun latausmuodossa kentän kuvaava lyhennenimi, jonka lomakemäärittelijä voi antaa kentälle. Kuvailutiedot on tarkoitettu ensisijaisesti rakennemäärittelyjen hyödyntäjälle (sovelluksen toteuttajalle) lisätiedoksi ja niiden hyödynnettävyys suoraan ohjelmallisesti on tapauskohtaista. Abbreviation voidaan myös muodostaa teknisesti katkaisemalla LongName-kentästä 50 ensimmäistä merkkiä. ShortName (kentän lyhyt nimi), käytetään kentän lyhyttä nimeä varten. Se voidaan muodostaa katkaisemalla LongName-kentästä 50 ensimmäistä merkkiä. Description (Määritelmä/kuvaus), kentän tarkempi kuvaus. Tässä voidaan ohjeistaa esimerkiksi toistuvien elementtien lukumäärästä ja yleisesti teknisen rakenteen tuottamisessa huomioitavista

15 Versio (33) asioista. Kuvauksessa on hyvä antaa toteuttajalle tulkintaohjeita tarvittavin osin, jotta ohjelmistotoimittajat osaavat tehdä kyseisen lomakkeen täytön käyttäjille mahdollisimman helpoksi. Mikäli kentän nimi on yli 255 merkkiä pitkä (jolloin nimi ei mahdu LongName-kenttään) niin teksti lyhennetään ja laitetaan kokonaisuudessaan näytettävä nimi tähän Description-kenttään (katso luku tarkempi ohje). BeginningDate (voimassaolon alkupäivä), ilmaisee päivämääränä (VVVVKKPP), mistä alkaen kenttä on voimassa. Se voi olla myös takautuva päivämäärä, jolloin lomake on otettu käyttöön. Generoidaan CDA-lomakkeen versionumerosta (joka on päivämäärä), jos muunnosta tehtäessä kentälle ei ole muuta arvoa annettu - katso myös luku 5.3 versioinnin osalta. Välttämätön ExpiringDate (voimassaolon loppupäivä), ilmaisee päivämääränä (VVVVKKPP) kentän viimeisen voimassaolopäivän. Käytännössä järjestelmät suositellaan toteutettavan siten, että ne pystyvät tulkitsemaan vanhempienkin lomakeversioiden tietosisältöä. Kenttien voimassaololla on tällöin ensijaisesti vaikutusta käyttöliittymään, jossa lomaketta täytetään. A:Järjestys, kentän järjestysnumero lomakkeella luettaessa rivi kerrallaan vasemmalta oikealle ja ylhaaltä alas. Järjestys siis kuvaa tietokenttien tulostusjärjestestystä lomakkeella. Voidaan tarvittaessa tehdä Terveyden ja hyvinvoinnin laitoksessa ennen koodistopalveluun latausta, mutta lomakkeen suunnittelijan on hyvä ottaa tähän kantaa. Tiedolla lomakemäärittelijä voi myös suositella hyppimisjärjestystä käyttöliittymässä. Järjestys on päivitettävä aina, kun lomakerakenteeseen tehdään muutoksia eli eri versioilla kenttien järjestysnumerot eivät välttämättä säily samoina. Järjestys ottaa myös kantaa kenttien järjestykseen CDA-rakenteessa. Välttämätön A:Tietokentän oid tunniste, kentän OID-koodi muodostuu lomakkeen OID-koodista, jonka perään liitetään kentän CodeId. (Esim. Lomakkeen Lääkärinlausunto C Vammais- ja hoitotukea varten OID-koodi on ja henkilötunnus-kentän CodeId on 5, jolloin henkilötunnus-kentän OID-koodi on ). Välttämätön A:Tietotyyppi, ilmaistaan tietotyyppi, jota kentässä käytetään. (esim. henkilötunnus on tyyppiä Instance Identifer) Välttämätön A:Tietotyypin tunniste, ilmaistaan tietotyypin lyhenne, jota kentässä käytetään. (esim. henkilötunnuksessa käytetyn tietotyypin lyhenne on II) Välttämätön A:Kentän pituus, määritetään kentän pituus merkkeinä, mihin järjestelmien tulee varautua. Kentän pituutta on tarve lähinnä määritellä string tyypisten kenttien osalta, missä merkkijonon pituutta voi olla tarve rajoittaa. A:Kentän minimiarvo, määritetään kentässä käytettävän tiedon minimiarvo. A:Kentän maksimiarvo, määritetään kentässä käytettävän tiedon maksimiarvo. A:Kentän pakollisuus, onko kentän täyttö pakollista? Kenttäkohtaisesti kohtaan täyttöohje tai kentän lisätiedot suositellaan antamaan lisäohjetta/-tulkintaa, mitä pakollisuus tässä tapauksessa tarkoittaa. Lomakerakennemäärittely ottaa kantaa tietojen pakollisuudesta cda-rakenteessa siirrettäessä tietoa eri organisaatioiden tai järjestelmien välillä. Pakollisuuden osalta tarpeen on toteuttajan näkökulmasta tällöin tietää, mitä pakollisuuden tyydyttämiseksi on tehtävä. Onko

16 Versio (33) NullFlavor-rakenne (esimerkiksi kirjaus ei ole tiedossa) sallittu vai onko tieto absoluuttisesti oltava olemassa tiedonsiirron mahdollistamiseksi. Välttämätön A:Kentän toistuma, toistuuko kenttä? Tässä ilmaistaan kyseisen kentän toistuvuus saman hierarkiatason ja tietoryhmän sisällä. Kenttä ei ole tässä kohtaa välttämättä toistuva vaikka sitä ylempi taso kokonaisuudessaan olisi toistuva. Välttämätön ALONG:Koodilista, koodilistassa kerrotaan lomakkeen sisäisten koodistojen mahdolliset koodiarvot. Lomakkeen sisäinen koodisto perustetaan tiedolle, jolla ei ole käytössä ja ei ole tarkoituksenmukaiseta perustaa yleisemmin hyödynnettävää koodistoa. Vastausvaihtoehdot ovat sidoksissa silloin vain kyseisen lomakkeen kyseisen kentän täyttämiseen. Esimerkiksi vastaus kysymykseen kestosta ilmaistaisiin sisäisenä koodistona CS-tietotyypillä (koodiarvo kiinnitetyllä koodistolla, coded simple value), jonka koodiarvot ovat 1=määräaikaisesti, 2=toistaiseksi. Koodilistan erotinmerkki on pilkku. A:Koodistoviittaus, jos kenttä viittaa johonkin koodistopalvelun koodistoon, tässä kentässä ilmaistaan sen nimi (esim. THL - Tautiluokitus ICD-10). Hyödynnetään lomakkeen ulkoisissa koodistoviittauksissa. Sanallisesti tässä kerrotaan esimerkiksi koodiston A:Koodiston oid, jos kenttä viittaa johonkin koodistopalvelun koodistoon, tässä kentässä ilmaistaan sen OID-tunnus (esim. THL - Tautiluokitus ICD-10:n kohdalla sen on ) A:Täytettävä kenttä, sisältääkö kyseinen lomakekenttä syötettävää tai annettavaa muuttuvaa tietoa (True / False). True: on täytettävä kenttä. False: ei ole täytettävä kenttä. Ei täytettävästä kentästä esimerkkinä ovat otsikkokentät ja lomakkeelle tulostettavat kiinteät kenttäohjeet (String). A:Kentän lisätieto, kenttään liittyvät lisätiedot. Esimerkiksi henkilötunnus-kentästä voidaan ilmaista, että se kuuluu Henkilötiedot-kentän alle. Kyseessä on semanttinen lisätieto/polku, miten kyseiseen tietoon on päädytty. Along:Kentän täyttöohje, tila kenttään liittyvälle täyttöohjeelle. Sähköiseen lomakkeeseen voidaan tätä kautta liittää lomakkeen omistajan haluamat tietokenttäkohtaiset täyttöohjeet. Täyttöohje on hyvin merkityksellinen myös lomaketoteutuksen toimivuuden ja tallennetun tiedon laadun kannalta. Ohjelman kehittäjä ei muuten välttämättä ymmärrä, mihin kentällä pyritään, eikä tällöin osaa mitenkään helpottaa käyttäjän toimia. A:Ydintieto tunniste, jos kenttä on ydintietoa, niin tässä viitataan jatkossa ydintietojen yksilöintitunnuksiin. Luvussa 3.1. on tarkempi ohjeistus. A:Henkilötieto tunniste, jos kenttä on henkilötietoa, niin tässä viitataan jatkossa henkilötietolomakkeen kenttätunnuksiin THL:n koodistopalvelimella. Luvussa 3.4. on tarkempi ohjeistus. Edellä käytettyjen kuvausten selitykset: A: lyhyt tekstimuotoinen lisätieto, maksimipituus lisätiedolle on tässä 255 merkkiä. Lyhyt tekstimuotoinen lisätieto ilmaistaan etuliitteellä "A:". Sen jälkeen tulee lisätiedon

17 Versio (33) ALONG: pitkä tekstimuotoinen lisätieto, maksimipituus lisätiedolle on tässä 4000 merkkiä. Pitkä tekstimuotoinen lisätieto ilmaistaan etuliitteellä "ALONG:". Sen jälkeen tulee lisätiedon Kappaleessa 4 on esimerkki lomakkeen: Lääkärinlausunto C Vammais- ja hoitotukea varten ensimmäisten kenttien viemisestä koodistopalvelumuotoon. Määrittelyt ja muutokset lomakkeen rakenteeseen voi toimittaa joko Excel- tai CSV -muodossa. Terveyden ja hyvinvoinnin laitoksen toimesta määrittelylle suoritetaan vielä tekninen tarkistus, jonka jälkeen se ladataan koodistopalvelimelle Hierarkian hyödyntäminen Edellä kuvattuja kenttiä Parentid, HierarchyLevel ja A:Kentän lisätieto voi hyödyntää näyttömuotoilua toteutettaessa. XML -muodostussäännöt on kuvattu Kertomus- ja sähköiset lomakkeet oppaassa [1] ja siinä hierarkian pystyy ilmaisemaan sisäkkäisinä componentsection rakenteina. Lähtökohtaisesti vain label-kenttien alla voi olla CDA-rakennetta, kun rakenne tarkoittaa ryhmää, jolle halutaan otsikko. Kenttä on siis lähtökohtaisesti lehtisolmu, jos se on jotain muuta tyyppiä kuin label. Vain erikoistapauksissa myös label voi olla lehtisolmu. Edellisestä perussäännöstä poiketen koodistopalvelun latausformaatissa hierarkiassa on mahdollista laittaa hierarkiatasoja muidenkin kuin label-kenttien alle. Esimerkkinä ylemmällä hierarkiatasolla kysytään (Boolean) tarvitseeko apua ja tarkentavana tietona seuraavalla tasolla missä asioissa (String). CDA-rakenteessa tätä alemman tason hierarkiasuhdetta ei kuvata vaan tietokentät kuvataan peräkkäisinä kenttinä [1]. Koodistopalvelun latausmuodossa hierarkiat ovat tällaisessakin tapauksessa mukana helpottamassa lomakkeen hyödyntäjän tiedon syöttökäyttöliittymän suunnittelua tai toteutettaessa tyylitiedostoa lomakkeen tietosisältöjen näyttämiseksi. Natiivi-CDA:ta tuottavissa järjestelmissä lomakerakenteiden tuottamisen logiikkaa on haastavaa automatisoida ja tehdä älykkäiksi. Useimmiten CDA jääneekin pääsääntöisesti siirtomuodoksi eikä HL7-tyylitiedostoilla sisällön näyttämisessä ole paljoa merkitystä. Enemmän näyttölogiikka on kiinni järjestelmän sisäisessä rakenteessa tuottaa haluttua tietoa. Koodistopalvelussa lomakerakenteiden kuvauksissa on kuitenkin tuotettu edellä kuvatun hierarkiatiedon tapaista määrämuotoista lisätietoa rakenteen tuottamiseksi, mikä toivottavasti edesauttaa hyödyntäjän työtä. 2.4 Lomakkeen rakennemäärittelyn tuottaminen koodistopalvelumuotoon Lomakkeen rakennemäärittelyn tuottamiseen koodistopalvelumuotoon vaikuttaa se, onko siitä jo olemassa -rakennemäärittely. Jos rakennemäärittelyä ei ole olemassa, se tuotetaan suoraan koodistopalvelun edellyttämässä muodossa. Jos rakennemäärittely on olemassa, siihen lisätään koodistopalvelumuodon edellyttämät lisäkentät ja samalla tarkistetaan olemassa oleva rakennemäärittely tietosisältöjen, koodistojen ja tietotyyppien osalta Lomake, josta ei ole olemassa -rakennemäärittelyä Lomakemäärittelyjen yleisprosessi on kuvattu luvussa 2.1. Mikäli rakennemäärittelyä ei ole entuudestaan tunnistetulle tarpeelle olemassa, lähdetään liikkeelle prosessin alkupäästä esitietojen kasaamiseksi. Varsinainen lomakkeen määrittely ja toteutus XML-muotoon on kolmivaiheinen prosessi. Ensin lomakkeen tietosisältö määritellään ja yksittäiset tietokentät ja niiden ryhmittely kirjataan Excel-

18 Versio (33) taulukkoon. Jokaiselle tietokentälle määritellään myös tietotyyppi, pakollisuus, raja-arvot ja käytettävät koodistot. Kun kaikki tietokentät on kirjattu ja tyypitetty, määritellään rivien järjestysnumerot, kentät yksilöidään CodeID:llä ja määritellään kenttien tietosisällön esittämiseen tarvittavat luokitukset ja kooditukset. Excel-pohjaan täytetään tiedot luvussa kuvattujen kenttäkuvausten mukaisesti Lomake, josta on olemassa -rakennemäärittely Koodistopalvelumuodon pohjana voidaan käyttää -rakennemäärittelystä luotua Exceltaulukkoa. Samalla tulee tarkistaa olemassa olevan -rakennemäärittelyn ajantasaisuus ja oikeellisuus. 1. Kopioidaan olemassa oleva -rakenne koodistopalvelumuodon Excel-pohjalle 2. Käydään läpi ja tarkistetaan tietotyypit ja päivitetyt linjaukset (luku 3.3) 3. Käydään läpi ja tarkistetaan ydintiedot 4. Täydennetään koodistopalvelumuodon vaatimat tietokentät (kuvaukset, hierarkiat jne.) Lomakkeen XML -muodostusohjeistus ja näytettävät kenttänimet Lomake kuvataan -muotoon (lomakkeen yksilöinti, lomakkeen objektien järjestys, yksilöinti ja ryhmittely) oppaassa Kertomus ja sähk. lomakkeet kuvatulla tavalla [1]. Muodostunut Excel-taulukko määrittelee XML -muodon yksikäsitteisesti. Muunnos perustuu ajatukseen, että jokaisesta tietokentästä muodostuu component.section rakenne siten, että kentän sisältämä arvo on sekä näyttömuodossa että rakenteisessa muodossa. Section:in alussa on code-elementti, joka kertoo mistä kentästä on kyse. Code-attribuutissa on lomakkeen kentän tunnus Excel-taulukon sarakkeesta CodeID/Tunnus, codesystem on lomakkeen OID-tunnus eli näkymätunnus Excel-taulukon sarakkeesta A:Tietokentän oid tunnus. Rakenteinen muoto sijoitetaan aina omaan entry.observation-elementtiinsä. Näyttömuodon esitysmuoto riippuu kentän tietotyypistä. Samoin rakenteisen muodon value-elementin muoto ja sisältö määräytyvät kentän tietotyypin mukaan. Seuraavat vastaavuudet on sovittu koodistopalvelumuodon kenttien ja CDA-muodon välillä KP-muodon LongName sisältö sijoitetaan CDA:ssa kentän Title:n Mikäli kentän nimi on yli 255 merkkiä pitkä (jolloin ei mahdu LongName-kenttää) niin teksti lyhennetään ja laitetaan kokonaisuudessaan näytettävä nimi Description-kenttään. Täten CDA:ssa kentät Title:n pituudella ei ole rajoitusta. Käytännössä tämä tarve tulee esimerkiksi vastaan lomakkeilla, missä lomakkeelle tulostetaan pidempiä täyttöohjeita. Kenttäkoodin displayname:a ei hyödynnetä CDA:ssa lomakkeiden osalta, koska se ei ole pakollinen eikä tässä tapauksessa tuo lisäarvoa. 2.5 Lomakkeen esitysmuodon ohjeistus Lähtökohtaisesti tämä määrittely ei ota kantaa esitysmuodon ohjeistukseen muilta osin kuin luvussa Hierarkian hyödyntäminen on kuvattu. Lomakkeen omistajan on mahdollista tuottaa ohjeistuksena malli ulkoasusta esimerkiksi PDF-muodossa. Malli ulkoasusta liitetään koodistopalvelussa kyseisen lomakemäärittelyn kohtaan joko linkkinä kyseisiin tiedostoihin tai verkkosivuille. Samoin lomakkeen omistaja voi halutessaan tuottaa tyylitiedostot lomakkeen tietosisällön esittämiseksi. Koodistopalveluun voidaan liittää kyseisen lomakerakenteen kohtaan linkki kyseisiin

19 Versio (33) tiedostoihin tai jollekin verkkosivuille muidenkin hyödynnettäväksi. Tyylitiedostojen jakeluun ei ole kuitenkaan kansallisesti sovittua toimintamallia. Suosituksena lomakkeen omistaja voi tehdä tai teetättää esimerkkilomakkeen CDA-muodon testaamisen ja toteutuksien tueksi. Esimerkissä tulee käsitellä kaikki kentät toistoineen riippumatta siitä, käytetäänkö niitä tavallisesti samanaikaisesti. 2.6 Koodistopalvelumuodon tekniset rajoitteet Lomakerakenteessa (THL:lle toimitettava Excel- tai CVS-pohja lomakerakennemäärittelyssä) ei saa käyttää teksteissä puolipisteitä, koska sitä käytetään koodistopalvelimessa erotinmerkkinä ladattaessa lomakemäärittely koodistopalvelimelle. Escape-merkkien käyttö ei ole tässä yhteydessä mahdollista. Pilkkua suositellaan käytettävän puolipisteen sijaan.

20 Versio (33) 3. RAKENNEKOHTAISET OHJEET 3.1 Ydintiedot -lomakkeissa Kaikkia ydintietorakenteita ei kopioida varsinaiseen lomakkeiden CDA-siirtomäärittelyyn. Siirrettävä lomake koostuu pelkästään Observation-luokista. Jos esimerkiksi kyseessä on toimenpiteen koodi, se siirretään omassa observationissaan ja toimenpiteen muut attribuutit omissa observationeissaan. Jos siirrettävä informaatio on ydintieto, observationista voi olla viittaus ydintietoon. Viittausmekanismin yksityiskohdat suunnitellaan tarkemmin ydintietokoodiston päivityksen jälkeen, ohjeistus päivitetään oppaaseen valmistuttuaan. Viittausmekanismin rakenne on suunniteltu olevan observationin refeence -elementtin sijoitettava ydintiedon templateid. Varsinainen ydintieto on dokumentoitu muualle, mutta tällä järjestelyllä sisällöllisesti ydintieto pystytään tunnistamaan lomakkeista. 3.2 Lomakkeiden täyttöohjeet Lomakkeiden täyttöohjeet voidaan hyödyntää suoraan lomakkeelle tietosisältöä tuottavissa ohjelmissa käyttäjän ohjeistuksessa. Lisätään tähän esimerkkinä muutama täyttöohje lomakkeelle (Duodecim). Kuten edellä painotettiin, täyttöohje on merkityksellinen myös lomaketoteutuksen toimivuuden ja tallennetun tiedon laadun kannalta. Ohjelman kehittäjä ei muuten välttämättä ymmärrä, mihin kentällä pyritään, eikä tällöin osaa mitenkään helpottaa käyttäjän toimia. 3.3 Linjaukset lomakkeiden yleisten tietokenttien osalta Tietotyyppioppaassa [2] on kattava ohjeistus tietotyyppien hyödyntämisestä, tuottamisesta -rakenteisessa muodossa ja suositus esitettävästä näyttömuodosta. Paikallistettua ohjeistusta löytyy mm. seuraavien yleisesti lomakkeissa hyödynnettävien tietojen osalta. Nimi [2, luku 2.1] Organisaation nimi [2, luku 2.2] Henkilön nimi [2, luku 2.3] Osoite [2, luku 2.4] Telekommunikaatio-osoite [2, luku 2.5] Tunnisteet (kuten henkilötunnukset, lääkärin SV-numero, terveydenhuollon ammattihenkilön terhikki-tunnus) [2, luku 2.6] -Observationilla kuvattava pienin kokonaisuus on samalla tasolla kuin HL7-tietotyypit. Jos esimerkiksi näytettävällä lomakkeella on potilaan etunimi ja sukunimi omissa kentissään, siirtomäärittelyssä ne ovat samassa Observationissa, koska asia ilmaistaan HL7:n PN (person name) -tietotyypillä. Mikäli hyödyntäjille on tarpeen antaa tietotyyppiohjeistusta tarkempaa soveltamisohjetta esimerkiksi nimen esittämisen osalta, tähän käytetään lomakerakenteen Description-kenttää, missä kerrotaan sanallisesti ohje. Esimerkiksi yksinkertaistettu nimen esitystapa voidaan kieltää tässä kentässä. Seuraavassa on esimerkki edellä kuvatusta periaatteesta, ensin kuvana paperilomakkeelta, seuraavana rivi rakennemäärittelyssä ja lopussa sama CDA-rakenteena.

21 Versio (33) <name> </name> <given>erkki</given> <given>matti</given> <family>meikäläinen</family> Toinen esimerkki on osoitteen esittämisestä (AD-tietotyyppi). <addr use="h"> <streetaddressline>mökkipolku 1 A 2</streetAddressLine> <postalcode>12345</postalcode> <city>mökkilä</city> </addr> Edellisten kohtien lisäksi lomakkeissa esiintyvät yleiset rakenteet suositellaan ilmaistavan seuraavasti: Koodistot o Lomakkeen sisäiset koodistot: CS-tietotyyppi (coded simple value). Näitä käytetään tapauksissa, missä vaihtoehdot ovat esitettynä paperitulosteella ja koodistoa ei käytetä lomakkeen ulkopuolella. [2, luku 3.5] o Koodistot koodistopalvelimelta tai joku muu yleisesti käytetty koodisto: CVtietotyyppi (coded value) [2, luku 3.3] Rastitettavat tai ympyröitävät valinnat o Boolean-tietotyyppi (kyllä/ei) jokaisen vaihtoehdon osalta erikseen [2, luku 3.1] Fysikaaliset mittaukset o Esitetään käyttäen PQ-tietotyyppiä (Physical quantity, määrä ) ja UCUM-koodistoa yksikön esittämiseen. Täten ilmaistaan siis esimerkiksi paino ja pituus. [2, luku 3.12]. Jatkossa tavoitteena on täydentää määrittelyä, missä muodossa kyseisen tiedon on kaikissa lomakkeissa esiinnyttävä, eikä lomakemäärittelyn tekijälle saa asiassa jättää harkintavaltaa. Luetteloa olisi täydennettävä tarvittaessa. Tavoiteltavaa myös olisi, jos näistä voisi tehdä mallit ja varsinaisessa lomakemäärittelyssä viitata vain malliin.

22 Versio (33) 3.4 Henkilötiedot Koodistopalvelun latausmuodossa on viittaus henkilötietojen osalta koodistopalvelusta löytyvään henkilötietolomakkeen tietoihin (OID ). Ajatuksena on yksilöidä kyseisellä lomakkeella esitettävien henkilötietojen osalta vastaavuus henkilötietolomakkeelta. CDAsiirtomäärittelyssä varaudutaan myös siirtämään tämä viittaustieto ja viittausmekanismi tulee olemaan samanlainen kuin ydintietojen osalta. Viittausmekanismin yksityiskohdat suunnitellaan tarkemmin ydintietokoodiston päivityksen jälkeen, jolloin ohjeistus päivitetään myös tähän oppaaseen esimerkkien kera. 3.5 Päättelyketjut Hierarkiatiedot sitovat päättelyketjut lomakerakennemäärittelyissä yhteneviksi kokonaisuuksiksi. Alla on yksi esimerkki, mutta sitä ei pysty yleistämään. Lomakekohtaisesti kenttien täyttöohjeissa ja Description-kentän kuvauksessa on lomakkeen määrittelijän kuvattava suunniteltu päättely- /täyttölogiikka kenttien osalta. Teknisen CDA-siirtorakenteen osalta ei varsinaisesti pystytä estämään lomakkeen älytöntä täyttöä, tämä logiikka pitää toteuttaa ohjelmistoon missä lomake täytetään. Ensin vastataan kysyttyyn kysymykseen ei tai kyllä Tämä kysymys ilmaistaan Boolean-tietotyypillä true/false. Jos on valittu kyllä, pitää valita seuraavassa kysymyksessä lomakkeella määräaikaisesti tai toistaiseksi Tähän lomakkeen kenttään perustetaan normaalitapauksessa oma koodisto, jonka koodiarvot kerrotaan rakennemäärittelyn koodistolista-kentässä (esimerkiksi 1=määräaikaisesti, 2=toistaiseksi). HierarchyLevel- ja ParentId -tiedoilla kerrotaan, että kysymys liittyy edelliseen kysymykseen ja on hierarkiatasoltaan yhtä tasoa alempi. Kentän täyttöohjeissa tai kyseisen lomakkeen soveltamisohjeissa ohjeistetaan asianmukaista täyttöä, jonka mukaan toteuttaja voi estää käyttäjää vastaamasta ensimmäisen Ei -vastauksen jälkeen hierarkiassa sitä alempana oleviin kysymyksiin. Jos on valittu määräaikaisesti, pitää antaa aika-arvo Tämä kerrotaan aikamääreenä alkaen esimerkiksi tietystä päivästä (PointInTime). HierarchyLevel- ja ParentId -tiedoilla kerrotaan, että kysymys liittyy edelliseen kysymykseen ja on hierarkiatasoltaan yhtä tasoa alempi. 3.6 Listat ja luettelot Valintalistat ja luettelot on tyypillisesti esitetty lomakkeissa vaihtoehto kerrallaan kyllä/ei boolean arvolla luetteloituna. Tietotyyppioppaassa [2] on esitetty geneeriset tietotyypit LIST, SET ja BAG, joita voidaan tietyissä tilanteissa hyödyntää. Näitä geneerisiä tietotyyppejä kuvaa seuraavat luonnehdinnat: List: järjestys, duplikaatit ovat sallittuja Set: ei järjestystä, ei duplikaatteja Bag: ei järjestystä duplikaatit ovat sallittuja Näistä SET on lomakkeiden osalta käytännöllisin, koska duplikaatit ovat kiellettyjä. Tällöin lomakkeella oleva valintaluettelo hyödyntää jotain olemassa olevaa koodistoa ja täyttäjän valinnat voidaan ilmasta luettelemalla kyseisen koodiston koodiarvot.

23 Versio (33) 4. LÄÄKÄRINLAUSUNTO C (KELA) ESIMERKKI Kansallisessa terveysprojektissa HL7 -rajapinnat Kansaneläkelaitoksen Lääkärinlausunto C:lle on määritellyt alunperin Antero Ensio (liite 1). Ension määritys on tässä esimerkissä muunnettu koodistopalvelumuotoon ja samalla tehty lomakkeen muutoksia sekä uusia linjauksia (luvussa 3.3 kuvatut asiat) vastaavat korjaukset (liite 2). Alla olevissa kuvissa on esitettynä alkuosa Lääkärinlausunto C:stä: Kuva 2. Kuvakaappaus paperimuodossa olevasta lomakkeesta ja Kuva 3. -määrittelyn mallipohja sekä kuva 4. Koodistopalvelun Excel-pohja. Kuva 2. Kuvakaappaus paperimuodossa olevasta lomakkeesta

24 Versio (33) Kuva 3. -määrittelyn mallipohja