Hajautuneen potilastiedon hallinta

Hajautuneen potilastiedon hallinta Hanna Kopperi Seminaari HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Helsinki, 6. maaliskuuta 2016

HELSINGIN YLIOPISTO HELSINGFORS UNIVERSITET UNIVERSITY OF HELSINKI Tiedekunta Fakultet Faculty Laitos Institution Department Matemaattis-luonnontieteellinen Tekijä Författare Author Hanna Kopperi Työn nimi Arbetets titel Title Tietojenkäsittelytieteen laitos Hajautuneen potilastiedon hallinta Oppiaine Läroämne Subject Tietojenkäsittelytiede Työn laji Arbetets art Level Aika Datum Month and year Sivumäärä Sidoantal Number of pages Seminaari 6. maaliskuuta 2016 12 Tiivistelmä Referat Abstract IHE XDS on yksi IHE:n kehittelemistä profiileista [Nou11], jossa käytetään hyödyksi ebxml rekisteristandardia (ISO 15000 osat 3 ja 4) [Ben12], tietojen vaihtoon SOAP:aa ja HTTP:aa ja tietojen hakuun SQL kieltä [Ben12, PP14]. IHE XDS mahdollistaa dokumenttien tallentamisen, jakamisen ja hallinnan yhdessä toimivien samat toimintatavat hyväksyneiden terveydenhuollon organisaatioiden välillä [Ben12]. Tällaiset yhdessä toimivat ja terveydenhuollon dokumentteja jakavat terveydenhuollon organisaatiot muodostavat joukon, jota IHE XDS terminologissa kutsutaan kliinisesti yhteneväksi toimialueeksi (clinical affinity domain) [DLA07, PP14]. IHE XDS tarjoaa hajautetun lähestymistavan kliinisten dokumenttien jakamiseen sen sijaan, että kaikki tieto yritettäisiin koota yhteen suureen tietokantaan [Ben12] Avainsanat Nyckelord Keywords IHE, IHE XDS Säilytyspaikka Förvaringsställe Where deposited Muita tietoja Övriga uppgifter Additional information

Sisältö 1 Johdanto 1 2 Integrating the Healthcare Enterprise (IHE) 1 2.1 IHE profiili............................ 2 3 IHE Cross-Enterprise Document Sharing (IHE XDS, IHE XDS.b) 2 3.1 IHE XDS arkkitehtuuri..................... 3 3.2 ebxml ja XDS.......................... 4 3.3 XDS metadata.......................... 5 3.4 Transaktiot............................ 7 3.5 XDS dokumentti, XDS kansio ja XDS kokoelma....... 7 4 Turvallisuus 8 5 Laajennukset 9 5.1 Cross-Enterprise Sharing for Imaging (XDS-I, XDS-I.b)... 9 5.2 Cross-Enterprise Sharing of Medical Summary (XDS-MS).. 9 6 Käyttö maailmalla 9 7 Yhteenveto 10 Lähteet 11 ii

1 Johdanto Terveydenhuollon toimialalla yksi suurimmista ongelmista on potilastietojen pirstaloituminen [Ben12] ja kykenemättömyys niiden toimivaan jakamiseen yritysten välillä [DLA07]. Koska potilastiedot ovat pääasiassa hajanaisesti useiden terveydenhuollon palveluita tarjoavien organisaatioiden järjestelmissä, on edellä kuvattujen ongelmien takia erittäin vaikeaa saada kokonaiskuvaa yhden potilaan potilashistoriasta. Pirstaloitumisesta aiheutuu myös turhaa työtä ja vaivaa niin sairaaloiden henkilökunnalle kuin potilaallekin, joka olettaa omien tietojensa seuraavan mukanaan sairaalasta toiseen. Lisäksi yhteentoimivuutta vaikeuttaa se, että kliinisen tiedon esittämiseen käytetään terveydenhuollon järjestelmissä useita erilaisia standardeja, joista esimerkkinä HL7 CDA ja openehr [DLA07]. Tähän ongelmaan on haettu ratkaisua Integrating the Healthcare Enterprise (IHE) organisaation kehittelemällä Cross-Enterprise Document Sharing (XDS) profiililla, joka muodostaa viitekehyksen alueellisten ja kansallisten potilastietojärjestelmien kehittämiselle [Nou11]. Profiili tarjoaa hajautetun lähestymistavan dokumenttien jakamiseen eri terveydenhuollon palveluita tarjoavien osapuolten välille. Profiilissa jokainen taho arkistoi omat dokumenttinsa käytettäviksi yhteisen rekisterin kautta yhden ison tietokannan sijaan. Tässä seminaarityössä esitellään lyhyesti IHE organisaatio, mihin sen toiminta perustuu ja miten organisaatio pyrkii ratkaisemaan terveydenhuollon informaatio-ongelmia kehittämällä ongelmiin vastaavanlaisia profiileja kuin XDS. Keskeisimpänä aiheena työssä on IHE XDS profiili ja sen rakenne. Työ rakentuu siten, että kappaleessa kaksi käsitellään IHE organisaatiota ja esitellään kuinka XDS:n kaltaiset profiilit kehitetään. Kappaleessa kolme esitellään mistä XDS profiili koostuu. Kappaleessa neljä kerrotaan miten turvallisuus tulee ottaa huomioon IHE XDS profiilia käytettäessä. Kappale viisi esittelee pintapuolisesti kaksi XDS profiilin laajennusta ja kappaleessa kuusi kerrotaan lyhyesti, miten käytetty XDS profiilia käytetään maailmalla. Kappaleeseen seitsemän on koottu tekstin yhteenveto. 2 Integrating the Healthcare Enterprise (IHE) IHE:n perusti vuonna 1999 Healthcare Information Systems and Management Society (HIMSS) ja Radiological Society of North America (RSNA) [Be12] ja sen tarkoitus on kehittää terveydenhuollon järjestelmien tietojen jakamista [Wit14]. IHE:n työ pohjautuu olemassa olevien standardien runsauteen [Wit14]. Vuosittain IHE kokoaa terveydenhuollon alan asiantuntijoita ja yhteistyökumppaneitaan ympäri maailmaa tapaamiseen, jossa selvitetään mihin terveydenhuollon informaatio-ongelmiin organisaation tulisi erityisesti keskittyä. Tapaamisessa osapuolet esittelevät ensin käyttötapauksia jotka an- 1

tavat yleiskuvan tiedon jakamiseen liittyvistä ongelmista ja lopuksi valitaan yksi käyttötapaus, johon IHE alkaa kehittää ratkaisua. Ratkaisun työstäminen etenee tunnistamalla ensin, mitä olemassa olevia standardeja ratkaisussa voitaisiin hyödyntää ja sen jälkeen selvittämällä kuinka standardeja tulisi käyttää ongelmatilanteen ratkaisemiseksi. Kun tekniset asiantuntija ovat saaneet kehitettyä ratkaisun, teollisuuden toimijat tekevät siitä konkreettisia toteutuksia omiin terveydenhuollon järjestelmiinsä [Be12, Wit14]. Näiden toteutuksien toimivuutta testataan IHE:n ympäri maailmaa järjestämissä IHE Connectathon tapahtumissa. Lopulta teollisuuden toimijat julkaisevat lausuntonsa ratkaisun toimivuudesta omissa järjestelmissään [Be12]. 2.1 IHE profiili IHE:n kehittämiä ratkaisuja kutsutaan IHE profiileiksi [Wit14]. IHE profiili on määritelmä, jossa on eriteltyinä ongelmatilanteen kuvaava käyttötapaus, ratkaisuun valitut standardit ja yksityiskohtainen kuvaus siitä kuinka standardeja käytetään käyttötilanteen saavuttamiseksi. IHE kuuluu standardeja kehitteleviin organisaatioihin (Standards Development Organization, SDO) ja noudattaa näille tyypillisiä periaatteita, joten profiilit eivät esimerkiksi sisällä tarkkaa kuvausta siitä, miten järjestelmä tulee toteuttaa jotta se noudattaisi profiilia. Tällä tavalla annetaan profiilia toteuttavalle taholle mahdollisuus määritellä itse esimerkiksi järjestelmän laatuvaatimukset, kuten skaalautuvuus ja luotettavuus, ja tarvittavat järjestelmä kohtaiset ominaisuudet. Tämän lisäksi IHE profiileissa otetaan huomioon monissa maissa eroavat toimintatavat ja käytännöt suunnittelemalla profiileista neutraaleja erilaisten käytäntöjen suhteen ja antamalla tuki erilaisten hallinnollisten variaatioiden käytölle. 3 IHE Cross-Enterprise Document Sharing (IHE XDS, IHE XDS.b) IHE XDS on yksi IHE:n kehittelemistä profiileista [Nou11], jossa käytetään hyödyksi ebxml rekisteristandardia (ISO 15000 osat 3 ja 4) [Ben12], tietojen vaihtoon SOAP:aa ja HTTP:aa ja tietojen hakuun SQL kieltä [Ben12, PP14]. IHE XDS mahdollistaa dokumenttien tallentamisen, jakamisen ja hallinnan yhdessä toimivien js samat toimintatavat hyväksyneiden terveydenhuollon organisaatioiden välillä [Ben12]. Tällaiset yhdessä toimivat ja dokumentteja jakavat terveydenhuollon organisaatiot muodostavat joukon, jota IHE XDS terminologissa kutsutaan kliinisesti yhteneväksi toimialueeksi (clinical affinity domain) [DLA07, PP14]. IHE XDS tarjoaa hajautetun lähestymistavan kliinisten dokumenttien jakamiseen sen sijaan, että kaikki tieto yritettäisiin koota yhteen suureen tietokantaan [Ben12]. 2

3.1 IHE XDS arkkitehtuuri IHE XDS muodostuu viidestä toimijasta, joita ovat rekisteri, tietovarasto, dokumenttien tuottaja, dokumenttien hyödyntäjä sekä potilaiden tunnistamiseen käytettävä potilasidentiteettien lähde (patient identity source) [Ben12, Nou11]. Kuvassa 1 näkyy XDS arkkitehtuurin perusrakenne ja sen toimijoiden yhteydet. Rekisteri sisältää metadataa eli kuvaavia tietoja kaikista luoduista dokumenteista [Nou11] ja URI linkit kaikkien näiden todellisiin sijainteihin [PP14]. Sen tehtävä on vastata dokumenttien hyödyntäjien lähettämiin kyselyihin palauttaen kyselyiden kriteerit täyttävien dokumenttien URI linkit. Rekisteri ei siis säilö dokumentteja, vaan sen tehtävä on indeksoida ne [Ben12, Nou11]. Dokumenttien arkistointivastuu on tietovarastolla [Nou11]. Yhteen rekisteriin voi olla yhteydessä useita tietovarastoja [Ben12]. Tietoturvan parantamiseksi rekisterillä ei ole minkäänlaista pääsyä dokumenttien sisältöihin, vaan se vastaa kyselyihin sisältämiensä dokumenttien metadatan perusteella. Kuva 1: XDS:n toimijat ja niiden yhteydet toisiinsa [Ben12, MDW11, Nou11, PP14] Tietovarastot tarjoavat siis pysyviä säilöjä dokumenteille [Ben12]. Jokaisella dokumenttien tuottajalla voi olla oma tietovarasto, johon se arkistoi omat dokumenttinsa. Uusi dokumentti tallentuu tietovarastoon siinä vaiheessa, kun dokumenttien tuottaja kuten laboratorion, kardiologian tai radiologian raportointijärjestelmä julkaisee uuden dokumentin ja lähettää sen ja siihen liittyvää metadataa tietovarastolle [Ben12, Nou11]. Tämä dokumentti voi olla esimerkiksi kuva, kirje tai tutkimustulokset [Ben12]. Kun dokumentti tallennetaan tietovarastoon, tietovarasto laskee muun muassa dokumentin tarkisteen (hash) ja koon ja toimittaa lopulta talletettuun dokumenttiin liittyvän metadatan rekisterille rekisteröitäväksi. Dokumenttien hyödyntäjä 3

lähettää potilaisiin perustuvia kyselyjä rekisterille ja saa vastineeksi tiedon tarvitsemiensa dokumenttien sijainnista [Ben12]. Sijaintitietojen perusteella hyödyntäjä pystyy hakemaan dokumentit tietovarastoista ja lukemaan niitä selaimellaan. Potilasidentiteettien lähdettä tarvitaan silloin, kun yhdessä toimivien terveydenhuollon organisaatioiden sisällä käytetään eri tunnuksia potilaiden tunnistamiseen [Ben12]. Koska jokaisella potilaalla tulee olla yksi yksikäsitteinen tunniste yhtenevän toimialueen sisällä [Ben12], jokaiselle potilaalle luodaan oma XAD-PID tunnus (XDS affinity domain patient identifier) [MDW11]. Potilaasta käytettävä tunnus on ainoa luotettava tieto dokumenttikohtaisessa metadatassa, jonka avulla pystytään hakemaan potilaskohtaisia dokumentteja [Nou11], sillä usea potilas voi jakaa esimerkiksi saman nimen ja syntymäajan. XAD-PID tunnuksen avulla dokumenttien tuottajat voivat julkaista dokumentteja tietovarastossaan ja dokumenttien hyödyntäjät voivat suorittaa kyselyitä rekisteriin [MDW11, Nou11]. Käytettäessä XAD-PID tunnusta, rekisterin tulee potilasidentiteettien lähdettä käyttäen tarkistaa ennen metadatan rekisteröimistä metadatassa olevan tunnuksen oikeellisuus ja voimassa olo, ja että rekisteröitävä dokumentti todella kuuluu tunnuksen osoittamalle henkilölle. Potilasidentiteettien lähteenä toimii useimmiten palvelin, joka tukee IHE PIX profiilia tai IHE PDQ profiilia [Ben12]. Palvelimen tehtävä on tarjota dokumenttien tuottajalle ja dokumenttien hyödyntäjälle yksinkertainen tapa selvittää lokaalia potilastunnusta vastaava XAD-PID [MDW11]. PIX (patien identity cross-referenving) profiilia käytettäessä palvelin vastaanottaa potilaan tunnuksen sisältäviä henkilötietoja useilta eri organisaatioilta, ja muodostaa tiedoista vertailutaulukon, jossa näkyy kaikki tietoihin täsmäävät potilaat [Wit14]. PDQ (patient demographics query) profiilia käytettäessä palvelimelle lähetetään rajoitettu määrä haettavan potilaan henkilötietoja ja vastineeksi saadaan lista tietoihin täsmäävistä potilaista. 3.2 ebxml ja XDS IHE XDS:n arkkitehtuuri on erikoistettu versio ebxml rekisteristandardin (ISO 1500 osat 3 ja 4) arkkitehtuurimallista [Ben12, Nou11], joka perustuu rekisterin ja tietovaraston käyttöön [DLA07]. Tietovarasto on paikka, jossa rekisterin osoittama dokumentti sijaitsee ja josta se voidaan noutaa tarvittaessa. Tietovarasto on kykenevä tallentamaan kaiken tyyppistä sisältöä, kun taas rekisteriin tallennetaan metadataa, joka kuvailee sisällön. ebxml rekisteri-informaatiomalli (ISO 15000-3:2004, ebxml RIM) määrittelee rekisteriin tallennettavat objektit ja kuvaa kuinka nämä tulee järjestää [Ben12, DLA07]. Kuvassa 2 näkyy ebxml RIM:in käsitteiden hierarkkinen rakenne. Ylimmällä tasolla oleva luokka RegistryObject tuottaa pienimmän tarvittavan määrän metadataa rekisteriin tallennettavalla objektille [PP14]. Muiden luokkien ilmentymät mahdollistavat dynaamisen tavan lisätä 4

omavalintaisia attribuutteja luokan RegistryObject ilmentymälle. Kuva 2: ebxml rekisteri-informaatiomallin hierarkkinen rakenne [PP14] 3.3 XDS metadata Kun terveydenhuollon organisaatiot päättävät käyttää IHE XDS:n tarjoamaa ratkaisua tietojen jakamiseen ja muodostavat yhtenevän toimialueen, yksi organisaatioiden tehtävistä on määritellä sallitut arvojoukot dokumentista rekisteröitävän tiedon eli metadatan elementeille [Ben12]. IHE XDS tarjoaa ennalta määritellyn joukon dokumentin metadatan elementtejä [DLA07], jotka voidaan jakaa aiheen mukaan dokumenttiin, potilaaseen, dokumentin laatijaan, tapahtumaan ja teknisiin tietoihin liittyviin elementteihin [Ben12]. Nämä metadatan elementit on lueteltu kuvassa 3, jossa elementit on lajiteltu ne määrittelevän toimijan mukaan. Osa metadatan elementtien arvoista on tavallisesti ihmiselle luettavassa muodossa kuten dokumentin otsikko (title) ja potilaan väestötiedot (sourcepatientinfo), joita ovat potilaan nimi, sukupuoli ja syntymäaika [Ben12]. Joidenkin elementtien arvojoukkona käytetään jotakin termistöä kuten SNOMED CT:tä tai LOINC:ia. Tällaisia elementtejä ovat muun muassa dokumentin luokkakoodi (classcode) ja tyyppikoodi (typecode) joiden avulla määritellään, minkälaisesta dokumentista on kyse. Dokumentti voi olla esimerkiksi resepti, kotiutusmääräys tai raportti. Elementtien joukkoon sisältyy useita eri tunnuksia. Näitä ovat esimerkiksi dokumentin tunnus (uniqueid), jolla kyseiseen dokumenttiin voidaan viitata muista dokumenteista, potilaan tunnus (patientid), jolla potilas tunnistetaan rekisterissä, yhtenevän toimialueen tunnus (homecommunityid) ja tietovaraston tunnus (repositoryuniqueid) [Ben12]. Osa tunnuksista, kuten dokumentin tunnus ja pelkästään rekisterissä käytettävä dokumentin tunnus (entryuuid), ovat yleismaallisesti uniikkeja tunnuksia (universally unique identifiers, UUID) ja osa, kuten yhtenevän toimialueen tunnus ja tietovaraston tunnus, ovat objektin tunnuksia (object identifier, OID) [B12, Ben12]. 5

UUID:t ovat ohjelmiston käytön aikana luomia uniikkeja tunnuksia, joita käytetään yleensä silloin kun tunnusta ei laadi ihminen [B12]. OID:t ovat tunnuksia, joiden avulla objekteja tunnistetaan tietyn rekisterin sisällä ja tunnukset ovat uniikkeja vain kyseisessä rekisterissä. Kuva 3: IHE XDS metadatan ennaltamääritellyt elementit [Ben12] Dokumentin metadatan rekisteröiminen rekisteriin on normaalisti täysin automatisoitu prosessi, joten rekisteriin tallennettua metadataa on hyvin epäkäytännöllistä ja usein jopa mahdotonta muokata [Ben12]. Tämän takia on otettava huomioon, että dokumentin tuottajan ja tietovaraston tulee koota tarvittavat tiedot dokumentista ennen metadatan rekisteröimistä. 6

3.4 Transaktiot XDS:ssä käytetään yleisimmin viittä erilaista transakstiota eli tapahtumaa [IHE9/15]. Dokumenttien tuottaja käynnistää Provide and Register Document Set-transaktion itsensä ja tietovaraston välille aloittaakseen dokumentin julkaisemisprosessin. Kun tietovarasto on vastaanottanut tallennettavat dokumentit, joita voi olla yksi tai useampi, se käyttää Register Document Set-transaktiota välittääkseen dokumenttien metadatan rekisterille rekisteröitäväksi. Ennen rekisteröimistä rekisteri varmistaa dokumenttien metadatan oikeellisuuden ja, jos rekisteri ei onnistu validoimaan yhden tai useamman dokumentin metadataa, transaktio epäonnistuu. Päästäkseen käsiksi tarvitsemiinsa dokumentteihin dokumenttien hyödyntäjä käyttää Registry Stored Query-transaktiota rekisteriin. Rekisteri etsii kyselyn kriteereihin täsmäävien dokumenttien tallennetut metadatat ja palauttaa listan löydettyjen dokumenttien sijainneita ja tunnisteista. Vastaanottamiaan tietoja käyttäen dokumenttien hyödyntäjä suorittaa Retrieve Document Set-transaktion kohdistaen sen dokumentin sisältävään tietovarastoon. Vastineeksi tietovarasto lähettää dokumenttien hyödyntäjälle transaktiossa määritellyn dokumentin. Patient Identity Feed-transaktio välittää potilaan tunnisteen ja potilaan väestötiedot potilasidentieteettien lähteeltä rekisterille [Nou11]. Tätä käytetään silloin, kun potilaille luodaan tunnisteita tai kun tunnisteita muokataan tai yhdistellään [IHE9/15]. Lisäksi transaktiota käytetään silloin, jos potilaan väestötiedot muuttuvat. Patient Identity Feed-transaktion tarkoituksena on pitää rekisterissä olevien potiladen tunnukset ajantasalla. 3.5 XDS dokumentti, XDS kansio ja XDS kokoelma XDS:ssä yksittäinen dokumentti on pienin tietoalkio, jonka tietovarasto arkistoi ja jonka metadata rekisteröidään rekisteriin [IHE9/15]. Dokumentti on kooste kliinisestä informaatiosta ja siltä vaaditaan HL7 CDA (Health Level Seven Clinival Document Architecture) määritelmän mukaiset ominaisuudet, joita ovat muun muassa pysyvyys (persistence) ja täydellisyys (wholeness). Dokumentti voi olla joko ihmisen tai järjestelmän luettavissa. XDS ei määrittele missä muodossa dokumentin sisällön tulisi olla. Tämän takia sisältö voi muodostua vapaasta tekstistä, muotoiltusta tekstistä (HL7 CDA taso 1), kuvista (DICOM) tai rakenteellisesta osasta, jossa on käytetty jotakin termistöä (HL7 CDA taso 2, CCR). XDS:ssä ei ole mahdollista päästä käsiksi vain osaan dokumentin sisältöä, vaan dokumentteja käsitellään kokonaisuuksina. XDS kansioiden avulla dokumenttien tuottajat voivat ryhmitellä dokumentteja haluamallaan tavalla ja dokumenttien hyödyntäjät löytävät yhdestä paikasta tarvitsemiensa dokumenttien sijainnit [IHE9/15]. Kansiot ovat pysyviä tallenteita joita luovat dokumenttien tuottajat. Kun kansio on kerran 7

luotu, se on rekisterin tiedossa ja sen sisältöön voidaan kohdistaa kyselyitä. XDS:ssä kansiot eivät voi olla sisäkkäisiä ja jokaisella kansiolla tulee olla uniikki tunniste. Sama dokumentti voi sisältyä useaan eri kansioon. XDS kokoelma (submission set) on pysyvä tallenne, ja se luodaan aina kun suoritetaan esityspyyntö (submisson request) [IHE9/15]. Esityspyyntöjä on kahdenlaisia, joista ensimmäinen on dokumenttien tuottajan lähettämä Provide and Register Document Set-transaktio tietovarastolle. Toinen esityspyyntö on tietovaraston lähettämä Register Document Set-transaktio rekisterille. Jokainen esityspyyntö sisältää informaatiota, jonka avulla XDS dokumentti saadaan rekisteröityä asianmukaisesti. Tämä informaatio koostuu muun muassa dokumentin metadatasta ja kokoelmasta, joka sisältää listan kaikista uusista julkaistavista dokumenteista ja kansioista ja mahdollisesti myös listan aiemmin julkaistuista dokumenteista. Koska kokoelmaan voidaan liittää tieto myös aiemmin julkaistuista dokumenteista, saadaan helposti yhdistettyä kaikki dokumentit, jotka liittyvät olennaisesti potilaan sen hetkiseen hoitoon. Dokumenttien hyödyntäjät voivat suorittaa rekisterille kyselyjä, joilla haetaan kaikki tiettyyn kokoelmaan liittyvät dokumentit. 4 Turvallisuus Yhtenevään toimialueeseen voi kuulua useita terveydenhuollon palveluita tarjoavia organisaatioita, jolloin turvallisuus- ja yksityisyyskäytäntöjen koordinointi voi olla haastavaa [IHE9/15]. Tämän lisäksi hajautetusti toimiva järjestelmä on aina haavoittuvaisempi hyökkäyksille kuin keskitetty järjestelmä, koska keskitetyn järjestelmän ympärille on helpompi rakentaa suojamuurit [Ben12]. Turvallisuuden takaavien käytäntöjen ylläpitäminen vaatii organisaatioilta hyvää yhteistyötä, sillä esimerkiksi yhden organisaation yhtiömuutokset voivat vaikuttaa yhteisiin käytäntöihin, jolloin kaikkien osapuolten on voitava ottaa tarvittavat muutokset huomioon [IHE9/15]. Turvallisuuskäytäntöjen hoitaminen ei siis ole vain kertaluonteinen tapahtuma, vaan vaatii osapuolilta pitkäaikaista aktiivisuutta. IHE XDS profiili ei ota kantaa turvallisuus- ja yksityisyyskäytäntöihin [IHE9/15]. Tämä johtuu siitä, että käytäntöjen toteutukset riippuvat pitkälti lainopillisista asioista sekä terveydenhuollon järjestelmien tyypeistä. XDS pyrkii tarjoamaan mahdollisimman joustavat lähtökohdat käytäntöjen toteutukselle. Lisäksi turvallisuus- ja yksityisuuskäytännöistä tehtävät päätökset saattavat myös vaikuttaa jonkin verran XDS:n toimijoiden toteutukseen, minkä vuoksi on yksinkertaisempaa jättää toteuttajille valinnanvapaus tarvittavien käytäntöjen toteutuksesta. IHE on kehittänyt erilaisia turvallisuutta käsitteleviä profiileja, joita ovat esimerkiksi ATNA (Audit Trail and Node Authentication), BPPC (Basic Patient Privacy Consent), DSG (Document Digital Signature), EUA (Enterprise User Authetication) ja XUA (Cross- Enterprise User Assertion) [Ben12]. 8

5 Laajennukset IHE XDS profiilin rinnalle on kehitetty erikoistetut profiilit esimerkiksi kuvantamista (imaging) [IHE7/15] ja lääketieteellisiä yhteenvetoja (medical summaries) varten [IHE14]. Seuraavissa kappaleissa esitellään lyhyesti nämä profiilit. 5.1 Cross-Enterprise Sharing for Imaging (XDS-I, XDS-I.b) XDS-I profiili laajentaa ja erikoistaa XDS profiilin mekanismeja tukemaan kuvantamisen dokumentaatiota, johon kuuluu muun muassa eri tekniikoilla otettuja kuvia sisältäviä tutkimuksia, analyysien tuloksia ja lausuntoja [IHE7/15]. Profiilissa määritellään käsiteltävien dokumenttien tyypit ja tarvittavat transaktiot kuvien julkaisemiseen, rekisteröimiseen ja noutamiseen. XDS-I ei aseta uusia vaatimuksia XDS profiilin määrittelmille toimijoille. 5.2 Cross-Enterprise Sharing of Medical Summary (XDS- MS) Lääketieteelliset yhteenvedot ovat kliinisiä dokumentteja, joissa on koottuna tärkein tieto sähköisistä sairauskertomuksista (electronic medical record, EMR) ja lisäksi dokumentin luomishetkellä kirjoitettu vapaamuotoinen yhteenveto [IHE14]. Yhteenveto luodaan yleisimmin siinä vaiheessa, kun potilaan tilannetietoa päivitetään esimerkiksi kirjaamalla potilaalle lähete toiselle lääkärille tai kotiuttamalla potilas ja lähettämällä potilaan tiedot kirjattavaksi laskutusta varten. XDS-MS profiili on XDS profiilin erikoistettu versio [Ben12] ja määrittelee tarvittavat standardit lääketieteellisten yhteenvetojen välitykseen sekä pienimmän pakollisen tietojoukon, joka tulee välittää yhteenvedossa eteenpäin [IHE14]. Näiden lisäksi profiili määrittelee yhteenvetojen vastaanottajalle vaatimukset, jotka varmistavat lähettäjän lähettämän yhteenvedon kontekstin asianmukaisen säilytyksen. 6 Käyttö maailmalla Kanadassa ja USA:ssa on otettu käyttöön useita XDS profiiliin perustuvia projekteja ja kumpikin maa on valinnut XDS:n dokumenttien jakamisen standardiksi [Nou11]. Myös Euroopassa, Kiinassa ja Japanissa on otettu käyttöön profiiliin perustuvia projekteja. Esimerkiksi Hollannissa laki kieltää potilastietojen keräämisen yhteen paikkaan, minkä takia tiedon jakamiseen on kehitetty IHE XDS profiilin tarjoamaa arkkitehtuuria vastaava kansallinen AORTA-järjestelmä [Spr08]. Suomessa tietoisuus IHE:n tarjoamista tiedonjakoon perustuvista profiileista ei ole vielä kovin mittavaa [Myk08]. IHE XDS profiilia ei Suomessa vielä käytetä sellaisenaan hyödyksi tietojen jakamisessa. 9

7 Yhteenveto IHE on terveydenhuollon tietojen jakamista parantamaan perustettu organisaatio, joka perustaa työnsä olemassa oleviin standardeihin. Se kokoaa vuosittain asiantuntijoita ympäri maailmaa tapaamiseen, jossa pyritään selvittämään, mihin terveydenhuollon informaatio-ongelmiin organisaation tulisi erityisesti keskittyä. Ratkaisuiksi IHE kehitelee IHE profiileja, joissa määritellään ratkaisussa käytettävät standardit ja kuinka niitä tulisi käyttää. Profiilien toteutuksia testataan ympäri maailmaa järjestettävissä IHE Connectathon tapahtumissa, joiden perusteella toteutuksien kehittäjät julkaisevat lausuntonsa profiilien toimivuudesta omissa järjestelmissään. IHE:n kehittämän IHE XDS profiilin tarkoitus on parantaa tiedon välitystä yhtenevään toimialueeseen kuuluvien terveydenhuollon palveluita tarjoavien organisaatioiden välillä. Profiili perustuu hajautettuun ratkaisuun, jossa jokainen organisaatio omalla tahollaan ylläpitää dokumenttien arkistointia ja dokumentteihin päästään käsiksi yhteisen rekisterin kautta. Organisaatiot, jotka ovat päättäneet toimia yhteistyössä ja muodostaneet yhtenevän toimialueen, ovat sopineet yhteisistä toimintatavoista ja käytännöistä. Tällaisia ovat esimerkiksi dokumenteista rekisteriin tallennettavien metadatatietojen elementtien arvojoukot. XDS profiili jättää metadatan arvojoukkojen määrittelyn lisäksi monia ohjelmistokehityksessä huomioon otettavia asioita, kuten turvallisuudesta ja yksityisyydestä huolehtimisen, toteuttajalle. Tämä johtuu siitä, että IHE haluaa tarjota järjestelmältä vaadittavien käytäntöjen ja toimintatapojen osalta mahdollisimman neutraalin viitekehyksen, jota on helppo soveltaa eri lähtökohdista. XDS profiilia käytetään laajalti eri puolilla maailmaa, mutta se ei ole muiden IHE:n kehittelemien profiilien lailla kovin tunnettu Suomessa. IHE XDS profiilin rinnalle on kehitetty muutamia sitä laajentavia ja erikoistavia profiileja, joista tekstissä esiteltiin esimerkkinä XDS-I ja XDS-MS. Pelkästään näillä profiileilla ei kuitenkaan saada rakennettua toimivaa ja kaikki käyttötilanteet huomioon ottavaa järjestelmää, sillä niiden tarkoituksena ei ole yksin ratkaista kaikkia dokumenttien jaon tarpeita [IHE7/15]. IHE on kehittänyt ja kehittää jatkuvasti lisää profiileja, joilla pyritään ratkaisemaan tietojen jakamiseen liittyviä ongelmia. Olemassa olevia profiileja ovat esimerkiksi IHE PIX ja IHE PDQ, joita käytetään hyödyksi potilaiden identiteettien selvittämisessä. Lisäksi IHE on kehittänyt esimerkiksi erilaisia profiileja turvallisuuden ja yksityisyyden takaamiseksi, joita voidaan hyödyntää XDS-profiilin yhteydessä. 10

Lähteet [B12] T. Benson. The HL7 V3 RIM. Teoksessa Principles of Health Interoperability HL7 and SNOMED, T. Benson, toim. Springer London, 2012, sivut 121 141. [Be12] T.Benson. Standards Development Organizations Healthcare. Teoksessa Principles of Health Interoperability HL7 and SNOMED, T. Benson, toim. Springer London, 2012, sivut 83 98. [Ben12] T. Benson. IHE XDS. Teoksessa Principles of Health Interoperability HL7 and SNOMED, T. Benson, toim. Springer London, 2012, sivut 187 198. [DLA07] A. Dogac, G.B. Laleci, T. Aden ja M. Eichelberg. Enhancing IHE XDS for Federated Clinical Affinity Domain Support. IEEE Transactions on Information Technology in Biomedicine, 11, 2 (2007), sivut 213 221. [IHE14] IHE. IHE Patient Care Coordination (PCC) Technical Framework, Volume 1 (IHE PCC TF-1): Integration Profiles. 2014, http://www.ihe.net/uploadedfiles/documents/pcc/ihe_pcc_tf_vol1.pdf (1.3.2016). [IHE7/15] IHE. IHE Radiology (RAD) Technical Framework, Volume 1 (IHE RAD TF-1): Integration Profiles. 2015, http://www.ihe.net/uploadedfiles/documents/radiology/ihe_rad_tf_vol1.pdf (1.3.2016). [IHE9/15] IHE. IHE IT Infrastructure (ITI) Technical Framework, Volume 1 (ITI TF-1): Integration Profiles. 2015, http://www.ihe.net/uploadedfiles/documents/iti/ihe_iti_tf_vol1.pdf (29.2.2016). [MDW11] J. Mussi, N. Domeij, K. Wiiting ja C. Parisot. IHE IT Infrastructure White Paper XDS Patient Identity Management. 2011, http://www.ihe.net/technical_framework/upload/ihe_iti_whitepaper_ Patient_ID_Management_Rev2-0_2011-03-04.pdf (22.2.2016). [Myk08] J. Mykkänen. IHE - Integrating the Healthcare Enterprise Suomessa - missä mennään? 2008, http://www.hl7.fi/wp-content/uploads/ihe-jm- 081114.pdf (2.3.2016). [Nou11] R. Noumeir. Sharing medical records: The XDS architecture and communication infrastructure. IT Professional, 13, 4 (2011), sivut 46 51. [PP14] J. Puustjärvi ja L. Puustjärvi. Using Ontology-Based Registry and SPARQL Engine in Searching Patient s Clinical Documents. BIOSTEC 11

2014, Proc. of 7th Internat. Joint Conf. on Biomedical Engineering Systems and Technologies, 2014, sivut 151 158. [Spr08] R. Spronk. AORTA, the Dutch national infrastructure. 2008, http://www.ringholm.com/docs/00980_en.htm (2.3.2016). [Wit14] K. Witting. Health Information Exchange: Integrating the Healthcare Enterprise (IHE). Teoksessa Introduction to Nursing Informatics, K.J. Hannah, P. Hussey, M.A. Kennedy ja M.J. Ball, toim. Springer, 2014, sivut 79 96. 12