Terveydenhuollon kansallisen tietojärjestelmäarkkitehtuurin määrittelyprojekti ARKKKITEHTUURIMÄÄRITTELY --- Versio 1.0 --- Laatija: STM ja konsultit Tarkistaja: Hyväksyjät:
ARKKITEHTUURIMÄÄRITTELY SISÄLLYSLUETTELO 1 JOHDANTO... 1 1.1 Dokumentin sisältö... 1 2 VIESTINVÄLITYKSEN NYKYTILA... 2 2.1 Potilastietojärjestelmien välinen liikenne... 2 2.1.1 Yleistä... 2 2.1.2 Tekninen toteutus... 3 2.2 Viitetietojärjestelmät... 3 2.2.1 Yleistä... 3 2.2.2 Tekninen toteutus... 5 3 VIESTINVÄLITYKSEN TAVOITETILA... 6 3.1 Viestinvälitysarkkitehtuuri... 6 3.2 Viestinvälityksen osapuolet... 7 3.2.1 Tiedon tuottajat... 7 3.2.2 Tiedon käyttäjät... 7 3.2.3 Kansallinen terveydenhuollon arkisto (KANTA)... 8 3.2.4 Sähköinen Lääkemääräys (eresepti)... 9 3.2.5 Lakisääteiset henkilörekisterit... 9 3.3 Viestinvälitykselle osoitetut vaatimukset... 9 3.4 Viestinvälityksen tehtävät... 10 3.4.1 Sanomaliikenne (vastaanotto ja lähetys)... 11 3.4.2 Puskurointi... 11 3.4.3 Kehyskäsittely... 11 3.4.4 Tarkistukset... 11 3.4.5 Palveluorkestrointi... 11 3.4.6 Valvonta ja hallinta... 12 3.4.7 Monitorointi... 12 3.4.8 Virheenkäsittely... 13 3.4.9 Kuittaukset... 13 3.4.10 Viestien edelleenvälitys... 13 3.5 Ulkoiset palvelut... 13 3.6 Osoitehakemisto... 13 4 VIESTINVÄLITYKSEN TEKNINEN ARKKITEHTUURI... 15 4.1 Teknisen arkkitehtuurin yleiskuvaus... 15 4.2 Viestinvälitysrajapinta... 17 4.3 Viestinvälitykseen liittyvät komponentit... 19 4.3.1 Tietoliikenne... 19 4.3.2 Sanomanvälityspalvelut... 19 4.3.3 Palveluväylä... 19 4.3.4 Prosessimoottori... 19 4.3.5 Adapterit... 20 4.3.6 Virheenhallinta ja monitorointi... 20 4.4 DICOM kuvamateriaali... 20 4.5 Käytettävät standardit... 22 4.6 Tietoliikenneratkaisu... 22 4.6.1 Tietoliikenneratkaisun kuvaus yleisellä tasolla... 22 4.6.2 Tietoliikenneratkaisuun vaikuttavat tekijät... 27
ARKKITEHTUURIMÄÄRITTELY o ii 4.6.3 Palvelunestohyökkäykset... 28 4.7 Tietoturva... 28 4.7.1 Yleisiä tietoturvavaatimuksia... 28 4.7.2 Tietoturvan tekninen yleiskuvaus... 30 4.7.3 Viestinvälityksen osapuolten tunnistaminen ja varmentaminen... 32 4.7.4 Tiedon salaaminen... 34 5 SUOSITUKSIA... 35 5.1 Potilastietojärjestelmien teknisiä vaatimuksia... 35 5.2 KanTo:n osajärjestelmien teknisiä vaatimuksia... 35 5.3 Muita suosituksia ja kommentteja... 35
ARKKITEHTUURIMÄÄRITTELY 1 /35 1 JOHDANTO 1.1 Dokumentin sisältö Tämä dokumentti keskittyy arkistopalvelun viestinvälityksen teknisen ratkaisun kuvaamiseen sekä tarkentaa tietojärjestelmän kokonaisarkkitehtuurissa koottua määrittelyä arkistopalveluista viestinvälityksen osalta.
ARKKITEHTUURIMÄÄRITTELY 2 /35 2 VIESTINVÄLITYKSEN NYKYTILA 2.1 Potilastietojärjestelmien välinen liikenne 2.1.1 Yleistä Kuva 1: Viestinvälityksen nykytila. Potilastietojärjestelmien välinen liikenne on etukäteen sovittua kahdenvälistä liikennettä. Nykytilassa kahdenvälisen sopimisen piiriin kuuluvat mm. tietoliikennemäärittelyt ja tunnisteet, sanomissa välitettävät tiedot, rakenteet ja koodit. Sen sijaan sanomamuodoissa ja protokollien määrittelyssä useimmiten tukeudutaan olemassa oleviin standardeihin tai yleisesti hyväksyttyihin suosituksiin. Näitä kuitenkin sovelletaan tapauskohtaisesti, joten rakennetut yhteydet kokonaisuutena harvoin täyttävät standardien vaatimuksia. Merkittävät sovellusalueet potilastietojärjestelmien välisessä liikenteessä ovat laboratoriopyynnöt ja -vastaukset, röntgenpyynnöt ja -vastaukset, lähetteet ja palautteet sekä radiologian ajanvaraukset. Laboratorioliikenne on sanomavolyymiltaan selkeästi suurin. Potilastietojärjestelmien välisen liikenteen tehtävä on mahdollistaa toimintojen hajauttaminen yksiköiden välillä. Liikenne on kaksisuuntaista. Operaatioihin liittyvät tarpeelliset tiedot välitetään sanomina yksiköstä toiseen ja potilas voi asioida toisessa yksikössä. Asioinnin tuloksena syntyneet tiedot palautetaan takaisin alkuperäiseen yksikköön vastaussanomana. Esimerkiksi laboratorioliikenteessä tapahtumaketju kulkee sanomaliikenteessä seuraavasti:
2.1.2 Tekninen toteutus 2.2 Viitetietojärjestelmät 2.2.1 Yleistä ARKKITEHTUURIMÄÄRITTELY 3 /35 1. Potilastietojärjestelmässä tehdään pyyntö laboratoriotutkimuksesta. Järjestelmä muodostaa pyynnöstä pyyntösanoman, joka lähetetään laboratoriojärjestelmään. 2. Laboratoriojärjestelmä vastaanottaa pyyntösanoman ja kirjaa laboratoriopyynnön tiedot omaan järjestelmäänsä. 3. Tutkimus valmistuu ja se kirjataan laboratoriojärjestelmään, laboratoriojärjestelmä muodostaa tulossanoman ja lähettää sen potilastietojärjestelmään. 4. Potilastietojärjestelmä vastaanottaa tulossanoman ja kirjaa tuloksen tiedot omaan järjestelmäänsä. Laboratorioliikenteen lisäksi muu olemassa oleva potilastietojärjestelmien välinen liikenne on luonteeltaan esimerkin kaltaista. Sanomaliikenne tapahtuu IP -verkossa. Käytössä on paikallinen tai muuten suljettu verkko tai julkiseen Internetiin rakennettu salattu verkko. Eräissä tapauksissa liikenne tapahtuu salaamattomana julkisen Internetin päällä. Sanomat ovat pääsääntöisesti HL7 V2.3 muotoisia sanomia. Myös muita sanomamuotoja on jonkin verran käytössä. Kuten edellä on mainittu, käytetty sanomamuoto saattaa olla standardoitu, mutta sen soveltamisesta on usein sovittu kahdenkeskisesti. Sanomien siirtoon käytetään joko FTP-protokollaa tai HL7 MLLP-protokollaa, joka on erittäin ohut TCP/IP:n päällä toimiva protokolla: toinen osapuoli avaa yhteyden etukäteen sovittuun kumppanin tietoliikenneporttiin ja lähettää sanoman. Sanoman ympärillä lähetetään ainoastaan aloitus- ja lopetusmerkit. Lähetyksen jälkeen odotetaan kuittausmerkkiä kumppanilta. Potilastietojärjestelmien ja viitetietojärjestelmien välinen liikenne on etukäteen määriteltyä kahdenvälistä liikennettä. Merkittävin ero perinteisiin potilastietojärjestelmien välisiin yhteyksiin viitetietojärjestelmäliikenteessä on modernimpien tekniikoiden käyttö, tietoliikenteen salaus, tiukempi standardien noudattaminen ja yleisesti edustapalvelinten ja -tietokantojen käyttö. Sanomissa käytetyt tiedot, rakenteet ja koodit ovat kansallisella tasolla sovittuja, ja kahden toimijan välille rakennettu yhteys on standardien mukainen - yhteyden kummassakin päässä voidaan toteutus tarvittaessa vaihtaa ilman että se vaikuttaa itse yhteyteen.
ARKKITEHTUURIMÄÄRITTELY 4 /35 Yleinen toimintamalli viitetietojärjestelmäympäristössä on seuraava: 1. Potilastietojärjestelmän adapterikomponentti tarjoaa viitetietojärjestelmälle rajapinnan, jonka kautta viitetietojärjestelmä voi lukea tietoja standardissa CDA R1 -muodossa. 2. Adapterikomponenttina voi toimia myös erillinen, omalla edustatietokannalla varustettu edustajärjestelmä. Potilastietojärjestelmä välittää potilasasiakirjat etukäteen edustakantaan CDA R1 muodossa. CDA R1 - muodon lisäksi potilastietojen siirto voi tapahtua muussa, sisäisessä muodossa. Tällöin edustajärjestelmä muuntaa potilasasiakirjan CDA R1 muotoon. 3. Adapterikomponentti lähettää potilasasiakirjoista viitetiedot eli asiakirjojen hakutiedot viitetietojärjestelmään. 4. Viitetietojärjestelmä tarjoaa käyttöliittymän viitetietojen selaukseen ja asiakirjojen hakuun. Käyttöliittymä on yleensä selainpohjainen. 5. Kun käyttäjä pyytää asiakirjaa, viitetietojärjestelmä ottaa yhteyden potilastietojärjestelmän adapterikomponenttiin ja pyytää asiakirjan. 6. Adapteri käsittelee pyyntösanoman synkronisesti ja palauttaa pyydetyn asiakirjan vastauksena pyyntöön. Viitetietojärjestelmät eivät tarjoa rajapintoja niihin tallennettujen viitteiden lukemiseksi. Viitetietojärjestelmässä olevia hakutietoja voidaan selata ainoastaan viitetietojärjestelmään integroidun sovelluksen välityksellä. Edellisestä poiketen on Kainuussa käytössä ns. Kainuun malli 1, jossa kaksi potilastietojärjestelmää keskustelee suoraan keskenään. Tässä tapauksessa viitetietoja ei välitetä potilastietojärjestelmien välillä etukäteen, vaan potilastietojärjestelmät pyytävät viitetiedot toisiltaan sitä mukaa, kun käyttäjät niitä pyytävät. Kainuun malli eroaa viitetietojärjestelmäratkaisuista ainoastaan siinä, että lähettämisen sijaan viitetiedot haetaan potilastietojärjestelmistä - käytössä on täsmälleen samat sanomat kuin viitetietojärjestelmäliikenteessä, ainoa lisä on viitetietojen hakuun käytettävä sanoma. Potilastietojärjestelmän vastaussanoma on sama kuin viitetietojen lähetyssanoma viitetietojärjestelmissä. Vastaavaa malli on käytössä omien historiatietojen lukemiseen muutamissa ympäristöissä, joissa potilastietojärjestelmiä on yhdistetty eikä historiatietoja ole haluttu siirtää uuteen kantaan. Viitetietojärjestelmäliikenteen osalta kahdenvälinen sopiminen rajoittuu yleensä tietoliikennetietoihin ja sanomaliikenteeseen liittyviin osapuolikoodeihin. Liikennöivien järjestelmien on tunnettava toistensa osapuolikoodit, jotta sanoma voidaan lähettää ja vastaanottaa. Jos asiakontekstiin liittyviä kansallisia koodistoja ei ole olemassa tai niitä ei ole otettu käyttöön potilastietojärjestelmässä (esim. palvelumuotokoodit), joudutaan kahdenvälisesti sopimaan myös sanomien sisällöissä käytettävistä koodeista. 1 Muita malleja esimerkiksi KAAPO- ja ESKO-mallit. Näistä molemmista on kuvaukset Stakes-raportissa 7/2006, Ilkka Winblad et al, Informaatio- ja kommunikaatioteknologian käyttö Suomen terveydenhuollossa vuonna 2005.
ARKKITEHTUURIMÄÄRITTELY 5 /35 2.2.2 Tekninen toteutus Sanomaliikenne tapahtuu Avoimet Rajapinnat -määrityksiä käyttäen, eli Avoimet Rajapinnat -määrittelyn mukaisilla otsikoilla varustetuilla SOAP -sanomilla TLS - salatun http-yhteyden yli. Sanomaliikenteen molemmat osapuolet varmennetaan aina X.509 -varmenteilla. Sanomaliikenne tapahtuu salattuna julkisessa Internetissä. Osapuolet ottavat suoraan yhteyden toisiinsa eli välissä ei käytetä sanomien välityspalvelimia. Tällä hetkellä sanomissa siirretään CDA R1 -muotoisia asiakirjoja ja viitteitä (asiakirjan otsikkotiedot). Avointen Rajapintojen uusi määritys eli HL7 OpenCDA 2006 -määritykset sisältävät myös sanomat CDA R2 -asiakirjojen siirtoon. Tuotantokäytössä ei näitä toistaiseksi kuitenkaan ole.
ARKKITEHTUURIMÄÄRITTELY 6 /35 3 VIESTINVÄLITYKSEN TAVOITETILA 3.1 Viestinvälitysarkkitehtuuri Terveydenhuollon kansallinen arkkitehtuuri, jossa näkyvät terveydenhuollon kansalliset toimijat ja kansallisen terveydenhuollon arkiston (KANTA) osajärjestelmät on esitetty kuvassa 2. KANTA on osan Kelan vastuulla olevaa Kansallinen Toimija (KanTo) palveluklusteria. KANTA:n lisäksi KanTo tarjoaa myös Sähköisen Lääkemääräyksen (ereseptin) reseptikeskuspalvelun reseptien ja niiden toimitustietojen välittämiseen apteekkijärjestelmien ja potilastietojärjestelmien välillä. Viestinvälityksen arkkitehtuuri on suunniteltu niin, että sekä KANTA:n että ereseptin tarpeet täyttyvät. Siten tässä dokumentissa kuvataan KanTo-viestinvälitysarkkitehtuuria, mutta arkkitehtuuria määriteltäessä päähuomio on ollut KANTA:n vaatimalla toiminnallisuudella. Tämä dokumentti kuvaa viestinvälityksen arkkitehtuurin. KANTA:n muita osajärjestelmiä ovat Tunnistus ja Sähköinen allekirjoitus, Koodistot, Hakemisto ja Rekisteröinti, Arkisto, Suostumuksen hallinta ja Lokipalvelu. Kuvan 2 yläosassa on kuvattu KANTA:an tietoa tuottavat ja niitä käyttävät osapuolet. Lisäksi kuvassa esiintyy ip-verkkoratkaisut ja varmenteita tuottavat ulkoiset osapuolet. KANTA ei edellytä muita ulkoisia osapuolia, ja toimijoiden väliseen viestinvälitykseen riittää IP -verkon tarjoamat palvelut. Palveluväylä toteuttaa rajapinnat, joilla tiedon tuottajat, tiedon käyttäjät ja KAN- TA vaihtavat potilasasiakirjoja ja kuvantamisaineistoja keskenään. Sen toinen päätehtävä on orkestroida KANTA:n julkisia palveluja, kuten asiakirjojen luonti, asiakirjojen käyttäminen ja asiakirjojen hallinta. Tietoa KANTA:an tuottavat ja sitä käyttävät järjestelmät käynnistävät prosesseja, jotka koostuvat KANTA:n osajärjestelmien tarjoamista sisäisistä palveluista. Tässä dokumentissa kuvattu viestinvälityksen arkkitehtuuri on niin suunniteltu, että sitä voidaan helposti laajentaa hyödynnettäväksi myös ereseptin viestinvälityksen tarpeisiin. Lisäksi lakisääteisten terveydenhuollon henkilörekisterien tilastotuotannon tarpeisiin voidaan tehdä laajennus tilastotiedon välittämiseksi kansallisille terveydenhuollon tilastojen tuottajille, kuten esim. Stakes.
ARKKITEHTUURIMÄÄRITTELY 7 /35 Kuva 2: Viestinvälityksen rooli kansallisessa arkkitehtuurissa. 3.2 Viestinvälityksen osapuolet 3.2.1 Tiedon tuottajat 3.2.2 Tiedon käyttäjät Tiedon tuottajat lähettävät asiakirjoja arkistoon viestinvälitysrajapinnan kautta. Tuottajina toimivat erityisesti terveydenhuollon yksikköjen potilastietojärjestelmät. Tietoa voivat tuottaa myös muut viestinvälityksen osapuolet, mutta tässä dokumentissa kuvataan tarkemmalla tasolla suoranaisesti Arkistoon liittyvät osapuolet. Arkiston lisäksi tuotettua tietoa voidaan välittää tarvittaessa muillekin osapuolille, kuten Stakes, KTL ja Lääkelaitos tilastojärjestelmille. Tiedon käyttäjät voivat hakevat asiakirjoja arkistosta viestinvälitysrajapinnan kautta. Tiedon käyttäjiä ovat muun muassa terveydenhuollon yksiköt ja kansalaisportaali.
ARKKITEHTUURIMÄÄRITTELY 8 /35 3.2.3 Kansallinen terveydenhuollon arkisto (KANTA) Arkisto Arkisto-osajärjestelmän tehtävänä on tarjota tietoturvallinen luotettu arkisto potilasasiakirjoille, kuten lähetteille, lääkemääräyksille, laboratoriolausunnoille sekä röntgenkuville. Palvelu mahdollistaa potilastietojen haun ja käytön paikasta ja ajasta riippumatta terveydenhuollon ammattihenkilön toimesta hänen käyttöoikeuksiensa ja potilaan suostumusten puitteissa. Arkisto-osajärjestelmään tietoja tuottavat potilastietojärjestelmät. Hakemisto ja rekisteröinti Hakemisto- ja rekisteröintipalvelu toimii osana kansallista arkistopalvelua tarjoten toiminnallisuuden, jonka avulla arkistopalvelu rekisteröi arkistoitujen asiakirjojen tiedot tai terveydenhuollon potilastietojärjestelmä rekisteröi hallinnoimiensa keskeneräisten asiakirjojen tiedot hakemisto- ja rekisteröintipalveluun. Rekisteröinnillä tarkoitetaan asiakirjan kuvailu- ja hakutietojen tallentamista palveluun siten, että niitä voidaan käyttää asiakirjojen hakemiseen. Asiakirjojen rekisteröintipalvelun lisäksi hakemisto- ja rekisteröintipalvelu tarjoaa teknisen palvelurajapinnan kautta toiminnallisuuden, jota hyödyntäen tietoa käyttävät potilastietojärjestelmät voivat hakea palveluun rekisteröityjä asiakirjoja erilaisin hakuehdoin. Tarkemmin Hakemisto- ja rekisteröintipalvelua on kuvattu sen vaatimusmäärittely- dokumentissa. Suostumusten hallinta Suostumustenhallinnan palvelu toimii osana kansallista sähköisten potilasasiakirjojen arkistointipalvelua. Sen tarkoitus on tarjota toiminnallisuus kansallisesti keskitetysti hakemistotietojen näkymisen ja sähköisten potilasasiakirjojen luovutusten sallimiseen tai kieltämiseen terveydenhuollon palvelun antajien välillä tai palvelun antajalta muulle tietoja tarvitsevalle osapuolelle. Suostumustenhallinnan palvelu tukee kieltojen ja suostumusten noudattamista perustuen kielto- ja suostumusasiakirjoihin. Nämä asiakirjat tuotetaan terveydenhuollon palvelun antajien potilastietojärjestelmissä. Arkistopalvelu arkistoi nämä asiakirjat ja rekisteröi ne. Koodisto Kansallinen koodistopalvelu mahdollistaa sen, että terveydenhuollon organisaatiot voivat luovuttaa tietoa yhteisesti sovituin rakentein keskitetyn arkiston välityksellä käyttäen yhteisiä koodistoja. Koodistopalvelun rajapinnan käyttäjiä ovat potilastietojärjestelmät ja KANTA:n sisäiset palvelut. Koodistopalvelun sisällöstä vastaa Stakes ja palvelun teknisestä toteutuksesta tulevaisuudessa Kela.
ARKKITEHTUURIMÄÄRITTELY 9 /35 Loki- ja valvonta Kansalaisella on oikeus saada tieto, mitä tietoja hänestä säilytetään, kenelle niitä on luovutettu ja ketkä ovat hänen tietojaan käyttäneet. Terveydenhuollon ammattilaisen oikeusturva edellyttää tietoa siitä, mitä tietoja on käytetty hänen tehdessään potilaan hoitoa koskevia päätöksiä. Tämän lisäksi rekisterinpitäjältä edellytetään aktiivista valvontaa, että väärinkäyttötapauksia ei pääse tapahtumaan. KANTA:n loki- ja valvontapalveluiden tehtävä on kerätä tarvittava tieto lokeihin, jotta pystytään toteuttamaan laissa määrätyt tiedonsaantivelvollisuudet sekä samalla mahdollistaa aktiivinen valvonta. Loki ja valvontapalvelun vastuulla on toteuttaa asiakirjojen luovutus- ja arkiston käyttölokit. Lisäksi tarvitaan tapahtumaloki, jonne kirjataan lokia palvelurajapinnan suorittamista prosesseista valvontatarkoituksiin. Palveluväylä kerää tätä tapahtumalokia osana valittavan integraatioalustan toiminnallisuutta. Valittava integraatioalusta toteuttaa järjestelmän toimivuuden ja tehokkuuden valvonnan myös muilta osin. Loki- ja valvontavaatimukset sisältyvät kaikilta, myös viestinvälityksen toteuttamilta, osin Loki-ja valvontapalvelun vaatimusmäärittely-dokumenttiin. 3.2.4 Sähköinen Lääkemääräys (eresepti) Sähköinen lääkemääräys on erillinen projekti, joka keskittyy sähköisen reseptin mahdollistavan järjestelmän toteuttamiseen. Sekä ereseptin että KANTA:n teknisenä palveluntarjoajan on Kela. Tämä mahdollistaa synergia etuja palvelutuotannossa, kun jo KANTA:n määrittelyissä huomioidaan ereseptin suunnittelu ja päinvastoin. Tunnistettuja yhtymäkohtia ovat kansalaisen katseluyhteys ja viestinvälitysarkkitehtuuri 3.2.5 Lakisääteiset henkilörekisterit Samaa sanomarajapintaa ja siihen rakennettavia palveluita voidaan hyödyntää lakisääteisten henkilörekisterien tilastomateriaalin keruussa. Terveydenhoidon yksiköt toimittavat tilastomateriaalin sanomanvälitysrajapintaan, josta tiedot välittyvät ym. organisaatioiden ylläpitämiin tilastotietojen vastaanottopalveluihin. 3.3 Viestinvälitykselle osoitetut vaatimukset Viestinvälitykselle osoitetut vaatimukset on kuvattu dokumentissa Kanta- Viestinvälityksen Vaatimusmäärittely.
3.4 Viestinvälityksen tehtävät ARKKITEHTUURIMÄÄRITTELY 10 /35 Arkisto Hakemisto- ja rekisteröinti Suostumusten hallinta Loki- ja valvonta Koodisto eresepti Palvelu X Kuva 3: Viestinvälitys Viestinvälitysarkkitehtuuri muodostuu osapuolista (terveydenhoidon yksiköt, apteekit, Stakes jne.), tietoliikenteestä (IP-verkko) sekä palveluväylästä. Viestinvälitys hoitaa KANTA:n sisäisten ja ulkoisten palveluiden sanomien käsittelyn, sisältäen sanomien eheystarkistukset, sanomien kehysmuunnokset, ja sanomien välittämisen KANTA:n palveluille palveluväyläratkaisua hyödyntäen. Palveluväylä tarjoaa myös palvelut sanomaliikenteen valvontaan ja monitorointiin. Kuvan 3 mukainen palveluväylä tarkoittaa sekä osajärjestelmien sanomaliikennettä, että palveluiden orkestrointia prosessimoottorin ja KANTA-palveluiden kesken. KANTA-osajärjestelmät ja liitännäisjärjestelmät tarjoavat viestinvälitysrajapinnan kautta sekä sanomia että palveluita sovituilla siirtoprotokollilla (oletusarvoisesti https) ja sanomaformaateilla (oletusarvoisesti HL7 V3).
ARKKITEHTUURIMÄÄRITTELY 11 /35 3.4.1 Sanomaliikenne (vastaanotto ja lähetys) 3.4.2 Puskurointi 3.4.3 Kehyskäsittely 3.4.4 Tarkistukset 3.4.5 Palveluorkestrointi Palveluväylä tarjoaa rajapinnan arkiston palveluiden käyttämiseksi terveydenhuollon perus- ja aluejärjestelmistä luvussa 5 kuvattujen standardi-, tietoliikenneprotokolla- ja tietoturvavaatimusten mukaisesti. Sanomaliikenteellä KANTA:ssa tarkoitetaan oletusarvoisesti asynkronisia ja synkronisia http/http(s) protokollan läpi välitettäviä sanomia. Yleisesti ottaen kyselysanomat voidaan toteuttaa synkronisina, mutta päivittävät sanomat voidaan toteuttaa synkronisina vain vastaanottokuittaukseen (mikäli käytössä), mutta ei sovellustason kuittaukseen asti. Kun sanoma on vastaanotettu ja hyväksytty, siirretään sanoma palveluorkestrointiin (prosessimoottori). Hyväksynnällä tarkoitetaan asiakasvarmenneen hyväksyntää. Palveluväylä huolehtii sanoman säilyttämisestä, kunnes vastaanottava arkiston osajärjestelmä on sen onnistuneesti käsitellyt tai virhetilanteessa lähettäjälle on palautettu virhekuittaus. Kehyskäsittelyllä tarkoitetaan XML -sanomien mahdollista pilkkomista tai uudelleen kokoamista palveluväylän sisällä. Esimerkiksi vastaanotettuun sanomaan voidaan lisätä kehys tai poistaa siirtokehykset, ennen sanoman toimittamista KAN- TA-palvelulle. Kehyskäsittelyssä ei muuteta siirrettävän asiakirjan sisältöä eikä palveluväylä koskaan avaa tai käsittele sanomassa kuljetettavaa asiakirjaa. Palveluväylä vastaa varmenteiden ja viestinvälitykseen liittyvien sanomakehysten oikeellisuuden tarkistuksesta ja muun sanomasisällön muodon oikeellisuuden tarkistuksesta. Palvelinvarmenteella varmistutaan siitä, että kommunikoiva järjestelmä on luotettu. Palveluväylän sisällä tehdään tarvittaessa myös muiden varmenteiden (esimerkiksi Web Services Security) tarkistukset. Virhetilanteissa palveluväylä palauttaa virhekuittauksen sanoman lähettäneelle järjestelmälle ja tekee lokimerkinnän. Virhetilanteet aiheuttavat koko sanoman hylkäämisen ja sen ettei sanoman sisältämiä asiakirjoja välitetä muille arkiston osajärjestelmille. Tarkistusten laajuus ja käyttö eri tilanteissa tullaan määrittelemään tarkemmin myöhemmissä jatkomäärittely-, suunnittelu- ja toteutusvaiheissa. Palveluväylän eräs keskeinen tehtävä on toteuttaa prosessinohjauskerros kokonaisarkkitehtuurissa. Palveluväylä orkestroi muiden arkiston osajärjestelmien tarjoamia palveluita arkistojärjestelmän käyttötapausten toteuttamiseksi. Käyttötapaukset ja prosessit on kuvattu pääosin kokonaisarkkitehtuurin määrittelyssä. Palveluväylä tarjoaa ajo- ja kehitysympäristön palveluorkestroinnille.
3.4.6 Valvonta ja hallinta 3.4.7 Monitorointi ARKKITEHTUURIMÄÄRITTELY 12 /35 Palveluiden orkestrointi tekee mahdolliseksi myös toimintaprosessien seurannan. Prosessin status voi olla käynnistetty, käynnissä, odottaa, valmis, virhe jne. Orkestroinnissa on oltava myös rajapinnat palveluväylän valvontaan ja monitorointiin. Erilaiset häiriötilanteet raportoidaan suoraan valvontaohjelmistolle. Esimerkkejä häiriöistä ovat tietoliikenneongelmat, sanomaliikenteessä olevat ongelmat, tietoturvaongelmat jne. Monitoroitavia asioita voivat olla esimerkiksi sanomavolyymit, ts. kuinka paljon sanomia liikkuu rajapintojen kautta, miten tehokkaasti kuvatut toimintoprosessit toimivat jne. Palveluiden orkestroinnista palveluväylässä vastaa prosessimoottori, joka käsitetään kuvatussa arkkitehtuurissa loogisena komponenttina. Palveluväylä tarjoaa välineet arkiston toimivuuden valvomiseksi arkiston ajoympäristöstä vastaavalle tekniselle henkilöstölle. Valvonta käsittää käyttöliittymän, teknisen lokin sekä välineet lokin tehokkaalle analysoinnille. Käyttöliittymällä on kyettävä seuraamaan järjestelmän kuormitusta, suorituskykyä ja poikkeustilanteita. Käyttöliittymän tulee mahdollistaa ylläpitotoimenpiteitä vaativat tilanteet välittömästi, sekä niiden tehokas paikallistaminen. Palveluväylässä liikkuu paljon viestejä ja toiminnan on oltava häiriötöntä. Valvonta on siis suoritettava pääosin automaattisesti. Kun palveluväylässä tapahtuu häiriöitä, on näistä automaattisesti lähetettävä häiriöilmoituksia valvojille ja hallintaan. Valvonnan yhteydessä suoritetaan myös häiriötilanteita ehkäiseviä automaattisia korjaustoimenpiteitä. Valvonta vastaanottaa myös orkestroinnista lähtöisin olevia sovellusvirheilmoituksia. Virheilmoituksia tulee sekä palveluväylästä (tekniset virheet) että palveluista. Virheilmoitukset priorisoidaan ja virheet käsitellään näiden mukaisesti. Osa virheistä voi olla informaatiovirheitä, jotka ainoastaan tilastoidaan lokeihin. Kriittiset virheet edellyttävät välittömiä toimia häiriötilanteen poistamiseksi. Hälytyksille tulee olla hallintaliittymä, jonka avulla virheet voidaan ohjata esimerkiksi sähköposteihin, tekstiviesteiksi tai järjestelmäkonsolille. Monitoroinnissa seurataan palveluväylän sanomaliikennettä kuvaruutunäytöistä ja raporteista. Seurantaa on voitava myös tehdä erilaisilla esimerkiksi aikaan perustuvilla kriteereillä (viestiä päivässä, viestiä tunnissa, viestiä kuukaudessa jne.). Monitoroinnissa on voitava asettaa erilaisia hälytysrajoja, esimerkiksi sanomaliikenteen hidastuminen aiheuttaa hälytysrajan ylittymisen. Toimintaprosessien seuranta on myös osa monitorointia. Tyypillisesti tarkasteltavana ovat prosessien tilat, orkestroinnin suoritusstatistiikka jne.
ARKKITEHTUURIMÄÄRITTELY 13 /35 3.4.8 Virheenkäsittely 3.4.9 Kuittaukset KANTA:n häiriötilanteissa palveluväylä tarjoaa yleisen virheenkäsittelypalvelun rajapintaan liitetyille palveluille, ts. sanomaliikenteeseen liittyvää virheenkäsittelyä ei rakenneta sovelluskohtaisesti, vaan se keskitetään palveluväylään. Virheenkäsittelyä ja siihen liittyvää sanomaliikennettä on kuvattu kokonaisarkkitehtuurin kuvauksessa, mutta se kiinnitetään lopullisesti suunnitteluvaiheessa. Palveluväylä huolehtii sanoman vastaanotto- ja virhekuittausten muodostamisesta ja lähetyksestä. Muiden kuin kohdassa 3.4.4 mainittujen virhetilanteiden havaitseminen on kuitenkin arkiston muiden osajärjestelmien vastuulla. Kuittaukset noudattavat HL7 V3 suosituksia. Palveluväylä vastaa siitä, että sanoma joko käsitellään onnistuneesti arkistojärjestelmässä tai lähettäjä saa virhekuittauksen 3.4.10 Viestien edelleenvälitys 3.5 Ulkoiset palvelut 3.6 Osoitehakemisto Lakisääteiset henkilörekisteri -tilastot tarkoittavat viestinvälityksessä, että samaa sanomarajapintaa ja siihen rakennettavia palveluita voidaan teknisesti hyödyntää Stakesin, KTL:n ja Lääkelaitoksen tilastomateriaalien vastaanotossa ja edelleen välittämisessä. Terveydenhoidon yksiköt toimittavat tilastomateriaalin sanomanvälitysrajapintaan, josta tiedot välittyvät ym. organisaatioiden tilastojen vastaanottopalveluihin. Tilastosanomat ovat HL7 / https tyyppisiä. Sanomien kuljetuskerroksena tulee olemaan HL7 V3. Vastaavasti viestinvälitystä voidaan teknisesti hyödyntää esimerkiksi potilastietojärjestelmiltä vakuutusyhtiöille (ml. Kela) reititettävien lausuntojen ja todistusten edelleenvälittämisessä. KANTA:n ulkoiset palvelut koostuvat sen osajärjestelmien toteuttamista sisäisistä palveluista, joita palveluväylässä toimiva prosessimoottori orkestroi. Ulkoiset palvelut on kuvattu dokumentissa KANTA-Kokonaisarkkitehtuuri, arkkitehtuurimäärittely. Sanomaliikenteen edellytyksenä on, että siihen osallistuvat osapuolet tietävät, miten muihin osapuoliin saadaan yhteys. Sanoman lähettämiseksi tarvitaan vähintään tieto kumppaniosapuolen osoitteesta. Osoitehakemisto on täten välttämätön osa arkkitehtuuria. Perinteisesti järjestelmissä on yleensä muodostettu point-to-point -yhteyksiä osapuolten kesken. Ratkaisun kaikilla osapuolilla on oma osoitehakemisto, johon kumppaneiden osoitteet on tallennettu. Myös KanTo tarvitsee kumppaneiden eli potilastietojärjestelmien ja muiden viestinvälitykseen osallistuvien osapuolten osoitteet voidakseen lähettää esimerkiksi
ARKKITEHTUURIMÄÄRITTELY 14 /35 kuittaussanomia. Lisäksi potilastietojärjestelmät tarvitsevat arkiston viestinvälitysrajapinnan osoitteen. KanTo:n osoitehakemisto on syytä toteuttaa kansallisena palveluna, jota voidaan hyödyntää sekä arkistoliikenteessä että mahdollisesti myös potilastietojärjestelmien välisessä liikenteessä. Myöhemmin sitä voidaan hyödyntää myös muissa kansallisissa terveydenhuollon palveluissa. Osoitehakemiston tehtävä on tallentaa tiedot sanomaliikenteen osapuolista, niiden tarjoamista palvelurajapinnoista ja rajapintojen osoitteista. Kukin sanomaliikenteen osapuoli tunnistetaan yksikäsitteisellä sanomaliikenteen osapuolitunnuksella, joka myös esiintyy kaikissa osapuolen lähettämissä tai osapuolelle osoitetuissa sanomissa. Myös palvelurajapinnat tunnistetaan yksikäsitteisellä koodilla. Kunkin osapuolen kullekin palvelurajapinnalle määritellään osoite (URL), johon kyseisen osapuolen ko. rajapintaan osoitetut sanomat lähetetään.
ARKKITEHTUURIMÄÄRITTELY 15 /35 4 VIESTINVÄLITYKSEN TEKNINEN ARKKITEHTUURI 4.1 Teknisen arkkitehtuurin yleiskuvaus Kuva 4: Viestinvälitysarkkitehtuuri Palveluväylässä käytetään SOA mallia, jossa osapuolet kommunikoivat keskenään palvelurajapintojen välityksellä. Alla on esitelty arkkitehtuurin suositeltavat linjaukset:
ARKKITEHTUURIMÄÄRITTELY 16 /35 Sanomaliikenteen tiedonsiirtoprotokolla on oletuksena https o Perustelluista syistä muiden tiedonsiirtoprotokollien käyttö on myös mahdollista (esim. FTP, sanomajonotekniikka, DICOM) o Siirtoprotokollasta riippumatta sanomaliikenne alkaa aina Web Services kutsuna Potilasasiakirjojen tietosisältöformaatteja on alkuvaiheessa kaksi: o HL7 CDA R2 ja o DICOM kuvat (muut kuvaformaatit on muutettu DICOM standardiin kuvantamisjärjestelmillä). Potilasasiakirjat liitetään palvelukutsuun käyttämällä HL7 V3 siirtokehyksiä. Nykyisin käytössä olevat Avoimen rajapinnan kehykset tulee päivittää arkkitehtuurin mukaisesti HL7 V3 siirtokehyksiksi. Kuvassa 4 ylhäällä olevat liitännäisjärjestelmät (potilastietojärjestelmä, kuvantamisjärjestelmä ja tiedon käyttäjät) on päivitettävä edellä tukemaan edellä esitettyjä linjauksia. Liitännäisjärjestelmät keskustelevat uuden viestinvälitysrajapinnan kanssa arkkitehtuurin mukaisesti pääosin omilla Web Services (SOAP-Client) komponenteilla. Liitännäisjärjestelmiin on viestien vastaanottoa varten (esim. kuittaukset) rakennettava oma SOAP Server komponentti. Viestinvälitysrajapinnassa on Gateway kerros, joka kattaa sekä eri tiedonsiirtoprotokollien käytön että palveluiden monistamisen. Gatewaystä sanomat välittyvät palveluväylään ja edelleen prosessimoottorin palveluorkestrointiin. Prosessimoottori suorittaa ennalta kuvattuja ydinprosesseja (esim. tallenna asiakirja) ja välittää viestejä kuvassa 4 alhaalla oleviin KanTo:n palveluihin, käyttäen SOAP -viestejä. eresepti on kuvattu osana arkkitehtuuria omina palveluinaan. Liikennöinti tapahtuu myös standardien rajapintojen kautta (HL7 V3 -kehys ja http/http(s) XML - sanomarakenteet).
ARKKITEHTUURIMÄÄRITTELY 17 /35 4.2 Viestinvälitysrajapinta Potilastietojärjestelmä Asiakirja DB WS/HTTPS, HL7 V3 CDA R2 / HL7 STATISTICS FTP/MQ, HL7 V3 DICOM HL7 V3 IP-verkko Palveluväylä GET PUT Arkistoi asiakirja Kuittaus Virheenhallinta Rekisteröi kuva Lähetä STAKES Tilastot HL7 V3 CDA R2 / HL7 STATISTICS / DICOM KANTA eresepti Koodistot Tilastot Hakemisto Asiakirjat Reseptikeskus Koodistot Kuva 5: Palveluväylä. Kuvassa 5 on esitetty palveluväylän komponentit. Kuvan yläosassa oleva potilastietojärjestelmä kommunikoi synkronisesti KANTA:n palveluväylän kanssa HL7 V3 kehystetyillä sanomilla (SOAP). Liikennöinti tapahtuu HTTPS-protokollalla. Tämän rajapinnan kautta potilastietojärjestelmä kutsuu KANTA:n ulkoisia palveluja (esim. asiakirjan luonti). Kuvat (DICOM) välitetään FTPS-, sanomajonorajapinnan tai DICOM-protokollan kautta. Lisäksi potilastietojärjestelmällä on oltava valmius vastaanottaa kuittauksia KanTo:sta.
ARKKITEHTUURIMÄÄRITTELY 18 /35 Palveluväylän minimitehtäviä (KanTo) ovat: 1. Tiedon tuottajien ja tiedon käyttäjien tunnistaminen ja varmentaminen varmennepalvelusta (TEO). 2. Sanoman välitys sen vastaanottajalle. 3. KANTA:n sisäisten prosessien suorittaminen (orkestrointi) 4. XML sanomien kehyskäsittelyt a. Osapuoli voi tuottaa sanomia, joissa on KANTA:n kannalta tarpeettomia kehyksiä. Palveluväylä poistaa ylimääräiset kehykset. b. Osapuoli edellyttää vastaanottamissaan sanomissa kehyksiä, joita KANTA ei käsittele. Palveluväylä lisää puuttuvat kehykset. 5. Palveluväylän läpi kulkeneiden sanomien tilastointi. 6. Palveluväylän monitorointi ja valvonta. Muita palveluväylän tehtäviä ovat: 7. Kuva-aineiston (DICOM) arkistointi 8. eresepti -sanomien käsittely. Prosessorimoottori käsittelee sähköisiä lääkemääräyksiä samaan tapaan kuin sähköisiä potilasasiakirjoja. Tämä edellyttää ereseptiltä standardin mukaista sanomaformaattia ja viestinvälitysprotokollan käyttöä. 9. Lakisääteisten henkilörekisterien tilastojen välitys Esimerkkejä palveluväylän laajennetusta käytöstä ovat: 10. Tiedonvälityksen protokollamuunnokset: Esimerkiksi osapuoli haluaa välittää asiakirjat FTP tiedostosiirtona KANTAan. 11. Asiakirjojen eräsiirto käyttäen HL7 V3 Batch siirtokehyksiä. 12. Tiedonvälityksen sanomaformaattimuunnokset: Esimerkiksi osapuoli haluaa välittää asiakirjat asiakirjaformaatissa KANTAan. Arkisto vastaanottaa asiakirjat HL7 V3 CDA R2 formaatissa. Viestinvälitys huolehtii sanomaformaatin muunnoksesta. Viestit ovat SOAP-viestejä ja viestinvälitysprotokollana käytetään https:ää. Sekä Web Services -kutsu että XML -eheys validoidaan. Jos sanoma on kunnossa, välitetään sanoma prosessimoottorille. Prosessimoottori käynnistää sanomaan liittyvän ydinprosessin. Ydinprosessit on kuvattu kokonaisarkkitehtuurin kuvauksissa.
ARKKITEHTUURIMÄÄRITTELY 19 /35 4.3 Viestinvälitykseen liittyvät komponentit 4.3.1 Tietoliikenne Seuraavissa kappaleissa on avattu viestinvälitykseen liittyviä komponentteja ja toimintoja eri kerroksissa. Tietoliikenne tapahtuu IP -verkossa, oletusarvoisesti viestit välittyvät Internetin läpi. Tämä ei rajoita muiden IP -verkkorakenteiden käyttöä, esimerkiksi suojatut, kiinteät eri osapuolien väliset verkot ovat mahdollisia taatun palvelutason saavuttamiseksi. 4.3.2 Sanomanvälityspalvelut 4.3.3 Palveluväylä 4.3.4 Prosessimoottori Viestien vastaanottopalveluihin arkkitehtuurissa valitaan tietoliikenneprotokolla, joilla viestien lähetys sanomanvälitysrajapintaan sallitaan. Määrittelyprojektin aikana on tunnistettu seuraavat tarpeet: https -sanomaliikenne SOAP -viesteille asynkroninen sanomaliikenne suurille aineistolle (esim. kuvamateriaali, suuret potilasasiakaskirjat). Asynkroninen sanomaliikenne on toteutettavissa esim. FTP -tiedostosiirtoina, ja/tai sanomajonotekniikkaan perustuvilla sanomanvälitystekniikoilla. Eri protokollille valitaan sanomanvälityspalveluihin adapterit liikennettä hoitamaan. Palveluväylän (Enterprise Service Bus, ESB) tehtävänä on sekä vastaanottaa, välivarastoida ja välittää sanomia että välittää sanomat määritellyille ydinprosesseille suoritettavaksi prosessimoottorissa. Palveluväylä on viestien vastaanottopalvelusta erillään oleva kokonaisuus. Esimerkiksi viestien vastaanottopalvelussa voidaan hyväksyä useita tietoliikenneprotokollia, mutta palveluväylän käyttö voidaan haluttaessa rajoittaa yhteen tietoliikenneprotokollaan (JMS, tms.). Tällöin viestien vastaanottopalvelut sisältävät adapteritekniikan protokollamuunnokselle. Prosessimoottori on KANTA-arkkitehtuurissa looginen arkkitehtuurikerros eikä se pakota tietyn tuotetyypin käyttöön. Prosessimoottori on loogisesti osa palveluväylää. Prosessimoottorin tehtävänä on orkestroida prosesseja, jotka koostuvat sen palveluväylään kytkettyjen osajärjestelmien ja integrointialustan itsessään tarjoamista palveluista. Prosessilogiikan toteuttaminen prosessimoottorissa mahdollistaa sen, että sen orkestroimien osajärjestelmien palveluille ei synny keskinäistä riippuvuutta. Ratkai-
4.3.5 Adapterit ARKKITEHTUURIMÄÄRITTELY 20 /35 su mahdollistaa uusien osajärjestelmien ja palvelukokonaisuuksien joustavan liittämisen palveluväylään. Myös prosessien muuttaminen, esimerkiksi lainsäädännön muuttuessa, on joustavaa. Prosessimoottorin tehtävänä on suorittaa käyttötapauksia toteuttavia prosesseja ja ylläpitää ja valvoa prosessien tilaa. Prosessit voivat olla myös pitkäkestoisia useita minuutteja tai jopa pidempiä aikoja kestäviä toimintoja. Adapterit tarkoittavat tässä dokumentissa ensisijaisesti tietoliikenneadaptereita. Adaptereita tarvitaan sekä KANTA:n palveluväylässä että ulkoisilla osapuolilla. Adapterin tehtävä on hoitaa tietoliikenneyhteyden avaus, sanomaliikenne, ja siihen liittyvät tehtävät. Tätä on esimerkiksi potilastietojärjestelmän ja viestinvälitysrajapinnan keskusteluyhteys ja siinä tarvittavat kuittausominaisuudet (HL7). Virhetilanteiden hallinta ja palveluväylän palveluiden valvonta edellyttävät mekanismia lähettää hälytyksiä palveluväylän tekniselle valvonnalle. Nämä hälytykset voidaan lähettää sähköpostilla, jolloin tarvitaan sähköposti-adapteria, joka pystyy lähettämään määritellyistä poikkeustilanteista sähköpostia. Tietomuodon muunnoksia tekeville adaptereille tai sovellusadaptereille ei ole esiintynyt tarvetta. 4.3.6 Virheenhallinta ja monitorointi Palveluväylässä on yleinen virheenhallintapalvelu, jota kutsutaan sekä sanomanvälitysrajapinnan sisäisistä palveluista että KANTA-osajärjestelmistä. Rajapinta palveluun on samanlainen kuin muutkin palvelurajapinnat, (SOAP / https). Virheenhallinta siis tarkoittaa ennalta määritettyjä kompensoivia toimintoprosesseja prosessimoottorissa. Kelalla KanTo-palvelujen tuottajana on palvelujen monitorointityökaluja, jotka tulee kytkeä palveluväylän monitorointipalveluihin. Valvonta- ja monitorointipalvelut vaativat oman ohjelmistonsa, joka tulee voida integroida valitun integraatioalustan kanssa niin, että alustan tilaa voidaan valvoa. 4.4 DICOM kuvamateriaali DICOM -kuvamateriaali tarkoittaa arkkitehtuurissa sähköistä potilasasiakirjaa, joka on DICOM -sanomaformaatissa. DICOM -kuvat välitetään joko HL7 V3 siirtokehyksissä tai DICOMprotokollalla. Tuetut tiedonsiirtoprotokollat ovat https / SOAP, FTP(s) ja sanomajonotekniikat, sekä mahdollisesti DICOM. Seuraavassa on kuvattu toiminnallisuus, mikäli käytetään HL7 V3 siirtokehystä eikä DICOM-protokollaa. Kuvan rekisteröinti ja arkistointi ovat erilliset toiminnot, ja edellyttävät prosessimoottorilta erilaista toiminnallisuutta (kuvat 6 ja 7).
ARKKITEHTUURIMÄÄRITTELY 21 /35 Kuva 6: Kuvan rekisteröinti. Kuvan rekisteröinti aloitetaan potilastietojärjestelmästä lähettämällä SOAP -viesti KANTA:n viestinvälitysrajapintaan. Kutsuttava KANTA:n ulkoinen rajapinta on Rekisteröi keskeneräinen asiakirja. Palveluväylä vastaanottaa viestin ja orkesteroi viestin käsittelyn prosessimoottorissa.
ARKKITEHTUURIMÄÄRITTELY 22 /35 Kuva 7: Kuvan arkistointi. Kuvan arkistointi aloitetaan potilastietojärjestelmästä lähettämällä SOAP -viesti KANTA:n viestinvälitysrajapintaan. Kuvan arkistoiminen on KANTA:n Arkistoi asiakirja palvelun erikoistapaus, jossa DICOM -kuvat siirretään erikseen SOAP - sanomasta. Palveluväylä vastaanottaa viestin, ja orkestroi viestin käsittelyn prosessimoottorissa. Prosessimoottorissa käynnistyy prosessi, joka odottaa kuvien saapumista potilastietojärjestelmästä ja kuvan/kuvien saapuessa palveluväylään, prosessit välittävät kuvat arkistopalvelulle. Arkistoinnin jälkeen prosessimoottorissa suoritetaan kuvien rekisteröinti rekisteröintipalveluun. Rekisteröintitiedot on vastaanotettu arkistointiviestin yhteydessä. Kuvien arkistointikuittaukset toimitetaan potilastietojärjestelmälle asynkronisesti SOAP-viestinä. 4.5 Käytettävät standardit 4.6 Tietoliikenneratkaisu Esimerkkejä tuettavista standardeista ovat: HL7 V3 (Medical Records), CDA R2, Web Services, SOAP kehys, http/s, DICOM. 4.6.1 Tietoliikenneratkaisun kuvaus yleisellä tasolla Tietoliikenneyhteydet potilastietojärjestelmistä arkistoon voidaan toteuttaa eri tavoin. Ratkaisuvaihtoehdot ovat joko Julkinen Internet tai Suljettu IP-verkko.
ARKKITEHTUURIMÄÄRITTELY 23 /35 Käytännössä arkistoon tulee voida liittyä sekä julkisen Internetin läpi että suljetun IP-verkon kautta. Terveydenhuollon yksiköt valitsevat itselleen sopivimman ratkaisun. Sopivan ratkaisun valintaan vaikuttavat ensisijaisesti kaistan tarve, arvio transaktioiden määristä, latenssi, haluttu palvelutaso sekä ratkaisusta koituvat kustannukset. Yhteys arkistoon voidaan toteuttaa julkisen Internetin läpi. Ratkaisun hyöty on jo olemassa olevat yhteydet ja siitä saatava kustannustehokkuus. Ratkaisun haittapuolina on se, että jatkuvaa yhteyttä KANTAan ei voida taata vaan kyseessä on ns. best effort -verkko. Verkon luonteen takia liikenteen priorisoiminen on käytännössä mahdotonta. Internetyhteyttä tarjoava operaattori voi taata yhteyden toiminnallisuuden ainoastaan oman verkkonsa piirissä mutta ei siitä eteenpäin. Jos julkinen Internet ei ole riittävä yhteystapa, voidaan tietoliikenne siirtää suljetun IP -verkon läpi. Suljetetulla IP -verkolla tarkoitetaan operaattorien tarjoamaa IP - verkkoa, joka on avoinna vain palvelun hankkineelle asiakkaalle. Käytännössä kuitenkin samoissa fyysisissä verkkokaapeleissa saattaa kulkea niin julkista (Internet) kuin useiden asiakkaiden suljettua liikennettä, mutta loogisesti nämä on erotettu toisistaan. Suljetussa IP-verkossa operaattori voi taata liikennöintikapasiteetin yhteyskohtaisesti ja palvelutaso voidaan määritellä yhteyden kriittisyyden mukaan. Liikenteen priorisoiminen on mahdollista mutta voi olla käytännössä monimutkaista, jos liikenne kulkee useiden suljettujen IP-verkkojen läpi. Viestinvälityksen tietoliikennettä ja sen luotettavuutta järjestelmien välillä on tarkasteltava käytettävyysnäkökulmasta aina päästä-päähän.
ARKKITEHTUURIMÄÄRITTELY 24 /35 Kuva 8: Operaattoreiden suljetut IP-verkot ja yhteydet KanToon. Kuvassa 8 on kuvattu esimerkki loogisella tasolla kolmen operaattorin tarjoamaa suljettua IP -verkkoa. Kuvan tarkoitus on havainnollistaa, mitä suljetulla IP -
ARKKITEHTUURIMÄÄRITTELY 25 /35 verkolla tarkoitetaan ja miten KanToon voidaan liittyä. Kuvan tarkoitus ei ole ehdottaa miten KanTo ja liitännäisjärjestelmät tulisi liittää toisiinsa. Kuvassa 8, KanTo:n liitytään Kelan hallinnoiman yhteyspisteen (koontireitittimen) kautta. Yhteyspisteessä on rajapinnat operaattori A:n ja B:n asiakkaille sekä yhteys julkiseen Internetiin. Liitännäisjärjestelmä A1, joka käyttää Asiakasverkkoa A1, voi muodostaa suljetun yhteyden KANTA:n operaattori A:n runkoverkon kautta. Vastaavasti Liitännäisjärjestelmä B1 voi muodostaa yhteyden oman operaattorinsa kautta, sillä yhteyspiste tarjoaa rajapinnat molemman operaattoreiden verkoille. Liitännäisjärjestelmä C1 ei sen sijaan voi suoraan muodostaa suljettua yhteyttä KanToon sillä yhteyspiste ei tarjoa rajapintaa operaattori C:n verkolle. Liitännäisjärjestelmä C1, kuten kuvan muutkin liitännäisjärjestelmät, voi muodostaa yhteyden KanToon julkisen Internetin kautta (kuvassa katkoviiva). Vaihtoehtoisesti liitännäisjärjestelmä C1 voi muodostaa suljetun yhteyden KANTA:n operaattori B:n kautta (kuvassa pisteviiva). Tämä edellyttää vähintään yhteystyötä operaattori B:n ja C:n osalta. Koska liikenne kuitenkin siirtyy kahden eri operaattoreiden välillä, voi liikenteen priorisoiminen olla ongelmallista muttei kuitenkaan mahdotonta. Liitännäisjärjestelmä AB on liittynyt sekä operaattori A:n että B:n tarjoamiin suljettuihin IP-verkkoihin. Järjestelyllä voidaan saavuttaa parempi käytettävyysaste. Saatu hyöty riippuu pitkälti verkon topologiasta ja liitännäisjärjestelmän sijainnista kyseisissä verkoissa. Kuten aiemmin jo todettiin, samassa fyysisessä verkkokaapelissa voi kulkea usean eri verkon liikennettä loogisesti eroteltuna toisistaan. Liitännäisjärjestelmä AB ei siis välttämättä saa kahdennetulla yhteydellään mitään lisäsuojaa verkkokaapelin vikaantumista vastaan. Oikean yhteystavan valinta riippuu pitkälti liitännäisjärjestelmien tarpeista. Jos yhteys KANTAan ei ole kriittinen, voi liitännäisjärjestelmä valita julkisen yhteyden. Kriittisyysastetta määriteltäessä on kuitenkin syytä pitää mielessä kokonaisuus eli koko järjestelmän käytettävyysaste. Jos liitännäisjärjestelmä C1 valitsee julkisen yhteyden sillä perusteella, että käyttökatkot eivät häiritse C1 toimintaa, heijastuu se myös arkiston muihin käyttäjiin. Julkisen yhteyden ollessa poikki liitännäisjärjestelmä C1 ei voi siirtää asiakirjoja arkistoon eikä tieto siksi näy liitännäisjärjestelmien käytössä. Muut liitännäisjärjestelmät eivät myöskään voi suoraan hakea tietoa liitännäisjärjestelmä C1:ltä. Yhteystavan valintaan vaikuttaa siis liitännäisjärjestelmän omat tarpeet, mutta myös muiden riippuvuus kyseisen liitännäisjärjestelmän toiminnasta. Epävarmuustekijöiden minimointi käyttämällä pelkästään suljettua IP-verkkoa ei välttämättä riitä. Jokainen verkkokomponentti järjestelmien välillä on otettava huomioon kriittisissä järjestelmissä. Arkiston edessä liityntärajapinnan tarjoavan tietoliikenneratkaisun perusarkkitehtuurin tulee olla vikasietoinen sekä suljetun IPverkon liitynnän että Internet-liitynnän osalta, jotta palvelutasovaatimukset voidaan varmuudella täyttää.
ARKKITEHTUURIMÄÄRITTELY 26 /35 Internet Suljetut verkot Reititin Reititin Palomuuri Palomuuri Kytkin Kytkin Kahdennetut KANTA-palvelimet Kuva 9: Verkkoyhteyksien vikasietoisuuden parantaminen KANTA-perusratkaisun tulisi tietoliikennerajapinnan toteuttamisessa arkistoon liittymiseksi minimissään vikasietoisuuden takaamiseksi toteuttaa kuvan 9 mukainen rakenne. Jokainen laite on fyysisesti vähintään kahdennettu ja laitteiden rikkoutumisen varalta vikasietoisuutta voidaan tarvittaessa nostaa monentamalla vielä laitteita lisää. Loogisesti Internet-yhteyksien ja suljettujen IP-verkkojen yhteydet voidaan toteuttaa samalla fyysisellä laitteella hyödyntämällä virtualisointitekniikoita niin reitittimissä, palomuureissa, kytkimissä kuin palvelimissakin. Arkistoon sidonnaiseen tietoliikenteeseen mahdollisesti liittyvät lisäkomponentit, kuten esimerkiksi salauskomponentit (VPN, SSL-kiihdyttimet) tulee niin ikään kahdentaa tai monentaa vastaavasti. Järjestelmät, jotka eivät kuulu tuotantoverkkoon vaan ovat esimerkiksi valvontajärjestelmiä, eivät välttämättä vaadi kahdentamista, sillä niiden vikaantuminen ei suoranaisesti vaikuta tuotantoverkkoon ja järjestelmiin. Fyysisen kahdentamisen lisäksi tulee huomioida laitteiden maantieteellinen sijoituspaikka. Kahdentamisen tulisikin tapahtua niin, että laitteet ja järjestelmät sijaitsevat vähintään eri paloalueilla (eri laitetila) mutta mieluiten kuitenkin eri sortumatiloissa (eri rakennus). Toiminnan varmistamiseksi myös poikkeusoloissa tulisi erillisen varajärjestelmän sijaita vähintään noin 300 kilometrin päässä toisistaan. KANTA:an liittyvien tahojen ja KANTA:n välisen liittymäverkon kelpoisuuden arviointi tulee kytkeä potilastietojärjestelmien sertifiointi- ja auditointimenettelyihin.
ARKKITEHTUURIMÄÄRITTELY 27 /35 4.6.2 Tietoliikenneratkaisuun vaikuttavat tekijät Tietoliikenneratkaisun valintaan vaikuttavat useat tekijät. Eri vaihtoehtoja punnittaessa tulee huomioida ainakin seuraavat tekijät: Kaistan tarve. Kaistan tarve voidaan arvioida, kun tiedetään transaktioiden määrä, siirrettävien viestien koko, miten siirtomäärät vaihtelevat eri ajanjaksojen aikana sekä miten nopeasti viestien tulee siirtyä KANTAsta potilastietojärjestelmään tai päinvastoin. Osa siirroista voitaneen toteuttaa eräajotyyppisesti esimerkiksi siirtämällä tiedot arkistoon öisin. KANTA:n käyttötarve oletettavasti vaihtelee huomattavasti viikonpäivien tai kellonajan mukaan, joten siirtämällä tietoa mahdollisimman paljon ruuhka-aikojen ulkopuolella voidaan ruuhkahuippuja tasoittaa. Etenkin siirto arkistosta potilastietojärjestelmiin tulee suunnitella niin, että kaistan puute ei aiheuta pullonkaulaa ja näin hidasta potilastietojärjestelmien toimintaa. Latenssi. Latenssi on se aika, joka viestiltä kuluu siirtyä lähettäjältä vastaanottajalle. Latenssin tulee olla alhainen kun siirretään reaaliaikaista tietoa (esim. VOIP liikennettä), mutta sanomapohjaisissa ratkaisuissa sen merkitys ei ole kovin suuri. Latenssin tulee kuitenkin olla niin pieni, ettei se merkittävästi vaikuta potilastietojärjestelmien käyttäjien kokemaan vaste-aikaan. Käytettävyys/Palvelutaso. Palvelutaso (SLA) on osa palvelusopimusta, jossa kuvataan eri mittarien avulla, miten palvelua aiotaan tuottaa. Yleisin käytetty mittari on käytettävyys, joka voidaan laskea seuraavasti: Käytettävyys(%) = HA/KA * 100, missä HA on järjestelmän todellinen häiriötön palveluaika ajanjaksolla t KA on järjestelmän palveluaika ajanjaksolla t Yleisesti voidaan sanoa, että mitä lähemmäksi 100 % palvelutasoa halutaan, sitä korkeammaksi kustannukset muodostuvat. Kuva 10 kuvaa käytettävyyden ja kustannusten suhdetta. Kuva 10: Käytettävyyden vaikutukset kustannuksiin Käytettävyys kertoo miten kauan järjestelmä voi olla poissa toiminnassa tietyn ajanjakson aikana. Esim. käytettävyydellä 99 % järjestelmä saisi olla poissa käy-
ARKKITEHTUURIMÄÄRITTELY 28 /35 tössä n. 87 tuntia vuoden aikana. Käytettävyysmittari ei ota kantaa miten käyttökatkokset ajoittuvat vuoden aikana. Kyseessä voi siis olla yksi pidempi katkos tai monta pientä. Pisin sallittu käyttökatko vaatimus tuleekin siksi ottaa huomioon käytettävyyden ohella tietoliikenneratkaisua valittaessa. Käyttökatkoksen tyyppi, ennakoitu tai ennakoimaton katko, määritellään palvelutason vaatimusmäärittelyssä. Palvelusopimuksissa voidaan sopia myös useita muita palvelutasoon vaikuttavia asioita kuten miten tietoturvaloukkauksiin reagoidaan, miten muutoksia hallitaan jne. mutta niitä ei ole käsitelty tässä dokumentissa vaan ne tulisi käsitellä palvelun suunnitteluvaiheessa. 4.6.3 Palvelunestohyökkäykset 4.7 Tietoturva Keskitetty arkisto on altis palvelunestohyökkäyksille. Palvelunestohyökkäyksellä tarkoitetaan tilannetta, jossa arkiston toimintaan yritetään vaikuttaa niin, ettei se enää ole käytettävissä normaalilla tavalla. Palvelunestohyökkäys voidaan toteuttaa usealla eri tavalla. Hyökkääjällä voi olla käytössään useita tuhansia koneita, jotka samanaikaisesti lähettävät tietoa hyökkäyksen kohteena olevalle järjestelmälle aiheuttaen jonkin rajallisen resurssin loppumisen. (Kaista, levytila ja suoritinaika ovat esimerkkejä rajallisista resursseista). Palvelunestohyökkäys on myös mahdollista toteuttaa vain yhtä laitetta apuna käyttäen esim. lähettämälle kohteelle vääränlaista dataa joka aiheuttaa virhetilanteen ja näin estää palvelun toiminnan. Palvelunestohyökkäystä muistuttava tilanne voi myös syntyä tahattomasti kuten laitevian tai ohjelmistovirheen takia, esimerkiksi kytkin vikaantuu ja alkaa lähettää moninkertaisen määrän paketteja. Palvelunestohyökkäyksiä on käytännössä mahdotonta kokonaan estää mutta hyvällä suunnittelulla ja toteutuksella riskiä voidaan pienentää. Palvelunestohyökkäykset kohdistuvat kohteeseen lähes kaikissa tapauksissa yleensä Internet-yhteystavan kautta, ei niinkään suljettujen IP-verkkojen kautta, joskin tämäkin on mahdollista. Arkistopalveluun liittyen verkkoyhteyksiä toimittavan operaattorin kanssa on sovittava menettelytavat ja reaktiiviset toimenpiteet kohdennettujen palvelunestohyökkäysten torjumiseksi ja niiden havaitsemiseksi jo operaattorin runkoverkkotasolla. Lisäksi tulisi käyttää hyökkäyksenhavainnointija estojärjestelmiä (IDS/IPS). Menetelmät, jotka vaikeuttavat palvelunestohyökkäyksen toteuttamista, on kuvattu tarkemmin kohdassa 4.7.2. 4.7.1 Yleisiä tietoturvavaatimuksia Viestinvälitykseen liittyy useita tietoturvavaatimuksia. Lyhyesti voidaan sanoa, että viestinvälityksen tärkein tehtävä on välittää oikea tieto oikeille tahoille oikeaan aikaan oikeansisältöisenä. Tämä tehtävä asettaa vaatimukset tietoturvan kolmelle keskeisimmälle käsitteelle: luottamuksellisuudelle, eheydelle ja käytettävyydelle.