Sosiaalihuollon viestinvälitys

Transkriptio

1 Sosiaalihuollon viestinvälitys Vaatimukset, perusratkaisut ja HL7 Medical Records -sanomien soveltuvuusarviointi SOSIAALIALAN TIETOTEKNOLOGIAHANKE SOSIAALI- JA TERVEYSMINISTERIÖ Kuopion Yliopisto Itä-Suomen sosiaalialan osaamiskeskus ISO Tekijät Marko Suhonen, Esa Paakkanen, Teppo Taskinen, Juha Mykkänen, Jani Komulainen Dokumentin versio 1.1 Päiväys

2 Sisällysluettelo 1 Johdanto Työn tavoitteet ja rajaukset Keskeiset käsitteet Dokumentin rakenne Viestinvälityksen osapuolet ja vaatimukset Viestinvälityksen osapuolet Tiedon tuottajat Tiedon käyttäjät Arkistopalvelu Viestinvälityksen vaatimukset Toiminnalliset vaatimukset Arkkitehtuurivaatimukset Tietoturvavaatimukset Tekniset vaatimukset Laatuvaatimukset KanTa-palvelun arkiston viestinvälityksen soveltuvuuden arviointi Viestinvälitysarkkitehtuurin soveltuvuus Medical Records -sanomien soveltuvuus Viestit ja interaktiot Sanomat ja kuvailutiedot MIME-paketointi Siirtokehys Kontrollikehys Dokumenttien tekninen kuljetustapa Tarvittavat tarkennukset sanomiin Soveltuvuuden yhteenveto ja laajennustarpeet Koodistojen käyttö Jatkokehitys ja tarkennukset Viestinvälityksen jatkomäärittelyt Vaatimukset muihin määrittelyihin Lähteet Liitteet: Medical Records-sanomien tietosisältöjen vastaavuus sosiaalihuollon metatietoihin Versio Pvm Tekijät Muutokset MS, EP, TT, Korjattu virheelliset viittaukset versiosta 1.0 JM, JK 2

3 1 Johdanto 1.1 Työn tavoitteet ja rajaukset Tässä dokumentissa kuvataan sosiaalihuollon asiakastietojärjestelmien ja arkiston väliseen viestinvälitykseen liittyviä vaatimuksia sekä arvioidaan terveydenhuoltoon toteutettujen KanTamäärittelyjen ja -ratkaisujen soveltuvuutta sosiaalihuoltoon viestinvälityksen osalta. Viestinvälitykseen liittyvistä taustaselvityksistä keskeisimmät ovat: Vaatimukset, perusratkaisut ja HL7 Medical Records -sanomien soveltuvuusarviointi (tämä dokumentti) Sosiaalihuollon header - Hyödyntämistarpeet ja toteutusarviointi Sosiaalialan tietoteknologiahankkeen hankesuunnitelmassa vuosille todetaan, että sosiaalihuollon osalta on selvitettävä ja ratkaistava kysymys kansallisesti ylläpidettävästä asiakasasiakirjojen sähköisestä arkistosta. Hankesuunnitelmassa aikataulutetaan sähköisen arkistoinnin kehittämistarpeiden arviointi vuodelle 2008, sosiaalihuollon sähköisen arkistoinnin hallinnan periaatteiden määrittely ja kuvaus vuosille 2008 ja 2009 sekä toteutusmallien testaus vuosille Hankkeen vuoden 2009 työsuunnitelman mukaisesti on jatkettu arkistointiratkaisun suunnittelu- ja määrittelytyötä Kansalliset tietojärjestelmäpalvelut -osahankkeessa. Alkuvuodesta 2008 hankkeen johtoryhmä teki linjauksen asiakirjojen rakenteeseen, metatietoihin ja viestinvälitykseen käytettävistä standardeista. Viestinvälityksen osalta päätettiin, että mikäli sosiaalihuollon arkistointiratkaisussa päädytään hyödyntämään Kanta-palveluja, terveydenhuollossa käytettävää viestinvälityskehystä ja tiedonsiirtoprotokollaa käytetään myös sosiaalihuollon asiakirjojen siirtämiseen. Näiden tekniikoiden soveltuvuutta arvioidaan tarkemmin tässä dokumentissa. Viestinvälitysmäärityksillä vastataan sosiaalihuollon sähköisten asiakasasiakirjojen tiedonsiirtotarpeisiin liittyen erityisesti arkistointiin. Määrityksissä huomioidaan Tikesos-hankkeen linjausten mukaisesti HL7-standardien, erityisesti Medical Records -sanomien hyödyntäminen viestinvälityksessä KanTa-järjestelmän osalta, mutta sovellettavat ratkaisut tarkentuvat edelleen hankkeen teknisessä määrittelytyössä. Tässä dokumentissa siis kuvataan tehtyjen arkisto- ja viestinvälityslinjausten pohjalta teknisten metatieto- ja viestinvälitysmäärittelyjen laajennuksia ja suuntaviivoja sekä kartoitetaan ratkaisuvaihtoehdot jatkotyön edistämiseksi. Tässä dokumentissa ei kuvata yksityiskohtaisia periaatteita viestien ja niiden tietosisällön tuottamiseen, lähettämiseen tai käsittelyyn. HL7- standardien hyödyntäminen on noussut aivan viime aikoina esiin sosiaalialalla myös mm. Hollannissa, ja myös Englannissa, Walesissa ja Ruotsissa sosiaali- ja terveydenhuollossa pyritään hyödyntämään toisiaan tukevia standardointiratkaisuja (Mykkänen 2009). Viestinvälitykseen liittyvien ratkaisujen lähtökohtia on kuvattu myös Tikesos-hankkeen selvityksessä, "Asiakirjastandardin implementointisuunnitelman taustaselvitys", luku 5. Tämä dokumentti viittaa useisiin HL7- ja KanTa-määrittelyihin ja osa siitä edellyttää HL7 versio 3 -perusteiden, XML:n sekä KanTa-ratkaisujen perustuntemusta. Dokumentti täydentää ja tarkentaa aiemmin julkaistuja sosiaalihuollon arkistoinnin vaatimuksia ja toiminnallisia määrittelyjä. Tämä dokumentti toimii pohjana sosiaalihuollon asiakirjojen arkistoinnissa tarvittaville sanomamäärittelyille. Useat eri tietojen käyttötarkoituksista ja kuvatuista ratkaisuista ovat alustavia 3

4 ehdotuksia ja voivat muuttua ja tarkentua jatkomäärittelyissä tai asiantuntijakommenttien pohjalta. Myös sosiaalihuollon metatiedot tarkentuvat hankkeen edetessä. 1.2 Keskeiset käsitteet Arkistojärjestelmä Sosiaalihuollon valtakunnallisesti keskitetty arkistointiratkaisu, jota käsitellään tässä sekä erityisesti arkistoon liittyvissä dokumenteissa. Interaktio järjestelmien välisestä (tässä arkisto ja asiakastietojärjestelmä) vuorovaikutuksesta. Yksi interaktio kuvaa yhden vuorovaikutustilanteen tai HL7-sanomamäärittelyissä yhden sanoman. KanTa Kansallinen terveysarkisto (KanTa) on yhteinen nimitys terveydenhuollon valtakunnallisille tietojärjestelmäpalveluille, joita ovat eresepti (sähköinen resepti), ekatselu (kansalaisen katseluyhteys) ja earkisto (sähköinen potilastietoarkisto). Viestinvälitys ja palveluväylä KanTa-palvelun viestinvälityksen vaatimusmäärittelyn mukaan viestinvälitys tarjoaa seuraavat palvelut: rajapinta terveydenhuollon perus- ja aluejärjestelmien kytkemiseksi arkistojärjestelmään (viestinvälitysrajapinta) sisäiset viestien käsittelymekanismit välineet arkiston ja muiden osajärjestelmien palveluiden orkestrointiin (prosessimoottori). Näistä käytetään yhteisnimitystä palveluväylä. HL7 Health Level Seven on voittoa tuottamaton terveydenhuollon kliiniseen ja hallinnolliseen puoleen standardeja tuottava yhdistys. Järjestöllä on kansainvälisiä HL7-standardeja paikallisiin oloihin ja lainsäädäntöön sopiviksi soveltavia sisarorganisaatioita useissa eri maissa. Suomalainen sisarorganisaatio on HL7 Finland ry. HL7 CDA R2 CDA R2 (Clinical Document Architecture, Release 2) on HL7:n kehittämä, terveydenhuollon tarpeisiin laadittu avoin XML-muotoinen standardi terveydenhuollon dokumenttien määrittelyyn. Suomessa CDA R2 -standardista ja sen paikallistamisesta vastaa HL7 Finland ry. CDA R2 -standardin käyttöä ohjataan soveltamisoppailla ja mallipohjilla (templates), jotka tarkentavat ja rajoittavat laadittavien asiakirjojen rakennetta. 4

5 CDA R2 -muotoisilla asiakirjoilla esitetään kliinistä tietoa katsojan ja sovelluksen ymmärtämässä muodossa. Katsojan ymmärtämällä muodolla tarkoitetaan asiakirjan muotoa, jossa asiakirjan sisältämät tiedot on muotoiltu siten, että ne ovat helposti ihmisen luettavissa ja ymmärrettävissä. Sovelluksen ymmärtämä muoto pohjautuu rakenteisiin ja koodistoihin, joiden pohjalta sovellus voi poimia tarvittavat tiedot ohjelmalliseen käsittelyyn. HL7 Medical Records HL7 Medical Records on HL7 versio 3 -standardin sovellusalue, jossa määritellään sanomia erityisesti dokumenttien vaihtoon tietojärjestelmien välillä. HL7 RIM HL7 versio 3 -standardien perustana on RIM (Reference Information Model), joka on HL7- sanomien ja asiakirjojen oliopohjainen viitetietomalli. RIM- mallin tehtävänä on mahdollistaa yhtenäinen tiedon käyttö ja jakaminen useiden eri käyttöalueiden välillä. RIM perustuu UMLmallinnusstandardiin. RIM-mallista löytyy lisätietoja suomeksi muun muassa seuraavista dokumenteista: Open CDA 2007 Johdanto (HL7 Finland 2007b) ja HL7-standardien soveltuvuus sosiaalihuoltoon (Taskinen ym. 2007) ja englanniksi kansainvälisiltä HL7:n sivuilta (esimerkiksi What Is HL7 2009). RIM-mallista tehdään sovellusalueen tietomalli D-MIM (Domain Information Model) "kloonaamalla" siten, että RIM:in rakenneobjekteja monistetaan kulkemalla act relationship -luokan kautta ja uusille acteille ja niihin liittyville muille objekteille annetaan uudet nimet. (HL7 Finland 2008a) Sovellusten välisten interaktioiden toteuttamista varten tehdään R-MIM-malleja (Refined Message Information Model). Loogisesti R-MIM periytyy D-MIM:istä. Teknisesti R-MIM rakennetaan samalla tavalla kuin D-MIM RIM-objekteista kloonaamalla. (HL7 Finland 2008a) R-MIM:istä tehdään hierarkisia (siirtotekniikasta riippumattomia) sanomakuvauksia (HMD, Hierarchical Message Descriptions), joista puolestaan generoidaan XML-skeemoja varsinaisten sanomien rakenteen määrittelyyn. (HL7 Finland 2008a) HL7 Web Services Transport Profile HL7 Web Services Transport Profile on HL7 versio 3 -sanomien siirtoon tarkoitettu tekninen määrittely, jonka avulla XML-muotoiset HL7-sanomat siirretään verkossa SOAP-protokollan avulla. Määrittely sisältää säännöt web services-tekniikoiden (SOAP-sanomat ja WSDLrajapintakuvaukset) käyttämiseen MIME MIME (Multipurpose Internet Mail Extension) on Internet-sähköpostiin kehitetty määrittely ja koodaustapa, joka mahdollistaa sanoman muodostamisen ASCII-tekstin lisäksi myös muista merkistöistä ja sisältökomponenteista kuten monimedia, salattu viesti ja organisaatioiden välisen tiedonsiirron sanomat (Tietotekniikan liitto 2008, 176). MIME-tyyppi (Internet media type, MIME type, Content-type) on kaksiosainen tunniste Internetissä käytettäville tiedostoformaateille (esimerkiksi teksti, ääni, valokuva, videokuva) (Tietotekniikan liitto 2008, 169). MIME-tyyppien tiedonsiirrossa voidaan hyödyntää Base64-koodausta, jonka avulla binäärimuotoinen tieto voidaan esittää merkkimuotoisena. 5

6 Sovellusrooli Sovellusrooli määrittelee HL7 versio 3 -standardeissa sovelluksen roolin ja vastuualueen sen ollessa yhteydessä toiseen sovellukseen. Sovellusrooli kertoo, mitä viestejä roolissa oleva järjestelmä lähettää ja vastaanottaa. Monissa ympäristöissä yksi sovellus voi olla useammassa kuin yhdessä roolissa. (HL7 2008b, Tuomainen 2006) SOAP SOAP (Simple Object Access Protocol) on yleensä HTTP-käytännöllä kuljetettaviin XMLmuotoisiin viesteihin perustuva, eri ympäristöissä toimiva yhteyskäytäntö, joka mahdollistaa webpalvelukomponenttien käytön (Tietotekniikan liitto 2008, 282). Web service XML Web service, web-palvelu 1) webin yhteyskäytäntöjen (SOAP, XML, HTTP) avulla käytettävä ohjelmakomponentti 2) web-ohjelmakomponentin tarjoama palvelu (Tietotekniikan liitto 2008, 395). Web services Web-palvelutekniikka, välineet ja menetelmät web-palvelujen hyödyntämiseksi (Tietotekniikan liitto 2008, 395). WSDL Web Services Description Language, web-palvelun kuvauskieli (Tietotekniikan liitto 2008, 397). XML Extensible Markup Language on yleiskäyttöinen, SGML-kielestä kehitetty merkkauskieli ja metakieli merkkauskielten määrittelyyn, jonka tarkoituksena on helpottaa dokumenttien siirrettävyyttä eri alustoille ja eri tarkoituksiin (Tietotekniikan liitto 2008, 397). XML on erityisesti internetkäyttöä varten rajattu merkintäkieli, joka on helposti laajennettavissa. XML-kielen käyttö helpottaa aineistojen yhdistämistä ja siirtoja erilaisten järjestelmien välillä. (Tietotekniikan termitalkoot 2007) 1.3 Dokumentin rakenne Luvussa 2 esitellään viestinvälityksen osapuolet sekä ja viestinvälitykselle asetetut vaatimukset. Vaatimukset on jaoteltu toiminnallisiin, arkkitehtuuri-, tietoturva-, teknisiin sekä laatuvaatimuksiin. Luku 3 käsittelee KanTa-järjestelmän arkisto-osuuden (earkisto) viestinvälityksen soveltuvuutta sosiaalihuollon arkiston tarpeisiin ja kartoittaa jatkotarkennuksiin liittyviä seikkoja, vaatimuksia sekä ratkaisuvaihtoehtoja, jotka nousevat esiin, mikäli asiakastietojärjestelmien ja arkiston välisessä tiedonsiirrossa hyödynnetään HL7 Medical Records -sanomia. Luvussa 4 käydään läpi viestinvälitysmääritysten jatkokehitykseen ja tarkennuksiin liittyviä asioita. 6

7 2 Viestinvälityksen osapuolet ja vaatimukset 2.1 Viestinvälityksen osapuolet Viestinvälitykseen osallistuvat osapuolet kuvataan aliluvuissa Kuvassa 1 esitetään sosiaalihuollon viestinvälitykseen tarvittava arkkitehtuuri, josta tässä yhteydessä keskitytään asiakastietojärjestelmien osuuteen, eli siihen mitä ja miten asiakastietojärjestelmien tulee lähettää ja ottaa tietoa vastaan. Viestinvälityksen käsitteeseen palveluväylänä ja esimerkiksi sen sisäiseen toiminnallisuuteen ei tässä selvityksessä oteta kantaa, joskin asiaa sivutaan luvussa 3.1. Kuva 1: Sosiaalihuollossa tarvittava viestinvälitys Viestinvälityksestä johdettavat sovellusroolit vastaavat pitkälti myös sosiaalihuollon osalta KanTapalvelussa ja HL7 Medical Records -standardissa määriteltyjä rooleja, jotka kuvataan tarkemmin luvussa 3.1. Kuvassa esiintyvällä termillä ATJ tarkoitetaan asiakastietojärjestelmää, joka käyttää arkistopalvelua. On kuitenkin huomioitava, ettei tässä kuvattu asiakastietojärjestelmä välttämättä toteuta viestinvälitystä itse, vaan siihen voidaan hyödyntää jotakin muuta palvelua, joka kuitenkin tämän määrityksen kannalta vastaa vuorovaikutuksen käynnistävää osapuolta. Termillä asiakastietojärjestelmä katetaan tämän selvityksen puitteissa kaikki järjestelmät, jotka liittyvät arkistoon, vaikkei kyseessä välttämättä olisikaan dedikoitu asiakastietojärjestelmä. Sosiaalihuollon asiakirjallisen tiedon tuottajat eivät aina välttämättä ole tiedon käyttäjiä, eivätkä kaikki tiedon hyödyntäjät tuota asiakirjallisia tietoja. Tulee huomioida, että nämä samat säännöt pätevät viestinvälityksen osalta myös muiden sidosryhmien tarpeisiin (ks. Suhonen ym. 2009) Tiedon tuottajat Tiedon tuottajat lähettävät asiakirjoja arkistoon käyttämänsä järjestelmän toteuttaman viestinvälitysrajapinnan kautta. Tiedon tuottajia sosiaalihuollossa ovat sosiaalihuollon toimijat, joita ovat esimerkiksi palvelun antajat, järjestäjät ja ammattihenkilöt. Tiedon tuottajia voivat olla myös asiakkaat, esimerkiksi sähköisen asioinnin kautta. Tämän selvityksen puitteissa tiedon tuottajia ja käyttäjiä ei yksilöidä henkilö- vaan järjestelmätasolla jolloin tässä dokumentissa tiedon tuottajaa vastaa asiakastietojärjestelmä. 7

8 2.1.2 Tiedon käyttäjät Tiedon käyttäjät voivat hakea asiakirjojen tietoja ja asiakirjoja arkistosta viestinvälitysrajapinnan kautta. Tiedon käyttäjällä tarkoitetaan tahoa, joka käyttää sosiaalihuollon palvelutehtävissä syntyneitä tietoja, ts. asiakirjoja, omassa toiminnassaan. Tietojen käyttöön ja saatavuuteen vaikuttavat muun muassa rekisterinpitäjyyteen ja suostumuksiin tai kieltoihin liittyvät seikat. Sosiaalihuollon suostumuksesta on tuotettu erillinen selvitys (Penttilä 2009) ja myös arkistointimäärittelyissä (Suhonen ym. 2009) on määritelty näitä seikkoja. Tiedon käyttäjiä ovat lähtökohtaisesti samat sosiaalihuollon toimijat kuin luvussa 2.1.1, mutta tiedonsaantitarpeita on myös muilla toimialoilla, kuten terveydenhuollolla, poliisilla ja vastaavilla sidosryhmillä. Tiedon käyttäjiä ovat myös asiakkaat, jotka voivat hakea ja tuottaa itseään koskevia tietoja arkistosta/arkistoon esimerkiksi kansalaisen katseluyhteyden avulla ja jatkossa mahdollisesti erilaisten asiointipalveluiden avulla. Järjestelmätasolla tiedon käyttäjällä tarkoitetaan tässä selvityksessä arkistopalvelusta asiakirjoja kyselevää ja hakevaa asiakastietojärjestelmää Arkistopalvelu Arkistopalvelulla tarkoitetaan määriteltävänä olevaa sosiaalihuollon valtakunnallista arkistointijärjestelmää. Kuten tämän työn pohjana hyödynnettävässä KanTa-palvelussa, myös tässä arkistopalvelu käsittää säilytyksestä vastaavan arkiston, asiakirjojen jakelun ja asiakirjanhallinnolliset tehtävät, jotka kuuluvat viestinvälityksen piiriin. KanTa-arkistoon kuuluvia osajärjestelmiä ovat mm.: Arkisto Hakemisto- ja rekisteröintipalvelu Suostumusten tai kieltojen hallinnan arkiston päässä tapahtuva käsittely (esimerkiksi suostumusasiakirjojen tarkastus palvelupyyntöjä vasten, varsinainen suostumusten pyytäminen ja luonti tapahtuu asiakastietojärjestelmässä) Kokonaisarkkitehtuuriin kuuluu myös muita palveluita, kuten valtakunnallinen koodistopalvelu ja jatkossa mahdollisesti erityyppisiä asiointipalveluja sekä muita yhteisiä tietojärjestelmäpalveluita, joita kartoitetaan erillisessä selvityksessä. Tämä viestinvälitysdokumentti keskittyy kuitenkin arkistointijärjestelmän ja asiakastietojärjestelmän väliseen viestintään. Lisäksi dokumentissa keskitytään niihin viesteihin, jotka liittyvät tiedon tuottajien, käyttäjien ja arkistopalvelun välillä tapahtuvaan vuorovaikutukseen. 2.2 Viestinvälityksen vaatimukset Viestinvälitysarkkitehtuurille ja sitä toteuttavalle palveluväylälle tehdyt vaatimusmäärittelyt terveydenhuollon KanTa-arkkitehtuurin osalta on kuvattu Sosiaali- ja terveysministeriön tuottamissa määrityksissä (STM 2007a, 2007b). Nämä dokumentit toimivat tämän työn tärkeinä lähteinä. Tässä luvussa kuvataan viestinvälityksen tehtävät, tärkeimmät laatuvaatimukset, ja mitä riippuvuuksia ja vaatimuksia tehtäviin liittyy erityisesti sosiaalihuollon osalta. 8

9 Vaatimusten keskeisiä lähteitä ovat Tikesos-hankkeen aiemmissa selvityksissä ja johtoryhmässä tehdyt linjaukset sekä KanTa-määrittelydokumentaatio. Yleisiä asiakastietojärjestelmien vaatimuksia on kuvattu dokumentissa Sosiaalihuollon asiakasasiakirjojen sähköinen arkistointi, Vaatimukset ja toiminnallinen määrittely (Suhonen ym. 2009). Mikäli sosiaalihuollon sähköisen arkistoinnin viestinvälityksessä tullaan soveltamaan Medical Records - sanomia, se aiheuttaa vaatimuksia asiakastietojärjestelmille. Asiakastietojärjestelmien tulee pystyä muodostamaan Medical Records -sanomia ja interaktioita tässä selvityksessä kuvattujen tarpeiden ja ratkaisuvaihtoehtojen mukaisesti tai kuten niiden osalta erikseen linjataan. Tämä tarkoittaa sekä viestien lähettämistä että niiden koostamista, jolloin sanomien tietokenttiin ja -rakenteisiin tulee pystyä tuottamaan tarvittavat tiedot oikeassa muodossa. Asiakastietojärjestelmien tulee myös pystyä vastaanottamaan ja käsittelemään arkistosta tulevia sanomia. Tätä kautta HL7-osaaminen toteuttajilla ja asiakastietojärjestelmien kehityksessä on myös tarpeellista. Vaatimustaulukon kuvaus Numeerinen tunniste, jolla vaatimukseen voidaan viitata yksiselitteisesti. voidaan muodostaa myös hierarkkisena, jos korkeamman tason vaatimuksia jaetaan yksittäisiksi, tarkemmiksi vaatimuksiksi. 1 = päätason tunniste 1.1, 1.2, 1.1.4, = alatason tunnisteita Sanallinen kuvaus vaatimuksesta. Vaatimuksen perustelut auttavat hahmottamaan vaatimuksen merkitystä. Tämä ei ole pakollinen tieto, jos vaatimus on hyvin yksinkertainen tai kuvaus-kenttä antaa siitä jo riittävästi tietoa. Lähde ilmoittaa keneltä tai mistä vaatimus on peräisin. Lähteenä voi olla henkilö, organisaatio, lainsäädäntö, määrittely tai muu vastaava. Lähdetietoa voidaan hyödyntää vaatimusten tarkentamisessa ja vaatimusten priorisoinnissa. Suhteet muihin vaatimuksiin. Viittauksessa käytetään vaatimuksen tunnistetta. Tämän ja prioriteettitiedon avulla voidaan varmistua siitä, ettei tärkeiden vaatimusten toteuttaminen jää riippumaan vähemmän tärkeistä vaatimuksista. n avulla mahdollistetaan muutosten seuranta ja helpotetaan vaatimusten versionhallintaa tulevaisuudessa. 9

10 2.2.1 Toiminnalliset vaatimukset VIESTINVÄLITYKSEN PÄÄVAATIMUKSET JA OSAPUOLTEN VASTUUT: V1.01 Viestinvälitys huolehtii tiedonvälityksestä arkiston ja asiakastietojärjestelmien välillä. Kaikki ATJ:n ja arkiston välinen tietoliikenne tapahtuu viestinvälitysmääritysten mukaan. KanTa-arkkitehtuuri. V1.02 Arkisto kykenee muodostamaan ja lähettämään viestinvälityksen kautta asiakastietojärjestelmälle lähetettävät sanomat Arkisto kommunikoi asiakastietojärjestelmien kanssa viestien avulla. V1.03 Arkisto kykenee vastaanottamaan ja tulkitsemaan asiakastietojärjestelmästä tulevat sanomat Arkisto kommunikoi asiakastietojärjestelmien kanssa viestien avulla. V1.04 Asiakastietojärjestelmä kykenee muodostamaan ja lähettämään viestinvälityksen kautta arkistoon lähetettävät viestit/sanomat, mukaan lukien niiden sisältämät asiakirjat ATJ käyttää arkistoa viestinvälitysrajapinnan kautta. Kaikki toiminnallisuus tapahtuu viestien avulla, joten vaatimuksenmukaisuus on välttämätöntä arkiston käyttämiseksi. ATJ kommunikoi arkiston kanssa viestien avulla. 10

11 V1.05 Asiakastietojärjestelmä kykenee vastaanottamaan ja tulkitsemaan tai näyttämään arkistosta tulevat sanomat, mukaan lukien niiden sisältämät asiakirjat. ATJ kommunikoi arkiston kanssa viestien avulla. VIESTINVÄLITYKSEN TOIMINNALLISUUS: V1.11 Viestinvälityksessä tuetaan yhden asiakasasiakirjan arkistointiin (arkistoon lähettämiseen) tarvittavaa sanomaa. Tyypillinen arkiston käyttötilanne on, kun asiakastietojärjestelmä lähettää arkistoon yhden asiakirjan arkistoitavaksi. V1.12 Viestinvälityksessä tuetaan yhden asiakasasiakirjan arkistosta hakemiseen tarvittavaa sanomaa. Tyypillinen arkiston käyttötilanne on, kun asiakastietojärjestelmä hakee arkistosta yhden asiakirjan tarkasteltavaksi. V1.13 Viestinvälityksessä tuetaan hakuehtoihin perustuvaa asiakirjaluettelon kyselysanomaa Asiakirjaluettelon kyselysanoman avulla voidaan kysellä arkistosta, mitä hakuehtoja vastaavia asiakirjoja sieltä löytyy. Hakuehdoilla rajattu kysely mahdollistaa tarkkojen hakujen tekemisen. 11

12 V1.14 Viestinvälityksessä tuetaan kyselysanoman vastauksena arkistosta palautuvaa asiakirjaluettelosanomaa Asiakirjaluettelosanoman perusteella voidaan valita ja hakea luettelon sisältämiä asiakirjoja. V1.15 Viestinvälityksessä tuetaan tarvittavia arkiston ja asiakirjojen hallintaan liittyviä sanomia Hallintaan liittyviä sanomia ovat suostumuksen lähettäminen arkistoon (esimerkiksi kyselyn yhteydessä) luovutusilmoitus luovutusloki V1.16 Viestinvälityksen avulla on voitava välittää lokipyyntöjä ja lokitietoja. VIESTINVÄLITYKSEN SEURANNAN JA HALLINNAN TOIMINNALLISUUS: Tässä osiossa kuvatut vaatimukset perustuvat KanTa-palveluväylälle asetettaviin vaatimuksiin. Asiakastietojärjestelmiin ja arkiston ja asiakastietojärjestelmän väliseen rajapintaan niillä ei ole suoraa vaikutusta. V1.21 Arkiston osalta viestinvälityksen tai palveluväylän tulee kirjoittaa teknistä lokia poikkeustilanteiden selvittämiseksi. 12

13 V1.22 Palveluväylän tulee tarjota käyttöliittymä sanomaliikenteen ja prosessien tilan valvomiseksi ja poikkeustilanteiden havaitsemiseksi ja korjaamiseksi. V1.23 Palveluväylän tulee mahdollistaa arkistopalvelun kuormituksen ja suorituskyvyn seuranta ja pullonkaulojen havainnointi. V1.24 Arkiston tai palveluväylän tulee voida pitää lokia siitä, mitä tietoja, koska ja kenelle se on välittänyt Arkkitehtuurivaatimukset V2.01 Sosiaalialan valtakunnallisen viestinvälityksen arkkitehtuurissa nojaudutaan KanTa-arkiston tarjoamiin valmiisiin malleihin, kun mahdollista. KanTa-perustaiset vaihtoehdot ovat arkistoratkaisuun jo tehtyjä linjauksia, ja jo tehtyjä määrittelyjä hyödyntämällä vältetään ylimääräistä työtä. (Johtoryhmän linjaukset) 13

14 V2.02 Viestinvälityksessä on varmistettava arkistoitavien asiakirjojen perille (arkistoon) saapuminen. Varmistus voidaan tehdä kuittauksia käyttämällä. Arkiston sanomaliikenne on synkroninen, jolloin sovellustason kuittaukset (tai vastaussanoma, tai vastaanottokuittaus) tulevat samassa synkronisessa yhteydessä. Asiakirjoja arkistoivilla asiakastietojärjestelmillä on oltava mahdollisuus ottaa vastaan arkiston lähettämiä kuittauksia. KanTa / Medical Records-määrittelyt KanTa-arkiston sanomaliikenne määriteltiin alun perin synkroniseksi, muutettu syyskuussa V2.03 Viestinvälityksessä asiakastietojärjestelmän suorittamat kyselyt voivat perustua synkroniseen kutsuun. Arkistosta tulee suora vastaus tai sovellustason kuittaus asiakastietojärjestelmän kyselyihin ja arkistointi-interaktioihin. Vastaanottokuittauksia käytetään ainoastaan teknisten virheiden esittämiseen. KanTa-määrittelyissä tietoliikenne on muutettu synkroniseksi määrittelyjen uusimmissa versioissa. V2.04 Arkistoitavien asiakirjojen toimittaminen arkistoon on varmistettava viestinvälitysratkaisuissa. Arkistoon kohdistuvien kyselyjen ja asiakirjan hakujen osalta kysely tai haku voidaan tarvittaessa toistaa. Mikäli asiakastietojärjestelmä ei saa kuittausta vastaanotetusta asiakirjasta, arkistointipyynnön uudelleen käynnistäminen on asiakastietojärjestelmän vastuulla. V2.05 Asiakastietojärjestelmä voi olla yhteydessä suoraan arkistojärjestelmän kanssa, tai niiden välissä voi toimia välittäjäpalvelin 14

15 2.2.3 Tietoturvavaatimukset V3.01 Viestinvälityksessä käytetään salattua tietoliikenneprotokollaa asiakastietojärjestelmän ja arkistojärjestelmän välisessä viestinvälityksessä. V3.02 Viestinvälityksen osapuolena olevat tietojärjestelmät on varmennettava kaksisuuntaisesti ennen tiedonvaihtoa (nk. 2-way SSL menettely), ja viestinvälityksen tulee olla rajattu vain tunnistetuille ja hyväksytyille järjestelmille V3.03 Viestinvälitykseen liittyvissä tietojärjestelmissä on huolehdittava siitä, että käyttäjä ja viestin lähettäjä tunnistetaan siten, että voidaan varmistua, että tämä on yksilöity oikein. Viestinvälityksen tulee olla rajattu vain näille tunnistetuille ja hyväksytyille käyttäjille. V3.04 Viestinvälityksen lokitiedoista tulee voida saada selville, mitä sanomia viestinvälityksessä on eri osapuolten kesken vaihdettu (jäljitettävyys), siten, että toinen osapuoli ei voi kiistää toimintaansa jälkikäteen. Toiminnan kiistämättömyys on taattava. 15

16 V3.05 Sanomaliikenteen ja viestinvälityksen valvontaratkaisuissa tulee poistaa tai vähintään minimoida asiakastietojen näkyvyys valvontaa suorittavalle henkilöstölle. V3.06 Viestinvälityksessä tulee turvata viestien muuttumattomuus. V3.07 Viestinvälityksessä tulee pyrkiä siihen, että viesti ei häviä matkalla, ja varautua viestien käsittelyssä mahdollisiin virhetilanteisiin Tekniset vaatimukset V4.1 Viestinvälitys toimii teknisesti IP-verkossa TCP/IP-protokollalla suojattua HTTP-protokollaa käyttäen (https). KanTa-määrittelyt, suojattu yhteys. V4.2 Viestinvälitys hyödyntää SOAP-protokollaa, jonka sisään varsinaiset siirrettävät sanomat paketoidaan. KanTa-määrittelyt. 16

17 V4.3 Viestinvälityksen osapuolien on osattava vastaanottaa ja lähettää HL7 versio 3 -sanomia HL7 V3 Web Services -siirtoprofiilia käyttäen. KanTa-määrittelyt. V4.4 Viestinvälityksen osapuolien on tuettava HL7 versio 3 Medical Records -sanomia, joilla asiakirjoja ja niiden tietoja rekisteröidään, tallennetaan, ja haetaan. KanTa-määrittelyt V4.5 SSL-protokollasta on käytettävä ns. two-way SSL versiota Two-way SSL on SSL-yhteyden muoto, jossa sekä SSL-yhteyden asiakas että palvelin esittävät toisilleen sertifikaatit, joilla kummankin identiteetti varmennetaan ennen varsinaisen yhteyden muodostamista. Tietoturvallinen ja luotettu yhteys viestinvälityksen osapuolten välillä Laatuvaatimukset V5.01 Viestinvälitykseen sekä arkiston että asiakastietojärjestelmän päässä on määriteltävä palvelutaso Palvelutasomäärittelyssä kuvataan ainakin palvelun saatavuus (esim. 99.9% lukuun ottamatta ennakoituja katkoja) ennakoitujen katkojen maksimipituus (esim. 20 minuuttia) palautuminen toimintahäiriön jälkeen (esimerkiksi voitava palauttaa normaalitilaan keskimäärin 10 minuutissa) riittävän nopeat vasteajat viestinvälityksessä. 17

18 3 KanTa-palvelun arkiston viestinvälityksen soveltuvuuden arviointi 3.1 Viestinvälitysarkkitehtuurin soveltuvuus Luvussa 3 kuvataan KanTa-ratkaisussa käytettävän viestinvälityksen soveltamistapa ja arvioidaan sen soveltuvuutta sosiaalihuoltoon. KanTa-ratkaisun viestinvälitystä on kuvattu jo Tikesos-hankkeessa tuotetussa Asiakirjastandardin implementointisuunnitelman taustaselvitys -dokumentissa (Savolainen ym. 2008). KanTa:n viestinvälitys (STM 2007a) tarjoaa: viestinvälitysrajapinnan terveydenhuollon perus- ja aluejärjestelmien kytkemiseksi arkistojärjestelmään sisäiset viestien käsittelymekanismit prosessimoottorin, eli välineet arkiston ja muiden osajärjestelmien palveluiden orkestrointiin. Edellä mainittuja toiminnallisuuksia kutsutaan termillä palveluväylä. Näiden lisäksi palveluväylä pitää huolta sanoman säilyttämisestä niin kauan kuin osajärjestelmä on käsitellyt sen onnistuneesti. Jos käsittely ei onnistunut, palveluväylä palauttaa sanoman lähettäjälle virheilmoituksen. Palveluväylä käsittelee myös XML-sanomien kehyksiä, tarkastaa varmenteiden ja sanomakehysten oikeellisuuden, hoitaa prosessiohjausta ja antaa välineet arkiston toimivuuden valvomiseksi. Palveluväylä mahdollistaa sanomaliikenteen ja toimintaprosessien seurannan, tarjoaa keskitetyn virheenkäsittelypalvelun, huolehtii sanomien vastaanotto- ja virhekuittausten muodostamisesta ja lähettämisestä sekä mahdollistaa sanomarajapinnan käytön THL:n ja Lääkelaitoksen tilastomateriaalin vastaanotossa ja edelleen välittämisessä (Savolainen ym. 2008a, STM 2007b). Osapuolten loogisten tunnisteiden ja fyysisten verkko-osoitteiden hallinta sekä osapuolten välinen tunnistaminen ja varmenteiden tarkastaminen ovat myös keskeisiä palveluväylään liittyviä tehtäviä. Palveluväylän malli ja arkkitehtuurin perusroolit ovat sellaisenaan hyödynnettävissä sosiaalihuollon arkiston ja asiakastietojärjestelmien välisessä viestinvälityksessä. Myös palveluväylään arkiston puolella liittyviä palveluja voidaan todennäköisesti hyödyntää sellaisenaan tai hyvin pienillä muutoksilla. 18

19 Kuva 2: KanTa-viestinvälitysratkaisu ja palveluväylä (STM 2007b) Viestinvälityksen toiminnallisessa arkkitehtuurissa sovellusrooli ryhmittelee yhden järjestelmän vastuualueeseen liittyvät vuorovaikutukset muiden järjestelmien kanssa. Sovellusrooliin liittyy joukko sanomia ja se kertoo, mitä viestejä roolissa oleva järjestelmä lähettää ja vastaanottaa. Myös HL7 versio 3 Web Services -siirtoprofiilin rajapintojen WSDL-rajapintakuvaus pohjautuu sovellusroolien käsitteeseen. KanTa-palvelussa hyödynnetään kolmea Medical Records -sovellusalueen viidestä sovellusroolista: Clinical Document Directory(RCMR_AR000005) ei käytössä Content Optional Document Management System(RCMR_AR000002) ei käytössä Content Required Document Management System(RCMR_AR000003) arkisto Document Originator(RCMR_AR000001) potilastietojärjestelmä Document Recipient(RCMR_AR000004) potilastietojärjestelmä 19

20 KanTa-arkisto vastaa lähinnä sovellusroolia Content Required Document Management System (RCMR_AR000003). Kyseessä on sovellusrooli, joka seuraa dokumenttien tilamuutoksia (esimerkiksi lisäykset, poistot, allekirjoitukset) ja se voi vastaanottaa viestejä dokumenttien tilan muutoksista (ml. varsinaiset dokumentit). Rooli voi tarjota luku- ja kirjoituspääsyn tietovarastoon joka hallinnoi dokumentteja sekä tehdä kyselyitä tai vastata niihin. Terveydenhuollon KanTa-ratkaisuissa potilaskertomusohjelmistot ovat lähinnä sovellusrooleja RCMR_AR (sovellus, jossa dokumentteja luodaan ja josta ne lähetään muualle) ja RCMR_AR (sovellus, joka vastaanottaa dokumentteja). Myös kansalaisen katseluyhteys käsittelee arkiston tietoja samoilla viesteillä kuin potilaskertomusohjelmistot. KanTa-arkiston ja HL7 Medical Records-määrittelyn mukaista arkiston ja asiakastietojärjestelmien roolijakoa voidaan hyödyntää myös sosiaalihuollossa tiedon käyttäjien, tuottajien ja arkistopalvelun osalta (ks. luku 2.1). 3.2 Medical Records -sanomien soveltuvuus Sosiaalihuollossa kansalliseen arkistoon tullaan arkistomäärittelyjen mukaisesti arkistoimaan sosiaalihuollon rakenteisia XML-asiakirjoja ja PDF/A-muotoisia asiakirjoja. Terveydenhuollon potilasasiakirjat tullaan ainakin alkuvaiheessa arkistoimaan CDA R2 -standardin ja suomalaisten soveltamisohjeiden mukaisina. Myös muiden formaattien, kuten DICOM ja PDF, käyttöä arkistossa on suunniteltu ja tämän selvityksen valmistumisen jälkeen täsmennetty terveydenhuollon osalta. Sosiaalihuollon asiakirjat itsessään eivät tule olemaan CDA R2 -formaatin mukaisia, joskin CDA R2 - kääreen hyödyntäminen asiakirjojen paketoinnissa on mahdollista. Medical Records -määrityksessä (HL7 2008) on kuvattu viestinvälityksen teknisten periaatteiden lisäksi myös alustavia toimintatapoja siihen, kuinka sanomien avulla pystytään arkistoimaan muutakin kuin CDA R2 -muodossa olevia asiakirjoja. KanTa-arkistoon arkistoitavaksi hyväksyttävät muut formaatit on tarkoitus tulevaisuudessa määritellä erikseen ja sopia siten, että kaikki pystyvät niitä hyödyntämään. Sosiaali- ja terveydenhuollon välisiä tietotarpeita ja KanTa-ratkaisuista valmiina löytyvien mallien ja palvelujen hyödyntämistä silmällä pitäen on järkevää pyrkiä täysin samaan tai samantyyppiseen ratkaisuun muiden kuin CDA-muotoisten asiakirjojen osalta sosiaali- ja terveydenhuollossa. Periaatteet 1 muiden kuin CDA R2 -muotoisten asiakirjojen arkistoimiseen ovat seuraavat (HL7 2008): käytetään samaa arkistointi-interaktiota Medical Records -sanomissa kuvataan kaikki kuvailutiedot (tai ainakin erikseen määritelty minimijoukko) clinicaldocument.text kenttään sisällytetään asiakirja MIME-paketissa Formaatti ilmaistaan text-kentän ED-tietotyypin mukaisessa mediatype kentässä o mediatypen arvona voidaan käyttää IANA rekisteröimää mediatypeä, esim: application/dicom application/pdf Sallitut formaatit on lueteltu erikseen KanTa-ohjeissa 1 Tässä kuvataan määrityksen (HL7 2008) mukainen toiminta, jota on linjattu ja täsmennetty myöhemmin, ks. Paakkanen ym. 2009b 20

21 Arkiston toiminta tapahtuu näiden asiakirjojen osalta samalla tavalla kuin CDA R2 -asiakirjoilla. Näihin periaatteisiin liittyviä seikkoja kuvataan ja arvioidaan seuraavissa aliluvuissa sekä tarkennetaan header-soveltuvuusarvioinnissa (Paakkanen ym. 2009b). Yllä mainittujen periaatteiden nojalla Medical Records -sanomia on mahdollista soveltaa myös sosiaalihuollon asiakirjoihin. Sanomissa kuvattava kuvailutietojen joukko tulee määritellä sosiaalihuoltoon soveltuvaksi. Tätä kuvataan tarkemmin luvuissa ja 3.3. Myös MIME-paketoinnin periaatteita on kuvattu myöhemmin tässä dokumentissa. Asiakirjojen formaattina tulee pystyä ilmaisemaan sosiaalihuollon asiakirjaformaatit eli sosiaalihuollon XML-formaatti (joka voidaan ilmaista esim. application/xml-tyypillä sekä tarvittaessa tarkentavalla fileformat-koodistolla) sekä PDF/A. Tässä selvityksessä keskitytään vaihtoehtoon, jossa sosiaalihuollon asiakirjoja ei tarvitse tuottaa CDA R2 -muotoisina 2. Tällä ratkaisulla helpotettaisiin ratkaisujen toteuttajiin kohdistuvia paineita HL7-osaamisen suhteen, koska mm. asiakirjastandardin suhteen on linjattu, ettei HL7 CDA R2 - formaattia käytetä. Tarvittavien metatietojen osalta on myöhemmin linjattu, että tarvittavat metatiedot ilmoitetaan CDA header -osiossa. Tällöin asiakastietojärjestelmien tulee pystyä tuottamaan tarvittavat metatiedot myös header-määritysten mukaisesti sekä viestikerrokseen siltä osin kuin on arkistopalvelun kannalta tarpeellista. CDA-headerin ja sosiaalihuollon metatietojen yhdenmukaisuutta on arvioitu Tikesos-hankkeen aikaisemmissa selvityksissä, keskeisimpänä Sosiaalihuollon asiakasasiakirjojen metatiedot -määrityksessä (Paakkanen ym. 2009a) sekä sen liitteinä olevissa taulukoissa. Sosiaalija terveydenhuollon metatiedot eivät täysin vastaa toisiaan ja paras vaihtoehto headerin tuottamiselle olisi tehdä se ainoastaan sosiaalihuollon metatietojen mukaisesti. Tästä syntyisi erillinen, niin kutsuttu sosiaalihuollon CDA-header. Mikäli asiakirja tulee lisäksi paketoida CDA-dokumentin sisälle, aiheutuu tästä vaatimuksena asiakastietojärjestelmille kyky muodostaa myös CDAdokumentteja. Asiaa käsitellään tarkemmin selvityksessä (Paakkanen ym. 2009b) Viestit ja interaktiot Tässä luvussa kuvataan Medical Records -interaktiot, jotka on määritelty KanTa-ratkaisuihin (HL7 2008b), ja arvioidaan niiden käyttöä sosiaalihuollon sähköiseen arkistointiin toteutettavassa asiakastietojärjestelmien ja arkistojärjestelmän välisessä liikenteessä. Tarvittavia interaktioita käyttötapaustasolla on kuvattu myös Sosiaalihuollon asiakasasiakirjojen sähköinen arkistointi - vaatimukset ja toiminnallinen määrittely -dokumentissa (Suhonen ym. 2009). KanTa-ratkaisuun määritellyt palvelut ja niitä vastaavat HL7-interaktiot sekä tarpeet sosiaalihuollossa on kuvattu alla olevassa taulukossa. 2 Myöhemmin linjattiin, että viestinvälityksessä käytetään SosXML-paketointiin CDA R2 -käärettä 21

22 Käyttötarkoitus HL7 interaktio Sosiaalihuolto Arkistoi asiakirja RCMR_IN100002FI01 Original document with content Tarvitaan vastaava toiminnallisuus; asiakirjojen formaateissa ja kuvailutiedoissa Hae asiakirjojen kuvailutietoja Hae asiakirjoja Kuittaukset ja virheet vastaanottokuittaus sovellustason kuittaus Korvaa arkistoitu asiakir- RCMR_IN100029FI01, RCMR_IN100030FI01 Find document metadata query + response RCMR_IN100031FI01, RCMR_IN100032FI01 Find document metadata and content query + response MCCI_IN000002UV01 RCMR_IN120001FI01 RCMR_IN FI01 ja Document Replacement with Content Arkiston alikäyttötapaukset: Näille ei ole omia interaktioita vaan siirto tapahtuu "Arkistoi asiakirja"- Tarkista suostumukset ja interaktiolla ja muuttaminen ja mitätöinti kiellot, "Korvaa arkistoitu asiakirja" in- Päivitä suostumuksenhallintaa teraktiolla. Suostumuksien tarkastamisanoman ja tarkista palvelunen tapahtuu luovutusten yhteydessä. lähetysoikeus. Nämä käyttötapaukset ovat arkiston sisäistä toimintaa. Sanomat, jotka eivät ole käytössä Liitä yhteiset asiakirjat RCMR_IN100001FI01 (Metatietojen muutosviesti Original Document liittämissanoma tai muu metatietomuutos) Lähetä välityssanoma RCMR_IN100004UV01 Original Document from Mgt System with Content eroja. Tarvitaan vastaava toiminnallisuus, kuvailutiedoissa eroja. Tarvitaan vastaava toiminnallisuus; asiakirjojen formaateissa ja kuvailutiedoissa eroja. Tarvitaan vastaava toiminnallisuus. Tarvitaan vastaava toiminnallisuus. Voidaan soveltaa samalla tavalla. Metatietojen päivityksille on käyttötarve, mutta voidaan osin hoitaa arkistonhallinnan kautta muuten kuin sanomilla. Ei ensivaiheessa. Sanomissa on KanTan osalta käytetty sanomatyyppejä RCMR_MT100001FI01 ja RCMR_MT100002FI01, joiden tietosisältö kuvataan luvussa Interaktioiden ja sanomatyyppien nimet niiden interaktioiden osalta, joissa tarvitaan sosiaalihuollon laajennusta on määriteltävä jatkossa erikseen Arkistoi asiakirja Arkistointi-interaktion tarkoituksena on lähettää asiakastietojärjestelmästä yksi tai mahdollisesti kerralla useampia asiakirjoja arkistoon. Viestinvälityksen tulee mahdollistaa Tikesos-hankkeessa määriteltyjen asiakirjojen lähettäminen, eli sosiaalihuollon omassa XML-muodossa sekä näyttömuodossa (esim. PDF/A) olevien asiakirjojen lähettäminen. Suostumusasiakirjat ja luovutusilmoitusasiakirjat toimitetaan saman interaktion avulla. Periaatteita asiakirjojen arkistoimiseen kuvataan tarkemmin luvussa 3.2.2, jossa kuvataan Medical Records -viestien tietosisältö. Keskeisintä sosiaa- 22

23 lihuollon osalta on toimia luvun 3.2 periaatteiden mukaisesti, jolloin viestiin on pystyttävä lisäämään sosiaalihuollon asiakirja ja sen metatiedot. Interaktiolla Original Document with Content (RCMR_IN100002FI01) siirretään eri dokumentteja arkistoon. Viestin hyötykuormaosio löytyy kontrollikehyksen (MCAI_MT700201UV01) elementistä RCMR_IN000002UV01.controlActProcess.subject. Subjektin alla oleva ClinicalDocumentelementti sisältää arkistoon lähetettävät tiedot. Varsinainen välitettävä asiakirja sijoitetaan Clinical- Document.text elementtiin (ks. myös luku 3.2. ja Medical Records -määrityksen luku 8.1.2), joka on tietotyypiltään ED (encapsulated data). Elementtiin liittyvissä attribuuteissa kuvataan tarkemmin menetelmä jolla varsinainen dokumenttisisältö on koodattu. Interaktion käsittelijän (arkiston) tulee lähettää sovellustasonkuittaus interaktiolla RCMR_IN120001FI01. Batch-sanomat ja niiden käyttötapa on kuvattu tarkemmin V3 messaging -oppaassa (HL7 2008a). Kaikki tilanteet joissa batch-sanomia voidaan käyttää määritellään omina tapauksina, jotka kerätään myös koodistoksi koodistopalvelimelle. Batch-sanoma mahdollistaa useiden HL7-interaktioiden siirtämisen yhdellä kertaa. Kyse on siirron aikaisesta käsitteestä eikä se vaikuta yksittäisten interaktioiden käsittelyyn, joten batch-sanomaan voidaan myös koota erityyppisiä interaktoita. Tavoitteena on tehostaa tiedonsiirtoa, koska samalla yhteydellä siirto on tehokkaampaa kuin uuden yhteyden avaaminen jokaista interaktiota varten. Nykyisten KanTa-määrittelyjen mukaisesti kukin asiakirja toimitetaan erikseen omassa interaktiossaan, jolloin useita asiakirjoja kerralla toimittavaa batch-kehystä ei ensivaiheessa hyödynnetä. Mikäli sosiaalihuollon asiakirjojen osalta toimitaan samoin, on tällöin huolehdittava toisiinsa liittyvien asiakirjojen linkittämisestä toisiinsa. Batch-kehyksen hyödyntäminen sosiaalihuollossa puoltaa paikkaansa esimerkiksi asiakirjan ja siihen kuuluvien liitteiden lähettämisessä. Samoin suostumusten lähettäminen yhtä aikaa pienentää erillisten viestien määrää ja helpottaa asiakirjojen linkitystä. Normaaleja sovellustason interaktioita kootaan batch-kehykseen Send Batch (MC- CI_IN200100UV) tilanteeseen sopiva tai sallittu määrä. Koko batch-sanomaan lähetetään yksi normaali arkiston vastaanottokuittaus Accept Ack (MCCI_IN000002UV01), jolloin batchin sisältämiin interaktioihin ei lähetetä erillisiä vastaanottokuittauksia. Batch-sanomaa ei myöskään kuitata sovellustasolla response batchillä Send Response Batch (MCCI_IN200101UV). Sovellustason vastaussanomat kootaan myös batchiin Send Batch (MCCI_IN200100UV) vastaavalla tavalla ja koko batch kuitataan normaalilla vastaanottokuittauksella MCCI_IN000002UV01. Vastaussanomat voivat nyt tulla useana eri batchinä (ilman rajoituksia). Interaktiota on mahdollista käyttää sosiaalihuollon asiakirjoilla, koska ne pystytään paketoimaan viestiin. Interaktio soveltuu sosiaalihuollon asiakirjojen arkistointiin tietyin tarkennuksin, joita käsitellään CDA R2 headerin hyödyntämisperiaatteiden yhteydessä (Paakkanen ym. 2009b) Hae kuvailutietoja Terveydenhuollossa asiakirjan metatietoja haetaan kahdella tasolla: hakutiedot ja kuvailutiedot. Sosiaalihuollossa ei ole erikseen säädettyjä suppeita hakutietoja, vaan asiakirjan kuvailutietoja ja asiakirjojen hakemisen hakuehtoja käsitellään sosiaalihuollon asiakirjojen kuvailutietoina. Terveydenhuollossa periaatteena on, että luovutustilanteissa tulee osoittaa sekä potilashallinnon varmistus että suostumus. Myös sosiaalihuollossa tullaan lähettämään suostumusasiakirjoja arkistoon, mutta varmistus/varmennekäytäntö poikkeaa nykyisestä KanTa-mallista. Sosiaalihuollossa erillisiä varmistusasiakirjoja ei lähetetä nykyisten määrittelyjen mukaisesti, vaan tieto asiayhteydestä esitetään viestitasolla. Tästä seuraa vaatimus sille, että viestissä on pystyttävä esittämään asiakastietojärjestelmän tuottama asiayhteys ja arkiston tulee pystyä käsittelemään sitä. 23

24 Kuvailutietojen hakemisella tarkoitetaan asiakirjojen metatietojen noutamista asiakastietojärjestelmään. Interaktion tärkeänä tarkoituksena on myös tukea käyttäjän tekemää asiakirjojen hakua siten, että ennen varsinaista asiakirjan fyysistä noutamista se voidaan yksilöidä tarkemmin hakuparametreina käytettävien kuvailutietojen avulla. Viestinvälityksen tulee mahdollistaa sosiaalihuollon metatietojen käyttäminen hakuparametreina. Hakemisessa käytettäviä parametreja on kuvattu myös arkistopalvelun määrittelyssä (Suhonen ym. 2009) ja niiden käyttötarkoitukset on tarkennettu metatietomäärityksen (Paakkanen ym. 2009a) liitteenä 1 olevassa taulukossa. Viestinvälityksen tulee mahdollistaa hakeminen kaikilla metatiedoilla, mutta yleisimmissä tapauksissa käytettäviä hakuparametreja ovat ainakin osa kaikille asiakirjoille pakollisista metatiedoista: Identifiointitunnus Alkuperäisen asiakirjan identifiointitunnus Palvelun järjestäjän organisaatiokoodi Palvelun järjestäjän nimi Palvelun tuottajan organisaatiokoodi Palvelun tuottajan nimi Ammattihenkilön nimi Ammattihenkilön tunniste Asiakkaan henkilötunnus Etunimet Sukunimi Sukupuoli Syntymäaika Asiakirjan tyyppi Prosessin (Asian) tunnus Asiakirjan nimi Palvelukokonaisuuden tunnus Palvelutehtävä Olennaisinta kuvailutietojen hakemisessa on, että käytettävät parametrit voidaan esittää viestitasolla palautesanomissa. Tämän tietosisällön soveltuvuutta arvioidaan luvussa ja tullaan tarkentamaan jatkomäärityksissä. Medical Records -mallin mukainen kuvailutietojen haku tapahtuu Find Document Metadata Query(RCMR_IN100029FI01) -interaktion avulla. Vastauksena saadaan sanomatyypin RCMR_MT100001FI01 ja lisärajoitusten mukaisia tietoja. Tietojen perusteella voidaan valita jokin asiakirjoista ja noutaa se arkistosta. Käytettävät kyselyparametrit ovat samat kuin koko dokumentin palauttavassa kyselyssä (ks. luku ). Kontrollikehyksen QueryByParameter -elementtiin on määritelty kyselyn keskeiset rajoitteet. Kyselyyn liittyvät yleiset kontrollitiedot ja niiden käyttöperiaatteet on kuvattu HL7 Finlandin suositus V3-viestien käyttöönottoon -dokumentin luvussa 2.4 (HL7 2008a). Kyselysanomia varten HL7 versio 3:ssa on kehitetty erillinen kyselyrunko (Query Infrastructure), jota käytetään kyselyiden toteutuksissa HL7v3:n eri domaineissa. Kyselyrunkoa pitää laajentaa domain-kohtaisella tiedolla, eli runkoon on lisättävä tarvittavat tietoelementit kyselyjen ja vastausten esittämiseen. Kyselyrunko sisältää yleisiä perusrakenteita, joita laajentamalla voidaan esittää parametri-tyyppiset kyselyt sekä itse parametrit. Kyselyviestin elementtien pakollisuus ja parametrien väliset suhteet (esim. boolean-logiikka) ilmaistaan domain-kohtaisessa määrittelyssä. Kyselyn runko voidaan tarvittaessa määrittää kokonaan itse, jos kyselyä ei voida toteuttaa valmiilla rakenteella. Myös kyselyiden vastausten lajitteluperiaatteille voidaan antaa useita parametreja. (HL7 2008a) 24

25 Kyseltävän tiedon ja haluttujen vastausten määrittäminen on täten suhteellisen vapaata jolloin tämän periaatteen hyödyntäminen myös sosiaalihuollon kyselyjen osalta on suositeltavaa. KanTa-arkiston Medical Records -mallin mukaan sekä kuvailutietoja että varsinaisia dokumentteja haettaessa kaikissa kyselyissä on pakollista rajata kysely koskemaan tiettyä terveydenhuollon potilasta. Poikkeuksena tähän on palvelupyyntö, jolla voidaan hakea rekisterinpitäjän omia tietoja ohi yksittäisten potilaiden. Tämä haku ei kuitenkaan ole käytössä alkuvaiheessa, mutta tarpeita sen hyödyntämiselle sosiaalihuollossa muun muassa tilastollisten hakujen yhteydessä on olemassa. Vaihtoehtoisesti on pakko antaa jokin seuraavista tiedoista: Potilaan yksilöivä tunniste (patient.id, haussa saa olla vain yksi potilas, omassa käytössä voidaan käyttää myös väliaikaista henkilötunnusta). Tässä voidaan hyödyntää sosiaalihuollon asiakkaan henkilötunnusta. Potilaan syntymäaika ja täydellinen sukunimi ja yksi etunimistä. Myös sosiaalihuollossa on havaittu käyttötapa tämäntyyppiselle kyselylle. Jos tietoja haetaan luovutustilanteissa syntymäajalla ja nimellä, arkisto rajaa hakutuloksesta pois palvelutapahtumat/asiakirjat joissa on virallinen henkilötunnus. Koska haku nimitietojen perusteella sisältää riskin että arkistosta saadaan tuloksena väärän potilaan tietoja, ei tällä hakukriteerillä haettuja tietoja saa tallentaa paikallisen potilaskertomuksen tietosisällöksi. Tietoja voidaan pelkästään katsella. Mikäli sosiaalihuollon arkistohaussa on tarpeen hakea tietoja asiakkaasta, joka ei ole yksilöitävissä henkilön tunnisteella tai etu- ja sukunimien ja syntymäajan perusteella, on hakukriteerit muodostettava eri tavalla tällaisessa tilanteessa Hae asiakirjoja Viestinvälityksen tulee mahdollistaa haluttujen asiakirjojen noutaminen arkistosta. Arkiston vaatimusmäärittelyjen mukaisesti viestinvälityksen tulee mahdollistaa myös pelkän näyttömuodon noutaminen arkistosta (palvelupyynnössä tulee pystyä ilmaisemaan palautettava tyyppi). Asiayhteys ja tarvittaessa suostumus tulee pystyä ilmaisemaan myös asiakirjojen hakupyynnöissä. Interaktiolla RCMR_IN100031FI pyydetään sanoman vastaanottajaa palauttamaan kaikki dokumentit, jotka täyttävät interaktion sisällä välitettävät kyselyparametrit. Interaktiossa käytetään yleistä siirtokehystä ja kontrollikehyksenä toimii Query Infrastructure -kohdealueessa määritelty QU- QI_MT021001UV01. Kyselyparametreja lukuunottamatta kyselyssä käytettävät rakenteet ovat yleisiä ja niitä käytetään samalla tavalla riippumatta sovellusalueesta. Kyselyn käsittelijä palauttaa interaktiolla RCMR_IN100032FI kyselyvastaukset. Toiminnallisuudeltaan interaktio vastaa sosiaalihuollossa tunnistettuja tarpeita Korvaa arkistoitu asiakirja Viestinvälityksen tulee mahdollistaa korvaussanomien lähettäminen, joilla jokin jo arkistossa oleva asiakirja korvataan toisella asiakirjalla. Document Replacement with Content(RCMR_IN100016FI01) -interaktiolla siirretään dokumentit, jotka korvaavat aiemman dokumenttiversion. Rakenteessa relateddocument ilmoitetaan korvattava asiakirja, sen indentifiointitunnus setid ja suhteen tyyppi. Dokumentista voidaan korvata vain uusin 25

26 versio. Asiakirjaa versioitaessa setid on ainoa kenttä joka ei saa muuttua. Arkiston lähettää sovellustason kuittauksen interaktiolla RCMR_IN120001FI01. Sosiaalihuollon osalta tulee hyödyntää myös metatietokenttiä korvaava asiakirja ja korvattu asiakirja, joilla ilmaistaan mikä asiakirja on korvattu millä asiakirjalla sellaisissa tilanteissa, joissa ei ole kysymys versioinnista vaan esimerkiksi myönteisellä päätöksellä korvataan kielteinen päätös Poista arkistoitu asiakirja Viestinvälityksen tulee mahdollistaa asiakirjojen poistaminen arkistosta sekä hävitystoimenpiteiden yhteydessä että ennen asiakirjan säilytysajan päättymistä, esimerkiksi jos kyseessä on virheellinen asiakirja. Poistamisessa hyödynnetään Medical Records -viestinvälityksessä korvaus-interaktiota (Document Replacement with Content), koska varsinainen asiakirjan hävittäminen tapahtuu vasta säilytysajan päätyttyä. Interaktion avulla arkistoon lähetetään tyhjä tai vastaava asiakirja. Sosiaalihuollossa vastaava lähestymistapa on otettu poistamisen käyttötapauksen pohjaksi myös arkistomääritysten osalta (Suhonen ym. 2009). Asiakirjojen poistamisia voi suorittaa myös arkistopalveluun liittyvän arkistonhoitajan käyttöliittymän kautta Metatietojen päivitys Viestinvälityksen tulee mahdollistaa päivitettäväksi määriteltyjen metatietojen muutoksiin kohdistuvat viestit. Metatietojen muutoksissa käytetään interaktiota Original Document (RCMR_IN100001FI01). Viestin clinicaldocument.id-kentässä annetaan muutettavan asiakirjan yksilöintitunnus. Muissa kentissä annetaan metatiedoille tulevat uudet arvot. Kaikkia kuvailutietoja ei pysty muuttamaan, vaan muutettavat tiedot on määriteltävä erikseen. Interaktio ei ole tällä hetkellä käytössä terveydenhuollossa, mutta sosiaalihuoltoon sille on tunnistettu tarve. Interaktion on tarkoitus tulla terveydenhuollossa käyttöön lähetteen käsittelyä ja luovutusilmoitusta hyödyntävien toimintojen yhteydessä. Interaktion käyttötarkoitus ei suoranaisesti ole metatietojen muuttaminen asiakirjan metatiedoissa olleiden virheiden takia, vaan tällaiset korjaukset on tarkoitus terveydenhuollossa toteuttaa versioimalla asiakirja. Alustavasti metatietomuutos voi olla mahdollista seuraavien kenttien osalta: hl7fi:extendedretentionperiod, asiakirjan pidennetty säilytysaika (säilytysaikaa ei voida lyhentää, jos asiakirja kuuluu usealle rekisterinpitäjälle, niin säilytysaika määräytyy sen rekisterinpitäjän mukaan joka on asettanut pisimmän säilytysajan) Rekisterinpitäjäketjuun liittyvät attribuutit: hl7fi:activecustodian o hl7fi:secondarycustodian (kuuluu myös rekisterinpitäjälle) o hl7fi:secondarycustodianid o hl7fi:secondarycustodianregisterid o hl7fi:linktodecisiondocument Sosiaalihuollossa päivitettäviksi ja muutettaviksi metatiedoiksi on määritelty seuraavat: aktiivi rekisterinpitäjä aktiivi rekisterinpitäjyysaika säilytysaika säilytysajan peruste pysyväissäilytettävä siirtoajankohta 26