HL7 CDA FAQ. Aihealueet: päivitetty 28.2.2006

HL7 CDA FAQ päivitetty 28.2.2006 HL7 Help Desk on tarkoitettu HL7 yhdistyksen toteuttamien standardien ja rajapintojen käyttöönottoon liittyvään neuvontaan sekä toimittajille että asiakkaille. Toiminta rahoitetaan kansallisen terveysprojektin ja HL7 Finland ry:n toimesta. Tänä vuonna on neuvontapalvelua laajennettu kattamaan myös ydintietoihin, kertomuksen rakenteisiin ja koodistoihin liittyvät kysymykset. Niihin asiantuntemus saadaan Kuntaliiton ydintietotyöryhmältä. Kaikki kysymykset osoitetaan palvelusta vastaavalle: antero.ensio@ensitieto.fi, mistä kysymykset ohjautuvat oikeille osaajille ja tarvittaessa vastaukset muotoillaan yhdessä. Keskittämisen syynä on, ettei nyt kysymyksiä tarvitse enää erikseen pilkkoa teknisiin ja asiasisältöä koskeviksi, vaan vastauksen asiantuntemus kootaan laajan asiantuntijaryhmän yhteisenä näkemyksenä. Osa vastauksista on syytä käsitellä yleisemminkin ja tuoda ne ehkä osin uudelleenmuotoiltuna www.hl7.fi sivustolla olevalle FAQ-listalle, joka avautuu aihealueittain linkkien perusteella. Vuonna 2005 on ensisijaisesti varauduttu CDA R2 ja sanomaliikenteen tukemiseen, vaikka asiantuntemusta löytyy kaikille osa-alueille. Aihealueet: 1 Standardointi 2 HL7 CDA R1 määritykset 3 HL7 CDA R2 määritykset 4 HL7 CDA sanomat (SOAP) 5 HL7 V2 sanomat 6 HL7 V3 sanomat 7 Oid-tunnus 8 Sovellutusrajapinnat API 9 Dokumenttiarkisto 10 Ydintiedot, kertomuksen rakenteet ja koodistot 11 Muut kysymykset Vuonna 2005 seuraavat asiantuntijat ovat käytettävissä: - Antero Ensio, Ensitieto Oy - Timo Itälä, Conceptia - Pasi Leino L-Force Oy - Jari Porrasmaa, Kuopion yliopisto - Timo Tarhonen, Tietotarha Oy - Aino Virtanen, Satakunnan sairaanhoitopiiri - Ari Vähä-Erkkilä, Prime Solutions Oy - Ydintietojen projektiryhmä Vuoden 2004 FAQ kysymyksiä ei käsitellä uudestaan ja ne löytyvät www.hl7.fi sivuilta kohasta:hl7-dokumenttiarkisto (kaikki määritykset) + Help Desk. Luettelosta otsake: Open CDA 2005 FAQ- lista ja asiakirja HL7 Help Desk FAQ-lista pvm: 15.1.2005 OID- 1.2.246.777.11.2005.9

1 Standardointi 1.1 Kuinka virallinen on HL7 CDA R2 standardi on? HL7 CDA R2 standardi sai 21.4.2005 ANSI standardin statuksen ANSI/HL7 CDA, R2-2005 4/21/2005. Kansallisen terveyshankkeen ja HL7 Finland ry:n alkuvuodesta 15.1.2005 julkaistu CDA R2 paikallistaminen noudattaa lähes kaikilta osin hyväksyttyä standardia. Vaikka standardi ei sisällä CDA R2- schemaa standardoimista, niin Suomessa on päädytty yhteen viralliseen schemaan. Nyt standardin saanutta CDA R2 vastaavaa schemaa ei ole vielä ilmestynyt. Koko open CDA 2005 paketti päivitetään viimeisimmän R2-scheman mukaiseksi vuoden 2005 lopussa. Samoin valmistuvat vuodelle 2005 tilatut uudet osuudet. Dokumentaatio on www.hl7.fi päiväyksellä 28.2.2006. 1.2 Miten toimin, jos tarvittavaa sosiaali- ja terveydenhuollon tietotekniikan standardia ole olemassa? Vähimmällä omalla työpanoksella pääsee, jos saa jonkun kansallisen tahon ymmärtämään standardin tarpeen ja on valmis rahoittamaan sen tekemistä. Myös itse voi tehdä vaikka yksinään standardin noudattaen niiden tekemisessä vallitsevia toteutustapoja ja hyväksyttämällä sen esimerkiksi HL7 Finland ry:ssä. Jos asiasta on jo standardi olemassa, niin rinnakkaista standardia ei yleensä hyväksytä. Mikäli standardi ei täytä yleisiä periaatteita ja tarpeita, niin sen hyväksyttäminen saattaa olla vaikeaa, minkä takia usein kannattaa jo tekovaiheessa hakea hankkeella laajempaa hyväksyntää esitetylle ratkaisulle. Myös apua on käytettävissä HL7 Help Desk tai teknillisen työryhmän jäseniltä. Kansallisten HL7 standardin hyväksymisessä on käytössä HL7 Finland ry:n äänestyssäännöt, jotka löytyvät www.hl7.fi sivuilta. 2 HL7 CDA R1 määritykset 2.1 Siirtyminen R1:stä R2:een Miksi siirtyminen kannattaa - mahdollisuus strukturoidun tiedon esittämiseen - kansallisesti yhtenäinen tapa esittää tietoa Haittoja - sanoman koko kasvaa entisestään (riippuu strukturoinnin tasosta) Siirtymispolku - Hyödyntävien järjestelmien täytyy tukea rinnakkaiskäyttöä - Adaptereissa suora siirtyminen R1:stä R2:een sekä tietosisällön strukturointi?

3 HL7 CDA R2 määritykset 3.1 R2 tietojen implementointi? Kansallisessa terveyshankkeessa määritellään potilaskertomustietojen siirrossa rakenteiset ydintiedot pakollisiksi vuoden 2007 loppuun mennessä. Miten kansallisen terveyshankkeen ydintietomääritykset implementoidaan CDA R2 mukaisesti (open CDA 2005 tuki paketti) Tuleeko CDA R2 myös arkistointiin? Potilaskertomustietojen siirtoon on tehty seuraavat CDA R2-määritykset, jotka tulee implementoida: - lähete/hoitopalaute - lääkityslista - henkilötiedot - fysiologiset mittaukset Edellä mainituissa implementointioppaissa käytetyt ydintietomääritykset löytyvät dokumentista Open CDA 2005, Kertomus ja lomakkeet, Versio 1.00, 15.1.2005, OID 1.2.246.777.11.2005.5 luvuista 3.2.1-3.2.14, jotka on päivitetty versio 2.00, 28.2.2006, OID 1.2.246.777.11.2006.3 Lisäksi on määritelty laboratoriovastauksien CDA R2 muoto, jota tulisi käyttää arkistoinnissa. On määritelty myös episodiin perustuva diagnoosilista, jonka käyttöä ei ole vielä ohjeistettu arkkitehtuurimielessä. CDA R2 tulee myös potilaskertomustietojen arkistointiin, mutta siitä ei ole vielä virallista määräystä. Perusjärjestelmässä potilaskertomustiedot voivat olla muussakin kuin CDA R2- muodossa, mutta mukana täytyy olla tarpeeksi rakenteista tietoa, jotta CDA R2 siirtoformaatti saadaan siirtoa varten aikaiseksi. Lisäksi on määritelty siirtomuoto todistuksille ja lausunnoille ja se on otettava käyttöön sitä mukaa kuin vastaavaa integraatiota toteutetaan. 3.2 Mitä tarkoittaa tietojen oleminen R2-muodossa? Arkiston osalta epäselvää on se, mitä tietojen olemisella CDA R2 muodossa tarkoitetaan. Onko CDA R2 tietojen fyysinen tallennusformaatti vai riittääkö, että tiedot saadaan ulospäin tässä formaatissa? Arkistossa tiedot ovat CDA R2-muodossa allekirjoitettuna. CDA R2 on myös fyysinen tallennus-formaatti (HL7 TC pohdinta15.3.2005). Toisaalta herää kysymys, mikä on fyysinen tallennusformaatti. Teoriassa tiedot voi muuntaa CDA R2-muotoon ja sähköisesti allekirjoittaa ja tallentaa vain allekirjoituksen. Muuttumattomuus voidaan varmistaa muuntamalla tiedot uudestaan CDA R2 muotoon. Jotta kyseinen menettely toimisi, niin muunnoksen täytyy tapahtua täysin yhtäläisesti ja tietokannan päivittyessä on syytä varautua häiriöihin. Käytännössä siis kannattaa tallettaa CDA R2-dokumentti allekirjoituksineen sellaisenaan. 3.3 Onko järkevää ottaa R2:a käyttöön, jos tietoa ei esitetä rakenteisesti?

Mikäli käytössä on toimiva R1 adapteri, niin sen päivittäminen R2 kannattaa tehdä, jos adapteri tarvitaan sähköiseen lääkemääräykseen, sähköisiin todistuksiin tai arkistointiin. Myös päivitys on järkevää silloin kun viitetietokantojen näyttöohjelmisto osaa hyödyntää rakenteisia tietoja kuten taulukoida laboratoriotuloksia. 3.4 Onko kansainvälisiä muutoksia R2:teen, jotka vaikuttavat viiteaihioon? Kansallinen CDA R2 paikallistaminen perustuu tammikuun 2005 äänestysversioon, mikä oli viimeinen äänestys R2 muodosta. Standardi sai 21.4.2005 ANSI standardin statuksen ANSI/HL7 CDA, R2-2005 4/21/2005 ja muutoksen vaikutukset schemaan ja muutaman elementin ja atrribuutin nimiin on muutettu ja joidenkin elementtien järjestys on korjattu. Kansallinen terveyshanke on määrittellyt arkistoinnin vaatimat pakolliset ja vapaaehtoiset kuvailutiedot, mikä on aiheuttanut myös pieniä muutospaineita R2 paikalliseen headerosuuteen. Nämä molemmat muutokset on toteutettu 28.2.2006 julkaiostussa versiossa. Tämän jälkeen muutoksia on odotettavissa lähivuosina varsin vähän. Seuraava R3 valmistelu on alkanut ja on tulossa valmiiksi nopeasti, mikä usein tarkoittaa useita vuosia (versio R2 valmistui 5:ssä vuodessa). 3.5 Koskeeko CDA R2 vain kertomusjärjestelmää vai myös muita järjestelmiä (esim. lab, rtg, leikkaussali)? CDA R2 ei suoraan koske muita järjestelmiä. Niissä on kuitenkin otettava huomioon rakenteiset ydintiedot siltä osin, kun niitä siirretään potilaskertomusjärjestelmään, koska potilaskertomusjärjestelmästä tiedot pitää saada ulos CDA R2-muodossa. Tietoja arkistoitaessa niiden on oltava kiistämättömiä ja standardimuotoa kuten CDA R2 sekä sähköisesti allekirjoitettuja (mahdollisesti organisaation). Sähköisen arkistoinnin määritys tältä osin on vielä valmisteluvaiheessa. Esimerkiksi resurssien varaamiseen, tilauksiin, tilastointiin ja laskutukseen on valmistunut (tai valmistumassa) HL7 V3 sanomat, jotka korvaavat meilläkin käytössä olevat V2 sanomat. 3.6 Voiko laboratoriopyynnöissä ja -vastauksissa käyttää CDA R2 standardia? Laboratoriopyyntö voidaan tallentaa kertomukseen CDA R2 muodossa ja vastaus on myös CDA R2 muodossa, missä muodossa se myös arkistoidaan. Laboratorioon toimitettu pyyntö sisältää lisäksi usein myös laskutukseen ja tilastointiin liittyvää tietoa ja toimitettu nykyisin V2 muodossa, joka on jatkossa korvattavissa V3, jonka määrittelle ei vielä ole aikataulua. 3.7 Onko lääkityslistan määritysperiaatteista olemassa mitään yleisempää ohjetta teknisen rakenteen lisäksi? Tällainen on open CDA 2003 paketissa lääkityshakemistossa, Ilkka Kunnamon tekemä lääkityksen_koodaus_231203.doc. Kyseinen tiedosto on unohtunut Open CDA 2005 paketista.

3.8 Lääkityslistassa on melko paljon pakollisia kenttiä ja näyttää siltä, että käyttäjä joutuu syöttämään hyvinkin paljon tietoja. Onko määritys liian tiukka? Lääkityslistan pakollisia kenttiä pohtii Kauko Hartikaisen (kuntaliitto) vetämä työryhmä. Pakollisten kenttien määrää tullaan vähentämään. Samalla pohditaan, mitkä kaikki tiedot saadaan lääketietokannoista automaattisesti. Toinen työryhmä pohtii lääketietokantojen sisältöjen yhtenäistämistä ja kehittämistä tietosisällön suhteen. Yksinkertaisimmillaan käyttäjä lisää lääkityksen lääkityslistalle valitsemalla potilaan, lääkkeen kauppanimen ja valvotun annostelun syöttökoodin. Valtakunnallista annostelun syöttökoodistoa ei ole kuitenkaan saatu vielä aikaiseksi. 3.9 Onko lääkityslista nyt valmis implementoitavaksi? Koko open CDA 2005 paketti päivitetään viimeisimmän R2 scheman mukaiseksi vuoden 2005 lopussa. CDA R2 on saanut ANSI-statuksen toukokuussa 2005, mutta lopullinen schema ei ole vielä ilmestynyt, koska HL7:n sääntöjen mukaan schema ei ole osa virallista standardia. Lopulliseen lääkityslistaversioon saattaa tulla vielä muutama lisäkenttä. 3.10 Lääkityslistassa lääkkeen rakenne ja annostus ovat hiukan epäselviä. Mistä saisi lisäohjeita? Rakennetta ja annostusta koskeva lisäohjeistus on tehty ja kyseinen ohje liitetään vuoden 2005 lääkityslistadokumenttiin käyttämisestä laboratorioliikenteessä. 3.11 Tulevatko nykyiset viitetietokannat tukemaan CDA R2 muotoa? Vaikka CDA R2 formaatista ei vielä olekaan hyötyä viitetietokannassa, niin uudet adapterit kannattaisi tehdä CDA R2:lla (sitten kun viitetietokanta osaa R2:n näyttömuodon). Tämä siksi, että olisi adapterit toimintakunnossa sitten kun alueelliset sovellukset pystyvät rakenteisia tietoja hyödyntämään. Tosin alussa varmaan adapteritkin tuottavat vain R2 näyttömuotoa. Open CDA 2005 paketissa on CDA R2 header määritykset ja mappaustaulukko R1:een ja myös viiteaihioesimerkki. Body-osan määrityksethän muodostavat open CDA 2005 paketista suurimman osan. Varsinainen liikennöintitapa on sama R2:ssa ja R1:ssa. Tietysti "arkkitehtuurimäärityksiä" ja toiminnallisia määrityksiäkin tarvitaan, esim. mistä asioista viitteitä muodostetaan ja millä tavalla ja mikä on todellinen viitatun aineiston sisältö jne. Mutta nämä määritykset eivät ole HL7-yhdistyksen asia, vaan ne julkaistaan STM:n oppaassa versiossa 1.2 28.2.2006 sekä Kuntaliiton ydintieto 3.12 Milloin uudet CDA R2 määrittelyt valmistuvat? Määrittelyä on viivästyttänyt lopullisen rakennetiedostojen, viranomaismäärittelyn ja JHS OID-tunnuksen takia. Määrittelyt julkistetaan 28.2.2006.

3.13 Vakuutusyhtiön tarvitsemat lisätiedot? Nykyisessä henkilötietolomakkeessa on seuraavat tiedot: Työnantajatiedot (täytetään vain työtapaturmissa) - Työnantajan nimi - Työnantajan osoite - Työnantajan puhelin Potilas voi jatkossa myös itse osaltaan täyttää kyseisen lomakkeen. Henkilötietolomakkeen on tarkoitus siirtyä lähetteen ja hoitopalautteen mukana. Kyseistä tietosisältöä voitaisiin laajentaa myös muuhun vakuutuksen korvattaviin tapauksiin. Vakuutusyhtiötiedot (täytetään vain vakuutusyhtiön korvaamissa tapauksissa) - Vahinkopäivä - Vakuutusyhtiö - Vakuutustodistus on/ei (tämä voisi olla myös tekstiosiossa eli ei siis välttämättä rakenteellisena) 3.14 Määritelläänkö kaikki lomakeet CDA R2 muodossa? Kaikista kansallisista lomakkeista tulee CDA R2 määritys ja vuoden 2006 pyritään saamaan puuttuvat määritykset kuten: - Lääkärintodistus ammatti-ihotaudista - Terveydenhoitolaitoksen/kuntoutuksen palveluntuottajan todistus matkakorvausta varten + Matkakorvaushakemus (KELA) - Tutkimus- ja hoitomääräys sekä selvitys annetusta fysioterapiasta (KELA) - Kuolintodistus, alle 28 vrk tai kuolleena syntynyt (Lääninhallitus) - Kuolintodistus, 28 vrk ikäisestä tai vanhemmasta (Lääninhallitus) - Ilmoitus näkövammarekisterille (NKL) - Ilmoitus syöpärekisterille (Syöpäyhdistys) - Ilmoitus todetusta ammattitaudista, Ilmoitus työstä johtuneesta muusta sairaalloisesta tilasta (STM) - Ilmoitus suoritetusta raskauden keskeyttämisestä tai steriloimisesta (STM) - Kudosirrotuspöytäkirja (STM) 3.15 Usean henkilötiedon käyttö CDA-dokumentissa? Potilasasiakirja on potilaan dokumentti, johon joskus joudutaan kirjaamaan myös tietoja muista henkilöistä. Nämä tiedot on poistettava asiakirjoista niitä luovutettaessa tai annettaessa potilaalle tarkastusoikeuden mukaista otetta. Henkilötietolomakkeella annetaan erilaiset yhteystiedot ja roolilla hoitaa suhde potilaaseen. 3.16 Toistuva kenttä lomakkeissa? Lomakkeiden toistuva kenttä hoidetaan toistamalla kenttä otsakkeineen uudestaan. Tällä taataan yksinkertainen ja yksikäsitteinen käsittely

3.17 Tilapäinen ht ja OID? Kysymykset: - Miten tehohoidon yhteenvedon sisältävässä CDA R2 -dokumentissa ilmoitetaan, että potilaan hetu on tilapäinen? - OpenCDA 2005 Header V1.0.doc ohjeistaa, että patient.person.id.=rt on normaaleissa hetuissa "1.2.246.573.21.1" - Miten CDA Headerissa (R2) kuvataan tilapäinen hetu? - OpenCDA2005 kertomus ja lomakkeet 2005-01-15.doc ohjeistaa tilapäisen hetun käyttöä sivulla 11, mm. nimi mainitaan pakolliseksi tiedoksi? Entä jos on kyse ensihoidosta, ja potilas on tajuton, eikä nimi ole tiedossa? - Miten CDA Bodyssä (R2) kuvataan tilapäinen hetu? Tilapäinen HT tehdään sen tekijän juuren alle (Stakes OID ohje) - 1.2.246.537.10.yhteisötunnus.22.2006.tilht on yhteisön vuonna 2006 antama yksikäsittteinen tilapäinen henkilötunnus - potilaan nimi on pyrittävä lisäämään niin nopeasti kuin mahdollista sekä tavallisiin että sähköisiin potilasasiakirjoihin - onnettomuuksissa voidaan potilas/potilaat aluksi tunnistaa vaikka numerolla, mutta oikeat tunnisteet tulee saada aina potilasasiakirjoihin, jotta potilaan oikeusturva on kunnossa 3.18 CDA R2 ja tapahtuma-aika? CDA R2 aika voidaan ilmaista aina halutulla tarkkuudella vaikka sekunnin osina. Kaikki ajat pitää tarvittaessa antaa kellonajan tarkkuudella kuten päivystykseen saapuminen tai tehohoidossa. CDA R2 ei anna ajalle tarkkuutta, vaan se tehdään kirjaamisohjeissa. - sanelussa aika purettaan sanelijan antamalla tarkkuudella - perusjärjestelmässä järjestelmän antama aika on syytä lähes aina kirjata minuutin tarkkuudella. Tarvittaessa kertomusohjelmiston näytöillä aika voi esiintyä tietojen näyttämiseen sopivalla tarkkuudella 3.19 CDA R2 paragraph ja content? Kysymys: - useimmissa CDA R2 -esimerkeissä on jätetty pois content-elementti paragraphin sisältä, OpenCDA -dokumentaatioon sisältyvät irralliset XML-esimerkit eivät kuitenkaan ole aivan johdonmukaisia - onko content tarpeellinen paragraphin sisällä (tai text:in) ainoastaan silloin, kun jaetaan ko. tekstikappale osiin? Esim. linkitetään osa tekstistä toisaalle: rakenteinen elementti, josta erillinen entry? Tai esimerkiksi osa tekstistä on lihavoitu tai sisältää muuta muotoilua? Vastaus: Teksin näyttäminen eri riveillä hoidetaan ensisijaisesti paragraph-elementillä. Content elementtillä on tarkoitus vain merkata xml ID:llä tekstin osia, joihin muualla viitataan. 3.20 Java JAXB CDA R2 luokat?

Kysymys: Voiko JAXB:lla (Java XML Binding) suoraan muuntaa CDA:n skeemaa Javaluokiksi. Vastaus: Suomessa ei ole kokeiltu JAXB:tä CDA scheemaan mutta HL7 xml keskustelu listoja on referoitu kahta ongelmaa. Paul Bironin vastauksen mukaan JAXB 1.0 reference implementaatio toimii ok HL7 tietotyyppien kanssa. Toisessa kohdin Ricardo Pires kertoo käyttäneensä JAXB:tä CDA scheemoihin. HL7 xml listoja pääsee selaamaan osoitteesta http://lists.hl7.org/read/?forum=xml -> search XML binding työkaluilla on ollut käsittääkseni vaikeuksia xsd:any tietotyypin ja siihen liitetyn periytymisen kanssa, sillä HL7 ei käytä any:ä vaan omaa ANY tyyppiä, josta muut tietotyypit on periytetty, mutta ongelma on sama. CDA:ssa ANY tyyppi on vain Observation/value elementissä. Ratkaisuna toimii ilmeisesti value elementin tietotyypin muuttaminen xsd:choice:ksi, joka sisältää listana mahdolliset tietotyypit.jaxb 2.0 reference implementaatio on ilmestynyt tammikuussa, faq sivulla mainitaan ettei 2.0:lla ole ongelmia any tyypin kanssa, JAXB 2.0 vaatii Java 1.5:n. http://java.sun.com/webservices/jaxb/index.jsp https://jaxb.dev.java.net/faq/#dom_bind 4 HL7 CDA sanomat (SOAP) 4.1 CDA QUERY? Kysymys 1: CDA:n QUERY-sanomassa voi QUERY_ID-elementissä olla määriteltynä useita set_id:itä. Miten kyselyyn pitäisi vastata tilanteessa, jossa vain osa pyydetyistä dokumenteista voidaan palauttaa? Vastaus 1: Kyselyyn vastaaja palauttaa ne dokumentit, jotka löytyvät. Kysyjä havaitsee tiettyjen dokumenttien puuttuvan ja kyselee niitä sitten erikseen (yksitellen) ja saa asianmukaiset virhekoodit. Lisäkysymys 1: Entä jos yhtään dokumenttia ei löydy? Lisävastaus 1: Silloin taaksepäin yhteensopivaa on käyttää NAK-kuittausta (koko kyselyn hylkäys) + virhekoodi. Yksittäiselle dokumentille voi saada tarkemman virhekoodin kysymällä sitä erikseen. Yleisperiaatteena on se, että kyselyyn vastaajan pitäisi selvitä muutamilla perusmäärityksillä ja kyselijä voi rakentaa mieleisensä monimutkaisenkin toimintalogiikan näiden peruspalikoiden avulla. Kyslujöitä on yleensä aina enemmän kuin vastauksien antajia. 4.2 Voidaanko sanomaliikennettä laajentaa käytettäväksi kaikkien järjestelmien väliseen kertomusliikenteeseen? Jatkossa järjestelmät voivat lähettää arkistoon tai toisilleen: - alkuperäisen kertomuksen tai sen osan säilytettäväksi - keskeneräisen kertomuksen kopion käyttöä ja säilytystä varten - keskeneräisen kertomuksen kopion käyttöä varten - lähetteen ja hoitopalautteen kopion - lähetteen lisäkyselyt ja niiden vastaukset

- todistuksen - konsultaatiot pyynnön, lisäkyselyt ja niiden vastaukset - lääkemääräykset - kertomuksen kopion käyttöä varten - kuvailutiedot (viitteet) käyttöä varten Käyttötapaukset tullaan vuoden 2005 kesän ja syksyn aikana kuvaamaan viranomais- ja arkistomäärittelyissä ja niiden perusteella täydennetään tarpeelliset lisätunnukset Soupsanomiin. 4.3 Onko SOAP määritykset riittävän kattavia? Sanomaliikennettä on SOAP sanomilla tehty usean toimittajan toimesta. Saadut kokemukset ovat pääsääntöisesti olleet myönteisiä, mutta määrityksistä on löytynyt myös pieniä virheitä, ristiriitaisuuksia sekä epätäsmällisiä ilmaisuja. Määritystä täydennetään ja lisätään uusien toimintojen lisäpiirteet ja uudet määrittelyt julkaistaan 31.1.2006 mennessä. 4.4 Mitä välityspalvelun pitää ja ei pidä tehdä? Välityspalvelun määrittely on tekemättä ja tämän hetken aikataulun mukaan toteutetaan heti alkuvuoden 2006 aikana. Välityspalvelu voidaan toteuttaa yhtenä kansallisena palveluna tai useina alueellisina palveluina. Päätökset toteuttajasta/toteuttajista ja arkkitehtuurista tehtäneen myös kevään 2006 aikana. Ideoita määrittelyä varten voi lähettää Help Deskiin, josta ne välittyvät määritysten tekijöille. 5 HL7 V2 sanomat 5.1 Ajanvaraussanoman tietosisältöä 2.x? Kuysymys: Mihin laitetaan ajanvarauskyselyn vastaussanomassa tutkimus ja vastaanotto/toimipiste? Vastaus: Versiossa 2.x ajanvaraukset määritellään kappaleessa 10. Tutkimus laitetaan AIS-tietoryhmään kenttään 3 universal service identifier, joka on tietotyyppiä CE Vastaanotto ja toimipiste laitetaan tietoryhmään AIL kenttään 3 location resource id, joka on tietotyyppiä PL. PL Henkilön sijainti PL Person location HL7 USA Ch. 2.8.26 <point of care (IS )> ^ <room (IS )> ^ <bed (IS)> ^ <facility (HD)> ^ < location status (IS )> ^ <person location type (IS)> ^ <building (IS )> ^ <floor (IS )> ^ <location description (ST)>

<hoitopiste (IS )> ^ <huone (IS )> ^ <vuode (IS)> ^ <toimipaikka (HD)> ^ < sijainnin tila (IS )> ^ <henkilön sijainnin tyyppi (IS)> ^ <rakennus (IS )> ^ <kerros (IS )> ^ <sijainnin kuvaus (ST)> Hoitopiste viittaa käyttäjätauluun 0302, huone käyttäjätauluun 0303, vuode käyttäjätauluun 0304, sijainnin tila käyttäjätauluun 0306, henkilön sijainnin tyyppi käyttäjätauluun 0305, rakennus käyttäjätauluun 0307, kerros käyttäjätauluun 0308. Kaikissa näissä tauluissa käytetään paikallista koodistoa. Toimipaikassa käytä organisaatiokoodia. Vastaanotto ekaan pieceen ja toimipiste neljänteen, siis: vastaanotto^^^toimipiste Muita oleellisia kenttiä: SCH-5: ajanvarauksen id SCH-9 ajanvarauksen kesto minuutteina SCH-11 ajanvarausaika muodossa ^^^alkuaika^loppuaika, jossa ajat minuutin tarkkuudella. Edellinen aika voi loppua samalla minuutilla, jolla seuraava alkaa. On huomattava, että SCH-11 TQ:ta ei käytetä versiosta 2.5 eteenpäin, vaan SCH-11 on korvattu erillisellä TQ1-tietoryhmällä. 6 HL7 V3 sanomat 7 Oid-tunnus 7.1 Omat radiologian nimikkeet? Sairaanhoitopiirissämme (Y-tunnus 101010-1) käytetään pääosin Kuntaliiton laboratoriotutkimusnimikkeistöä ja radiologian nimikkeistöä. Emme käytä kummastakaan nimikkeistöstä läheskään kaikkia nimikkeitä, mutta radiologiassa meillä lisäksi 23 omaa nimikettä ja laboratoriossa 31. Kuntaliiton uusin laboratoriotutkimusnimikkeistö on vuodelta 2004. Sen OID on 1.2.246.537.6.3.2004.1 ja radiologian tutkimusnimikkeistön (2003) OID-koodi on 1.2.246.537.6.4.2003.1. Silloin kun siirrossa käytetään koodeja, jotka löytyvät virallisesta nimikkeistöstä, käytetään virallisen nimikkeistön OID-tunnusta. CDA R2 attribuutin displayname avulla voi tuoda esiin paikallista nimeämiskäytäntöä. Omille luokituksille annetaan omat OID-tunnuksensa. Omaan luokitukseen kuuluu pelkästään organisaation omat nimikkeet. OID rakennetaan seuraavalla tavalla:

a) Juureksi laitetaan oman organisaation OID-tunnus (yleensä SHP-taso) b) Luokituksen tunnus (tässä 6.3 tai 6.4) otetaan virallisesta luokituksesta c) versiointi hoidetaan paikallisesti. Esim. edellä mainitut 23 radiologian nimikettä muodostavat oman luokituksensa 1.2.246.537.10.1010101.6.4.2005.1 Laboratorion 31 nimikettä muodostavat puolestaan luokituksen, jonka OID voisi olla: 1.2.246.537.10.1010101.6.3.2005.1. Organisaation omien nimikkeiden koodiarvoille on annettu myös suositukset ja niitä voidaan käyttää omissa järjestelmissä ilman pitkää OID-tunnusta. Siirrossa on käytettävä organisaation omaa pitkää muotoa, jotta ei päällekkäisiä koodistoja esiinny. Vastaanottaja tunnistaa tutkimuksen displayname:n perusteella, mutta samoja tutkimuksia ei pystytä taulukoimaan. Silloin kun kyseessä on oman luokituksen nimike, CDA R2:ssa pitäisi käyttää myös attribuuttia codesystemname. Laajassa käytössä olevat omat nimikkeistöt pitäisi rekisteröidä valtakunnalliselle koodistopalvelimelle. Seuraavassa esimerkissä siirretään peräkkäisissä vastauksissa kuntaliiton luokitukseen kuuluva tutkimus sekä oma paikallinen tutkimus. <observation classcode= OBS moodcode= EVN > <code code="2382" codesystem="1.2.246.537.6.3.2004" displayname="s Tyreotropiini"> </code> </observation> <observation classcode= OBS moodcode= EVN > <code code="3942111hehehe" codesystem="1.2.246.537.10.1010101.6.3.2005.1" codesystemname= 1010101-1 Tropit displayname="t Troppi"> </code> </observation> 7.2 Terveydenhuollon ammattihenkilöiden OID-tunnukset? Onko terveydenhuollon ammattihenkilöille (muille kuin lääkäreille) tulossa valtakunnallinen yksikäsitteinen tunnus?

Tällä hetkellä käytössä henkilötunnus, mutta varmenneasiat ovat työn alla TEO:ssa 7.3 Yritysten OID-tunnukset? Kysymys HL7:n omasta OID-koodipuusta. Kuinka pitkälle sitä on määritelty ja onko siellä paikkaa, johon sovellustoimittajat voivat omia koodistojaan sitoa? Nythän on tarpeen OIDkoodeja tiputtaa esimerkiksi sovellustunnuksiksi, joillekin sovelluskohtaisille koodistoille jne. Eli löytyykö 1.2.246.777 puusta suoraan solmua, jossa määritellään esimerkiksi toimittajan x sovellus y tai voisiko toimittajat saada 777:n alta solmun/solmuja (esimerkiksi sovelluksittain), jotka olisivat vapaasti määriteltävissä sovellusten omiin tarpeisiin? Vastaus: On valmisteltu ehdotusta HL7 hallitukselle, että HL7 Finland ry:n jäsenet voisivat käyttää oman yrityksensä osalta HL7 OID-tunnusta 1.2.246.777.10.123456, missä 123456 on y- tunnus ilman etunollaa ja väliviivaa. Solmuluokkien ja muiden ratkaisujen osalta noudatettaisiin Stakesin OID-ohjetta. Ohjelmistojen solmuluokka on 12 tai jatkoalueella 12001 12999. Ohjelmistojen eri versiot saavat omat yksilöintitunnuksen. ohjelmisto 1.2.246.777.10.123456.12.2005.23 esim. Pagasos versio 1.2.246.777.10.123456.12.2005.23.2.561 versio 2.531 7.4 Meillä on RIS ja pacs hankkeissa tullut sellainen tarve, että toimipaikan tutkimushuoneille on annettava oma OID tunnus. Huoneille ollaan antamassa oma solmuluokka 7.4 On kuulunut tietoa, että OID-tunnuksesta olisi tulossa juhta standardi Juhtan toimesta ollaan parhaillaan valmistelemassa JHS standardia yksilöinnin ja OIDtunnuksen käyttöönottamiseksi sekä toimipaikkojen yksilöimiseksi. 7.5 Juhtassa on OID suositus tulossa ja meneekö terveydenhuollon OID uusiksi? Juhtan toimesta ollaan parhaillaan valmistelemassa JHS-suositustusta ISO OIDyksilöintitunnuksen soveltamisesta julkishallinnossa. Lausuntopyyntö löytyy http://www.jhssuositukset.fi/suomi/oid-lausuntop2005-11-29. Suositus tulee hivenen muuttamaan sosiaali- ja terveydenhuollon OID-tunnuksia, mutta solmuluokat pysyvät esityksessä muuttumattomina ja toimipaikkojen yksilöintinumero säilyy myös muuttumattomana. Suositus tulee mahdollistamaan kuntahallinnossa yhtäläisen yksilöinnin käyttöönoton toimialasta riippumatta. 7.6 Tarvitsen terveyskeskukseen OID-tunnuksen. Mistä sen saa? Keskussairaalat auttavat terveyskeskuksia aluehankkeiden yhteydessä OID-tunnuksen käyttöönotossa ja toimipaikkarekisterin tekemisessä. 7.7 Eikö Stakesin koodistopalvelimelle voi lähettää koodistoja tai toimipaikkojen tietoja?

Kyseinen palvelu ei ole vielä käytössä. Palvelu määritellään vuoden 2006 loppuun mennessä ja toteutetaan alkuvuonna 2006 ja testataan ja käyttöönotetaan lääninhallitusten yksityissektorin toimipaikkailmoituksilla. Sen jälkeen palvelu on erikseen sovittaessa sairaanhoitopiirien toimipaikkailmoitusten ja koodistontuottajien käytettävissä. 7.8 Projektien yksilöinti OID tunnuksella? Projekteille voidaan varata yksi toimipaikka, joka saa oman pysyvän OID-tunnuksen esim. 1, joka on sitten varattu eikä voi käyttää toiseen kertaan. Tämän toimipaikan alle voidaan projektit yksilöidä antamalla solmuluokka 10 ja sen alle projektin OID-tunnus 1, 2, 3 jne. 8 Sovellutusrajapinnat API (kontekstinhallinta ja ydinpalvelut) 9 Dokumenttiarkisto 9.1 Riittääkö nykyinen dokumentaatio? Kaikki dokumentaatio pyritään kokoamaan www.hl7.fi palveluun. Dokumentaatiota pyritään täydentämään koulutuksilla, esimerkeillä, HelpDeskillä ja FAQ-listalla. 9.2 Mistä löytyy virallinen, viimeisin versio Open CDA R2 -henkilötietosanomasta? Tuorein versio löytyy aineistosta: Open CDA 2005 4.2 Kertomus ja sähköiset lomakkeet Määritystaulukot Henkilötietolomakekentät excel-taulu 9.3 Mistä löytyy uusien määrittelyjen dokumentit? - STM, Open sähköisen potilaskertomuksen rakenteesta, versio 1.2 28.2.2006 - STM, Arkki sähköisen arkiston toiminnallinen vaatimusmäärittely projekti loppuraportti 2.1.2006 - Stakes OID-tunnuksen käyttö terveydenhuollossa - Käytettävät koodistot Stakes koodistopalvelu www.stakes.fi/koodisto - Suomen kuntaliitto, Opas ydintietojen, otsikoiden ja näkymien toteuttaminen sähköisessä potilaskertomuksessa versio 1.0 28.2.2006 - OpenCDA 2005 Header V2.00 28.2.2006 - OpenCDA2005 kertomus ja lomakkeet v2.00 28.2.2006 10 Ydintiedot, kertomuksen rakenteet ja koodistot

10.1 Mistä saa lisätietoja ydintiedoista, kertomuksen rakenteista ja koodistoista? Ydintietoihin liittyviä vastauksia kootaan myös Internetin Ydintietoprojektin cametyöpöydälle, johon kaikilla hankkeilla ja järjestelmätoimittajilla on linkki käytössä. Jos linkki puuttuu, sen voi tilata sähköpostilla: kauko.hartikainen@kuntaliitto.fi 10.2 Onko sähköisen kertomuksen rakenne jo toteuttamiskelpoinen? Kertomuksen näkemys/lomake, pää- ja väliotsikot pyritään kansallisesti määrittelemään ja saamaan lausunnolle elokuun lopulla yhdessä viranomaismääritysten kanssa. 10.3 Määritelmät seuraaville: episodi, hoitokokonaisuus ja palveluketju Asia on ongelmallinen, koska määrittelyt vaihtelevat eri sovelluksissa. Asiakirjoja ja niiden ketjutuksia ei ole sovelluksissa määritelty. Asiaan pyritään vaikuttamaan Kansallisen terveyshankkeen viranomaismäärityksen työpaketissa, joka tulee lausuntokierrokselle elokuun lopulla. 10.4 Ydintietojen maksimipituus ja näyttöesitysmuoto (ei rakenteinen) Ydintietojen pituuden määrittely kuuluu ensisijaisesti ydintietoryhmälle. Lääkityslistassa maksimi-pituuksia on jo määritelty. HL7-yhdistys on määritellyt, että OID-koodin tallettamista varten varataan 60 merkkiä. Ydintietoryhmä tulee lisäksi antamaan keskeisempien tietojen osalta suosituksen näyttö ja tulostusasusta. 10.5 Minkä ajankohdan mukaiset tiedot siirretään ja säilytetään? Esimerkiksi henkilötiedot siirretään tiedon syntyajankohdan mukaan. Jos pyydetään esim. vanhaa hoitojaksoa viranomaiselle, ko. henkilön tiedot siirretään kaikilta osin tiedon synty hetken mukaisena. 10.6 Kertomuksen väliotsikot. Kertomuksen väliotsikkoja ei ole vieläkään kiinnitetty. Mikä on työn tilanne ja millä aikataululla otsikot olisivat käytettävissä? Viranomaismäärittelyssä on tarkoitus määritellä vuoden 2005 lokakuun loppuun mennessä viralliset kansalliset: - näkymät ent. lomaketunnukset (erikoisala- ja ammattilaisnäkymät) - pääotsakkeet - otsakkeet Ydintietojen osalta on lisäksi määritelty käytettävät tietokentät ja koodistot. Tauti- ja erityisseurantaa vaativien tietojen osalta kansallisten yhteisten määritysten ja koodistojen työ on alkanut tänä vuonna (keuhkosairaudet, työterveyden- ja hammashuolto) ja jatkuu usean lähivuoden ajan. 10.7 Mikä on yksi lomake, kun puhutaan potilaskertomuksen jatkuvakäyttöisistä osista? Sellaista lomaketta ei ole, vaan kyse on keromusohjelmiston tuottamasta näyttönäkymästä, esimerkiksi sisätautitiedot tai laboratoriotulokset ajallisesti peräkkäin

esitettynä kattaen useita hoitojaksoja ja mahdollisesti myös useita toimintayksiköitä tarvittaessa potilaan suostumuksella. Tieto on tallennettuna hoitojaksokohtaisiin asiakirjoihin. 10.8 Miten rakenteisuus hoidetaan sanelussa? Sanelua purettaessa voidaan käyttää fraaseja, vakiolausuntopohjaa ja hakea koodeja diagnoosin perusteella, kunhan riittävästi varmistetaan, ettei sanelun purussa esiinny virheitä. Lääkäri vastaa sanelusta puretun tiedon oikeellisuudesta. 10.9 Miksi CDA R2 headerin tiedot poikkeavat R1 vastaavista tiedoista? CDA R2 headerin kentät täsmentyvät parhaillaan käynnissä olevassa viranomaismäärityksissä, jolloin arkistoinnin pakolliset ja vapaaehtoiset kuvailutiedot määritellään. 10.10 Miksi ohjelmakohtaisille lomakkeille ei ole OID-tunnusta? CDA R2 muodossa on tarkoitus tallentaa vain tiedot kertaalleen varsinaisille lomakkeille ja niiden pohjalta vain näytetään muita tietoja (katso kirjan luku 3.5) Koska tietoja ei talleteta R2 rakenteeseen, vaan tarvittaessa näytetään, niin tunnusta ei tarvita eikä ole annettu. Viitetietokannoissa on tallennus ja eri näyttömuodot toteutettu toimittaja ja viitetietokanta kohtaisesti ja oikeaa toimintatapaa pitää kysyä tilaajalta. lähteet löytyvät: www.hl7.fi DCA dokumenttiarkisto Open CDA 2003 Open CDA määrittelydokumentti v 1.0 Pvm: 2.2.2004 OID: 1.2.246.777.11.2004.3 Koodistot CDA_koodit_lomakkeet CDA_koodit_otsakkeet www.hl7.fi DCA dokumenttiarkisto Open CDA 2005 Kertomus ja sähköiset lomakkeet v 1.0 Dokumentit Kertomus ja sähköiset lomakkeet v 1.0 Pvm: 15.1.2005 OID: 1.2.246.777.11.2005.5 10.11 Miksi en löydä tiettyä tautikohtaista tai muuta vastaavaa lomaketta? Kuntaliitossa ollaan tämän vuoden aikana työstämässä tarkemmin 1. keuhkosairaudet 2. työterveydenhuolto 3. hampaat ja toivottavasti lähiaikoina työstetään myös toivottu tauti tai vastaava

Jo nyt voidaan tiedot rekisteröidä HL7 CDA R2 muodossa vähintään näkymä ja otsaketasolla sekä ydintiedot tietokenttätasolla. Tautikohtaisessa määrittelyssä on tarkoitus nimetä muut käytettävät tietokentät niiden sisältö kuten käytettävät koodistot, jolloin ne ovat helpommin käytettävissä taulukoissa, laadunseurannassa ja tilastoissa. Määrittely voidaan tehdä kansallisesti kuten Kuntaliiton koordinoimana tai käyttäjien ja toimittajien aloitteesta muita kuullen. Tautikohtaisia tulosteita (eli paperiversiossa olevia tauti- tai vastaavia lomakkeita) ei ole tarkoitus tässä vaiheessa kansallisesti määritellä, vaan tuotteet voivat vapaasti kilpailla hyvien tuotteiden tekemisessä noudattaen vain sovittuja säilytysmuotoja. 11 Muut kysymykset 11.1 Miten sähköinen C-lausunto voitaisiin liittää Kelan sähköiseen hakemukseen? Kun kansalainen anoo sähköisesti etuutta Kelalta, niin anomuksessa voisi kansalainen antaa suostumuksensa Kelalle hakea sähköisistä arkistoista kyseinen todistus. Toiminta voisi tapahtua seuraavasti: Annan Kelalle suostumuksen noutaa minua koskeva sähköinen C-todistus anotulle ajalle sähköisistä potilaskertomusarkistoista Toimitan itse todistuksen Kelan toimistoon Edellisen toimintamallin toteutusta selvitetään vielä STM:n lakityöryhmässä, Tellu työryhmässä ja viranomaismäärityksissä. 11.2 Onko terveydenhuollon ohjelmistotuotteet sertifioitava vuonna 2007? Sosiaali- ja terveysministeriön työryhmämuistioita 2004:18 Sähköisten potilasasiakirjajärjestelmien toteuttamista ohjaavan työryhmän loppuraportti seuraavaa: Yleispalaute strategiasta oli myönteinen. Strategia todettiin kattavaksi ja oikeansuuntaiseksi. Strategian aikataulua pidettiin yleisesti tiukkana ja toteutuksen todettiin vaativan paitsi hankkeiden priorisointia ja aikataulutusta myös valtion rahoitusta. Puutteena nähtiin yksityisten terveyspalveluiden tuottajien vähäinen huomioon ottaminen strategian valmistelussa. Myös tarvetta kehittää rinnalla sosiaalialan tietojärjestelmiä korostettiin. Hankkeiden koordinaatio ja kansallisen ohjaus todettiin tärkeiksi. Tietojärjestelmien sertifioinnin aikaansaamista toivottiin useassa lausunnossa. 2.9 Sähköisten potilaskertomusjärjestelmien sertifiointi Tekesin FinnWell ohjelma on tehnyt myönteisen rahoituspäätöksen VTT:n koordinoimalle terveydenhuollon tietojärjestelmien testausta selvittävälle hankkeelle ajalle 1.9.2004-31.8.2005. Työryhmä korostaa tietojärjestelmien yhteistoiminnallisuuden, tietoturvan, ydintietojen koodauksen ja rajapintojen testauksen tärkeyttä. Jatkossa tulisi voida sertifioida,

täyttävätkö tietojärjestelmät uudistettava potilasasiakirja-asetuksen (kohta 4.2.) vaatimukset. Teknisen alustan lisäksi tulee valmistella myös hallinnollinen malli sertifioinnin järjestämiseksi. Sertifiointijärjestelmä tulisi rakentaa vuoden 2006 aikana ja testaus käynnistää vuoden 2007 loppuun mennessä. Kyseinen raportti antaa suuntaviivoja kehitykselle ja toteutus tarvitsee omat päätökset ja niitä ei ole tehty.