Vaihtoehtoja Import-palvelun rajapinnan toteuttamiseen

OmaHyvinvointi-hanke Vaihtoehtoja Import-palvelun rajapinnan toteuttamiseen Mika Tuomainen, Juha Mykkänen ISBN 978-952-61-0093-7

Julkaisun nimi Julkaisun laatijat Hankkeen nimi Rahoittajat ja osallistuvat organisaatiot Vaihtoehtoja Import-palvelun rajapinnan toteuttamiseen Mika Tuomainen, Itä-Suomen yliopisto, HIS-yksikkö Juha Mykkänen, Itä-Suomen yliopisto, HIS-yksikkö OmaHyvinvointi-hanke TEKES/FinnWell, Cel Amanzi, Itella Oyj, Kustannus Oy Duodecim, Logica, Mediconsult, Huoltoliitto, Jaatinen Ry, Kuopion kaupunki, Turun kaupunki Julkaisun kuvaus Tässä dokumentissa keskitytään tietolähdeliitäntään, jolla palvelun antajan järjestelmästä voidaan siirtää tietoja kansalaisen Pärjäimeen. Tästä tietolähdeliitännästä käytetään nimitystä import-palvelun rajapinta. Tätä määrittelyä voidaan hyödyntää myös tietojen siirrossa kansallisesta sähköisestä arkistosta Pärjäimeen, tämä ei kuitenkaan ole erityisen tarkastelun kohteena tässä dokumentissa. Asiasanat Yhteyshenkilö Julkaisija Julkaisupaikka Dokumentissa kuvataan import-palvelun rajapinnan mahdollisia toteutusvaihtoehtoja. Kuvatun rajapinnan kohteena on erityisesti terveyteen liittyvien rakenteisten tietojen välittäminen Pärjäimeen. Peruslähtökohtana on ollut, että hyödynnetään jo olemassa olevia terveydenhuollon järjestelmien kansallisiin määrityksiin pohjautuvia rajapintatoteutuksia sekä tiettyjä kansallisesti käytettäviä rakenteisia tietokokonaisuuksia. Lisäksi on selvitetty, onko näille olemassa muita vaihtoehtoja. personal health record, rajapinnat, järjestelmäintegraatio, terveystieto Mika Tuomainen, Itä-Suomen yliopisto, mika.tuomainen@uef.fi Itä-Suomen yliopisto Kuopio Julkaisuvuosi 2010 ISBN 978-952-61-0093-7 OmaHyvinvointi-hanke 2

Sisällysluettelo 1 Johdanto... 5 2 Import-palvelu... 6 2.1 Import-palvelu ja rajapinta... 6 2.2 Rajaukset... 7 3 Tekniikkariippumattomat määrittelyt... 8 3.1 Käyttötapaukset... 8 3.2 Toiminnot... 9 3.3 Triggerit (laukaisevat tapahtumat)... 10 3.4 Tietosisällöt... 11 3.5 Import-palvelun arkkitehtuuri... 17 4 Import-palvelun käytön edellytykset... 20 5 Hyödynnettävissä olevat standardit ja määritykset... 22 5.1 Tietosisältömäärittelyt... 22 5.2 earkiston tiedonsiirtoratkaisu... 58 6 Yhteenveto... 66 6.1 Ratkaisujen valinta... 66 6.2 Pärjäimen tietojensiirron rajapintojen jatkokehitys... 66 6.3 Import-palvelun rajapinnan suhde FeelGood-hankkeen ekosysteemiin... 67 3 OmaHyvinvointi-hanke

ESIPUHE OmaHyvinvointi (OHV)-hanke oli Tekesin FinnWell-teknologiaohjelmasta 2008-2010 rahoitettu tutkimushanke. Hankkeen visiona on kansalainen, joka hallitsee omaa elämäänsä ja siihen liittyviä tiedonhallinta- ja asiointitarpeita yhteistyössä erilaisten toimijoiden ja palveluntarjoajien kanssa. Hankkeessa kansalaisen tueksi kehitettiin Pärjäin-konsepti, joka auttaa kansalaista huolehtimaan omista hyvinvointitarpeistaan ja antaa tälle välineitä aktiiviseen ja yksilölähtöiseen omien asioidensa hoitamiseen. Samalla avautuu mahdollisuuksia uudentyyppisten ja integroitujen sähköisten hyvinvointipalvelujen kehittämiseen. Tässä dokumentissa kuvataan eri vaihtoehtoja Import-palvelun rajapinnan toteuttamiseen. Importpalvelun rajapinnalla voidaan siirtää tietoja palvelun antajan järjestelmästä kansalaisen Pärjäimeen. Tekijät kiittävät kaikkia hankkeen tutkimus- ja yritysosapuolia hankkeen aikana tehdystä yhteistyöstä. Kuopiossa 18.3.2010 Mika Tuomainen OmaHyvinvointi-hanke 4

1 Johdanto Pärjäimen toteutuksessa voidaan käyttää erilaisia tietolähdeliitäntöjä, joilla pyritään helpottamaan tietojen saantia Pärjäimeen. Kansalaisen ei tällöin tarvitse syöttää tai ladata kaikkia tietoja itse käsin, vaan tietojen saanti voi olla mahdollisimman automaattista ja vaivatonta. Yksi keskeisimmistä tietolähdeliitännöistä on palvelun antajien tietojärjestelmien ja Pärjäimen välinen tiedonvaihto. Tämä tiedonvaihto on avainasemassa, sillä esimerkiksi PHR-katsauksesta [TML10] havaittiin, että monet kansalaiskeskeiset välineet itse asiassa pohjautuvat palvelujen antajien tarjoamiin mahdollisuuksiin avata kansalaiselle hänen omia tietojaan. Tässä dokumentissa keskitytään tietolähdeliitäntään, jolla palvelun antajan järjestelmästä voidaan siirtää tietoja kansalaisen Pärjäimeen. Tästä tietolähdeliitännästä käytetään nimitystä importpalvelun rajapinta. Tätä määrittelyä voidaan hyödyntää myös tietojen siirrossa kansallisesta sähköisestä arkistosta Pärjäimeen, tämä ei kuitenkaan ole erityisen tarkastelun kohteena tässä dokumentissa. Dokumentissa kuvataan import-palvelun rajapinnan mahdollisia toteutusvaihtoehtoja. Kuvatun rajapinnan kohteena on erityisesti terveyteen liittyvien rakenteisten tietojen välittäminen Pärjäimeen FIN Terveys-Pärjäin-skenaarion pohjalta [MNM10]. Peruslähtökohtana on ollut, että hyödynnetään jo olemassa olevia terveydenhuollon järjestelmien kansallisiin määrityksiin pohjautuvia rajapintatoteutuksia sekä tiettyjä kansallisesti käytettäviä rakenteisia tietokokonaisuuksia. Lisäksi on selvitetty, onko näille olemassa muita vaihtoehtoja. Import-palvelun rajapintaa vastaavaa rajapintaa on pohdittu alustavasti myös FeelGood-hankkeessa. Import-rajapinnan suhdetta FeelGood-hankkeen suunnitelmiin on kuvattu tämän dokumentin luvussa 6.3. 5 OmaHyvinvointi-hanke

2 Import-palvelu 2.1 Import-palvelu ja rajapinta Omahyvinvointi-hankkeen toteutustyöpajoissa sovittiin, että tietojen siirrossa Pärjäimen ja palvelun antajien järjestelmien välillä lähdetään aluksi liikkeelle tietojen siirtämisestä palvelun antajan järjestelmistä (perusjärjestelmä, kertomusjärjestelmä, tms.) kansalaisen henkilökohtaiseen Pärjäinjärjestelmään. Kansalaisen näkökulmasta tästä toiminnallisuudesta on suuri hyöty, sillä kansalainen voi saada omia tietoja palvelun antajan järjestelmistä suoraan Pärjäimeen eikä kansalaisen tarvitse syöttää niitä erikseen käsin omiin tietoihinsa. Tässä dokumentissa tämä tietojen siirtäminen on kuvattu import-palvelun tehtäväksi (kuva 1). Import-palvelu tarjoaa palvelun antajien järjestelmille yhdenmukaisen rajapinnan, jonka avulla ne voivat välittää tietoja Pärjäimeen. Import-palvelun rajapinnassa määritellään tähän tiedonsiirtoon tarvittavat toiminnallisuudet ja rakenteiset tietosisällöt sekä ratkaisun arkkitehtuuri. Toteutuksen vastuulle jää, kuinka import-palvelu toimii varsinaisen Pärjäin-toteutuksen kanssa (onko se erillinen palvelu vai kiinteä osa Pärjäin-toteutusta), mitä saaduilla tiedoilla tehdään ja kuinka tietoja esitetään kansalaiselle. Yhdenmukaisen rajapinnan käytön etuna tällaisessa tietojen siirrossa on, että palvelun antajat voivat siirtää samalla rajapinnalla omista järjestelmistään tietoja useisiin Pärjäimiin ja toisaalta Pärjäin voi ottaa vastaan tietoja samalla ratkaisulla useista eri tietolähteistä. Kuva 1. Import-palvelu ja rajapinta yleisellä tasolla. Aluksi järjestelmien väliset yhteydet voidaan toteuttaa point-to-point-periaatteella, kuten kuvassa 1 on kuvattu. Näin määrittelyissä päästään nopeasti liikkeelle ja määrittelyjen testausta on mahdollista tehdä yksinkertaisessa ympäristössä. Jatkossa viestinvälitys yksittäistä ratkaisua laajemmalla tasolla pohjautunee kuitenkin integroinnin helpottamiseksi viestinvälityspalveluihin ja vastaaviin ratkaisuihin, sillä tietoja tulee olemaan saatavissa Pärjäimeen useista eri lähteistä. Lisäksi on myös huomioitava, että Pärjäimiäkin voi olla käytössä useita. Nämä seikat huomioidaan rajapintamäärittelyissä, vaikka alussa lähdetäänkin liikkeelle point-to-point-lähestymistavalla. Näin varmistetaan, ettei määritellä ratkaisuja, jotka estävät jatkossa viestinvälityspalvelujen käytön. OmaHyvinvointi-hanke 6

Import-palvelu toimii siten, että palvelun hyödyntäjä (palvelun antaja järjestelmä) kutsuu palvelua ja lähettää tietoja sen avulla import-palvelun tarjoajalle (Pärjäin). Tiedonsiirto tapahtuu palvelun antajan järjestelmän näkökulmasta PUSH-periaatteella. Alkuvaiheessa tästä tietojen viemisestä Pärjäimeen on sovittava kansalaisen kanssa etukäteen, esimerkiksi jo vastaanotolla. Näin ei tarvita vielä erillisiä ratkaisuja, joilla palvelun antajalle annetaan valtuutus/suostumus tietojen lähettämiseen Pärjäimeen. Tämä on toimiva ratkaisu varsinkin ensimmäisessä peruslataustilanteessa, jossa kansalaisen uuteen Pärjäimeen siirretään hänen tietojaan palvelun antajalta tai kyseessä on yhden palvelun antajan kansalaiselle tarjoama Pärjäin. Lähettävän järjestelmän ja vastaanottavan järjestelmän on myös tunnettava tai tunnistettava toisensa tietoturvallisen kommunikoinnin saavuttamiseksi. Nämä on kuvattava varsinaisessa teknisessä määrittelyssä. Tietosisältöjen osalta on huomioitava, että Pärjäimen on osattava jatkossa käsitellä useita eri formaatteja. Näitä ovat mm. tekstidokumentit, rakenteiset dokumentit, hyper- ja multimedia, binääridokumentit, rakenteiset tietoalkiot ja metatiedot. Tässä dokumentissa kuvattujen tietosisältöjen lähtökohtana ovat olleet rakenteiset tietosisällöt. 2.2 Rajaukset Import-palvelun rajapinnassa ei oteta kantaa, mitä tiedoilla Pärjäimessä sen jälkeen tehdään, kun tiedot ovat välittyneet Pärjäimeen (miten näytetään kansalaiselle, tallennetaan tietovarastoon jne.). Nämä on ratkaistava toteutuskohtaisesti. Rajapinnassa ei oteta myöskään kantaa siihen, kuinka tietoja luokitellaan tai tagitetaan Pärjäimessä tietojen saannin jälkeen. Rajapinnan tietosisällöissä voidaan kuitenkin määritellä tietyt metatiedot ja näitä voidaan hyödyntää myös luokittelussa. Kun tietosisältöjen pohjana aletaan käyttää rakenteisia tietoja (esim. CDA R2-, CCR- tai CCDrakenteita), on varmistuttava, että molemmat osapuolet osaavat hyödyntää ja muodostaa näitä. Lisäksi välitettävät rakenteet on myös muutettava luonnollisesti kansalaisen ymmärtämään näytettävään muotoon. Tämä rajapinta ei ota näitä seikkoja huomioon, se ainoastaan välittää viestit sovituilla tietosisältö- ja rakennemäärittelyillä. Peruslataustilanteessa ei välttämättä ole tarvetta erilliselle kansalaisen lähettämälle kuittaukselle (teknisiä tiedonsiirtoprotokollaan liittyviä kuittauksia voi olla). Sen sijaan tiettyjen yksittäisten tietojen lähettämisen yhteydessä lähettäjä voi olla kiinnostunut, onko viesti mennyt perille käyttäjälle asti ja haluaa tästä kansalaiselta erillisen kuittauksen (esim. annosteluohjeen muutoksen meneminen perille). Tällaisia erillisiä kuittauksia ei ole määritelty tähän määrittelyyn. Jatkossa rajapintamäärittelyä voidaan laajentaa myös tietojen siirtoon Pärjäimestä palveluntuottajien järjestelmiin (eport) eli kansalainen voi välittää tiettyjä ennalta sovittuja tietoja palveluntuottajalle. Tässä dokumentissa keskitytään kuitenkin ainoastaan import-palvelun rajapintaan. 7 OmaHyvinvointi-hanke

3 Tekniikkariippumattomat määrittelyt Alla on kuvattu tekniikkariippumattomia määrittelyjä import-palvelulle, joilla kuvataan palvelulle asetettuja vaatimuksia. Aluksi lähdetään liikkeelle yksinkertaisimmasta mahdollisesta käyttötapauksesta, jonka avulla saadaan määriteltyä minimitaso (käyttötapaus 1). 3.1 Käyttötapaukset 1. Käytön aloittaminen - "Omat tietoni ovat valmiina Pärjäimessä" Esiehdot: Tässä käyttötapauksessa lähdetään liikkeelle yksinkertaisimmasta skenaariosta: palvelun antaja tarjoaa kansalaiselle myös Pärjäimen. Ne ovat näin samaa rekisterinpitäjää, joten pelkkä kansalaisen suostumus tietojen siirtämiseen riittää. Näin ei myöskään tarvitse ratkaista Pärjäimen rekisterinpitäjien välisen luovutuksen hallinnoimista. Lisäksi oletetaan, että palvelun antajan järjestelmällä on tiedossa Pärjäimen sijainti ja järjestelmät tuntevat toisensa. Aluksi ei siis ole mukana useita eri palvelun antajan järjestelmiä, joista tietoja lähetetään Pärjäimeen. Kansalaiselle on ehdotettu, haluaako hän käyttöönsä www-pohjaisen Pärjäimen (vaatii kansalaiselta www-yhteyden). Kansalainen haluaa itselleen Pärjäimen ja näin hänen kanssa tehdään sopimus Pärjäimen tarjoamisesta. Samassa yhteydessä kansalainen antaa suostumuksen, että hänen tietojaan voidaan siirtää myös Pärjäimeen. Kuvaus: Kansalaiselle annetaan paperilla ohje, kuinka hän saa Pärjäimen käyttöönsä. Ammattilainen käy luomassa kansalaiselle käyttäjätilin Pärjäimeen. Ammattilainen valitsee järjestelmästään toiminnon vie tietoja Pärjäimeen ja valitsee kansalaiset tiedot/tietosetit/kaikki tiedot, jotka on tarkoitus lähettää Pärjäimeen. Ammattilainen valitsee toiminnon lähetä Pärjäimeen ja tiedot siirtyvät ammattilaisen järjestelmästä kansalaisten Pärjäimeen. Vaihtoehtoisesti heti tapahtuvalle tietojen välittämiselle tietojen kasaus ja siirtäminen tehdään myöhemmin ja kansalaiselle ilmoitetaan esim. tekstiviestillä milloin hänen tietonsa ovat siirretty Pärjäimeen. Kansalaiselle annetussa ohjeessa on kerrottu Pärjäimen www-osoite ja annettu tunnukset järjestelmään (tai kansalainen kirjautuu vahvan tunnistautumisen kautta, esim. pankkitunnukset). Kansalainen avaa ensimmäisen kerran www-selaimen kautta käytettävän Pärjäin-järjestelmänsä ja kirjautuu siihen. Pärjäin näyttää kansalaiselle siihen siirretyt tiedot 2. Tämän käyttötapauksen kuittaus- ja tekstiviesti-ilmoitus-toiminnallisuudet eivät ole tämän dokumentin määrittelyissä mukana. Yksittäisen tiedon/tietosetin import: yksittäisen tiedon/tietosetin import + kuittaus saaduista tiedoista (kansalaisen aloitteesta Pärjäimen lähettämä kuittaus, joka on pakollinen) + erillinen tekstiviesti-ilmoitus uusista tiedoista (Pärjäimen kansalaiselle lähettämä ilmoitus uusien tietojen saapumisesta) OmaHyvinvointi-hanke 8

Alkulatausvaiheen jälkeen on pian tarve lähettää uusia yksittäisiä tietoja/tietosettejä palvelun antajan järjestelmästä Pärjäimeen. Näin kansalainen saa jatkossakin uudet tiedot automaattisesti Pärjäimeensä. Ammattilainen voi olla kiinnostunut tiettyjen lähetettyjen tietojen osalta, onko kansalainen saanut lähetetyt tiedot ja vielä tarkempana tietona onko kansalainen myös lukenut tiedot. Näissä tilanteissa tarvitaan erillistä kuittausviestiä, jolla kansalainen voi ilmoittaa saaneensa/lukeneensa tiedot. Esimerkiksi kun kansalainen käy avaamassa uudet tiedot Pärjäimestä, voi hän lähettää ammattilaiselle kuittauksen luettuaan tiedot. Kuittaus voi lähteä Pärjäimestä myös automaattisesti, kun kansalainen avaa uudet tiedot. Jos kansalaisella on lähetettyjen tietojen osalta jotain tarkennettavaa tai hän haluaa antaa palautetta, ei näitä tarkennuksia tai palautteita enää hoideta tällä tiedonsiirtorajapinnalla, vaan apuna käytetään muita kommunikointitapoja (esim. luotettu sähköposti, erillinen palautteen kysymisja antokanava). Kuvaus: Palvelun antajan järjestelmä lähettää kansalaiselle laboratoriotulokset Pärjäimeen, kun tulokset on lausuttu ja arkistoitu (arkistointitapahtuma triggerinä) toiminnolla lähetä Pärjäimeen. Pärjäin vastaanottaa tiedot ja sijoittaa ne oikeaan luokkaan metatietojen perusteella. Pärjäin ilmoittaa kansalaiselle tekstiviestillä, että uusia tietoja on saapunut Pärjäimeen. Kansalainen kirjautuu Pärjäimeen ja Pärjäin ilmoittaa kansalaiselle uusista tiedoista. Kansalainen avaa uudet tiedot ja lähettää kuittauksen, että hän on saanut tiedot Pärjäimen toiminnolla lähetä kuittaus saaduista tiedoista. Pärjäin lähettää kuittauksen ammattilaisen järjestelmään. Ammattilaisen järjestelmä merkitsee kansalaiselle lähetettyjen tietojen listasta laboratoriotulokset luetuiksi (ehkä laboratoriotuloksia ei haluta seurata näin, mutta esimerkin vuoksi näin). 3.2 Toiminnot Käyttötapauksissa edellä kuvattiin, kuinka kansalaiselle siirretään palvelun antajan järjestelmästä tietoja Pärjäimeen. Alla on kuvattu (kuva 2) yksi mahdollinen etenemisprosessi järjestelmien välillä. Prosessissa ei ole kuvattu tekstiviesti-ilmoituksia eikä esimerkiksi palautteen antamista, vaan keskitytään vain tietojen siirtämiseen ja niiden saamisesta kuittaamiseen. 9 OmaHyvinvointi-hanke

Kuva 2. Esimerkki tietojen siirtämisprosessista Pärjäimeen. Import-palvelussa ja sen rajapinnassa tarvitaan edellisessä yksinkertaisessa prosessissa seuraavat toiminnallisuudet: tietojen välittäminen Pärjäimeen o palvelun antajan järjestelmän näkökulmasta PUSH-malli, jossa se välittää tietoja kutsumalla import-palvelua o Pärjäimen näkökulmasta import, jossa se vastaanottaa tietoja import-palvelun avulla kuittaus saaduista tiedoista (käyttötapauksen 2 yhteydessä) o kansalaisen Pärjäimen välityksellä lähettämä erillinen kuittaus, jolla hän ilmaisee että on havainnut/vastaanottanut lähetetyt tiedot. Kuittaus voi lähteä Pärjäimestä myös automaattisesti tietoja avattaessa ilman että kansalainen kuittaa erikseen tiedot. o tätä kuittausta ei määritellä tässä määrittelyn versiossa. HUOM! Kuittaus voi olla myös tekninen kuittaus siitä, että lähetetyt tiedot ovat menneet perille Pärjäimeen (järjestelmä/palvelu on vastaanottanut tiedot). Tekniset kuittaukset on kuvattu varsinaisessa teknisessä ratkaisussa. 3.3 Triggerit (laukaisevat tapahtumat) Toiminnallisuuksiin liittyen on lisäksi määriteltävä toiminnot laukaisevat tapahtumat eli triggerit. Triggerit määrittelevät milloin tietojen lähettäminen Pärjäimeen tai kuittausviestin lähettäminen Pärjäimestä tapahtuu. Tällaisia tapahtumia voivat olla esimerkiksi: Merkinnän hyväksyminen palvelun antajan järjestelmässä OmaHyvinvointi-hanke 10

Tietojen lähettäminen arkistoon (samalla lähetetään vastaavia tietoja myös Pärjäimeen) Käyttäjän (ammattilaisen/kansalaisen) niin halutessa/aloitteesta 3.4 Tietosisällöt Mitään varsinaisia tietosisältövaatimuksia Omahyvinvointi-hankkeen case-ryhmistä tai muutenkaan hankkeen sisällä ei ole formaalisti kartoitettu. Tietosisältöjen osalta on huomioita, mitä ovat siirrettävät tietokokonaisuudet ja mitkä ovat näiden tarkemmat tietosisällöt, tietojen rakenteisuuden taso, virallisen ja kansalaisen itse ylläpitämien tietojen erottaminen toisistaan sekä tietoihin liitettävät metatiedot. [TTM10] 3.4.1 Terveystietojen tietokokonaisuudet ja -sisällöt Minimitason tietosisältöjen lähtökohdaksi voidaan ottaa Suomessa määritellyt kansalliset ydintietomäärittelyt. Ydintiedot sisältävät mm. potilaan perustiedot, palvelutapahtuman ja palvelukokonaisuuden tunnistetiedot, ongelmat ja diagnoosit (+ riskitiedot), terveyteen vaikuttavat tekijät, mittaukset, tulokset, toimenpiteet, lääkehoito, preventio: rokotukset. Tämä on hyvä lähtökohta siinä mielessä, että em. ydintiedot on jo määritelty suurimmaksi osaksi CDA R2 rakenteina. Toisena lähtökohtana voivat olla myös Continuity of Care Record (CCR) [HL707a] ja Continuity of Care Document (CCD) [HL707a] määrittelyt, jotka on tarkoitettu siirtämään kansalaisen terveystietojen yhteenvetotietoja. Alla olevassa taulukossa 1 on kuvattu Ydintieto-oppaan version 2.2 tietosisällöt [Kun07]. Huom. ydintietojen oppaasta on tullut myös uusi versio (versio 3.0) [Kan09]. Ydintietoja ja niihin käytettävissä olevia tietosisältömäärittelyvaihtoehtoja on kuvattu luvussa 5.1 Tietosisältömäärittelyt. Taulukko 1. Ydintieto-oppaan tietosisällöt [Kun07]. Ydintietojen tietokentät Potilaan perustiedot Potilaan yksilöintitiedot Etunimet Etunimen tyyppi Sukunimet Sukunimen tyyppi Nimihistoria Henkilötunnus Väliaikainen henkilötunnus Syntymäaika Kuolinaika Sukupuoli Potilaan yhteystiedot Osoite Osoitteen tyyppi Kotikunta 11 OmaHyvinvointi-hanke

Yhteyshenkilö Puhelin, faksi, sähköposti Ammatti Äidinkieli Asiointikieli Etunimet Hoidon antajan tunnistetiedot Sukunimet Sukulaisuus Etunimen tyyppi Sukunimen tyyppi Yhteyshenkilön laji (Ensisijainen, toissijainen) Yhteyshenkilön osoite Yhteyshenkilön Puhelin Palvelun antaja (terveydenhuollon toimintayksikkö) Organisaation yksilöintitunnus Nimi Erikoisala Terveydenhuollossa toimiva henkilö Nimi SV koodi / muun terveydenhuollon ammattilaisen yksilöinti Ammattikoodi ja luokitus Palvelutapahtuman ja palvelukokonaisuuden tunnistetiedot Ongelmat ja diagnoosit Palvelukokonaisuuden tunnistetiedot Palvelukokonaisuuden nimi Palvelukokonaisuuden yksilöintitunnus Palvelukokonaisuuden luokitus (nimi ja koodi) Palvelutapahtuman tunnistetiedot Palvelutapahtuman nimi Palvelu- tai hoitotapahtuman tyyppi (Avohoitojakso, laitoshoitojakso) Palvelutapahtuman yksilöintitunnus Ajankohta Riskitiedon aste (Kriittiset tiedot / Hoidossa huomioitavat tiedot) Riskitiedon tyyppi Riskin nimi tai kuvaus Riskin koodiarvo ja käytetty koodisto/luokitus Selite, riskin huomiointi potilaan hoidossa Riskitietoon liittyvä tieto (esim. lääkeaine) Riskitietoon liittyvän tiedon koodaus ja koodisto (esim. lääkeaine) Riskin pysyvyys Riskin varmuusaste Riskin vakavuus Linkki kertomustekstiin jossa riski on todettu Tiedon lähde OmaHyvinvointi-hanke 12

Päiväys, riskitiedon anto Päiväys, riskitiedon poisto Hoidon syy Pää ja sivu (0 - n) Nimi, hoidon syyn kuvaus Hoidon syyn koodi ja luokitus Diagnoosi Pää ja sivudiagnoosit (0 - n) Diagnoosin nimi Diagnoosikoodi ja luokitus Diagnoosin tila Koodi, diagnoosin varmuusaste Koodi, diagnoosin pysyvyys Koodi, diagnoosin tyyppi Diagnoosin episoditunnus Tiedonlähde Päiväys, diagnoosin anto Päiväys, diagnoosin päättyminen Terveyteen vaikuttavat tekijät Tupakointi Päihteet Liikunta Raskaus Ravitsemus Fysiologiset mittaukset Mittauksen nimi Mittauskoodi ja luokitus Mittaustapa Mittaustulos Päiväys Hoitotyö Hoidon tarve (kirjatun hoidon kannalta merkittävä hoidon tarve) Nimi Koodi ja luokitus Hoidon tarpeen tila Koodi ja luokitus Päiväys Toiminto (kirjatun hoidon kannalta merkittävä toiminto) Nimi Koodi ja luokitus 13 OmaHyvinvointi-hanke

Tulos Toiminnon tuloksen arviointi Päiväys Hoidon tulokset (toimintojen vaikutus arvioituun hoidon tarpeeseen) Tulos Tuloksen tila Koodi ja luokitus Arviointi Päiväys Hoitoisuus Hoitoisuus Koodi ja luokitus Päiväys Hoitotyön yhteenveto Tutkimukset Tutkimuksen nimi Tutkimuskoodi ja luokitus Lausunto löydöksistä Tutkimustulos Päiväys Toimenpiteet Toimenpiteen nimi Toimenpidekoodi ja luokitus Lausunto ja löydökset Toimenpiteen komplikaatio ja sen kuvaus Komplikaation diagnoosi Komplikaation koodi Päiväys Lääkehoito Lääkkeen nimi ja vahvuus Lääkekoodi Lääkkeen rooli Lääkeannostus Päiväys, lääkityksen aloittaminen tai muuttaminen Lääkehoidon aloituksen tai muutoksen syy Lääkeindikaation nimi Lääkeindikaation koodi Päiväys, lääkityksen lopetus Lääkkeen vaihdettavuus Lääkitysohjeistuksen antaminen OmaHyvinvointi-hanke 14

Päiväys Preventio Rokotteen nimi Rokotekoodi Rokotteen kauppanimi Eränumero Annoksen järjestysluku Rokotustapa Pistokohta Päiväys, rokotteen anto Rokotusreaktio Rokotusreaktion diagnoosi Rokotusreaktion koodi Päiväys Lausunnot Todistukset ja lausunnot Koodi ja luokitus Toimintakyky Kuvaus Koodi ja luokitus Päiväys Apuvälineet Kuvaus Koodi ja luokitus Päiväys Palvelutapahtuman yhteenveto Hoitoprosessin vaihe Koodi ja luokitus Otsikko Koodi ja luokitus Teksti Päiväys Jatkohoidon järjestämistä koskevat tiedot Jatkohoidon syy Nimi Koodi ja luokitus Jatkohoitopaikka Organisaatio, toimipaikka Terveydenhuollon ammattihenkilö Palveluala Koodi ja luokitus 15 OmaHyvinvointi-hanke

Suostumus Palvelu (0-n) Nimi Varauksen tila Terveydenhuollon ammattihenkilö Päiväys Koodi ja luokitus Koodi ja luokitus Päivämäärä 3.4.2 Tiedon rakenteisuus Tietojen sähköinen sisällöllinen rakenne mahdollistaa tietojen lisäarvoa tuottavan yhdistettävyyden ja tietojen paremman jatkohyödynnettävyyden (esim. päätöksentuki, tietämystiedon linkitys) sekä on merkittävä tekijä eri järjestelmien integroitavuudessa. Tietojen yleinen formaatti vaikuttaa myös siirrettävyyteen välineestä toiseen esim. tilanteessa, jossa kansalainen haluaa vaihtaa Pärjäimen tarjoajaa. Rakenteisille terveyteen liittyville tiedoille on käytettävissä Suomessa CDA R2-määrittelyjä. Varsinkin kertomusjärjestelmät jo käyttävät näitä määrittelyjä ja samaa formaattia käytetään tietojen viennissä kansalliseen arkistoon (earkisto). Muita mahdollisia rakenteisia formaatteja ovat esimerkiksi CCR- ja CCD-määrittelyt. Näitä eri vaihtoehtoja on kuvattu tarkemmin tämä dokumentin luvussa 5.1 Tietosisältömäärittelyt. Tässä määrittelyssä lähdetään liikkeelle siitä, että palvelun antajan järjestelemästä importoitava tieto (virallinen tieto) on jotenkin rakenteista ja rakenteinen tieto toimii määrittelyn lähtökohtana. Tietojen rakenteisuuden määrittelyssä voidaan huomioida lisäksi kaksi eri näkökulmaa: virallisista lähteistä Pärjäimeen saatavat viralliset tiedot sekä kansalaisen Pärjäimessä henkilökohtaisesti ylläpitämät tiedot. Virallisista lähteistä saatavien tietojen (terveystietojen) voidaan olettaa noudattavan tiettyjä rakenteisia sisältömäärittelyjä ja tavoitteena voidaan pitää, että ainakin viralliset Pärjäimeen tuotavat terveystiedot ovat rakenteista tietoa. Kansalainen itsensä kirjaamat tai ylläpitämät tiedot voivat olla myös rakenteiseen muotoon tallennettavia (pakotetaan käyttäjä käyttämään rakenteita käyttöliittymässä). Tämä on erityisen tärkeää tietojen jatkohyödynnettävyydelle ammattilaisjärjestelmissä sekä mahdolliselle kansalaisen päätöksentuelle. On kuitenkin huomioitava, että tieto voi olla myös rakenteetonta tai ainakin jotkin osat tiedosta ovat rakenteetonta (esim. sanallinen palaute). Rakenteettomalle tiedollekin on kuitenkin määriteltävä tietoon liittyvät metatiedot. Lisäksi on huomioitava, että palvelun antajaltakin voi tulla ilman rakennetta olevia tietoja. 3.4.3 Virallisen tiedon suhde omiin tietoihin Nämä kaikki kohdat eivät kohdistu suoraan import-palveluun vaan ovat Pärjäimen toteutuskohtaisesti ratkaistavia. Mutta nämä ovat huomioitava mm. tietosisältöjen metatietojen määrittelyssä: Virallinen tieto (palvelun antajalta saatu) on virallista, ja sitä ei voi muuttaa tai poistaa. Esim. HL7 PHR-S FM-määrittelyissä [HL707b] sallitaan ainoastaan itse raportoitujen tietojen muuttaminen ja muokkaaminen. OmaHyvinvointi-hanke 16

Tietoja on kuitenkin voitava täydentää kansalaisen toimesta. Esim. tietoja voi kommentoida vapaalla tekstillä. Tiettyjen tietojen osalta korjaaminen ja muokkaaminen on oltava mahdollista. Yksi metatieto voikin olla voiko/saako kansalainen täydentää, korjata tai muokata tietoja. Päätöksentukirajapinnassa käytetään lähtökohtaisesti virallista tietoa mutta on huomioitava, että suuri osa päätöksentuen arvosta tulee siitä jos myös omat mittaukset on mahdollista liittää mukaan rakenteisena. Tiedoissa on oltava mukana tieto sen tuottajasta (metatieto: muokkaajasta, korjaajasta, lisääjästä), josta selviää myös tiedon alkuperä. Pidemmälle viedyn ekosysteemin rakentamisessa pitää sopimuksissa huomioida, että missä yhteydessä hyväksytään vain viralliset tiedot ja kuka on vastuussa virheellisistä tiedoista, jos käytetään muita kuin virallisia tietoja. 3.4.4 Metatiedot Jotta tiedot eivät olisi Pärjäimen sisällönhallinnassa hallitsematon tietomassa, on tietoihin liitettävä luokittelu- ja lajittelutekijöitä (metatietoja, tagitus). Näiden metatietojen avulla voidaan helpottaa Pärjäimessä olevien tietojen hallintaa ja löytymistä. Metatiedoilla voidaan myös varmistaa dokumenttien ajantasaisuus, liittää tietoja tiedon tuottajasta jne. Metatietoja voidaan hyödyntää Pärjäimeen tulevien tietojen automaattisessa luokittelussa. Tietojen luokittelun on hyvä olla mahdollisimman automaattista (vaivatonta kansalaiselle), sillä harvoilla on loogisen ryhmittelyn kykyä tai halua ja automatiikka voi hoitaa tietojen tagituksen kansalaisen puolesta. Lisäksi PUSH-mallissa tietoja tulee Pärjäimeen, vaikka kansalainen ei kävisi Pärjäimessä lainkaan. Tällöin on riski, että Pärjäimeen kertyy liian iso massa tietoja hallittavaksi. Tätä ongelmaan voidaan ratkaista lisäämällä automatiikka Pärjäimeen tulevien tietojen käsittelyyn siten, että tiedot menevät järkeviin kokonaisuuksiin automaattisesti metatietojen perusteella. Esimerkiksi palvelutapahtumat voivat toimia terveystietoja niputtavana tekijänä myös Pärjäimen puolella, kuten ne toimivat palvelun antajan järjestelmissä. Palvelutapahtumat muodostavat näin kokonaisuuksia, joihin voidaan liittää eri tietoja ja asioita joko automaattisesti tai sitten kansalaisen itsensä toimesta. On kuitenkin huomioitava että kansalainen voi halutessaan tagittaa tietoja myös omilla perusteilla mutta kuitenkin siten, ettei jäljitettävyys alkuperäisiin metatietoihin katoa. Esimerkiksi terveystietojen osalta metatiedot on kuvattu kattavasti kansallisissa CDA R2 headermäärittelyissä ja näitä metatietoja voidaan hyödyntää CDA R2 määrittelyjä käytettäessä Pärjäimessä luokittelu- ja lajittelutekijöinä. Yleisemmällä tasolla metatiedoille on määritelty pohjaa OHVhankkeen tietoarkkitehtuurimäärittelytyössä [TTM10]. 3.5 Import-palvelun arkkitehtuuri Import-palvelussa voidaan lähteä aluksi liikkeelle yksinkertaisella point-to-pointtiedonsiirtomallilla. Pointo-to-point-malli on järkevä ainoastaan tilanteessa, jossa on vain muutamia osapuolia (esim. palvelun antaja tarjoaa Pärjäimen kuntalaisille). Tulevaisuudessa tilanne voi olla sellainen, että Pärjäimeen tulee tietoja useiden eri palvelun antajien järjestelmistä ja myös Pärjäimiä voi olla useita. Tällöin tulee tarpeelliseksi viestinvälityspalvelujen ja vastaavien käyttäminen (kuva 3). 17 OmaHyvinvointi-hanke

Kuva 3. Viestinvälityspalvelu. PUSH-periaatteeseen pohjautuva import-palvelu on yksinkertainen tiedonsiirtomalli. Palvelun antajan järjestelmän ei tarvitse toteuttaa erillistä palvelua, se ainoastaan kutsuu import-palvelua ja hyödyntää sen tarjoamaa rajapintaa (kuva 4). Jos liikenne on synkronista, ei vastauksen vastaanottamiseksikaan tarvita erillistä vasteita kuuntelevaa palvelua (vasteet ovat tällöin synkroniseen liikenteeseen liittyviä vastauksia Pärjäimeltä). Kuva 4. Yksinkertainen synkroninen liikenne vaatii ainoastaan import-palveluun kuuntelevan palvelun. Jos tietojen siirrossa huomioidaan myös kansalaisen aloitteesta lähettämät kuittaukset, vaativat kuittaukset kuuntelevan palvelun toteuttamista myös palvelun antajan järjestelmään. Koska kansalainen ei ole lähettämässä kuittauksia heti Pärjäimen saatua tiedot, tiedonsiirrossa on huomioitava tämä seikka. a) Jos liikenne olisi asynkronista, voisi kansalaisen aloitteesta lähetetty kuittaus hänen saamistaan tiedoista toimia asynkronisena vastauksena asynkroniseen palvelupyyntöön (kuva 5). OmaHyvinvointi-hanke 18

Kuva 5. Asynkroninen viestintä. b) Jos liikenne on synkronista, tällöin tietojen lähettäminen on yksi synkroninen viestinvälitys ja kansalaisen aloitteesta Pärjäimen tekemä kuittaus oma erillinen synkroninen viestinvälitys (kuva 6). Tällöin kuittauksille on määriteltävä oma interaktio(t) ja tietosisällössä on huomioitava, että niissä pitää välittää tieto mihin tietoihin/tapahtumaan kuittaus kohdistuu. Kuva 6. Synkroninen viestintä. 19 OmaHyvinvointi-hanke

4 Import-palvelun käytön edellytykset Import-palvelun ja yleisemmin myös Pärjäimen käytön edellytykseksi on ratkaistava taustalla erilaisia sopimussuhteita. Näihin voi liittyä myös palvelujen maksullisuuteen liittyviä seikkoja, näitä ei kuitenkaan käsitellä tässä dokumentaatiossa. Tässä luvussa on kuvattu vain pääpiirteet sopimuksissa huomioitavista asioista, näitä on käsitelty tarkemmin OmaHyvinvointi-hankkeessa erillisessä raportissa "Lainsäädännön mahdollisuudet ja rajoitukset kansalaislähtöisessä sähköisessä Pärjäinpalvelussa" [LEM10]. Kansalaisen näkökulmasta Pärjäimen käytöstä on tehtävä sopimus kansalaisen ja Pärjäin-palvelujen tarjoajan välillä. Lisäksi tarvitaan myös sopimukset kansalaisen ja muiden hyvinvointipalvelujen tarjoajien kanssa siitä, että kansalaisen tietoja voi välittää kansalaisen Pärjäimeen. Näiden lisäksi palveluntarjoajien näkökulmasta on vielä tarpeellista huomioida myös Pärjäin-palvelujen tarjoajan ja hyvinvointipalvelujen tarjoajien väliset sopimukset. Näitä suhteita on kuvattu alla kuvassa 7. Kuva 7. Pärjäimeen liittyvät sopimussuhteet [LEM10]. Edellä kuvatut sopimussuhteet voivat toimia esimerkiksi seuraavasti: Kansalainen tekee sopimuksen Pärjäin-palvelujen tarjoajan kanssa. Pärjäin-palvelujen tarjoajana toimii kunta, jolloin tässä sopimuksessa voidaan jo sopia myös siitä, että kunnan käyttämästä kertomusjärjestelmästä siirtyy tietoja kansalaisen Pärjäimeen. Ellei tilanne ole tämä, on kunta ja sen käyttämä kertomusjärjestelmä samassa asemassa kuin seuraavassa kuvatut hyvinvointipalvelujen tarjoajat. Pärjäin-palvelujen tarjoaja tekee sopimukset eri hyvinvointipalvelujen tarjoajien kanssa, että nämä näkyvät tietolähteinä Pärjäimessä. Tällainen sopimus voidaan tehdä myös tarpeen mukaan, jos tietolähde ei ole jo valmiina tarjottavana Pärjäimessä. Kun kansalainen ottaa käyttöön tällaisen Pärjäimestä erillään olevan tietolähteen, tekee hän sopimuksen tietolähdettä tarjoavan hyvinvointipalvelun tarjoajan kanssa. Seuraavat kohdat eivät näy Pärjäintä käyttävälle kansalaiselle mutta on oltava taustalla hoidettuna erilaisilla sopimussuhteina nekin: OmaHyvinvointi-hanke 20

Import-palvelua kutsuvien järjestelmien on toteutettava import-palvelun rajapintakutsut, tiedettävä miten palvelua kutsutaan sekä mistä osoitteesta palvelu tavoitettavissa. Järjestelmät, jotka kutsuvat Pärjäimen import-palvelua (eli välittävät tietoja Pärjäimeen), on tunnistettava luotettavasti import-palvelussa. Näin import-palvelu voi luottaa siihen, että tietoja lähettää osapuoli, joksi se itseään väittää. Edellä kuvattu vaatimus toimii myös toisinpäin eli kutsuvien järjestelmien on tunnistettava import-palvelu, jotta ne voivat olla varmoja siitä, että tietoja vastaanottaa osapuoli, joksi se itseään väittää. Kaksi viimeisintä edellä ovat erityisen tärkeitä tietoturvan kannalta, sillä import-palvelussa siirretään arkaluontoisia tietoja. Käytännössä vaatimukset tarkoittavat sitä, että järjestelmien on tunnettava toisensa etukäteen ennen liikennöintiä. Lisäksi jos käytössä on viestinvälityspalvelu tai vastaava, on Pärjäimen ja hyvinvointipalvelujen mahdollisesti tehtävä liittymissopimus tällaiseen viestinvälityspalveluun. 21 OmaHyvinvointi-hanke

5 Hyödynnettävissä olevat standardit ja määritykset Rakenteisten terveystietojen välittämiseen Pärjäimen ja palvelun antajien järjestelmien välille on olemassa useita standardeja ja määrityksiä. Alla on listattu valmiita standardeja ja määrittelyjä terveyteen liittyvien tietojen rakenteisille tietosisällöille ja tiedonsiirrolle sekä kuinka näitä voi yhdistellä import-rajapinnan määrittelemiseksi: HL7 V3 Medical Records + HL7 V3 WS + CDA R2 o tiedonsiirto: käytetään HL7 V3:ssa määriteltyjä HL7 V3 Medical Records määrittelyjä sekä HL7 V3 Web Services profiilia. Tätä tiedonsiirtotapaa käytetään kansallisissa ratkaisuissa, joissa tietoja välitetään kansalliseen kertomusarkistoon tai reseptikeskukseen. o tietosisältö: ydintiedot rakenteisina CDA R2 määrittelyinä tai muut CDA R2 määrittelyt. HL7 V3 Medical Records + HL7 V3 WS + CCR tai CCR o tiedonsiirto: kuten edellisessä vaihtoehdossa. o tietosisältö: HL7 Continuity of Care Document (CCD) määrittelyn tietosisällöt ja rakenteet. ASTM Continuity of Care Record (CCR) määrittelyn tietosisällöt ja rakenteet. Joku muu tiedonsiirtomäärittely + CCR/CCD/CDA R2 o tiedonsiirto: Google Health API (http://code.google.com/intl/fi/apis/health/). Google Healthiin siirretään CCR:n pieni osajoukko Google Health APIn avulla. Pärjäimen yhteydessä tätä voitaisiin hyödyntää CCR/CCD-tietosisältöjen siirtoon, miksei CDA R2 tietosisältöjenkin. Käytännössä tiedonsiirto olisi kuitenkin tällöin määritelty Google Health PHR:ää varten. Myös Microsoft HealthVaultiin löytyy oma erillinen rajapinta ja sinne voi siirtää sekä CCD- että CCR-tietosisältöjä. Yhtä yhteistä rajapintaa tiedonsiirrolle Google Healthiin tai MS HealthVaultiin ei ole. o tietosisältö: CCD/CCR/CDA R2 EBMeDS-rajapinta o tiedonsiirto: EBMeDS rajapinnassa määritelty Web Services-määrittely. o tietosisältö: EBMeDS rajapinnassa määritellyt tietosisällöt ja rakenteet. Seuraavissa aliluvuissa on kuvattu tarkemmin em. tietosisältömäärittelyitä (kansalliset ydintiedot, EBMeDS-tietosisällöt, CCR/CCD-määrittelyt) sekä tiedonsiirtoon earkiston rajapinnan hyödyntäminen. 5.1 Tietosisältömäärittelyt Alla on kuvattu eri vaihtoehtoja terveyteen liittyville tietosisältömäärittelyille. Läpi käytyjä määrittelyjä ovat kansalliset ydintiedot (CDA R2 määritykset), päätöksentuenteon rajapinnan tiedot (EB- MeDS -tiedot) sekä CCR/CCD-tiedot edellisiä yleisemmällä tasolla. OmaHyvinvointi-hanke 22

5.1.1 Ydintiedot Tässä luvussa tietosisältöjen lähtökohdaksi on otettu Suomessa jo määrittelyt kansalliset ydintietomäärittelyjen tietokokonaisuudet ja -sisällöt [Kun07]. Ydintietomäärittelyissä pyritään hyödyntämään yhdenmukaisia luokituksia. Valtakunnallisesti luokitukset, joihin määrittelyistä viitataan, ovat koodistopalvelussa. Ydintietomäärittelyissä hyödynnetään HL7 CDA R2 standardia. Ydintiedot on esitetty tämän luvun taulukoissa. Ydintietojen osalta on myös kartoitettu, mitä määrityksiä ydintietoihin on tällä hetkellä tarjolla. Taulukoissa olevat Kertomus ja lomakkeet -viittaukset pohjautuvat dokumenttiin OpenCDA 2009, Kertomus ja lomakkeet, v4.2 [Ope09b], tarkemmat ohjeet näiden tietojen esittämiseen löytyvät kyseisestä dokumentista eikä niitä käydä läpi tässä määrittelyssä (mm. CDA R2 dokumentin siirto, säilytys ja rakenne). HUOM. Ydintieto-oppaasta on saatavilla myös uusi versio 3.0 [Kan09]. Näitä ei ole huomioitu tässä dokumentissa tarkalla tasolla eikä näiden osalta ole kartoitettu, mitä määrityksiä näihin löytyy. Kunkin Ydintietojen tietokentän osalta on kuitenkin alla olevissa kappaleissa kuvattu muutokset kunkin esitetyn taulukon jälkeen. 5.1.1.1 Potilaan perustiedot Pärjäimeen välitettävistä henkilötiedoista on määriteltävä, mitä tietoja ne tarkalleen ovat. Minimivaatimuksena voidaan pitää, että Pärjäimen perustamisvaiheessa kansalaisesta välitetään vähintään yksilöintiin tarvittavat tiedot. Ydintietomäärittelyissä on määritelty tietokenttään potilaan perustiedot seuraavat tiedot potilaan yksilöintitiedot potilaan yhteystiedot yhteyshenkilö Ydintietojen potilaan perustiedot sopivat näin Pärjäimeen välitettävien henkilötietojen laajemmaksi tietosisällöksi. 23 OmaHyvinvointi-hanke

Taulukko 2. Potilaan perustiedot. Tietokentät Ydintieto-oppaan version 2.2 31.7.2007 pohjalta. Ydintietojen tietokentät Eri määrittelyt otettu uudemmista kansallisista määrittelyistä kuin mitä Ydintieto-oppaan versiossa 2.2 on mainittu. Kansalliset tietomäärittelyt on/ei Määrittely Potilaan perustiedot Henkilötietolomake HEN (2007-01-18) Potilaan yksilöintitiedot Etunimet HEN/Perustiedot: Sukunimi, etunimet (PN) Etunimen tyyppi HEN/Perustiedot: Sukunimi, etunimet (PN) Sukunimet HEN/Perustiedot: Sukunimi, etunimet (PN) Sukunimen tyyppi HEN/Perustiedot: Sukunimi, etunimet (PN) Nimihistoria HEN/Perustiedot: Entinen sukunimi, etunimet (PN) (toistuva) Henkilötunnus HEN/Perustiedot: Henkilötunnus (II) Väliaikainen henkilötunnus HEN/Perustiedot: Väliaikainen henkilötunnus (II) Syntymäaika HEN/Perustiedot: Syntymäaika (TS) Kuolinaika HEN/Perustiedot: Kuolinaika (TS), ISO 639, poistettu lomakkeesta? Sukupuoli HEN/Perustiedot: Sukupuoli (CV), ISO 5218 Potilaan yhteystiedot Osoite X HEN/Perustiedot: Osoite (laji ja voimassaolo) (AD) (toistuva) Osoitteen tyyppi X HEN/Perustiedot: Osoite (laji ja voimassaolo) (AD) (toistuva) Kotikunta HEN/Laskutustiedot: kotikunta (JHS110) (CV) Puhelin, faksi, sähköposti HEN/Perustiedot: Puhelin, fa ja sähköposti (TEL) (toistuva) Ammatti HEN/Laskutustiedot: ammatti (ST) Äidinkieli HEN/Perustiedot: Äidinkieli (CD), ISO 639 Asiointikieli HEN/Perustiedot: Asiointikieli (CD), ISO 639 Yhteyshenkilö Etunimet HEN/Yhteystiedot: yhteyshenkilön suku, etunimet (PN) Etunimen tyyppi HEN/Yhteystiedot: yhteyshenkilön suku, etunimet (PN) Sukunimet HEN/Yhteystiedot: yhteyshenkilön suku, etunimet (PN) Sukunimen tyyppi HEN/Yhteystiedot: yhteyshenkilön suku, etunimet (PN) Sukulaisuus HEN/Yhteystiedot: yhteyshenkilön sukulaisuus (CV) Yhteyshenkilön laji (Ensisijainen, toissijainen) HEN/Yhteystiedot: yhteystiedon ensisijaisuus (CV), onko vastaava? Yhteyshenkilön osoite HEN/Yhteystiedot: yhteyshenkilön osoite (laji ja voimassaolo) (AD) (toistuva) Yhteyshenkilön Puhelin HEN/Yhteystiedot: yhteyshenkilön puhelin, fa ja sähköposti (TEL) (toistuva) Muita Henkilötietolomakkeelta löytyviä, ehkä jatkossa tarvittavia tietoja Päivitystiedot: henkilötietojen käyttötarkoitus, henkilötiedot on päivitetty (pvm), henkilötietojen päivittäjä Työnantajatiedot (HEN-lomakkeella vain työtapaturmissa): Työnantajan nimi, osoite, puhelin Lisätiedot alle 18-vuotiaasta: Kutsuma tai lempini, Päivähoitopaikka/neuvola/koulu ja luokka Laskutustiedot: kansalaisuus, syntymäkansalaisuus, onko opiskelija, työssäkäynti, ammatti, entinen ammatti, kotikunta, kuntaan muuttopäivä, henkikirjoituskunta, rekisteriviranomainen, entiset kotikunnat ja niihin muuttopäivät, väestövastuualue Ehdolla olevat kentät: Vakuutusyhtiötiedot: Vahinkopäivä, Vakuutusyhtiö, Vakuutustodistus on/ei Oppaan uudessa versiossa [Kan09] Potilaan perustietoihin: lisätty tietokentän Yhteyshenkilö alle: o tietokenttä Huoltaja/laillinen edustaja ja sen alle kentät Huoltajien välinen tehtävien jako Huoltajuussuhteen voimassaolo o tietokenttä Edunvalvoja ja sen alle kentät Edunvalvonnan alkamispäivämäärä Edunvalvonnan loppumispäivämäärä Edunvalvonnan tehtävien jako Edunvalvontatieto o Yhteyshenkilön laji -tietokenttä muutettu Yhteyshenkilön ensisijaisuus tietokentäksi lisätty uusi tietokenttä Turvakielto ja sen alle kentät o Alkupvm o Päättymispäivä lisätty uusi tietokenttä Työnantajan vakuutusyhtiö 5.1.1.2 Hoidon antajan tunnistetiedot Tämä tietokenttä sisältää tiedot palvelun antajasta (terveydenhuollon toimintayksikkö) sekä terveydenhuollossa toimivasta henkilöstä. Tietokenttää Hoidon antajan tunnistetiedot käytetään muissa ydintietojen tietokentissä, jos tällaista tietoa on tarve liittää potilasasiakirjoihin. Tätä tietokenttää voidaan hyödyntää, kun Pärjäimen tietoihin liitetään esim. tietoja tietojen alkuperästä. OmaHyvinvointi-hanke 24

Taulukko 3. Hoidon antajan tunnistetiedot. Ydintietojen tietokentät Kansalliset tietomäärittelyt on/ei Määrittely Ydintietomäärittelyisstä näille viitataan käytettäväksi Lähetteen ja hoitopalautteen CDA R2 rakennetta (uusin versio on 4.1, 4.2.2008) Hoidon antajan tarkat tunnistetiedot on CDA R2:ssa CDA R2 headerissa, CDA R2 bodyssa Hoidon antajan tunnistetiedot Palvelun antaja (terveydenhuollon toimintayksikkö) (/lomakkeissa) vain rajattu tietosisältö ja tarkat tiedot haetaan hetun perusteella headerista Kertomus ja lomakkeet: Terveydenhuollon ammattihenkilö ja laitos (palveluyksikkö) Organisaation yksilöintitunnus Kertomus ja lomakkeet: Terveydenhuollon ammattihenkilö ja laitos (palveluyksikkö) Nimi Haetaan CDA R2 headerista Erikoisala Haetaan CDA R2 headerista Terveydenhuollossa toimiva henkilö Kertomus ja lomakkeet: Terveydenhuollon ammattihenkilö ja laitos (palveluyksikkö) Nimi Haetaan CDA R2 headerista SV koodi / muun terveydenhuollon ammattilaisen yksilöinti Kertomus ja lomakkeet: Terveydenhuollon ammattihenkilö ja laitos (palveluyksikkö) Ammattikoodi ja luokitus Kertomus ja lomakkeet: Terveydenhuollon ammattihenkilö ja laitos (palveluyksikkö) Oppaan uudessa versiossa [Kan09]: Ei enää viittausta lähetteen ja hoitopalautteen CDA R2 rakenteeseen Palvelun antaja kentän nimi muutettu muotoon Palvelun toteuttaja Terveydenhuollossa toimiva henkilö kentän nimi muutettu muotoon Terveydenhuoltoa toteuttava henkilö 5.1.1.3 Palvelutapahtuman ja palvelukokonaisuuden tunnistetiedot Palvelutapahtuman ja palvelukokonaisuuden käsitteet pohjautuvat lakiin sosiaali- ja terveydenhuollon asiakastietojen sähköisestä käsittelystä. Näille käsitteille annetaan yksilöintitunnukset, joiden avulla potilasasiakirjat voidaan liittää niihin. [Kun07] Näistä tiedoista varsinkin palvelutapahtuma voisi toimia Pärjäimessä kokonaisuuden luojana tai tagina, johon voidaan liittää automaattisesti palvelutapahtumaan (kokonaisuuteen) liittyviä tietoja tai ne toimivat pohjana kansalaisen itsensä suorittamille kokonaisuuksien hallinnalle. Kansallinen palvelukokonaisuus on enemmän hallinnollista tarvetta varten luotu kokonaisuus. Taulukko 4. Palvelutapahtuman ja palvelukokonaisuuden tunnistetiedot. Ydintietojen tietokentät Kansalliset tietomäärittelyt on/ei Määrittely Palvelutapahtuman ja palvelukokonaisuuden tunnistetiedot Palvelukokonaisuuden tunnistetiedot Palvelukokonaisuuden nimi Palvelukokonaisuuden yksilöintitunnus Palvelukokonaisuuden luokitus (nimi ja koodi) Palvelutapahtuman tunnistetiedot Kertomus- ja lomakkeet dokumentissa on kuvattu oma rakenne palvelutapahtumille, jota käytetään kun viitataan toiseen palvelutapahtumaan. Meneillään olevan palvelukokonaisuuden ja -tapahtuman tiedot löytyvät CDA R2 headerista. CDA R2 Header v4.41: hl7fi:servicechainlink CDA R2 Header v4.41: hl7fi:servicechainlink CDA R2 Header v4.41: hl7fi:servicechainlink CDA R2 Header v4.41: hl7fi:servicechainlink CDA R2 Header v4.41: ClinicalDocument.componentOf CDA R2 Header v4.41: ClinicalDocument.componentOf CDA R2 Header v4.41: ClinicalDocument.componentOf Palvelutapahtuman nimi Palvelu- tai hoitotapahtuman tyyppi (Avohoitojakso, laitoshoitojakso) Palvelutapahtuman yksilöintitunnus CDA R2 Header v4.41: ClinicalDocument.componentOf Ajankohta CDA R2 Header v4.41: ClinicalDocument.componentOf Oppaan uudessa versiossa [Kan09]: Kentän Palvelukokonaisuuden tunnistetiedot alle tullut uusi kenttä Palvelukokonaisuuden ajankohta Kentän Palvelutapahtuman tunnistetiedot alta o poistettu kenttä Palvelutapahtuman nimi o muutettu kentän Palvelu- tai hoitotapahtuman tyyppi nimi muotoon Palvelutapahtuman tyyppi 5.1.1.4 Ongelmat ja diagnoosit Ydintietomäärittelyissä riskitiedoille on määritelty tietokenttään ongelmat ja diagnoosit oma rakenne, jolla eri riskitiedot voidaan välittää. Aiemmin riskitiedot olivat ydintietomäärittelyissä kukin omana sisältönään. Tällaisia riskitietoja olivat tuolloin mm. kriittiset riskitiedot (allergiat, lääkeai- 25 OmaHyvinvointi-hanke

neen aiheuttamat poikkeavat reaktiot, riskitaudit, keinoelimet/siirtoelimet/vierasesineet, muut riskit) sekä keskeiset hoidossa huomioitavat tiedot (edellisten lisäksi muita tarkempia tietoja). Tämä lisäksi ongelmat ja diagnoosit tietokentästä löytyy rakenteet hoidon syylle ja diagnooseille. Hoidon syy on tieto siitä, minkä vuoksi potilas hakeutui hoitoon. Hoidon syitä voi olla nolla, yksi tai useampia, ja ne voivat olla pää- tai sivusyitä. Diagnooseista kirjataan sekä pää- että sivudiagnoosit, joita molempia voi olla nolla, yksi tai useampia [Kun07]. Näistä keskeisimpiä Pärjäimen yhteydessä ovat diagnoosit ja riskitiedot. Sen sijaan hoidon syyn tarpeellisuutta voidaan harkita tarvitaanko sitä. Taulukko 5. Ongelmat ja diagnoosit. Ydintietojen tietokentät Kansalliset tietomäärittelyt on/ei Määrittely Ongelmat ja diagnoosit Riskitiedon aste (Kriittiset tiedot / Hoidossa huomioitavat tiedot) Kertomus ja lomakkeet: Riskitieto (RIS) Riskitiedon tyyppi Kertomus ja lomakkeet: RIS Riskin nimi tai kuvaus Kertomus ja lomakkeet: RIS Riskin koodiarvo ja käytetty koodisto/luokitus Kertomus ja lomakkeet: RIS Selite, riskin huomiointi potilaan hoidossa Kertomus ja lomakkeet: RIS Riskitietoon liittyvä tieto (esim lääkeaine) Kertomus ja lomakkeet: RIS Riskitietoon liittyvän tiedon koodaus ja koodisto (esim. lääkeaine) Kertomus ja lomakkeet: RIS Riskin pysyvyys Kertomus ja lomakkeet: RIS Riskin varmuusaste Kertomus ja lomakkeet: RIS Riskin vakavuus Kertomus ja lomakkeet: RIS Linkki kertomustekstiin jossa riski on todettu Kertomus ja lomakkeet: RIS/ Tiedon lähde Kertomus ja lomakkeet: RIS/Tiedonlähde Kertomus ja lomakkeet: Terveydenhuollon ammattihenkilö ja laitos (palveluyksikkö) Päiväys, riskitedon anto Kertomus ja lomakkeet: RIS Kertomus ja lomakkeet: Terveydenhuollon ammattihenkilö ja laitos (palveluyksikkö) Päiväys, riskitiedon poisto Kertomus ja lomakkeet: RIS Hoidon syy Pää ja sivu (0 - n) Nimi, hoidon syyn kuvaus?? Hoidon syyn koodi ja luokitus? ICD10/ ICPC / SHTaL? Ei ole kuvattu Kertomus ja lomakkeet diagnoosiluvussa tai erillisessä diagnoosilistan CDA R2 määrittelyssä. Otsikkotasolla siis voi näkyä otsikko "hoidon syy". Ydintietomäärittelyisstä näille viitataan käytettäväksi Diagnoosilistan CDA R2 rakennetta. Diagnoosi Kertomus- ja lomakkeet dokumentissa on kuvattu oma rakenne diagnooseille Pää ja sivudiagnoosit (0 - n) Kertomus ja lomakkeet: Diagnoosit Diagnoosin nimi Kertomus ja lomakkeet: Diagnoosit Diagnoosikoodi ja luokitus Kertomus ja lomakkeet: Diagnoosit Diagnoosin tila Kertomus ja lomakkeet: Diagnoosit Koodi, diagnoosin varmuusaste Kertomus ja lomakkeet: Diagnoosit Koodi, diagnoosin pysyvyys Kertomus ja lomakkeet: Diagnoosit Koodi, diagnoosin tyyppi Kertomus ja lomakkeet: Diagnoosit Diagnoosin episoditunnus Kertomus ja lomakkeet: Diagnoosit Tiedonlähde Kertomus ja lomakkeet: Diagnoosit/Tiedonlähde Kertomus ja lomakkeet: Terveydenhuollon ammattihenkilö ja laitos (palveluyksikkö) Päiväys, diagnoosin anto Kertomus ja lomakkeet: Diagnoosit Päiväys, diagnoosin päättyminen Kertomus ja lomakkeet: Diagnoosit Oppaan uudessa versiossa [Kan09]: Riskitiedoissa: o Kentän Riskitiedon aste tarkennuksessa tarkennettu jaottelua (Keskeiset hoidossa huomioitavat tiedot) o Kentän Riskin pysyvyys nimi muutettu muotoon Pysyvyys o Kentän Riskin varmuusaste nimi muutettu muotoon Varmuusaste o Kenttä Riskin vakavuus poistettu o Kentän nimi muutettu muotoon Terveydenhuoltoa toteuttava henkilö ja organisaatio Tietokentästä Hoidon syy poistettu kenttä Tietokentän Diagnoosi alla o lisätty kenttä Diagnoosin tarkenne o kentän Diagnoosin tila alla olevia nimiä muutettu Koodi, diagnoosin varmuusaste -> Koodi, varmuusaste Koodi, diagnoosin pysyvyys -> Koodi, pysyvyys o poistettu toinen kentistä OmaHyvinvointi-hanke 26

5.1.1.5 Terveyteen vaikuttavat tekijät Terveyteen vaikuttavat tekijät ovat tietoja, jotka kuvaavat henkilön terveyteen ja sairauteen liittyviä elintapoja ja elämäntilanteita kuten tupakointia tai päihteiden käyttöä. [Kun07]. Näille tiedoille ei ole vielä CDA R2-määrityksiä. Nämä tiedot voivat olla Pärjäimessä ylläpidettäviä mutta ei välttämättä esim. kertomusjärjestelmistä Pärjäimeen siirrettäviä. Taulukko 6. Terveyteen vaikuttavat tekijät. Ydintietojen tietokentät Kansalliset tietomäärittelyt on/ei Määrittely Terveyteen vaikuttavat tekijät? Näille ei ole CDA-määritystä Tupakointi? Fagerström 2-kohdan nikotiiniriippuvuustestin indeksiluku Päihteet? 10-kohdan alkoholi Audit-testin indeksiluku Liikunta? UKK liikkumisresepti Raskaus? kyllä/ei Ravitsemus? Oppaan uudessa versiossa [Kan09]: Kentän Tupakointi alle lisätty kentät o Tupakointialtistus o Tupakoinnin määrä o Nikotiiniriippuvuus 5.1.1.6 Fysiologiset mittaukset Fysiologiset mittaukset kuvaavat henkilön terveydentilaan liittyviä fysiologisia suureita kuten pituutta, painoa, verenpainetta, sykettä ja lämpöä. Tietoja tarvitsevat potilaan ajankohtaiseen hoitoon osallistuvat terveydenhuollon ammattilaiset. Tiedoista voidaan koota numeerisia ja graafisia listoja, jotka kuvaavat potilaan terveydentilaan liittyvän fysiologisen suureen kehitystä ajan myötä. [Kun07] Nämä tiedot voivat olla Pärjäimessä ylläpidettäviä (saadaan esim. suoraan mittalaitteista) mutta ei välttämättä esim. kertomusjärjestelmistä Pärjäimeen siirrettäviä. Taulukko 7. Fysiologiset mittaukset. Ydintietojen tietokentät Kansalliset tietomäärittelyt on/ei Määrittely Kertomus ja lomakkeet: Fysiologiset mittaukset (palvelukohtaiset kirjaukset). Fysiologiset mittaukset ilmaistaan rakenteisena Kertomus ja lomakkeet dokun luvussa Tutkimukset ja tulokset kuvatulla Fysiologiset mittaukset CDA R2 rakenteella. Mittauksen nimi Kertomus ja lomakkeet: Fysiologiset mittaukset/tutkimukset ja tulokset Mittauskoodi ja luokitus Kertomus ja lomakkeet: Fysiologiset mittaukset/tutkimukset ja tulokset Mittaustapa Kertomus ja lomakkeet: Fysiologiset mittaukset/tutkimukset ja tulokset Mittaustulos Kertomus ja lomakkeet: Fysiologiset mittaukset/tutkimukset ja tulokset Kertomus ja lomakkeet: Terveydenhuollon ammattihenkilö ja laitos (palveluyksikkö) Päiväys Kertomus ja lomakkeet: Terveydenhuollon ammattihenkilö ja laitos (palveluyksikkö) Oppaan uudessa versiossa [Kan09]: Kentän Mittauksen nimi alle lisätty kenttä Mittalaite Poistettu kenttä sekä Päiväys 27 OmaHyvinvointi-hanke