ereseptin integraatioarkkitehtuurin perusteet

Transkriptio

1 ereseptin integraatioarkkitehtuurin perusteet KuntaIT Arkkitehtuuri Versio: 1.0 Laatinut: KuntaIT:n ereseptin integraatioarkkitehtuurin projektiryhmä

2 2 Sisällys Sisällys...2 Dokumentin tila Yhteenveto Dokumentin tarkoitus Tarkastellun kohteen keskeisimmät rajaukset ja oletukset Kohderyhmä Kuntasektorin arkkitehtuurimenetelmä ereseptin taustaviitekehys ereseptin yleiskuvaus Sanoma- ja liittymismäärittelyt Kelan liittymisohjeistus KanTa-liittymisen edellytykset eriaatetason arkkitehtuuri Arkkitehtuuriperiaatteet Toimintaan vaikuttavat periaatteet Tietoon kohdistuvat periaatteet Järjestelmiin kohdistuvat periaatteet Rajaukset ja reunaehdot Sidosarkkitehtuurit ja niitä kehittävät hankkeet Tietoturvatarpeet ja periaatteet Käsitteellisen tason arkkitehtuuri Roolit Toimijat Integraatiopalveluun liittyvät tietojärjestelmäpalvelut Varmennepalvelu Integraatioratkaisun osapalvelut Loogisen tason arkkitehtuuri Liityntäpalvelun integraatioperiaatteet Liityntäpalvelussa ja liittymismalleissa käytettyjä termejä Liityntäpalvelu osana viestinvälitysketjua otilastietojärjestelmän rooli ereseptin viestinvälityksessä Integraatioratkaisu tietojärjestelmänä teknologia-arkkitehtuuri Liityntäpalvelun integraatioratkaisun looginen jäsennys...32 Liityntäpalvelun sanomanvälitys integraation osapalveluina alvelutasovaatimukset Liittymismallit (integraatiovaihtoehdot) Liittymismalleissa käytetyt symbolit Liittymismalli A suora järjestelmäliityntä Liittymismalli B kuntatoimijan keskitetty ratkaisu Liittymismalli C alueellinen liityntäpalvelu Liittymismalli D järjestelmäkohtaisesti keskitetty integraatio Liittymismalli E tuplaintegraatio Esimerkki: Muita liittymismallivariaatioita...45

3 Liittymismallien vertailu ja arviointi Liittymismalli A - suora järjestelmäliityntä Liittymismalli B kuntatoimijan keskitetty ratkaisu Liittymismalli C alueellinen liityntäpalvelu Liittymismalli D järjestelmäkohtaisesti keskitetty integraatio Liittymismalli E tuplaintegraatio Yhteenveto ja suositukset Liityntäpalvelun sanomankulkukaaviot Virheettömät, onnistuneen sanomanvälityksen sanomakulut Virheitä sisältävien sanomanvälitysten sanomakulut Liityntäpalvelun keskeiset prosessit Ratkaisun mitoitusperiaatteet Kansalliset volyymit Liityntäpisteen mitoitusperiaate Valvonta- ja hallinta-arkkitehtuurin perusteet Liityntäpalvelun toteutuksen päävaatimukset Liitteet...79 Dokumentin tila Versio äiväys Laatija Muutoksen kuvaus rojektiryhmä rojektiryhmän lopputuotos

4 4 1. Yhteenveto Tämä dokumentti käsittelee terveydenhuollon valtakunnallisiin palveluihin (KanTa-palvelut) sisältyvän eresepti-palvelun käyttöönotossa tarvittavia liityntäratkaisuja julkisen terveydenhuollon toimijoiden näkökulmasta. Dokumentin tarkoituksena on antaa kunnille tai sairaanhoitopiireille välineitä ja suosituksia, joiden pohjalta ne voivat tehdä päätöksiä millä liityntämallilla liittyminen eresepti-palveluun kannattaa toteuttaa. Dokumentti kuvaa lisäksi sähköisiä lääkemääräyksiä tuottavien ja välittävien tahojen keskeiset integraatiopalvelutarpeet, ratkaisuperiaatteet, prosessi- ja tekniset vaatimukset. Tämän dokumentin lähtökohtana ovat kansalliset eresepti-määritykset ja KanTa-arkkitehtuuri. Tämä tuotos on tehty KuntaIT:n kuntien arkkitehtuurin kehittäminen -projektin ereseptin integraatioarkkitehtuuria koskevassa osaprojektissa. Työssä hyödynnettiin kuntasektorin kokonaisarkkitehtuurimenetelmää soveltaen. Kokonaisarkkitehtuurilla (KA) tarkoitetaan toiminnan, tietotarpeiden, tietojärjestelmien ja teknologiaratkaisujen mallintamista, kuvaamista ja suunnittelemista yhtenäisen mallin mukaisesti. ereseptin taustaviitekehystä ja arkkitehtuuriin ja liittymisratkaisun valintaan vaikuttavia periaatteita on kuvattu dokumentin luvuissa 3 ja 4. Liittymisvaihtoehtoja ja liittymisratkaisun tarkempaa toteutusta on kuvattu ja arvioitu luvuissa 5-10; liittymismallien (integraatiovaihtoehdot) esittely kappaleessa 6.2, ja vaihtoehtoja koskeva arviointi ja vertailu sekä yhteiset suositukset kappaleessa 6.3. Vaikka projektissa ja tässä dokumentissa on pääosin rajauduttu käsittelemään ainoastaan ereseptin käyttöönottoon liittyvää liittymisratkaisua, tulisi työryhmän näkemyksen mukaan liittymisratkaisun valinnassa huomioida nykytoteutusten lisäksi myös muut alueelliset ja paikalliset integraatiotarpeet sekä arkkitehtuuriin, tietojärjestelmäympäristöihin ja organisaatioihin lähivuosina kohdistuvat muutokset ja kehittämistarpeet. Tämä ennakointi tulee huomioida sekä integraatio-arkkitehtuuriin liittyvissä teknisissä ratkaisuissa sekä hallinnollisesti, kuten liittyjien välisissä ja palveluiden hankintaan liittyvissä sopimuksissa. Terveydenhuollon sähköisen tiedonhallinnan kehittäminen ja valtakunnallisten palveluiden vaiheittainen käyttöönotto tulee jatkossa edellyttämään kuntasektorin toimijoilta entistä tiiviimpää organisaatiorajat ylittävää yhteistyötä palveluiden kehittämisen, järjestämisen sekä käyttöönottojen koordinoinnin osalta. Tämän johdosta työryhmä suosittelee että myös KanTa-liittymisessä tarvittavat palvelut ja niiden toteuttamis- ja tuottamistapa arvioidaan ja suunnitellaan yhteistyössä alueen julkisen terveydenhuollon organisaatioiden kesken.

5 Dokumentin tarkoitus Tämä dokumentti kuvaa kansallisen ereseptin liityntäarkkitehtuurin (integraatioarkkitehtuurin) keskeisiä periaatteita. Dokumentti kuvaa yleisten liittymismallien ja toteutusvaihtoehtoihin sisältyvän integraatiopalvelun viite- ja palveluarkkitehtuurin päätason. Tämän viitearkkitehtuurin lähtökohtana ovat kansalliset eresepti-määritykset ja KanTa-arkkitehtuuri. Tämä tuotos on tehty KuntaIT:n kuntien arkkitehtuurin kehittäminen projektin ereseptin integraatioarkkitehtuuria koskevassa osaprojektissa. Kansallisella ereseptin liityntäarkkitehtuurilla on kaksi keskeistä tarkoitusta: Dokumentti antaa yksittäisille kunnille tai sairaanhoitopiireille välineitä, joiden pohjalta ne voivat tehdä päätöksiä millä liityntämallilla niiden kannattaa liittyä Reseptikeskukseen. Dokumentti kuvaa sähköisiä lääkemääräyksiä välittävän tahon keskeiset integraatiopalvelutarpeet, ratkaisuperiaatteet ja prosessi- ja tekniset vaatimukset. Työ on tehty järjestelmä- ja tuoteriippumattomasti ja sen periaatteita voidaan soveltaa kaikkiin eri potilastietojärjestelmiin. Dokumentin rakenne Dokumentin alussa on viitattu lyhyesti taustalla olevaan ereseptimääritykseen yleisesti ja tätä seuraavat ns. periaatteellisen ja käsitteellisen tason arkkitehtuurikuvaukset, jotka toimivat integraatioarkkitehtuurin peruskivinä. Näitä seuraa varsinainen liittymismallien (integraatiovaihtoehtojen) ja itse integraatiopalvelun sisäisen jäsennyksen kuvaukset. Näitä seuraavat integraatiopalvelun prosessien ylätason kuvaukset sekä integraatiopalvelun keskeisimmät vaatimukset. Varsinaiset kuntatoimijaa koskevat integraatiopalvelusuositukset on listattu tämän dokumentin loppuun Tarkastellun kohteen keskeisimmät rajaukset ja oletukset Tässä dokumentissa käsitellään eresepti-arkkitehtuuria yksinomaan integraatioratkaisun (liittymismallin) ja siihen liittyvän palvelun näkökulmasta. Tässä työssä ei oteta kantaa muuhun ereseptin toiminnallisuuteen ja määrityksiin eikä näihin liittyviin hoitoprosesseihin. Tässä työssä ereseptin kansalliset määritykset otetaan annettuina ja niitä noudatetaan sellaisenaan. Keskeisimmät muut rajaukset ovat seuraavat: Työ keskittyy kuntien liittymismalleihin, työssä EI ole huomioitu lainkaan apteekkien liittymismalleja eikä yksityisen sektorin terveydenhuollon toimijoiden liittymisperiaatteita

6 6 o Apteekit on jätetty esimerkiksi sanomakulkukuvauksista pois ja niissä on kuvattu vain kuntatoimijoiden eresepti-liikenne Reseptikeskukseen asti Työssä ei kehitetä ereseptin määrityksiä vaan niitä noudatetaan sellaisenaan Integraatioarkkitehtuurissa ei oteta kantaa, miten Reseptikeskuksen sisäinen integraatiopalvelu toteutetaan Työssä ei ole voitu tarkasti arvioida tai mitata integraatiopalvelun aiheuttamaa teknistä viivettä ereseptin sanomakulussa, tämä tulee mitata myöhemmin testimittauksin. Työssä on oletettu, ettei 1-2 suorituskykyisen integraatioratkaisun sijoittaminen synkronisen liikenteen välittäjäksi merkittävästi heikennä viestinvälityksen palvelutasoa. On hyvä vielä huomata, että liittymismallit ja niiden arviointi lähtevät siitä oletuksesta, että synkronisen liikenteen integraatiopalvelun valvonta- ja hallinta sekä toteutusperiaatteet eivät merkittävästi poikkea asynkronisen viestinvälityksen keskeisistä pääperiaatteista. Tarkemmat työn rajaukset ja reunaehdot on kuvattu jäljempänä osana periaatteellisen tason arkkitehtuuria Kohderyhmä Tämä ereseptin integraatioarkkitehtuurin perusteiden kuvaus on tarkoitettu kuntasektorin ereseptiin liittyvien terveydenhuollon organisaatioiden kuntien ja kuntayhtymien sekä kuntien terveydenhuollon palveluntuottajien kehittäjille, asiantuntijoille, terveydenhuollon tietoteknisten ratkaisujen kehittämisestä vastaaville sekä kyseisten toimijoiden tietohallinto-organisaatioille. Kuntatoimijalla tarkoitetaan kaikkia kuntasektoriin kuuluvia toimijoita terveydenhuollon palveluita tuottavia organisaatioita kuten kunnat ja kuntayhtymät. Keskeisiä tämän arkkitehtuurikuvauksen kohderooleja ovat: Tietohallintojohtajat ja tietohallintopäälliköt kunnissa ja terveydenhuollon kuntayhtymissä Kuntatoimijoiden kokonaisarkkitehtuurista tai ICT 1 -arkkitehtuurista vastaavat asiantuntijat nimetyt arkkitehdit Kuntien eresepti-kehittämisestä vastaavat avainhenkilöt Kuntasektorin arkkitehtuurityöstä vastaavat henkilöt Edellisten lisäksi tämän hallintamallin kohderyhmään kuuluvat kunnille tietojärjestelmiä, ICT-palveluja, konsultointi- ja asiantuntijapalveluja tai kehittämispalveluja tarjoavat julkishallinnolliset ja yksityissektorin palveluntuottajat Kuntasektorin arkkitehtuurimenetelmä Kokonaisarkkitehtuurilla (KA) tarkoitetaan toiminnan, tietotarpeiden, tietojärjestelmien ja teknologiaratkaisujen mallintamista, kuvaamista ja suunnittele- 1 Tunnetaan myös lyhenteenä TVT = tieto- ja viestintätekniikka

7 7 mista yhtenäisen mallin mukaisesti. Kokonaisarkkitehtuuri varmistaa eri osaalueiden ja erityisesti toiminnan tarpeiden yhdenmukaisen huomioimisen kaikessa toiminnan ja ICT-ratkaisujen kehittämisessä. Käytännössä kokonaisarkkitehtuuri koostuu jäsennyksestä, kuvauspohjista ja näiden avulla toteutetuista arkkitehtuurilinjauksista. Kokonaisarkkitehtuuri ulottaa näkökulmansa pelkkien tietojärjestelmien ulkopuolelle kuvatakseen ne substanssitoiminnan syyt ja tarpeet, joita varten tietojärjestelmiä tehdään sekä tässä tarvittavat tiedot. Varmistaakseen toteutettavien ratkaisujen kattavuuden ja tarkoituksenmukaisuuden kokonaisarkkitehtuurimenetelmä jäsentyykin näkökulmiin ja käsitteellisiin tasoihin (abstraktiotasoihin). Näkökulmat: o Toiminta: liiketoiminnan ja asiakkuuksien näkökulma o Tieto: tietoa, käsitteitä ja tietovarantoja tarkasteleva näkökulma o Järjestelmä: järjestelmien näkökulma o Teknologia: tekniikan, laitteiden ja teknisten ratkaisujen sekä ylläpidon näkökulma Käsitteelliset tasot: o eriaatteellinen taso MIKSI, missä rajoissa o Käsitteellinen taso MITÄ esim. mitä tietoa taltioidaan, mitä tarkoitusta varten, mitkä ovat toiminnan keskeiset käsitteet o Looginen taso MITEN esim. tietovarantojen looginen jäsennys ja tietojen sijoittuminen eri kokonaisuuksiin o Fyysinen taso MILLÄ esim. mihin fyysisiin tietokantoihin eri loogiset tietovarannot sijoitetaan, mitä sovelluksia tai laitteita palvelun toteuttamiseen käytetään Tässä työssä kokonaisarkkitehtuurimenetelmää on sovitettu integraatioarkkitehtuurin ja liityntämallivaihtoehtojen tarkastelun tarpeiden mukaisesti. Kokonaisarkkitehtuurimenetelmä on parhaimmillaan laajojen kokonaisuuksien ratkaisujen ja tietojärjestelmäkokonaisuuksien nyky- tai tavoitetilakuvauksissa. Tässä työssä yhtä aikaa arvioidaan eri liityntämallien (integraatiotopologiavaihtoehtojen) soveltuvuutta eri toimijoille ja määritellään mahdollisen liityntäpalveluja tarjoavan organisaation keskeiset toiminnalliset, tekniset ja palveluvaatimukset, mikä edellyttää KA-menetelmän sovittamista. Tässä työssä on hyödynnetty kuntasektorin KA-menetelmän kuvauspohjia seuraavasti:

8 8 eriaatteellinen taso - MIKSI Arkkitehtuuriperiaatteet Sidosarkkitehtuurit, rajaukset ja reunaehdot Tietoturvatarpeet ja -periaatteet SOA-linjaukset Tietoarkkitehtuuri Toimintaarkkitehtuuri Tietojärjestelmäarkkitehtuuri Teknologiaarkkitehtuuri Strategia Käsitemalli Tietojärjestelmäpalvelut Teknologiapalvelut Käsitteellinen taso - MITÄ alvelut Sidosryhmät, roolit alvelut-käsitteet - matriisi Looginen Taso - MITEN rosessikartta (rosessikuvaukset) rosessit-tiedot matriisi (Tietomallit) Loogiset tietovarannot Loog. järjestelmäjäsennys Järjestelmät-tiedot matriisi Järjestelmät-prosessit matriisi Integraatioperiaatteet (sis. liittymät) Teknologiakomponentit Valvonta- ja hallintaarkkitehtuuri Integraatioratkaisut (sis. rajapinnat) Fyysinen taso - MILLÄ Fyysiset tietovarannot Koodistot Fyys. järjestelmäsalkku Sijoituskaavio Verkkokaavio Teknologiasalkku Standardit Tässä työssä on kuvattu KA-menetelmän avulla yllä kuvatut oranssit kuvaukset yleisellä tasolla. Tämän lisäksi kuvattuja palveluarkkitehtuuriin ja liityntämallin valintaan liittyviä kuvauksia ja määrityksiä ovat: Integraatiopalvelun sisäinen jäsennys Liittymismallien (integraatiovaihtoehdot) SWOT-analyysit Liityntäpalvelun keskeiset prosessit Liityntäpalvelun vaatimukset ereseptin integraatio on sijoitettu osaksi laajempaa arkkitehtuuri- ja palvelukenttää. Työssä on huomioitu mm. kehitettävä valtionhallinnon VALTASAarkkitehtuurikehitys. Seuraavaan on koottu varsinainen viitearkkitehtuuri kuntasektorin KAmenetelmän mukaisesti käsitetasoittain tarkentuen kohti fyysistä tasoa. 2. ereseptin taustaviitekehys 2.1. ereseptin yleiskuvaus Tässä dokumentissa keskitytään ereseptin integraatioarkkitehtuurin kuvaamiseen. Kokonaiskuvan saamiseksi oheen on kuitenkin kuvattu yleiskuvausta ereseptistä. Taustaa

9 9 ereseptillä tarkoitetaan sekä sähköistä lääkemääräystä eli sähköistä reseptiä että valtakunnallista tietojärjestelmäpalvelua, joka on osa KanTa-palveluita eli terveydenhuollon valtakunnallisia tietojärjestelmäpalveluita, joihin kuuluvat myös earkisto- ja Omien tietojen katselu palvelut sekä yhteisiä tukipalveluita. Sähköisestä lääkemääräyksestä annetun lain mukaan lääkäri tai hammaslääkäri voi jatkossa laatia reseptin sähköisesti ja siirtää sen suoraan valtakunnalliseen Reseptikeskukseen. Kun potilas menee noutamaan lääkettä, apteekki ottaa yhteyden Reseptikeskukseen ja hakee sieltä tiedot potilaalle määrätystä lääkkeestä. Järjestelmään luodaan myös katseluyhteys, jonka kautta potilas voi omalta kotikoneeltaan katsoa tietoja hänelle kirjoitetuista resepteistä ja niillä toimitetuista lääkkeistä. 2 Sähköisiä lääkemääräyksiä voidaan tulevaisuudessa laatia kaikissa terveydenhuollon yksiköissä ja lääkemääräyksiä voidaan toimittaa kaikista apteekeista tässä keskitetyssä järjestelmässä. Sähköisen lääkemääräyksen tavoitteena on parantaa potilas- ja lääketurvallisuutta sekä helpottaa ja tehostaa lääkkeen määräämistä ja toimittamista. Sähköisestä lääkemääräyksestä annetun lain mukaan Kela toimii rekisterinpitäjänä ja ylläpitää valtakunnallista Reseptikeskusta ja -arkistoa. Sähköisen lääkemääräyksen käyttöönotot alkavat vuoden 2010 aikana. Sähköinen resepti eresepti on lääkemääräys, jonka lääkäri laatii ja allekirjoittaa sähköisesti ja tallentaa keskitettyyn tietokantaan, jota kutsutaan Reseptikeskukseksi. Valtakunnallinen Reseptikeskus sisältää sähköiset reseptit ja apteekkien niihin tekemät toimitusmerkinnät. Resepti ja sen toimitustiedot säilyvät Reseptikeskuksessa 30 kuukautta eli 2,5 vuotta. Sähköisen reseptin hyödyt Kun potilaan kaikki reseptit on tallennettu Reseptikeskukseen, lääkäri voi potilaan suostumuksella tarkistaa tämän kokonaislääkityksen ja ehkäistä lääkkeiden haitallisia yhteisvaikutuksia ja päällekkäisyyksiä. otilaan pyynnöstä myös farmaseutti tai proviisori voi tarkistaa kokonaislääkityksen. Sähköisen reseptin käyttöönoton jälkeen kaikilla terveydenhuollon toimipisteillä ja apteekeilla on käytössään yhtenäiseen Lääketietokantaan perustuvat tiedot. Lääketietokanta sisältää lääkkeen määräämisen ja toimittamisen kannalta tarpeelliset tiedot lääkkeestä, sen hinnasta ja korvattavuudesta sekä keskenään vaihtokelpoisista lääkevalmisteista. Tietokannassa on myös tiedot korvattavista perusvoiteista ja kliinisistä ravintovalmisteista. Sähköisen reseptin käyttöönoton jälkeen potilaalla on edelleen oikeus saada paperiresepti, jos hän kieltäytyy sähköisestä reseptistä. 2

10 10 Reseptitietoja voidaan käyttää valvontaan, lääketurvatoimintaan, lääkekorvausten maksamiseen ja tutkimukseen vielä 10 vuotta sen jälkeen, kun ne eivät enää näy Reseptikeskuksessa. Näihin tarkoituksiin tietoja voivat saada mm. Valvira, lääninhallitukset, Lääkealan turvallisuus- ja kehittämiskeskus, Kela ja Lääkehoidon kehittämiskeskus. ereseptin toiminnallisuus ereseptin toiminnallisuus kattaa normaalin lääkemääräyksen käsittelyn sähköisesti. Se kattaa sekä reseptin kirjoittamisen, lääkkeen toimittamisen reseptin mukaisesti potilaalle että reseptin uusimisen toiminnot. Terveydenhuollon yksikkö Reseptikeskus Apteekki otilastietojärjestelmä Lääkärit Lääketieteen opiskelijat Hammaslääkärit Hammaslääketieteen opiskelijat Lääkemääräyksen kirjoittaminen Lääkemääräyksen korjaaminen Lääkemääräyksen mitätöinti Uusimispyyntöjen käsittely Lääkemääräyksen uusiminen Lukitusten purku Määräysten ja toimitusten haku Reseptikeskus Lääkemääräykset & lääketoimitukset Määräysten ja toimitusten haku Lääkemääräysten varaus Lääkemääräysten lukitus Uusimispyyntöjen kirjoitus Annosjakelu Varauksen purku Lukituksen purku Annosjakelun purku Toimitusvarauksen purku Apteekkitietojärjestelmä Farmaseutit roviisorit eresepti sisältää myös resepteihin liittyvän terveydenhuollon ammattilaisten ja kyseisen potilaan tietopalvelun olemassa olevista resepteistä. ereseptin arkkitehtuuri ereseptin arkkitehtuuri koostuu erityisesti viidestä toiminnallisesta osasta: Terveydenhuollon toimijoiden potilastietojärjestelmät Kansallinen Reseptikeskus, jossa sähköisiä lääkemääräyksiä säilytetään ja joka toimii terveydenhuollon toimijoiden ja apteekkien reseptien välittäjänä Apteekkien lääkkeitä ja lääkemääräyksiä käsittelevät tietojärjestelmät Valviran (ent. TEO) varmenne- ja attribuuttipalvelu Mahdolliset liityntäpalvelut toimijoiden välillä Seuraavassa esitetään yleiskuva KanTa-arkkitehtuurista.

11 11 Valvira Varmenteet THL Koodistot 2.2. Sanoma- ja liittymismäärittelyt ereseptin toteutuksessa on sovittu käytettävän HL7- rajapintatasoa. Lisäksi tulee huomioida ereseptin sanomamäärittelyistä tehty erratadokumentti. Molemmat dokumentit ovat saatavissa HL7-yhdistyksen dokumenttiarkistosta 4. On huomattava, että sanomamäärityksissä niissä on huomioitu myös apteekit, jotka on jätetty tämän integraatioarkkitehtuuritarkastelun ulkopuolelle. 3 3 Kansallisen Terveysarkiston (KanTan) tavoitteet, Jari orrasmaa, 4

12 12 Määritysdokumentti keskittyy Reseptikeskuksen viestinvälitysrajapinnan määrittelyyn. Dokumentissa on luettavuuden vuoksi kuvattu toiminnallisuutta myös yleisemmällä tasolla. Kela on tehnyt Reseptikeskuksesta erillisen toiminnallisen ja teknisen vaatimusmäärittelyn, joita tulee käyttää yhdessä HL7 rajapintadokumentaation kanssa. Vaatimusmääritykset löytyvät sivustolta. HL7 dokumentissa kuvattu toiminnallisuus on esitetty luettavuuden vuoksi ja se on tehty yhteensopivaksi Kelan dokumentaation kanssa. Jos dokumenteissa on ristiriitaisuuksia, Kelan dokumentaatio 5 on ensisijainen lähde. Rajapintakokonaisuuden kannalta on järkevää lukea dokumentti "Lääkemääräyksen CDA R2 rakenne - Johdanto" ennen muita yksityiskohtaisempia dokumentteja. Johdannossa on käyty läpi, mitä dokumentteja rajapintakokonaisuus sisältää, eräitä tärkeitä reunaehtoja ja kunkin dokumentin karkea sisältö. Liityntäarkkitehtuurin kuvauksessa ei käsitellä tarkasti varsinaisia ereseptin sanomamäärityksiä, joten sanomien yksityiskohtia ei käsitellä tässä dokumentissa Kelan liittymisohjeistus Kela on julkaissut KanTa- liittymismallin ja liittymisohjeen, 6 jonka tarkoituksena on antaa yleiskuva KanTa-palveluihin liittymisen edellytyksistä ja liittymisen eri vaiheista painopisteenä eresepti-palveluun liittyminen KanTa-liittymisen edellytykset Liittyminen KanTa-palveluihin edellyttää liittyjältä integraatioratkaisun toteuttamisen lisäksi oman toimintaympäristön muutoksia. Näitä ovat mm. - KanTa-palveluiden käyttöön liittyvien toimintamallien suunnittelu ja toteutus sekä sopiminen alueen apteekkien kanssa - organisaation tietoturvallisuuskäytäntöjen dokumentointi - Henkilöstön ohjeistus ja koulutus (toimintamallit ja tietoturva) - liittymisaikataulun suunnittelua - omien tietojärjestelmien eresepti-toiminnallisuuden sisältävän versioiden hankinta - vaadittavien tukipalveluiden kustannustehokas hankinta - Henkilöstön ohjeistus ja koulutus Liittymisen edellytyksiä on tarkemmin kuvattu Kelan Liittymisohje KanTa-palveluihin-dokumentissa

13 13 3. eriaatetason arkkitehtuuri 3.1. Arkkitehtuuriperiaatteet Arkkitehtuuriperiaatteiden määrittelyssä on huomioitu mm. kehitteillä olevassa valtionhallinnon valtiotason arkkitehtuurit hankkeen (VALTASA) valtionhallinnon arkkitehtuuriperiaatteet ja linjaukset projektissa tehdyt linjaukset. 8 Näitä on muokattu siten, että ne huomioivat ereseptin integrointiin liittyvät erityispiirteet kuntasektorille paremmin soveltuviksi. Tässä kuvataan vain keskeisimmät periaatteet. Laajempi kuvaus kaikista 15 periaatteesta löytyy liitteestä 2, Arkkitehtuuriperiaatteet Toimintaan vaikuttavat periaatteet Arkkitehtuurin tulee olla strategialähtöistä ja edistää kustannustehokkaita ratkaisumalleja kehittyvässä toimintaympäristössä Kansallisen ereseptin integraatioarkkitehtuurin tulee tukea terveyden- ja sairaanhoidon toteuttamisen tavoitteita. Tavoitteiden tulee heijastua ereseptin integraatioarkkitehtuurissa. Tiedon hallinnan kehittämistyön taustalla on oltava toiminnan tehostamisen tukeminen kustannustehokkaasti. Kustannustehokkuutta lisää toimintaa tukevan ICT-teknologian suunnittelu ja käyttöönotot, joissa ennakoidaan toistuvat toimintaympäristön muutokset sekä uusien sähköisten palveluiden kehittäminen. Integraatioarkkitehtuurilla voidaan nimenomaan helpottaa muutosten kustannustehokasta hallintaa sekä nopeuttaa niiden toteuttamista sekä uusien sähköisten palveluiden kehittämistä. Integraatioratkaisut tukevat usein mainittuja tavoitteita erityisen hyvin, jos ratkaisuja toteutetaan samaa väestöä hoitavien organisaatioiden yhteiskäyttöisinä toteutuksina Tietoon kohdistuvat periaatteet Tietoturvallisuus on huomioitava tiedon koko elinkaaren ajan Tietoturvallisuus on kokonaisuus, joka liittyy tietoihin, tietoja käsitteleviin järjestelmiin, tiedon siirtoon sekä tietojen käsittelyprosesseihin ja prosesseissa mukana oleviin ihmisiin. Henkilötiedot ovat terveydenhuollossa pitkään säilytettäviä ja usein myös pitkään käytössä, minkä vuoksi niiden turvallisuutta on tarkasteltava koko elinkaaren aikana. On kuitenkin huomioitava, että yksittäisten tietojen luokitus tietoturvan suhteen voi muuttua tiedon elinkaaren eri vaiheissa. Terveydenhuollon terveyden- ja sairaanhoidossa käsiteltävät tiedot ovat pääsääntöisesti salassa pidettäviä luottamuksellisia tietoja. Luottamuksellisuus säilyy tiedon koko elinkaaren ajan. ereseptin integraatio sekä tietojärjestelmien ja tietojen yhteiskäyttöisyys korostaa tietoturvan merkitystä järjestelmissä ja tietojen käsittelyprosesseissa Valtasa: Valtionhallinnon arkkitehtuurilinjaukset ja periaatteet v 0.62 ( )

14 14 Tietoturvaan liittyviä VAHTI -ohjeita 9 suositellaan hyödynnettäväksi. Kaikkien ereseptin integraatioon liittyvien tietovarantojen ja tietojärjestelmähankkeiden yhteydessä on tehtävä tietoturvatarkastelu. Tietoturvallisuus muodostuu kokonaisuudesta, johon kuuluvat tietojärjestelmien lisäksi mm. toimijan organisaatio, toimintamallit, yksittäiset ihmiset sekä fyysiset tilat. Tietoturvallisuuden yhteydessä tulee ottaa huomioon tietosuojavaatimukset sekä terveyssektorilla vaatimus tiedon saatavuudesta läpi kansalaisen elämän ja asiointitilanteiden. Erityisen haasteen tietosuojan toteutukseen tuovat tulossa olevat muutokset loogisen tason ja fyysisen tason rekisterinpitoon niitä koskevien säädösmuutosten ja toisaalta hyvinvointipalveluiden organisaatiomuutosten takia. Muutokset tulevat tapahtumaan asteittain Järjestelmiin kohdistuvat periaatteet Tässä liityntäpalvelukeskeisessä arkkitehtuurityössä ei juuri käsitellä tai kehitetä uusia tietojärjestelmiä. Tämän luvun periaatteet kohdistuvat lähinnä integraatiopalveluun, joka muodostuu teknisestä alustasta ja viestinvälityssovelluksesta. Kehitä järjestelmiä toimintalähtöisesti ereseptin integraatiopalvelun ja siinä käytettävän integraatiosovelluksen suunnitelman, tarvittavien palveluiden tunnistamisen ja mitoittamisen tulee perustua toiminnallisiin vaatimuksiin. Kehittämistyön tavoitteen määrittelyssä tai tavoitteen kuvaamisesta ei tule tinkiä, vaikka välivaiheen toteutuksessa joudutaan huomioimaan aikataulut ja lyhyen aikavälin taloudelliset realiteetit. Integraatioratkaisun tulee tukea kansalaislähtöistä tiedon saatavuutta ja olla mukautuva tarpeiden ja organisaation muutoksiin ilman tiedonhallintajärjestelmän täydellistä uudelleensuunnittelua. Integraatioratkaisun tulee mahdollistaa joustavasti toimintaympäristössä tapahtuvat muutokset. Vältä päällekkäisiä ratkaisuja Yhdenmukaista toimintaa tukevista ereseptin integraatiojärjestelmistä ei tule olla useita päällekkäisiä tietoteknisiä ratkaisuja. Jo tehtyä on hyödynnettävä ja rinnakkaisten ratkaisujen kehittämistä on vältettävä. Uudelleenkäyttöä tukee, että järjestelmät pyritään määrittelemään hyödyntämään jo toteutettuja loogisia tiedonkäsittelyprosesseja samanlaisissa toiminnallisissa tilanteissa Uusia ratkaisuja kehitettäessä on otettava huomioon ratkaisujen tai niiden osien uudelleenkäyttömahdollisuudet. Ratkaisun valinnan tulee tukea tehokkaampaa sosiaali- ja terveydenhuollon sektorin erityisten tiedonhallintapalveluiden 9 ex.jsp

15 15 tuottamista yhteisesti yli organisaatiorajojen ja yleisiä tukipalveluita hyödyntäen Ratkaisuilta edellytetään modulaarisuutta ja eri osien korvattavuutta toisella vastaavalla. Ratkaisujen ja niiden määritysten on oltava löydettävissä siten, että uudelleenkäytettävyys voidaan arvioida. Varmista yhteentoimivuus ereseptin integraatiojärjestelmien tulee olla yhteentoimivia muiden järjestelmien kanssa sekä nyt että tulevaisuudessa. Yhteentoimivuuden vaatimus koskee myös palveluita, tuotteita ja laitteita. Integrointiarkkitehtuurin tulee muodostaa looginen ja ymmärrettävä osakokonaisuus osana kunkin toimijan koko sähköisen lääkemääräyksen toimintaympäristöä. Integraatioarkkitehtuuri tulee jäsentää loogisiin integraatiokerroksiin ja palveluihin. Järjestelmien yhteensopivuus arkkitehtuurien, standardien ja muiden järjestelmien kanssa tulee varmistaa. Järjestelmien avoimiin ja dokumentoituihin rajapintoihin tulee kiinnittää erityistä huomiota. Minimoi toimittajariippuvuus ereseptin integraatiojärjestelmien ja sovellusten ei tulisi olla sidottuja suljettuihin teknologiaratkaisuihin eikä yksittäisiin tuotetoimittajiin. Tietojärjestelmien ja niiden laitteistojen, rajapintojen ja ohjelmistojen tulisi olla toimialan ja toimijan viitearkkitehtuurin ja standardien kanssa yhteensopivia. Lisäksi tulisi suosia avoimia ratkaisuja. ereseptin integraatiojärjestelmien, tietojen sekä palvelujen tulee käyttää ja tukea standardeja ja standardinmukaisia rajapintoja, ellei ole perusteltua syytä poiketa niistä. Käytettyjen rajapintojen tulee vastata kansallisia terveydenhuollon rajapintavaatimuksia Hyödynnä avointa palvelukeskeistä arkkitehtuuria ja suosi avoimia rajapintoja ja standardeja Julkisella rahoituksella tehtävän kehitystyön tulisi hyödyttää kaikkia julkishallinnon toimijoita. Kehityksen tulisi tukea avoimeen palvelukeskeiseen arkkitehtuuriin siirtymistä, avoimia rajapintoja ja standardeja sekä avoimia standardoituja tietorakenteita. Myös Avoimen lähdekoodin ratkaisujen hyödyntämistä osana integraatioratkaisun toteutusta tulee arvioida. Niiltä osin kun integraatioratkaisun toteutuksessa hyödynnetään ei-avoimen lähdekoodin ratkaisuja, tulee varmistaa että ratkaisujen käyttöönottoihin liittyvä suunnittelutyön tuotokset,

16 16 tehdyt räätälöinnit ja konfiguraatiot ovat käyttäjäorganisaatioiden edelleenkehitettävissä ja jaettavissa Varmista suorituskyky, käytettävyys ja skaalautuvuus Integraatioratkaisun käytettävyyden ja suorituskyvyn tulee kaikissa olosuhteissa vastata toiminnan tarpeita. Integraatioratkaisun tulee mukautua ja olla suorituskyvyltään skaalattavissa KanTa-hankkeen earkiston-käyttöönoton tarpeisiin. Integraatioratkaisu tulee jakaa loogisiin kerroksiin (vertikaalinen skaalautuvuus) sekä mahdollistetaan näiden kerrosten ns. horisontaalinen skaalautuvuus. Ratkaisussa tulee huomioida myös itse sanomanvälityksen hallinta kuten lähetykset yöaikaan, toistuvat lähettämiset ja erilaiset ajastukset Rajaukset ja reunaehdot Tässä työssä on huomioitu seuraavan taulukon mukaiset rajaukset ja reunaehdot: Kuvaus Reunaehto/rajaus Vaikutukset Integraatioarkkitehtuurissa hyödynnetään sellaisenaan ereseptiin liittyviä kansallisia määrityksiä. Työssä ei puututa ereseptin rakenteeseen tai sisältöön. Työssä käsitellään vain Lain sähköisestä lääkemääräystä koskevan lain alaisia lääkkeitä ja lääkemääräyksiä. Ei esimerkiksi eläinlääkkeitä tai rohdoksia ja luontaistuotteita eikä laitosapteekin toimitettavaksi tarkoitettuja lääkkeitä. Työ kattaa terveydenhuollon organisaatiossa tapahtuvan sähköisen lääkemääräyksen käsittelyn koko sen elinkaaren aikana, mutta ei esim. apteekin ja Reseptikeskuksen välistä integraatiota. Työ kattaa varsinaisten integraatioprosessien lisäksi myös hallinnointiprosessit: - Liityntäpalveluun liittyminen, muutoksenhallinta, liittyjän sulautuminen toiseen liittyjään, liityntäpalvelusta irrottautuminen Reunaehto Reunaehto Rajaus Rajaus Rajaus Integraatioratkaisu noudattaa ereseptin kansallisia määrityksiä, millä varmistetaan toteutuksen yhdenmukaisuus ja yhteentoimivuus muiden arkkitehtuurin mukaisten valtionhallinnon ratkaisujen kanssa. Tämä projekti keskittyy vain integraatioon ja rakenne ja sisältö tuotetaan muissa projekteissa. Huom. Joskus resepteillä voidaan määrätä myös reseptivapaita lääkkeitä, sidostarpeita tai muita tarvikkeita. Näin varmistetaan, että ratkaisu kattaa reseptin koko elinkaaren. Näin varmistetaan, että ratkaisu kattaa sekä integroinnin että sen hallinnoinnin. Tässä työssä ei kuvata prosesseja liittymisestä Reseptikeskukseen. Työ kattaa tekniset käytettävyysvaatimukset (SLA) ja koko integraatioratkaisun valvontaperiaatteet. Rajaus Näin varmistetaan, että ratkaisu tyydyttää käytettävyydelle asetettavat vaatimukset ja että ratkaisun toiminta on valvottua ja sen käytöstä saadaan riittävät valvontatiedot Työ ei kata sairaala-apteekkien reseptitoimintaa. Rajaus Sairaala-apteekit eivät juuri käsittele varsinaisia lääkemääräyksiä. Sairaala-apteekit voidaan tarvittaessa ottaa haluttaessa mukaan myöhemmin. Lääketietokannan käsittely Rajaus Käsitellään vain siinä määrin, kun se on välttämätön ylätason integraatioarkkitehtuurin määrittämiseksi. Arkkitehtuuriratkaisun tulee olla kustannustehokas sekä käyttöönottovaiheessa että käytön aikana Reunaehto Ks. Arkkitehtuuriperiaate: Arkkitehtuurin tulee olla strategialähtöistä ja edistää kustannustehokkaita

17 17 ratkaisumalleja Sidosarkkitehtuurit ja niitä kehittävät hankkeet ereseptin integraatioarkkitehtuurissa tulee huomioida muu kansallinen ja sektorikohtainen arkkitehtuurikehittäminen. Keskeisimmät ereseptin integraatioon vaikuttavat sidosarkkitehtuurit ja niitä kehittävät hankkeet ovat: Nimi Velvoittavuus Kuvaus Keskeinen sisältö KanTa Velvoittava Sosiaali- ja terveydenhuollon kansallinen sähköinen arkisto. Työ on aloitettu terveydenhuollon puolelta. KANTA - ereseptiarkki-tehtuuri Kansallinen terveysarkisto KanTa on tarkoitettu palvelemaan sekä terveydenhuollon ammattilaisia että kansalaisia. KanTa-palveluihin kuuluvat sähköinen resepti, potilastietoarkisto sekä mahdollisuus katsoa omia terveystietojaan netin kautta. Ensivaiheessa terveydenhuollon potilastiedot ja eresepti, jatkossa myös sosiaalitoimen asiakirjat Velvoittava Reseptikeskus ja tämän erityisratkaisut ereseptin teknisen käsittelyn vaatimukset ja määritykset Solea-hanke Huomioitava SOLEA-hankkeessa tutkitaan ja kehitetään palvelukeskeisen arkkitehtuurin (SOA) hyödyntämistä osana organisaatioiden kokonaisarkkitehtuuria (EA). Valtasa-hanke Huomioitava Valtionhallinnon arkkitehtuurin kehittämishanke (Valtasa) Virtu-K Huomioitava Kuntien virkamiehen tunnistaminen ja käyttövaltuushallinta, Virtu-K Tavoitteena on tutkia ja mitata palvelupohjaisen kehitystavan hyötyjen (joustavuus ja liitettävyys) saavuttamista siten, että kehittämistyössä liiketoiminnan / toiminnan kehittämisen ja teknisen kehityksen välimatka pienenee, ja kokonaisjärjestelmän kehityssyklit nopeutuvat. Määrittää valtionhallinnon ja osin julkishallinnon arkkitehtuurin pääjäsennyksen sekä karkeantason kuvan tavoitetilasta. Valtiotason arkkitehtuurityön tehtävä on huomioida koko julkishallinnon näkökulma ja soveltuvin osin tuottaa koko julkishallintoa koskevia arkkitehtuurimäärityksiä. Kuntien virkatunnisteratkaisun vaatimusmäärittely / ohje. Käyttövaltuushallinnan kehittämisen ohjeistus. Jälkimmäisessä on koottu yhteen olemassa oleva ohjeistus ja luotu esimerkkitapaukset käyttövaltuushallinnan prosesseista. SADe Huomioitava Ensimmäisen vaiheen tarkoitus oli tehdä ehdotuksia kehittämistoimenpiteiksi ja laajoiksi toteuttamishankkeiksi, joilla tavoitellaan parempaa sähköisten asiointipalveluiden saatavuutta ja löydettävyyttä kansalaisille ja yrityksille. Kehittämisen painopisteenä ovat asioinnin ohella elämäntilanteista ja tarpeista lähtevien palvelukokonaisuuksien luominen.

18 18 Asiointitili Huomioitava Julkishallinnon kansalaisen asiointitili Kansallinen sähköisen asioinnin kanava, jota kautta kansalaisen tulisi jatkossa päästä kuntien ja valtionhallinnon sähköisiin palveluihin. Kansallinen koodistopalvelu Velvoittava THL koodistopalvelin. Koodistopalvelimelta jaellaan yhtenäiset sosiaali- ja terveydenhuollon sähköisten asiakastietojärjestelmien tarvitsemat koodirakenteet (Laki 159/2007). Sisältää sosiaali- ja terveysalan sanastoja ja koodistoja, joita hyödynnetään operatiivisissa järjestelmissä. Koodistojen päätietolähteenä toimii THL:n koodistopalvelu, mutta koodistopalvelin voidaan toteuttaa myös paikallisesti tai alueellisesti, jolloin kansalliset koodistot haetaan soveltuvin väliajoin tähän paikalliseen tai alueelliseen ratkaisuun Tietoturvatarpeet ja periaatteet Kokonaisarkkitehtuurimallissa tietoturvallisuus on kaikki arkkitehtuurinäkökulmat läpäisevä ominaisuus. ereseptin integraation tietoturvallisuus muodostuu eri arkkitehtuurinäkökulmien summana: tietoarkkitehtuuri (mm. käsiteltävät tietoaineistot ja niiden luokittelu tietosuojan ja tietoturvallisuuden näkökulmasta, tietojen alkuperä ja oikeellisuus), toiminnan arkkitehtuuri (mm. tietoaineistojen käsittelyn prosessit, tietojärjestelmien kehittämisen ja hallinnan prosessit), teknologia-arkkitehtuuri (mm. tietoturvallisuuteen vaikuttavat teknologiavalinnat) tietojärjestelmäarkkitehtuuri (mm. tietojärjestelmien toteutuksen tietoturvallisuus) Tietoturvaperiaatteet ereseptin integraatiossa noudatetaan voimassaolevaa lainsäädäntöä (Laki sähköisestä lääkemääräyksestä, Laki sosiaali- ja terveydenhuollon asiakastietojen sähköisestä käsittelystä, Sosiaali- ja terveysministeriön asetus potilasasiakirjoista), ereseptin vaatimusmäärityksiä ja vaatimuksissa kuvattuja KanTaliittymän sanomaliikenteen tietoturvavaatimuksia. Lisäksi tietoturvaperiaatteita suositellaan täydennettävän valtionhallinnon VAHTI-tietoturvatasojen ja Liitteessä 1, kuvattujen tietoturvaperiaatteiden pohjalta. Sanomaliikenteen tietoturvavaatimukset löytyvät Kelan määrityksistä. Seuraavaan on siitä poimittu muutama keskeinen vaatimus: Liikenne liityntäpisteen ja KanTa-palvelun välillä salataan ja osapuolet tunnistetaan SSL 3.0 tai TLS 1.0 tekniikoin (vähintään 1024 bittinen RSA-avain), käyttäen Valviran palvelinvarmenteita (mutual authentication) Liityntäpisteellä tulee yhteystyypistä riippumatta olla yksi kiinteä Iosoite, liityntäpisteitä voi olla useita

19 19 alvelinvarmenteen subject/serialnumber kentän OID-koodi tulee yksilöidä liityntäpiste ja vastata KanTa-osoitehakemiston tietoja Mikäli liityntäpisteen toteuttaa joku muu kuin KanTa-liittyjä (eli käytetään välittäjää) o liikenne liittyjän potilastieto- tai apteekkijärjestelmältä ulkoistetulle liityntäpisteelle tulee salata vähintään vastaavan tasoisella menetelmällä kuin SSL/TLS siltä osin kuin se kulkee muualla kuin organisaation sisäverkossa (esimerkiksi operaattorin runkoverkko, vaikka käytössä olisi operaattorin suljettu yhteys) o sanomaliikenteen kaikkien osapuolten identiteetti tulee varmentaa. o liityntäpisteen toteuttajan tulee varmistaa, että sanoma on lähetetty oikean tahon nimissä (eli HL7-sanoman controlactrocess / authororerformer / assignederson / assignederson / representedorganization / id vastaa edellisessä kohdassa varmennettua identiteettiä) o välittäjältä vaaditun tietoturvatason toteutuminen tulee varmistaa auditointimenettelyllä eli KANTA-määrittelyistä (2007) poiketen WS-Security standardin mukainen sanomatason allekirjoitus ja/tai salaus eivät ole käytössä (VVAR019) Kaikkien KanTa-sanomaliikenteeseen liittyvien tahojen tulee suojata liityntäpistesijaintinsa ja tietojärjestelmien käyttöympäristöt tilallisella palomuurilla tai sovelluspalomuurilla Vastaanottopalveluissa (KanTa liittyjä eli paluusuuntaisissa yhteysavauksissa) o liityntäpisteen toteuttaja on velvollinen tarkistamaan Kelan KanTa-liityntäpisteen palvelinvarmenteen (ns. mutual authentication) o kullekin palvelulle (esimerkiksi lääkemääräyksen uudistamispyynnön vastaanotto) tulee olla yksi KanTa-palvelulle päin näkyvä organisaatioyksikkökohtainen liityntäpiste.

20 20 4. Käsitteellisen tason arkkitehtuuri Tässä osiossa kuvataan ereseptiin liittymistä käsitteellisellä tasolla millaisia rooleja ja toimijoita tarvitaan, mitä elementtejä eresepti-integraation liittyvä järjestelmäkokonaisuus käsittelee ja mitä palveluja siihen liittyy. Käytännössä tämä tarkoittaa sitä, ettei tässä osiossa oteta vielä kantaa siihen, miten liittymisratkaisu toteutetaan ja organisoidaan, miten järjestelmän ohjelmisto on suunniteltu tai millä palvelimilla tietyt toiminnallisuudet tai tietovarannot sijaitsevat. Tämän arkkitehtuurikuvauksen pääasiallinen kohde on kuitenkin ereseptin käyttöönottoon liittyvä integratioarkkitehtuuri. Muut integraatioarkkitehtuurin valintaan ja toimeenpanoon liittyvät kohteet on huomioitu yleisellä tasolla Roolit Seuraavassa on lueteltu ereseptiin ja monilta osin integraatioratkaisuun liittyvät pääroolit: Reseptikeskus Rekisterinpitäjä Liityntäpalvelu Välittäjä Reitittäjä (Tietoliikennepalveluiden järjestäjä) Liittyjä otilas uolesta asioija Lääkäri Eräät muut terveydenhuollon ammattihenkilöt Maksaja Työnantaja Apteekin työntekijä Tietoliikenneoperaattori Roolit on kuvattu tarkemmin vastuineen ja tehtävineen liitteessä 1, Arkkitehtuuritaulukot Toimijat ereseptin integraatioratkaisuun osallistuu suuri joukko erilaisia sidosryhmätoimijoita, joista osa on ereseptin operatiivisia toimijoita. Operatiiviset toimijat (organisaatiot): Reseptikeskus

21 21 THL Valvira Kela Terveydenhuollon toimintayksiköt Apteekit Liityntäpalvelu/liittyjä IT-palvelutoimittajat Muut toimijat: Fimea (Lääkelaitos) STM KuntaIT ValtIT Valtion IT-palvelukeskus Apteekkariliitto Lääketeollisuus Ry Lääkäriliitto Hammaslääkäriliitto Toimijat on kuvattu tarkemmin liitteessä 1, Arkkitehtuuritaulukot Integraatiopalveluun liittyvät tietojärjestelmäpalvelut Integraatiopalveluun liittyy erilaisia tietojärjestelmäpalveluita: ereseptin toiminnallisuuteen määritellyt tietojärjestelmäpalvelut o Valviran varmennepalvelu o Koodistopalvelu o Terveydenhuollon organisaation potilastietojärjestelmä o Reseptikeskuksen ereseptiarkisto o Apteekin tietojärjestelmä Integraatiosovellus o Integraatiosovelluksen sisäiset osapalvelut Integraatiopalvelun tukijärjestelmät o Integraatioratkaisun valvonta- ja hallintajärjestelmät

22 22 o Liittyjien asiantuntijatuen tukijärjestelmät (palvelupyyntöjen hallintajärjestelmä, konfiguraationhallintajärjestelmä jne.) Edellisistä varmennepalvelua ja integraatioratkaisun osapalveluita on kuvattu tarkemmin seuraavassa. Valvonta-arkkitehtuuria on kuvattu tarkemmin jäljempänä Varmennepalvelu Valviran varmennepalvelu Valviran varmennepalvelu toimii palvelinten ja terveydenhuollon ammattilaisten sähköisenä varmennepalveluna. Sähköinen tunnistaminen ja allekirjoittaminen perustuvat varmenteisiin, joiden avulla yhdessä ammattihenkilön attribuuttitietojen kanssa varmistetaan, että lääkkeen määränneellä ja toimittaneella henkilöllä on ammattihenkilölakiin perustuva oikeus määrätä tai toimittaa lääkkeitä sekä lääkärin ja hammaslääkärin tiedonsaantioikeus Reseptikeskukseen tallennetuista lääkemääräyksistä. ereseptissä Valviran varmennepalvelun kautta tunnistetaan ja määritetään luotettavasti sekä ereseptin liityntäpisteen ja Reseptikeskuksen palvelimet, järjestelmäallekirjoitus sekä henkilökäyttäjä terveydenhuollon ammattilainen. Valvira toimittaa varmennekortit ereseptin käyttöönottoaikataulussa lääkäreille, hammaslääkäreille, farmasian alan ammattihenkilöille ja näiden alojen opiskelijoille. Kortit tuotetaan pääsääntöisesti tehdastoimituksena, mistä syystä alueilta ei edellytetä valmistelevia toimenpiteitä korttijakelun osalta. Valvira julkaisee lisäinformaatiota korttien jakelusta Terveydenhuollon varmennepalveluiden kotisivuilla Integraatioratkaisun osapalvelut Integraatiopalvelu jakautuu luonteviin osapalveluihin, joiden yhdistelmänä voidaan määrittää tarvittavia integraatiopalveluita erilaisiin sanomaliikennetarpeisiin. ereseptin integraatioratkaisua on kuvattu kappaleissa 5.3 ja 5.4. Seuraavassa on lueteltu yleiset integraatioratkaisun osapalvelut ja loogisen rakenteen kuvauksessa tarvittavat symbolit:

23 23

24 24 Näiden osapalveluiden toteutuksessa tulee noudattaa soveltaen ValtIT:n Looginen integraatioarkkitehtuuri dokumentin 10 suosituksia. ereseptiin rakennettavan integraatioratkaisun tulee perustua välineeseen, joka sisältää kaikki yllä kuvatut loogiset osapalvelut, jotta sitä voidaan laajentaa myöhemmissä KanTa-ratkaisuissa. Näistä tarvitaan ereseptivaiheessa lähinnä kappaleessa kuvatut osapalvelut. Integraatioratkaisussa ja siihen liittyvässä palvelussa sanomaliikenteen korkean palvelutason valvonta on erittäin tärkeää. Keskitetyn sanomanvälityspalvelun valvonnan avulla voidaan kerätä sekä reaaliaikaista tietoa palvelun vikatilanteista (hälytykset), että kerätä trenditietoa ongelmanhallinta, kapasiteetinhallintaa ja jatkuvuudenhallintaa varten. 5. Loogisen tason arkkitehtuuri 5.1. Liityntäpalvelun integraatioperiaatteet Liityntäpalvelussa ja liittymismalleissa käytettyjä termejä KanTa-liittyjä ja liittyvä organisaatio Laissa mainittu organisaatio (ks. yllä), joka ryhtyy käyttämään KanTapalveluja. Kaikkien KanTa-palveluihin liittyvien organisaatioiden ja näiden mukana liittyvien palveluyksiköiden ja sivuapteekkien pitää olla rekisteröitynä Terveyden ja hyvinvoinnin laitoksen (THL) ylläpitämään valtakunnalliseen koodistopalveluun terveydenhuollon organisaatiorekisteriin (THL SOTE-organisaatiorekisteri) tai apteekkirekisteriin (Fimea apteekkirekisteri). Tätä kautta niiden ISO OIDyksilöintitunnukset ja muut rekisteröidyt tiedot tulevat KanTapalvelujen käyttöön. KanTa-välittäjä ja välittäjä Välittäjällä tarkoitetaan terveydenhuollon organisaation tai apteekin KanTa-liitynnän toteuttamisessa käyttämää palveluntarjoajaa, jolla on tässä roolissa mahdollisuus nähdä salaamattomia potilastietoja, esim. ylläpitotoimien yhteydessä. Valviran palvelinvarmenteella toteutettava TLS-salattu yhteys muodostetaan välittäjän ja KanTa-palvelujen välille. Välittäjäksi ei määritellä organisaatiota, joka toimii ainoastaan TLSsalatun tietoliikenteen reitittäjänä eikä voi nähdä salaamattomia potilastietoja. Välittäjän erityistapaus on organisaatio, joka on itse KanTaliittyjä, esim. sairaanhoitopiiri tai sen liikelaitos. 10 Valtionhallinnon yhteentoimivuuden kehittämisohjelma, Integraatioarkkitehtuuri, Looginen integraatioarkkitehtuuri, V 1.0(E), _09_Valtionhallinnon_integraatioarkkitehtuuri.pdf

25 25 Välittäjät voivat muodostaa keskenään alihankintaketjuja. Sen välittäjän, jonka nimissä Valviran palvelinvarmenne on, pitää olla sopimussuhteessa terveydenhuollon organisaation tai apteekin kanssa. Jos välittäjä toteuttaa liityntäpisteen palvelut usealle KanTa-liittyjälle, hankitaan liityntäpisteen palvelinvarmenne yleensä välittäjän nimiin. Välittäjän toteuttaman liityntäpisteen OID-tunnus muodostetaan välittäjän OID-tunnuksen alle solmuluokkaan 13. KanTa-liityntäpiste KanTa-liityntäpiste on julkisen internetin tai suljetun asiakasverkon tietoliikenneosoitteen ja palvelinvarmenteen yhdistelmä. KanTaliityntäpisteen ja KanTa-palvelujen välille muodostetaan salattu ja tunnistettu tietoliikenneyhteys Valviran myöntämän palvelinvarmenteen avulla. Jokaisella liittyvällä organisaatiolla on vähintään yksi KanTaliityntäpiste, joka voi olla toteutettu organisaation omana toimintana tai toisen organisaation toteuttama. Liityntäpisteitä voi erityistapauksissa olla useita, jos o organisaation yksiköt liittyvät KanTaan suoraan eri tietojärjestelmistä ilman keskistettyä viestinvälitysratkaisua o organisaation vastaanottopalvelut sijaitsevat eri palvelimessa kuin siinä, josta organisaation järjestelmät kutsuvat KanTapalveluja o organisaation järjestelmät käyttävät Valviran rooli- ja attribuuttipalvelua eri osoitteesta kuin siitä, josta ne kutsuvat KanTapalveluja Tietojen ylläpidon kannalta on suositeltavaa, että KanTa-liittyjä keskittää KanTa-palveluihin tapahtuvan tietoliikenteensä yhteen liityntäpisteeseen tai korkeintaan kahteen, jos se tarjoaa vastaanottopalveluja. Yhden liityntäpisteen toteutusmalli ei sulje pois tietoliikenneyhteyksien ja palvelimien kahdentamista. KanTa-liityntäpisteelle annetaan yksilöivä OID-tunnus, joka muodostetaan liityntäpisteen toteuttamisesta vastaavan organisaation tai organisaatioyksikön OID-tunnuksen alle solmu-luokkaan 13. alvelinvarmenne alvelinvarmennetta tarvitaan, jotta voidaan muodostaa salattu TLSyhteys KanTa-palvelujen ja KanTa-liityntäpisteen välille sekä tunnistaa KanTa-liityntäpiste. Jokaista KanTa-liityntäpistettä varten pitää hankkia oma palvelinvarmenne Valvirasta. alvelinvarmenne ja KanTaliityntäpiste kytketään toisiinsa palvelinvarmenteen Subject-osion SerialNumber-kentän1 välityksellä. Sen arvoksi tulee KanTaliityntäpisteen OID-tunnuksen arvo. alvelinvarmenteen Subject-osion

26 26 commonname-kenttään tulee arvoksi liityntäpisteen DNS-nimi tai Iosoite. alvelinvarmennetta voidaan käyttää myös organisaation ja ulkoistetun KanTa-liityntäpisteen välisen liikenteen salaamisessa ja liikennöivien osapuolien tunnistamisessa. otilastietojärjestelmä Järjestelmä on tarkoitettu potilaiden terveyteen ja hoitoon liittyvän tiedon kirjaamiseen ja hallintaan. Järjestelmässä tieto kirjataan sähköisesti ja tieto on siirrettävissä sähköisesti organisaatiosta toiseen. Tällaisia järjestelmiä ovat mm. Effica, egasos, Uranus, Mediatri jne. Järjestelmä tarjoaa mm. seuraavia toimintoja: o Lähetteiden ja palautteiden käsittely o Hoidon ja resurssien varaus o Ajanvarausten ja vuodepaikkojen hallinta o Vastaanottotoiminta o Sähköiset potilaskertomukset o Laboratoriotoiminta o Hammashuolto o Kuvantaminen, kuvien käsittely ja arkistointi o Digitaalinen sanelu ja puheentunnistus o Kotihoito o Lääkitys o Alueelliset ratkaisut Liityntäpalvelu osana viestinvälitysketjua Liityntäpalvelulla (integraatiopalvelulla) tarkoitetaan tässä kokonaispalvelua, jolla potilastietojärjestelmässä muodostettavat eresepti-sanomat välitetään Reseptikeskukseen, reseptikeskuksen tietoja luetaan ja jonka kautta paluusuuntaiset yhteydenmuodostukset (uudistamispyynnöt) toteutetaan. Lisäksi liityntäpalvelua voidaan hyödyntää KanTa-tukipalveluiden käytössä tarvittavien integraatioiden toteutuksessa, kuten terveydenhuollon ammattihenkilöiden attribuuttipalveluun liittyvissä integraatiotarpeissa. SSL/TLS SSL/TLS Reseptikeskus Liityntäpalvelu Liityntäpalvelu on looginen palvelukokonaisuus, joka täyttää ereseptin tekniset vaatimukset sanomien välittämiseksi potilastietojärjestelmän ja Reseptikeskuksen välillä. Liityntäpalvelu sisältää oleellisena osana myös integraatioratkaisun (integraatioalusta), jota on kuvattu tarkemmin kohdissa ja

27 27 Loogisella tasolla liityntäpalveluun sisältyviä osia ja toiminnallisuuksia sisältyy myös potilastietojärjestelmien sisäisiin toteutuksiin, koska potilastietojärjestelmien tulee pystyä voimassaolevien vaatimusmääritysten mukaan liittymään reseptikeskuksen palveluihin ilman ulkoista järjestelmäriippumatonta liityntäpalvelua. otilastietojärjestelmien sisäisiä palveluita ei kuitenkaan ole välttämättä suunniteltu usean järjestelmän ja toimijan eresepti-sanomien välittämiseen. KanTa-määrityksissä määritellyn liityntäpisteen ja KanTa-järjestelmän välinen yhteys vaatii aina Valviran palvelinvarmenteen, joka identifioi kiistämättömästi palvelimen ja osoitteen. Yhteyttä määrittävät seuraavat tekniset periaatteet: Klusteroidun ratkaisun tapauksessa kaikilla noodeilla voi olla sama palvelinvarmenne (mikäli klusterilla on yksi ulospäin näkyvä osoite), joten muodostavat yhden liityntäpisteen. Kutakin ulospäin näkyvää (kiinteää) I-osoitetta varten määritetään oma liityntäpisteensä ja palvelinvarmenteensa (yksi osoite, yksi liityntäpiste, yksi palvelinvarmenne) Salattu TLS-yhteys muodostetaan Valviran palvelinvarmenteella liityntäpisteestä KanTa-palveluun asti. Reitillä voi olla tietoliikenteen koontipisteitä (osoitemuunnokset) ilman, että TLS-yhteyttä välissä puretaan. Reseptikeskuksesta (laajemmin KanTa-palvelusta) liittyjälle menevässä liikenteessä (uudistamispyynnöt) tulee kuitenkin olla yksikäsitteinen osoite, jolla reitti löytyy vastaanottajalle asti. Liityntäpiste (TLS-yhteyden muodostava piste) voi olla esimerkiksi potilastietojärjestelmä, viestinvälitysalusta, liityntäpalvelu (integraatioratkaisu) tai verkon aktiivilaite, joten liityntä KanTaan voidaan määritellä joko tietoliikenne-, sanomanvälitys- tai sovellustasolla. Liityntäpalvelun kohdalla tarkastellaan erityisesti sanomanvälitystason liityntäpistevaihtoehtoa - joskin liityntäpalvelun sisällä TLS/SSL-yhteyksien muodostaminen ja purkaminen voi tapahtua tietoliikennetasolla, esim erillisen laitteen toiminnallisuutena..alla olevissa kuvissa liityntäpiste on merkitty keltaisella pisteellä.

28 28 Kuntatoimija Liityntäpalvelu SSL/TLS Kuntatoimija Jatkettu verkko, VN SSL/TLS Reseptikeskus Reseptikeskus Liityntäpalvelu Kuntatoimija Salaus SSL/TLS Reseptikeskus Liityntäpalvelu Asetettujen vaatimusten mukaisesti potilastietojärjestelmän ja liityntäpalvelun välisillä yhteyksillä tulee myös käyttää molemminpuolista autentikointia sekä tiedonsiirron salausta, vähintään niiltä osin kun tiedonsiirtoon hyödynnetään muita kuin organisaation sisäverkon yhteyksiä (esimerkiksi operaattorin runkoverkko, vaikka käytössä olisi operaattorin suljettu yhteys). Toteutustapana voidaan käyttää varmennepohjaista SSL/TLS-toteutusta tai tietoturvaltaan vastaavantasoista teknologiaa. otilastietojärjestelmä voidaan liittää reseptikeskukseen suoraan, kunnan tietojärjestelmäpalvelukokonaisuuteen kuuluvan liityntäpalvelun kautta tai kuntatoimija voi käyttää ulkoista usean organisaation yhteistä liityntäpalvelua. Tämän dokumentin teknisissä kuvauksissa ja palvelumäärityksissä tarkastellaan erityisesti sellaisen ulkoisen liityntäpalvelun käyttöä, joka välittää useamman rekisterinpitäjän, kunnan, sairaanhoitopiirin tai muun terveydenhuollon kuntatoimijan sähköisiä lääkemääräyksiä. Liittymismalliskenaarioissa on arvioitu myös muita liittymisvaihtoehtoja. Ulkoinen palvelu voi olla esimerkiksi toisen kuntatoimijan tai palveluntarjoajan hallinnassa oleva usean organisaation yhteinen liityntäpalvelu, johon yksittäisten toimijoiden lähiverkot liitetään. Liityntäpalvelun varaan voidaan rakentaa myös sanomien reitittämiseen liittyviä säännöstöjä. Tämä koskee esim. tilannetta jossa sähköisten lääkemääräyksen uudistamispyyntö kohdistetaan eri järjestelmiin vastaanottavan yksikön tms. kuvailutiedon perusteella, mutta toimitetaan Kelalta samaan tietoliikenneosoitteeseen. Liityntäpalvelun avulla toteutettavaa reititystä voidaan hyödyntää

29 29 myös esimerkiksi tilanteissa, joissa kuntaliitosten tai vastaavien organisaatiouudistusten tai tietojärjestelmän vaihtoon liittyvissä tapauksissa joudutaan tekemään esim. kuvailutietoihin perustuvia reitityssääntöjä. Reitityssääntöjen toteuttaminen järjestelmistä ulkoisessa liityntäpalvelussa edellyttää luonnollisesti huolellista sopimista liittyjän ja liityntäpalvelun toimittajan välillä sekä toimivaa muutoksenhallintaprosessia. Sanomaliikenteen tietoturva liityntäpalvelun tapauksessa otilastietojärjestelmien liittämisessä KanTa-palveluihin edellytettyjä sanomaliikenteen tietosuoja- ja tietoturvavaatimuksia ja suosituksia on asetettu/kuvattu pääosin seuraavissa dokumenteissa: KanTa-viestinvälityksen arkkitehtuurimäärittely, lähinnä kappaleen 4.7 alakohdissa. OpenC- DA_2008_Laakemaarayksen_MedicalRecords_sanomat_v2.50.doc - dokumentista (kappale 6.5) STM:n auditointikriteerit Vahti Tietoturvatasot Kaikki potilastietojärjestelmien ja KanTa-palveluiden väliset tiedonsiirtoyhteydet on suojattava siten, ettei ulkopuolisilla ole mahdollisuus päästä käsiksi siirrettävään tietoon. Liikenne liittyjän potilastietojärjestelmältä ulkoistetulle integraatioratkaisulle tulee salata vähintään vastaavan tasoisella menetelmällä kuin SSL 3.0 tai TLS 1.0 siltä osin kun se kulkee muualla kuin organisaation sisäverkossa (esimerkiksi operaattorin runkoverkko, vaikka käytössä olisi operaattorin suljettu yhteys). Sanomaliikenteen kaikkien osapuolten identiteetti tulee varmentaa. Varmentaminen on pakollista organisaatioiden välisessä tiedonsiirrossa, jossa käytetään muita kuin sisäverkon yhteyksiä. Tapauksissa joissa tietojärjestelmien palvelimet sijaitsevat samassa konesaliympäristössä tai ympäristöissä välityspalvelun- tai tiedonsiirtoon osallistuvien mahdollisesti hyödynnettävien erillisten laitteistojen kanssa (kuormantasaajat, SSL-kiihdyttimet tms.) kanssa, ei varmennepohjainen tunnistaminen ole pakollista, edellyttäen että konesali- ja käyttöympäristön sisäisestä tietoturvasta on huolehdittu vaatimusten mukaisesti. Autentikoinnin ja salauksen toteutuksessa käytetään KanTa-liitynnän osalta julkisen avaimen infrastruktuuria (KI) ja palvelinvarmenteita. Kelan ja varmennepalveluiden tuottajien ohjeistuksessa on yksityiskohtaisempaa tietoa varmenteiden hankkimisesta ja varmentamisen teknisestä toteutuksesta. Mikäli integraatioratkaisussa välitetyt sanomat tallennetaan sovituksi ajaksi ns. sanomacahceen, näiden tietojen pääsynhallintaan tulee kiinnittää huomiota tyypillisesti synkronisen liikenteen sanomia ei yleensä taltioida välityspalveluun. ereseptin liityntäarkkitehtuuria määritellyt työryhmä suosittelee liityntäpalvelun tuottajia toteuttamaan palvelunsa siten, että välitetyistä sanomista taltioidaan teknistä lokia, johon tallennetaan pääsääntöisesti seuraavat tiedot: aikaleima, sanomatyyppi, sanoma_id, mikä järjestelmä lähetti, mihin välitettiin.

30 otilastietojärjestelmän rooli ereseptin viestinvälityksessä otilastietojärjestelmältä edellytetään, että se voi liittyä suoraan tai ulkoisen välitysratkaisun kautta Reseptikeskukseen. otilastietojärjestelmästä voidaankin ereseptin integraationäkökulmasta tunnistaa ainakin kolme sisäistä loogisesti toisiaan täydentävää tietojärjestelmäpalvelua: Lääkemääräystä koskevan asiakirjan luonti eresepti-sanoman muodostaminen Viestinvälitys: Sanoman käärimiseen (SOA), varmenteen hallintaan ja sanoman välittämiseen. Näistä sanomanmuodostus ja siihen liittyvä viestinvälitys ovat varsinaisesti integraatioon suoraan liittyviä palveluja. otilastietojärjestelmä Sanomanmuodostus Asiakirjanmuodostus Reseptikeskus WS erus-tj TJ:n sisäinen liityntäratkaisu Yllä olevassa kuvassa potilastietojärjestelmän (TJ) sanomanmuodostus ja sen sisäinen, looginen liityntäratkaisu kommunikoivat keskenään Web services rajapinnalla, mutta tämä voidaan luonnollisesti toteuttaa myös muilla tavoilla. Eri tietojärjestelmätoimittajat ovat toteuttaneet ereseptisanomanmuodostuksen ja varsinaisen viestinvälitystoteutuksen eri tavoilla. Osa on toteuttanut liityntäratkaisun hyvin tiukasti muuhun toimintaan integroituna, osa taas jakaa kyseiset palvelut myös järjestelmän sisällä erillisiksi ja käyttää mahdollisesti eri loogisten palvelujen toteutukseen kaupallista välinettä. On hyvä huomata, että potilastietojärjestelmäkohtaisen liityntäratkaisun ja ulkoisen liityntäpalvelun välinen yhteys voidaan toteuttaa tarvittaessa samoja rajapintoja ja tietoliikennemäärityksiä hyödyntämällä kuin yhteys liityntäpisteestä Reseptikeskukseenkin. Tällöin hyödynnetään potilastietojärjestelmän varmenteita kuten muidenkin liityntäpisteiden kohdalla. Kelan määritys ei kuitenkaan anna tietoturvaa lukuun ottamatta tarkkoja määräyksiä liityntäpisteenä toimivan alueellisen liityntäpalvelun ja potilastietojärjestelmän väliselle yhteydelle. Oletusarvoisesti potilastietojärjestelmä kannattaa liittää liityntäpalveluun samoin periaattein kuin reseptikeskukseenkin. Loogisen tietojärjestelmäpalvelujäsennyksen kannalta olisi selkeintä, jos varsinainen järjestelmäkohtainen liityntäratkaisu erotetaan selkeästi sanomanmuodostuksesta ja sanomanmuodostuksen ja liityntäratkaisun välinen rajapinta dokumentoitaisiin ja tämä dokumentaatio saatettaisiin avoimesti liityntäpalveluntuottajien ja terveydenhuollon kuntatoimijoiden saataville. Kehittyneimmmässä mallissa tämä määritettäisiin kansallisella standardilla. Avoimet rajapinnat loisivat muita järjestelmäkohtaisia ratkaisuja joustavamman ympäristön, joka mukautuu terveydenhuollon toimijoiden toimintaympäristön muuttuessa

31 31 ja KanTA-arkkitehtuurin kehittyessä. Avoin, ja dokumentoitu rajapinta mahdollistaisi myös seuraavan toteutuksen: otilastietojärjestelmä Sanomanmuodostus Asiakirjanmuodostus Reseptikeskus WS SSL/TLS Rajapinta SSL/TLS erus-tj Alueelliseen liityntäpalveluun voidaan näin avointen määritysten mukaan toteuttaa tässä tapauksessa rajapinta potilastietojärjestelmään ja se voi korvata tarvittaessa potilastietojärjestelmäkohtaisen viestinvälitysratkaisun. Nykymallissa rajapinnan dokumentointivastuu ja tämän saattaminen avoimesti saataville on järjestelmätoimittajien vastuulla. Alueellisten liityntäpalveluiden integraatioratkaisujen tulee olla liitettävissä kaikkiin keskeisiin potilastietojärjestelmiin Integraatioratkaisu tietojärjestelmänä teknologia-arkkitehtuuri Integraatioratkaisu on tietojärjestelmä, joka edellyttää kaikkia keskeisiä normaalin tietojärjestelmän jatkuvan palvelun teknisiä komponentteja: Laitetila o Turvallinen, fyysiseltä pääsyltään rajattu tila o Varmennettu ja turvattu, kapasiteetiltaan riittävä sähkönsyöttö o Varmennettu ja turvattu, kapasiteetiltaan riittävä ympäristönhallinta jäähdytys ja kosteudenhallinta o Sammutuskalusto ja tulipaloilmaisimet Laitetilan ja sen ympäristön tietoliikenne o Konesaliverkko fyysiset yhteydet o Tarvittavat konesalikytkimet o Laitetilan liittyminen muuhun tietoliikenteeseen palomuurilaittein Integraatioratkaisun palvelinympäristö o alvelinlaitteet ja niiden varusohjelmistot o Tarvittavat tietokannat o Varsinainen integraatiosovellus Valvonta ja hallinta o Keskitetty valvontaratkaisu (ks. tarkempi kuvaus jäljempänä) o Etähallintayhteydet

32 32 Alla on kuvattu tämä teknologisten palveluiden pino laitetilasta valvontaratkaisuihin alhaalta ylös. Integraatioratkaisu tulee sijoittaa turvalliseen laitetilaan, jossa on fyysisen turvallisuuden lisäksi vakioitu ympäristö ja varavoimalaitteisto. Liityntäpalvelun hyödyntämä infrastruktuuri, kuten tietoliikenne, edellyttää kokonaispalvelutason mukaista korkeaa käytettävyyttä. Itse integraatioratkaisu koostuu integraatiosovelluksesta ja tätä varten varatusta itsenäisestä tai yhteiskäyttöisestä palvelimesta ja tarvittavista integraatioratkaisukohtaisista tietovarannoista. Integraatiopalveluun kuuluvat teknisen integraatioratkaisun lisäksi myös sen valvonta- ja hallintapalvelut. Liityntäpalvelua tuottavalla toimijalla tulee olla integraatioratkaisun tuotantoympäristön lisäksi myös testiympäristö, jossa esimerkiksi toteutettaviksi hyväksytyt muutokset voidaan testata ennen niiden viemistä tuotantoon Liityntäpalvelun integraatioratkaisun looginen jäsennys Integraatioratkaisun loogista jäsennystä voidaan tarkastella kahdesta näkökulmasta Integraatioratkaisun kerroksellisuus Integraatioratkaisun looginen palveluketju Integraatioratkaisun kerroksellisuus Integraatioratkaisun toiminnot voidaan jakaa seuraaviin kerroksiin

33 33 Ohjauskerros alvelu/sovelluskerros Välityskerros Tiedonsiirtokerros Ohjauskerroksessa hallitaan sanomanvälitysketjuja ja valvotaan sanomaliikennettä. alvelu- ja sovelluskerros sisältää varsinaiset integraatioratkaisun osapalvelut, välityskerros siirtää varsinaisia sanomia ja tiedonsiirtokerroksella tarkoitetaan lähinnä järjestelmän sisäistä tietoliikennettä. Integraatioratkaisun looginen palveluketju Seuraavassa on kuvattu liityntäpalvelun looginen palveluketju. Kuvassa ereseptisanoman oletetaan kulkevan vasemmalta oikealle. Valvira SSL/TLS SSL/TLS Sanomaliikenteen suunta Liityntäpalvelun sisäinen palvelurakenne on lähtöpään salattua liikennettä ja palomuuria lukuun ottamatta identtinen sekä kuntatoimijan omassa liityntäpalvelussa että ulkoisessa usean toimijan keskitetyssä liityntäpalvelussa. Vaikka tässä työssä keskitytäänkin lähinnä sanomanvälitystason integraatioon, ereseptin integraatiossa tietoliikennetasolla toteutetaan lähes väistämättä reitityksiä keskitettyjen tietoliikennesolmujen läpi. Tätä kautta voidaan toteuttaa ns. verkkokerroksen välityspalveluita sekä vaihtoehtoisia reittejä, jotka parantavat sähköisten lääkemääräysten käytettävyyttä (availability) ja jatkuvuutta. Sanomanvälitystason ja verkkotason vaihtoehtoisia reitityksiä voidaan käyttää riippumattomasti yhtä aikaa. Liityntäpalvelun sanomanvälitys integraation osapalveluina Edellä kuvattu liityntäpalvelun integraatioratkaisun sisäiset loogiset palvelut voidaan jakaa osiin seuraavasti (sanoman välityksen loogisessa järjestyksessä, oletuksena, että sanoma välitetään potilastietojärjestelmästä Reseptikeskukseen):

34 34 1. Sanoma saapuu salattua yhteyttä pitkin liityntäpalvelun palomuuriin. Synkronisessa liikenteessä synkroninen kanava avataan aina päätepisteen sovellukseen saakka 2. alomuuri tunnistaa sallitun liikenteen ja protokollan päästää sen liityntäpalveluun 3. Sanoma reititetään liityntäpalvelun tietoliikenneverkossa integraatiosovellukselle (päädytään siniselle alueelle) 4. Kanava-adapteri kytkee potilastietojärjestelmän integraatiosovellukseen 5. (Ehdollinen vaihe) Integraatiopalvelu suodattaa ei-sallitut sanomat liikenteestä esim. täysin väärät sanomat, virheellinen sanoma (ei osata välittää edelleen) tai kielletty sanoma. Virheellisen sanoman yhteydessä integraatiopalvelu lähettää 6. Sanoma välitetään sanomakanavaan ja tätä kautta sanomaväylään 7. Sanomareititin selvittää sanomasta, mihin se pitää reitittää ja välittää sanoman oikealle taholle tässä tapauksessa Reseptikeskukseen. Mikäli sanoma on virheellinen, eikä integraatiopalvelu pysty välittämään sanomaa eteenpäin, integraatiopalvelu palauttaa potilastietojärjestelmälle teknisen virhekuittauksen 8. (Ehdollinen vaihe) Mikäli liityntäpalvelun asiakasorganisaatio (kunnallinen terveydenhuollon toimija) on sopinut esimerkiksi reseptien uusimispyyntöjen reitittämisen joko pysyvästi tai väliaikaisesti toiseen kohteeseen (esimerkiksi kuntaliitos, kesäkausi), integraatiopalvelu tekee sanomamuunnoksen (muuttaa uusivan organisaation OID-koodia) 9. Kanava-adapteri kytkee integraatiosovelluksen Reseptikeskuksen ereseptisovellukseen 10. Sanoma reititetään integraatiosovellukselta liityntäpalvelun tietoliikenneverkkoon (poistutaan siniseltä alueelta) 11. Sanoma siirtyy salattua yhteyttä pitkin Reseptikeskuksen palomuuriin. Synkronisessa liikenteessä synkroninen kanava on auki päätepisteen sovellukseen saakka Sanomaliikennettä ja loogista käsittelyketjua hallitaan ja valvotaan integraatiopalvelun ohjauskerroksessa (punaruskea kerros). Keskeisiä välineitä ovat integraatioratkaisun valvontaväylä, joka seuraa sanomaliikennettä, liikenteen lokitiedot tallentava tietovaranto sekä varsinaista käsittelyprosessia hallinnoiva prosessimoottori ja prosessien kuvausvälineet.

35 alvelutasovaatimukset Seuraavassa on kuvattu alustavat suositukset liityntäpalvelun palvelutasovaatimuksista. Seuraavia suosituksia suositellaan käytettävän liityntäpalvelun palvelutasomääritysten pohjana ottaen huomioon paikalliset erityisvaatimukset. Laatumääreitä koskeva terminologia Liityntäpalvelun palvelutasot koostuvat soveltuvista laatumääreistä sekä näiden palveluun valituista tasoista. Laatumääreellä tarkoitetaan palvelun laatua koskevaa, vielä luokittelematonta tekijää ja sen yksikköä. Laatumäärettä käytetään laadun mittaamiseen. Esim. palveluaika (yksikkö = aikaväli tunteina ja minuutteina), käytettävyys (yksikkö = käytettävyysprosentti), toimitusaika (yksikkö = kesto). alvelutasolla taas tarkoitetaan tietyn laatumääreen luokiteltua laadullista tasoa, joka on asiakkaan valittavissa kyseiseen palveluun. Esim. palveluajan palvelutasoluokkia voivat olla mm. arkisin klo 8-16 ja 24/7 kaikkina vuoden päivinä. Seuraavaan on koottu liityntäpalvelussa käytettävien laatumääreiden keskeiset määritelmät: Laatumääre alveluaika Käytettävyys Maksimikatko Kuvaus Service Hours. Sovittu aikaväli, jolloin asiakkaalle tai palvelun kohteelle tuotetaan palvelukuvauksen mukaista palvelua. Esimerkiksi arkisin klo Availability. Käytettävyydellä tarkoitetaan kohteena olevan laitteen, palvelun päälläoloa ja kykyä tuottaa sitä palvelua, jota kohteelta edellytetään, sovitun toiminnon suoritus vaadittuna aikana. Käytettävyys lasketaan vähentämällä käyttökatkojen aika ideaalikäytettävyydestä palveluaikana. Tässä käytettävyys vastaa ITIL-termiä availability, jolla suosituksen laatimishetkellä on ITSMF- Finlandin termistössä kaksi rinnakkaista suomennosta: käytettävyys ja saatavuus. Käytettävyydellä ei tässä siis tarkoiteta helppokäyttöisyyttä (usability). isin yksittäinen yhtämittainen palvelukatko, joka sallitaan palvelun palvelutasotavoitteiden puitteissa palveluaikana sovitulla tarkasteluvälillä. Esim. 2 tuntia yhden kalenterikuukauden aikana. Huom. tämä yksittäisen katkon enimmäispituus on määritelty tässä suosituksessa aina pienemmäksi kuin kaikkien palvelukatkojen kumulatiivinen kesto.

36 36 Reagointiaika Ratkaisuaika Response Time. Aika, jonka kuluessa tapahtuman tai häiriön havaitsemisesta tulee häiriön korjaaminen tai tapahtuman käsittely aloittaa. Reagointiaika riippuu yleensä häiriön kriittisyysluokasta. Häiriö voidaan havaita joko asiakkaan häiriöilmoituksesta (tapahtuma) tai toimittajan itsenäisen valvontahälytyksen tai muun havainnon (event management) pohjalta Aika häiriön tai ongelman havaitsemisesta, jonka aikana toimittajan tulee saada poistettua häiriö tai ongelma tai muuten normalisoida palvelu. Liityntäpalvelun laatumääreet ja palvelutasot Liityntäpalvelun palvelutasoon vaikuttavat seuraavat laatumääreet: Liityntäpalvelun yleinen palvelutaso o Käytettävyys, maksimikatkot, reagointiaika, ratkaisuaika, palveluaika, Liityntäpalvelun suorituskyky ja virhesuhde o Välitettyjen sanomien kulkuaika liityntäpalvelun läpi (mediaani ja maksimi) o Välitettyjen sanomien määrä (maksimimäärä, jolla suorituskyky voidaan saavuttaa) o Välitettyjen ereseptisanomien virheettömyys (sanomavirhesuhde) Asiantuntijatuen palvelutaso o alveluaika, tavoitettavuus, ratkaisukyky Liityntäpalvelun yleisiin palvelutasotavoitteisiin sekä asiantuntijatuen palvelutasoon voidaan soveltaa JHS-174 määrityksissä kuvattua palvelinten käyttöpalveluiden palvelutasoluokitusta. Tässä tapauksessa sitä sovelletaan koko liityntäpalveluun (edellä oleva liityntäpalvelukuvauksen palomuurista palomuuriin ). Liityntäpalveluun suositellaan sovellettavan JHS-174 suosituksen palvelutasoluokituksista valittuja palvelutasotavoitteita seuraavasti: Yleinen palvelutasotavoite Tuotantoympäristö Liityntäpalvelun tuotantoympäristön yleisen palvelutasotavoitteen tulee olla seuraava: Yleinen palvelutasotavoite = alvelutaso D (Kriittinen) Kriittinen palvelutaso sisältää seuraavat tavoitearvot: alveluaika: 4 = 24/7 vuoden kaikkina päivinä

37 37 Käytettävyys: K3 = 99,5 %, maksimikatko palveluaikana 2 tuntia alveluvaste: V3 = kriittisissä häiriöissä reagointiaika: 30 min, ratkaisuaika: 4 tuntia Yllä kuvattu yleinen palvelutaso edellyttänee monennettua palvelin- ja konesalilaitteistoa. Suorituskyky ja virhesuhde Välitettyjen sanomien kulkuaikatavoite: mediaani < 0,5 s / sanoma, maksimi < 5 s / sanoma. Välitettyjen sanomien määrä: Vähintään 10 sanomaa sekunnissa (ks. myös mitoitusperiaatteet jäljempänä, mikäli liityntäpalvelun kautta välitetään huomattavan suuren kansalaisjoukon sähköisiä lääkemääräyksiä, liityntäpalvelun sanomamäärätavoitteet tulee suhteuttaa kansallisiin volyymeihin jäljempänä kuvattujen mitoitusperiaatteiden mukaisesti). Välitettyjen ereseptisanomien virheettömyys: lähetettyjen virheellisten sanomien suhde kaikkiin lähetettyihin sanomiin < 1/1000. Testi- ja kehitysympäristö Liityntäpalvelun testi- ja/tai kehitysympäristön yleisen palvelutasotavoitteen tulee olla seuraava: Yleinen palvelutasotavoite = alvelutaso B (Normaali) Kriittinen palvelutaso sisältää seuraavat tavoitearvot: alveluaika: 2 = arkisin klo 7-19 Käytettävyys: K2 = 99%, maksimikatko palveluaikana 4 tuntia alveluvaste: V2 = kriittisissä häiriöissä reagointiaika: 2 tuntia, ratkaisuaika: 1 työpäivä Tarvittaessa liityntäpalvelun toimittaja ja palvelun asiakkaat voivat sopia myös alhaisemmasta testi- ja kehitysympäristön palvelutasosta: alvelutasotavoite = A (Lähtötaso). Tästä tulee sopia selvästi erikseen. Asiantuntijatuki Asiantuntijatuen palvelutasotavoite = 5 (jatkuva tuki) Jatkuva tuki sisältää seuraavat tavoitearvot: alveluaika: 4 = 24/7 vuoden kaikkina päivinä Tavoitettavuus: T3 = 80 % -tukipuheluista vastataan 45 s kuluessa Ratkaisukyky: Koska kyseessä on päivystysluontoinen työ ja ns. 2. tason asiantuntijatuki, JHS-174 luokituksesta poiketen ratkaisukyvylle ei aseteta tavoitearvoa Asiantuntijatuki ottaa häiriöilmoituksia vastaan 24/7, muutostöitä ym. käsitellään normaalina työaikana.

38 38 Asiantuntijatuki on ns. 2. tason tuki, joka palvelee asiakkaiden omia tietoteknisiä tukiorganisaatioita. Se ei palvele loppukäyttäjiä. Huoltoikkuna Liityntäpalvelulle suositellaan määritettävän ns. huoltoikkunakäytäntö, jossa palvelukatkoa edellyttävät päivitys- ja kunnossapitotoimenpiteet sijoitetaan ennalta vuosikalenteriin sovittuihin hetkiin huoltoikkunoihin. alveluun suositellaan määritettävän neljä vuosittaista huoltoikkunaa. Huoltoikkuna käytetään vain tarvittaessa ja tästä ilmoitetaan etukäteen. Huoltoikkuna sijoitetaan kuukauden toiselle tiistaille aamuyöhön kello Tämä on alustavien arvioiden mukaan aikaa, jolloin kirjoitetaan ja toimitetaan hyvin vähän sähköisiä lääkemääräyksiä. Huoltoikkunan käytöstä tulee ilmoittaa liittyjille vähintään 21 päivää etukäteen Liittymismallit (integraatiovaihtoehdot) Tässä kappaleessa esitellään pääliittymismallit ja joitakin niiden variaatioita. Kuvauksissa on hyödynnetty pohjana KanTa-liittymismallit 2.4 dokumenttia. On hyvä huomioida, että tässä liittymismalleja tarkastellaan loogisella tietojärjestelmäpalvelutasolla. Alla kuvatut liittymismallit eivät siis ota esimerkiksi kantaa, operoiko kuntatoimija itse omaa konesaliaan ja palvelimiaan vai hankkiiko sen tämän operointityön ulkopuoliselta toimijalta. Olennaista on, kuinka kyseinen organisaatio järjestää loogisella tasolla liittymisensä Reseptikeskukseen ja myöhemmin KanTaan. Liittymismallien vahvuuksia, heikkouksia, mahdollisuuksia ja uhkia on arvioitu seuraavassa pääluvussa Liittymismalleissa käytetyt symbolit Liittymismalleissa käytetään seuraavia symboleja: KanTa-liittyjän terveydenhuollon järjestelmä. Tyypillisesti potilastietojärjestelmä. Eri värisillä symboleilla kuvataan eri toimittajien potilastietojär- tai jestelmiä (esim. Effica, egasos, Uranus, Mediatri jne.). Seuraavissa skenaarioissa nämä symbolit katsotaan sisältävän luvussa kuvatut potilastietojärjestelmien sisäiset liityntäratkaisut.

39 39 Kansallinen Reseptikeskus eli keskitetty tietokanta, jonne sähköiset reseptit ja tiedot apteekkien niihin tekemistä toimituksista tallennetaan KanTa-liittyjän oma integraatioratkaisu. Voi olla esimerkiksi kuntatoimijan keskitetty palveluväylä tai muu integraatioratkaisu. KanTa-liittyjän ulkopuolinen välittäjätahon toteuttama liityntäpalvelu Järjestelmätoimittajan oma, järjestelmäkohtainen integraatioratkaisu, johon on koottu useiden saman toimittajan järjestelmien eresepti-liittymät. Työasema, jolla käytetään toimittajan tarjoamaa palvelua (esim. SaaSpalveluna) Liittymismalleissa ei ole enää merkitty erikseen liityntäpistettä. Kaikissa vaihtoehdoissa se taho/palvelu, joka liittyy Reseptikeskukseen, toimii liityntäpisteenä.

40 Liittymismalli A suora järjestelmäliityntä Tässä mallissa liittyjäorganisaation KanTaan liitettävä järjestelmä ja KanTaliityntäpiste ovat liittyjäorganisaation omassa hallinnassa. alvelinvarmenne asennetaan suoraan sovelluspalvelimelle tai erilliseen aktiivilaitteeseen potilastietojärjestelmän yhteyteen eli kunnan järjestelmä tai kukin järjestelmä, jos niitä on useita, liittyvät suoraan Reseptikeskukseen potilastietojärjestelmän sisäisten tietojärjestelmäpalveluiden avulla. Kunnalla voi siis olla useita KanTa-liityntäpisteitä, jos sillä on useita liitettäviä tietojärjestelmiä tai jos organisaatio vastaanottaa sähköisen lääkemääräyksen uusimispyynnöt tai käyttää Valviran rooli- ja attribuuttipalvelua eri osoitteessa kuin siinä, josta se kutsuu KanTa-palveluja. Liitynnälle asetetaan mm. seuraavia suosituksia ja vaatimuksia: suljetun asiakasverkon yhteys, esim. MLS (suositus) kiinteät ja julkiset tietoliikenneosoitteet tilallinen palomuuri ja muu tietoturva palvelinvarmenne / liityntäpiste suoraan sovelluspalvelimelle tai erilliseen aktiivilaitteeseen potilastietojärjestelmän yhteyteen

41 Liittymismalli B kuntatoimijan keskitetty ratkaisu Tässä mallissa KanTa-liittyjällä on organisaatiokohtainen viestinvälitysratkaisu, jonka kautta KanTa-palveluihin voidaan liittää useita järjestelmiä ja organisaatioyksiköitä. Valviran myöntämä palvelinvarmenne asennetaan viestinvälitysratkaisun yhteyteen. Tällä palvelinvarmenteella muodostetaan tunnistettu ja salattu yhteys KanTa-palveluihin. alvelinvarmennetta voidaan tarvita myös liityntäpalvelun ja liitettävien tietojärjestelmien välillä osapuolten identiteetin varmistamisessa ja tiedonsiirron salaamisessa, mikäli esim. järjestelmät sijaitsevat eri konesaliympäristöissä. Viestinvälitysratkaisun käyttö mahdollistaa useiden järjestelmien liittymisen KanTaan samaa integraatioyhteyttä pitkin. Vaikka liittymismallissa hyödynnetään organisaatiokohtaisesti keskitettyä integraatioratkaisua, mahdollistaa malli KanTa-tietoliikenneyhteyksien keskittämisen laajempana kokonaisuutena esim. alueellisesti. Liittymälle asetetaan mm. seuraavia vaatimuksia ja suosituksia: suljetun asiakasverkon yhteys, esim. MLS (suositus) kiinteät ja julkiset tietoliikenneosoitteet tilallinen palomuuri ja muu tietoturva palvelinvarmenne viestinvälitysalustassa tai erillisessä aktiivilaitteessa viestinvälitysratkaisun ja tietojärjestelmien välillä osapuolten identiteetin varmistaminen, esim. Valviran palvelinvarmenteella

42 42 TLS-salattu tai vastaavasti suojattu yhteys organisaatioiden välillä, joka on toteutettu esim. Valviran palvelinvarmenteella Liittymismalli C alueellinen liityntäpalvelu Tässä mallissa KanTa-liittyjä on liittynyt KanTa-palveluihin usean organisaation yhteisen esim. alueellisen, järjestelmäriippumattoman KanTaliityntäpalvelun kautta. Keskitetyn integraatioratkaisun hyödyntämisen lisäksi myös liittymismallissa hyödynnettävät tietoliikenneyhteydet kannattaa usein toteuttaa keskitettynä. alvelinvarmenne asennetaan liityntäpalvelun yhteyteen. alvelinvarmennetta voidaan tarvita myös liityntäpalvelun ja liitettävien tietojärjestelmien välillä osapuolten identiteetin varmistamisessa ja tiedonsiirron salaamisessa, mikäli esim. järjestelmät sijaitsevat eri konesaliympäristöissä. Liittymälle asetetaan mm. seuraavia vaatimuksia ja suosituksia: integraatiopalvelun ja tietojärjestelmien välillä osapuolten identiteetin varmistaminen ja tiedonsiirron salaus, esim. Valviran palvelinvarmenteella suljetun asiakasverkon yhteys, esim. MLS, liityntäpalvelun ja KanTapalvelujen välillä sekä potilastietojärjestelmän ja liityntäpalvelun välillä (suositus)edellyttää välittäjäorganisaation auditointia palvelinvarmenne välittäjäorganisaation nimissä

43 43 järjestelmäallekirjoitusvarmenne potilastietojärjestelmän yhteydessä joko liittyjällä tai välittäjäorganisaatiolla, kuitenkin liittyvän organisaation nimissä (earkistoon liityttäessä) Liittymismalli D järjestelmäkohtaisesti keskitetty integraatio Tässä mallissa KanTa-liittyjä on liittynyt KanTa-palveluihin järjestelmäkohtaisen KanTa-liityntäpalvelun kautta. Jos kunnalla on useammanlaisia järjestelmiä, jokaiselle järjestelmätyypille on siis oma liittyntäpalvelunsa. alvelinvarmenne asennetaan liityntäpalvelun yhteyteen. alvelinvarmennetta voidaan tarvita myös liityntäpalvelun ja liitettävien tietojärjestelmien välillä osapuolten identiteetin varmistamisessa ja tiedonsiirron salaamisessa, mikäli esim. järjestelmät sijaitsevat eri konesaliympäristöissä. Keskitetty järjestelmäkohtainen palvelu voidaan toteuttaa joko alueellisesti, jolloin palvelu voidaan hankkia ja toteuttaa alueen organisaatioiden yhteistyössä tai valtakunnallisesti, mikäli ko järjestelmätoimittajalla on tarjolla keskitetty liittymisratkaisu. Liittymälle asetetaan mm. seuraavia vaatimuksia: integraatiopalvelun ja tietojärjestelmien välillä osapuolten identiteetin varmistaminen ja tiedonsiirron salaus, esim. Valviran palvelinvarmenteella suljetun asiakasverkon yhteys, esim. MLS, liityntäpalvelun ja KanTapalvelujen välillä edellyttää välittäjäorganisaation auditointia

44 44 palvelinvarmenne yleensä välittäjäorganisaation nimissä Liittymismalli E tuplaintegraatio Liittymismalli E Kunta 1 Kunta 2 Reseptikeskus Tässä mallissa KanTa-liittyjällä tai KanTa-välittäjällä on viestinvälitysratkaisu, jonka kautta KanTa-palveluihin liittyy useita järjestelmiä, organisaatioyksiköitä tai organisaatioita. Malliin B verrattuna erona on, että samanlaiset järjestelmät on ensin keskitetty järjestelmäspesifiseen palveluun ja sen jälkeen yhdistetty järjestelmäriippumattomaan liityntäpalveluun. Viestinvälitysalustan tehtävänä on reitittää sanomat sovelluspalvelimille, jotka voivat sijaita eri organisaatioyksiköissä tai organisaatioissa. Valviran myöntämä palvelinvarmenne asennetaan viestinvälitysratkaisun yhteyteen. Tällä palvelinvarmenteella muodostetaan tunnistettu ja salattu yhteys KanTa-palveluihin. alvelin-varmennetta voidaan tarvita myös viestinvälitysratkaisun ja liitettävien tietojärjestelmien välillä osapuolten identiteetin varmistamisessa ja tiedonsiirron salaamisessa, mikäli esim. järjestelmät sijaitsevat eri konesaliympäristöissä.

45 45 Viestinvälitysratkaisun käyttö mahdollistaa useiden järjestelmien, organisaatioyksiköiden tai organisaatioiden liittymisen KanTaan samaa tietoliikenneyhteyttä pitkin. Liittymälle asetetaan mm. seuraavia vaatimuksia: integraatiopalveluiden ja tietojärjestelmien välillä osapuolten identiteetin varmistaminen ja tiedonsiirron salaus, esim. Valviran palvelinvarmenteella. suljetun asiakasverkon yhteys, esim. MLS (suositus) kiinteät ja julkiset tietoliikenneosoitteet tilallinen palomuuri ja muu tietoturva palvelinvarmenne viestinvälitysalustassa tai erillisessä aktiivilaitteessa viestinvälitysratkaisun ja tietojärjestelmien välillä osapuolten identiteetin varmistaminen, esim. Valviran palvelinvarmenteella TLS-salattu tai vastaavasti suojattu yhteys organisaatioiden välillä, joka on toteutettu esim. Valviran palvelinvarmenteella Esimerkki: Muita liittymismallivariaatioita Tässä on esitetty vielä muutama variaatio edellä kuvatuista perusliittymismalleista. Erilaisia variaatioita on hyvin monia ja tässä kuvatut liityntämallit kuvaavat esimerkkejä tästä monimuotoisuudesta.

46 46 Vain edellä kuvatuille päävaihtoehdoille on tehty SWOT-analyysit. Liittymismallissa C2 kunnille tarjotaan palvelua palvelukeskuksesta ilman kunnan omaa järjestelmää. alveluntarjoaja liittyy viestinvälitysratkaisuun, jonka kautta liitytään sitten KanTa-palveluihin. Liittymismallissa D2 kunnille tarjotaan järjestelmäkohtaista palvelua palvelukeskuksesta ilman kunnan omaa järjestelmää tai kunnan järjestelmä liittyy järjestelmätoimittajan viestinvälitysratkaisuun. Tämän viestinvälitysratkaisun, kautta liitytään sitten KanTa-palveluihin. Liittymismalli X on yhdistelmä malleista B ja C. Kuntatoimija kokoaa kaikki ulkoiset integraatiot ensin organisaatiotasoiseen integraatiopalveluun, jota kautta liitytään alueelliseen integraatiopalveluun. Tämän välittäjän toteuttaman KanTa-liityntäpisteen kautta organisaatio liittyy KanTa-palveluihin Liittymismallien vertailu ja arviointi Liitteessä 3 on kuvattu kunkin päävaihtoehdon vahvuuksia, heikkouksia, mahdollisuuksia ja uhkia tehdyn SWOT-analyysin pohjalta. Liittymismalleja vertailtaessa voidaan erottaa ratkaisut, joissa hyödynnetään keskitettyä integraatioratkaisua (B,C,D,E) ja mallit, joissa integraatio toteutetaan suoraan järjestelmäkohtaisesti (A). Liittymismalleissa on tässä yhteydessä kuvattu ja arvioitu toteutusta integraatioarkkitehtuurin näkökulmasta. Toinen keskeinen KanTa-palveluiden käyttöönotoissa tarvittava tekninen palvelu on tietoliikenneyhteydet, jotka voidaan kaikissa arvioiduissa malleissa toteuttaa joko keskitetysti tai hajautetusti. Usein keskitetty ratkaisu on suositeltava. Reititys yhteen pisteeseen alueella voi olla jo valmiina alueen terveydenhuollon aiemmin luodun yhteistyöverkoston takia. Hajautetussa mallissa jokainen KanTa-liittyjä, joutuu järjestämään tietoliikenneyhteydet organisaatiokohtaisesti. Liittymismalleja on työssä arvioitu seuraavien näkökulmien mukaisesti Kustannustehokkuus Liittymisratkaisun kustannustehokkuutta tarkastellessa tulee huomioida ratkaisun käyttöönotosta syntyvien kustannusten lisäksi myös käytön kustannukset, sekä ratkaisun avulla saavutettava säästöpotentiaali. Keskitettyjen ratkaisujen (B,C, E ja D alueellisella tasolla toteutettuna ) ovat kaikki todennäköisesti käyttöönottokustannuksiltaan järjestelmäkohtaista ratkaisua korkeampia, mutta ratkaisuilla voidaan saavuttaa säästöjä paremman- ja tehokkaamman konfiguraation- ja muutostenhallinnan, tuotannonaikaisen valvonnan ja keskitettyjen tuki- ja asiantuntijapalveluiden hyödyntämisen ansiosta. Järjestelmäkohtaisesti ja järjestelmätoimittajavetoisesti keskitetty integraatioratkaisu (D järjestelmätoimittajakohtaisesti), on todennäköisesti käyttöönottokustannuksiltaan edullinen, mutta kokonaiskustannuksiltaan saattaa muodostua kalliiksi (muihin vaihtoehtoihin nähden), alueellisen tai paikallisen tason konfiguraation- ja muutostenhallinnan mahdollisuuksien puutteen vuoksi.

47 47 Toimijan koko / järjestelmien lukumäärä Mallit C,D alueellisesti toteutettuna ja E soveltuvat kaiken kokoisille organisaatioille. Malli B soveltuu vain suurille organisaatiolle, joilla on joko omia kehitysresursseja tai ulkoistetun integraatiopalvelun hankkimiseen tarvittavaan toimittajahallinnan osaamista. Malli A ja D kansallisesti toteutettuna soveltuu ainoastaan organisaatiolle jolla on käytössää vain yksi KanTa-palveluihin liitetty järjestelmä. Organisaatioille jolla on useita KanTa-palveluihin liitettyjä järjestelmiä soveltuvat parhaiten mallit B, C ja D alueellisesti toteutettuna. Toimijan olemassa olevat ja tiedossa olevat palvelut Yksi keskeinen valintaan vaikuttava tekijä on luonnollisesti se onko alueella tai organisaatiossa käytössä tässä dokumentissa ja liitteissä kuvatut tarpeet täyttävää integraatiopalvelua. Mikäli palvelu on olemassa, ovat mallit B,C,Dalueellinen tukeutuen olemassa olevaan ratkaisuun järkeviä. Kaikilla julkisen terveydenhuollon organisaatioilla on KanTa-palveluiden käyttöönottojen lisäksi myös muita paikallisia, alueellisia tai valtakunnallisia integraatiotarpeita. Valintaa tehtäessä suositellaan arvioitavan ensisijaisena vaihtoehtona mallia, jossa organisaatio tai organisaatiot toteuttavat myös muut integraatiotarpeensa samaan valittavaan ratkaisuun tukeutuen. Tietoturvallisuus, palvelun käytettävyys Kaikissa malleissa voidaan palvelun tietoturva ja käytettävyys taata, mikäli em. näkökohdat huomioidaan ratkaisua suunniteltaessa ja käyttöönotettaessa. Suorituskyky ja skaalautuvuus: Kaikissa malleissa voidaan ratkaisun suorituskyky ja skaalautuvuus varmistaa, mikäli em. näkökohdat huomioidaan ratkaisua suunniteltaessa ja käyttöönotettaessa. Keskitetyt liittymismalleja (B,C,D,E) suunniteltaessa tulee suorituskykyyn liittyviin näkökulmiin (esim. vaikutukset vasteaikoihin) erityisesti kiinnittää huomiota. Käyttöönoton aikataulu: Käytössä/saatavissa olevan integraatiopalvelun kautta toteutettavan keskitettyjen liittymismallien (B,C,D,E) mukaisen käyttöönoton aikataulun ei arvioida olevan merkittävästä pidempi kuin järjestelmäkohtaisessa liittymismallissa A. Mikäli integraatiopalvelua ei ole valmiiksi jo käytössä/saatavilla arvioidaan sen suunnittelun- ja käyttöönoton olevan pitkäkestoinen ja vaativa prosessi, johon tulee varautua myös ereseptin käyttöönottoaikatauluissa. Kansallisten palveluiden näkökulma: Kansallisten palveluiden näkökulmasta ratkaisut, joissa yksittäisten intergaatioyhteyksien ja tätä kautta kokonaisintegraatioyhteyksien määrä on mahdolli-

48 48 simman pieni ovat suositeltavia (mallit B,C,D,E). Myös ratkaisut jossa osa konfigurointitarpeista ja muutoksista voidaan hallita alueellisella tai paikallisella tasolla keskitetyn integraatiopalvelun avulla ovat suositeltavia kansallisten palveluiden näkökulmasta. Hallinnan näkökulma: Keskitetyn integraatiopalvelun vaihtoehdoilla (B,C,D-alueellinen, E) arvioidaan helpottavan ja nopeuttavan arkkitehtuuriin ja tietojärjestelmäympäristöihin kohdistuvaa konfiguraation- ja muutostenhallinnan toteuttamista. Järjestelmäkohtaisesti ja järjestelmätoimittajavetoisesti keskitetty integraatioratkaisussa (D-valtakunnallinen), arvioidaan paikallisesta ja alueellisista tarpeista lähtevien muutosten toteuttaminen olevan hitaampaa ja tietyissä tilanteissa jopa mahdotonta. Järjestelmäkohtaisen integraatiomallin vaihtoehdossa (A) kaikki muutokset joudutaan tekemään järjestelmäkohtaisesti, joka tekee muutosten hallinnasta hitaampaa ja kustannuksiltaan kalliimpaa. Tietyissä muutostenhallinnan tilanteissa (organisaatiomuutokset, järjestelmämuutokset) saattaa järjestelmien välisiin integraatioihin perustuvan toiminnan turvaaminen olla haasteellista tai mahdotonta. Seuraavassa on kuvattu kunkin päävaihtoehdon vahvuuksia, heikkouksia, mahdollisuuksia ja uhkia tehdyn SWOT-analyysin pohjalta. Liitteessä 3, Liittymismallien SWOT-analyysi sama on esitetty tekstimuodossa ja sitä paikalliset toimijat voivat tarvittaessa muokata paikallisten tarpeiden mukaisesti.

49 Liittymismalli A - suora järjestelmäliityntä V A H V U U D E T Riippuvainen vain liittyjästä ja Reseptikeskuksesta Ei solmuja hidastamassa verkon nopeutta Kukin kunta voi mitoittaa yhteytensä Reseptikeskukseen tarpeidensa mukaisesti Yksinkertainen ratkaisu, hallinnollisesti helpompi jos tämän osaa toteuttaa kokonaan itse Toiminnalliset käyttöönottokustannukset ovat muita malleja pienemmät Mahdollisesti nopeampi toteuttaa kuin monet muut mallit Tämäkin malli mahdollistaa tietoliikennetason yhdistämisen verkkoliikenteen yhdistämisen M A H D O L L I S U U D E T H E I K K O U D E T Suoria liittyjiä Reseptikeskukseen on suuri määrä. Ylläpito ja muutostenhallinta työläs ja riskialtis, kun liittyminen ja liittymien ylläpito on kuntakohtaista ja vieläpä järjestelmäkohtaista Ei synergiaetuja, koska on useita eri tapoja liittyä Kokonaiskustannukset, joka kunnan tehtävä kaikki liittymiseen vaadittavat tehtävät. Valvonta on hankalaa ja kallista. Maksimoi kokonaistyömäärän Ei tue KanTan taustalla olevien lakien tai uuden terveydenhuoltolain henkeä toimijoiden välisestä yhteistyöstä Kaikki järjestelmät vaativat Reseptikeskusrajapintatoteutuksen Syntyy useita eri toimintatapoja Miten end- to- end valvonta voidaan toteuttaa jokaiseen solmuun? Sekava kokonaisuus Järjestelmien ja toimijoiden entistä suurempi eriytyminen Resurssien riittävyys Liittymismuutosten tekeminen työlästä Auditointi voi tuoda yllätyksiä ja haasteita Joudutaan mahdollisesti earkistovaiheessa siirtymään toiseen liittymismalliin U H A T

50 Liittymismalli B kuntatoimijan keskitetty ratkaisu V A H V U U D E T Toimija vastaa liityntäpalvelusta ja liittyjistä Kohtalaisen yksinkertainen verkkotopologia, kun kustakin kunnasta on vain yksi rajapinta Reseptikeskukseen. Kunnan ja Reseptikeskuksen välisen yhteyden mitoittaminen helpohkoa, kun kunta tuntee järjestelmiensä tapahtumamäärät ja kehitystrendin. Ongelmatilanteissa osapuolina ovat vain kunta ja Reseptikeskus. Kunnassa yksi rajapinta ulos kaikkiin palveluihin Hallittavuus ehkä lisääntyy Sertifiointi yhdestä pisteestä kunnalla Varayhteyksiä voitaisiin rakentaa ristiin Tukee järjestelmäriippumattomien vaihtoehtojen kehittämistä, mikä mahdollistaa avointen teknologioiden käyttöönoton Oikein toteutettuna järjestelmien yhteisestä rajapinnasta tulee vahvuus H E I K K O U D E T Suoria liittyjiä Reseptikeskukseen on suuri määrä Ylläpito on työlästä ja riskialtista, kun liittyminen ja liittymien ylläpito on kuntakohtaista. Joka kunnan on tehtävä kaikki liittymiseen vaadittavat toimenpiteet ja ylläpito itse Varayhteyden järjestäminen on kallista eli palvelun saatavuuden takaaminen hankalaa Ei tue KanTan taustalla olevien lakien tai uuden terveydenhuoltolain henkeä toimijoiden välisestä yhteistyöstä Ei vastaa nykyistä terveydenhuollon tuottamistapaa Yhteinen rajapinta on väärin toteutettuna rajoitin Järjestelmien liityntätoteutuksessa on huomioitava vaihtoehtoja M A H D O L L I S U U D E T U H A T

51 Liittymismalli C alueellinen liityntäpalvelu V A H V U U D E T Suoria liittyjiä Reseptikeskukseen on pienehkö määrä. Muita ratkaisuja korkeampi palvelutaso: päästä päähän mittaus, integraatiopalveluiden keskittäminen Käyttökustannukset ovat muita Liittymismalleja pienemmät (24/7 palvelu, suorituskykyinen alusta) Valvonta ja hallinta voidaan toteuttaa paremmin Varayhteyden järjestäminen kohtuuhintaan on mahdollista eli palvelun saatavuuden takaaminen helpohkoa KanTan taustalla olevien lakien tai uuden terveydenhuoltolain hengen mukainen ratkaisu edistäessään toimijoiden välistä yhteistyötä H E I K K O U D E T Vaatii palvelunhallintamallin Tarvitaan prosessien ja hallinnan prosessien osaamista Käyttöönottokustannukset (vikasietoisuus, 24/7 tuki, skaalautuvuus), heti alusta alkaen pitää olla useita liittyjiä mukana Ylläpito on työlästä ja riskialtista, kun liittyminen alueelliseen liityntäpalveluun ja liittymien ylläpito on kuntakohtaista ja vieläpä järjestelmäkohtaista Järjestelmätoimittajat eivät toiminnallaan helpota eri järjestelmien yhteisten liityntäpalveluiden toteuttamista, jolloin ratkaisut saattavat muodostua kalliiksi Integraatiopalveluiden keskittäminen on mahdollista alvelun osaavia toimijoita on tarjolla Eri hinnoittelumallit ovat mahdollisia Liittyjän on helppo liittyä, kun ei tarvita omaa osaamista tai ratkaisua Integraatiopalveluosaaminen ja palvelun tuotteistaminen voidaan kohdistaa riittävän suuriin yksiköihin Tukee järjestelmäriippumattomien vaihtoehtojen kehittämistä, mikä mahdollistaa avointen teknologioiden käyttöönoton Mahdollistaa alueellisten tietokantojen ja arkistojen muodostamisen ja käytön (esim. keskeneräiset hoitotiedot käytettävissä yli organisaatiorajojen) M A H D O L L I S U U D E T Skaalautuvuus eli alueellisen liityntäpalvelun ja Reseptikeskuksen välisen yhteyden mitoitus haasteellista Tulee ottaa huomioon single point of failure, koska liityntäpalvelun takana on useita organisaatioita Häiriötiedottaminen on hankalaa Selkeän kustannuksenjakomallin laatiminen on haasteellista Mahdolliset häiriöt liityntäpalvelussa voivat olla laajoja Voi aiheuttaa viiveitä sanomaliikenteessä Ongelmien selvittelyssä on monta osapuolta, mikä voi hankaloittaa ja viivästyttää ongelmien selvitystä U H A T

52 Liittymismalli D järjestelmäkohtaisesti keskitetty integraatio V A H V U U D E T Liitynnät ovat järjestelmäkohtaisia, joten organisaation ei välttämättä tarvitse ratkaista kaikkea itse Suoria liittyjiä Reseptikeskukseen on pienehkö määrä. Jossain määrin ylläpitomalli on yksinkertaisempi, mutta ei välttämättä halvempi Järjestelmän liityntätoteutuksessa ei tarvitse huomioida vaihtoehtoja Kunta ei tarvitse sertifiointia Reseptikeskukseen Ei vaadi kunnalta syvällistä liityntätekniikan tuntemusta Mahdollistaa järjestelmäkohtaiset kansalliset poolit Reseptikeskuksen liityntöjen määrä voi vähetä, jos järjestelmiä saadaan vähenemään KuntaIT:n tai Sitran hankkeiden kautta Voi olla tietyntyyppisille toimijoille toimiva ratkaisu M A H D O L L I S U U D E T H E I K K O U D E T Uusi järjestelmä vaatii uuden yhteyden rakentamisen järjestelmästä Reseptikeskukseen ja Reseptikeskuksen liityntöjen määrä kasvaa Varayhteyksien järjestäminen on hankalahkoa Sitoo koko palvelun tiettyyn toimittajaan Vastuutuiden määrittely eli kuka vastaa mistäkin on työlästä ja ongelmien selvittelyssä on monta osapuolta Voi aiheuttaa erilaisten hinnoittelumallien käytön Hallinta- ja tukimalleja voi olla kirjava joukko Ei tue KanTan taustalla olevien lakien tai uuden terveydenhuoltolain henkeä toimijoiden välisestä yhteistyöstä Koska järjestelmätoimittajat ovat mukana, voivat paketoida liityntöjä ja siten harrastaa kytkykauppoja. Järjestelmätoimittajat voivat kaivautua entistä syvemmälle omiin poteroihinsa Järjestelmäkohtaisilla toimijoilla ei ole antaa riittävästi tukea eikä tarjota hallintamalleja Voi aiheuttaa viiveitä sanomaliikenteessä Ongelmien selvittelyssä on monta osapuolta, mikä voi hankaloittaa ja viivästyttää ongelmien selvitystä Uudistamispyyntöjä saattaa olla haastava kohdistaa tiettyyn oikeaan paikkaan U H A T

53 Liittymismalli E tuplaintegraatio V A H V U U D E T Hyödynnetään sellaisenaan potilastietojärjestelmään rakennettua viestintäratkaisua Kohtalaisen yksinkertainen verkkotopologia, kun kustakin kunnasta on vain yksi rajapinta Reseptikeskukseen. Kunnan ja Reseptikeskuksen välisen yhteyden mitoittaminen helpohkoa, kun kunta tuntee järjestelmiensä tapahtumamäärät ja kehitystrendin Ongelmatilanteissa osapuolina ovat vain kunta ja Reseptikeskus Mahdollistaa alueelliseen ratkaisuun verrattuna yksinkertaisemman kustannusten jaon, kun vain yksi kuntatoimija on ratkaisussa mukana Tietoliikenne solmut voivat olla operaattoreilla, mikä mahdollistaa kunnon yhteydet Tukee järjestelmäriippumattomien vaihtoehtojen kehittämistä ja siten avointen teknologioiden käyttöönoton H E I K K O U D E T Toteuttaminen vaatii monia toimijoita ja ratkaisuja Suoria liittyjiä Reseptikeskukseen on suuri määrä Ylläpito on työlästä ja riskialtista, kun liittyminen ja liittymien ylläpito on kuntakohtaista Varayhteyden järjestäminen on kallista eli palvelun saatavuuden takaaminen hankalaa Tarvitaan monta solmua, mikä monimutkaistaa sanomaliikennettä Ei tue KanTan taustalla olevien lakien tai uuden terveydenhuoltolain henkeä toimijoiden välisestä yhteistyöstä Viiveet sanoman käsittelystä kasvavat Maksetaan tuplaintegraatiosta M A H D O L L I S U U D E T U H A T Yhteenveto ja suositukset Vaikka tässä työssä on rajauduttu käsittelemään ainoastaan ereseptin käyttöönottoon liittyvää integraatioarkkitehtuuriratkaisua, tulisi ratkaisun valinnassa huomioda nykyiset alueelliset- ja paikalliset integraatiotarpeet sekä arkkitehtuuriin, tietojärjestelmäympäristöihin ja organisaatioihin lähivuosina kohdistuvat muutokset ja kehittämistarpeet, joita on tuotu esille tämän dokumentin aiemmissa luvuissa. Kuvatuilla lainsäädännön, organisaatio- ja palvelurakenteiden aikaansaamilla kehittämistarpeilla tulee olemaan vaikutusta myös terveydenhuollon alueellisen- ja paikallisen tason arkkitehtuuriratkaisuihin ja tietojärjestelmiin. Vaikkei kaikkien muutosten yksityiskohtaiset vaikutukset ole tiedossa, arvioidaan että muutoksilla tulee olemaan kokonaisuudessaan merkittäviä vaikutuksia sosiaali- ja terveydenhuollon sähköisen tiedonhallinnan ja tietoteknisten järjestelmien sekä ympäristöjen kehitykseen. Tämä vuoksi jo ereseptin integraatioratkaisua valitessa tulee kiinnittää huomioita sellaisiin ratkaisumalleihin, jotka luovat perustaa kehitykselle ja osaltaan mahdollistavat tietojärjestelmiin ja organisaatioihin kohdistuvien muutosten läpiviennin. Tämä ennakointi tulee huomioida sekä integraatio-arkkitehtuuriin liittyvissä teknisissä ratkaisuissa sekä hallinnollisesti (liittyjien väliset ja palveluiden hankintaan liittyvät sopimukset).

54 54 Työryhmä suosittelee kaikkien julkisen terveydenhuollon liittyjäorganisaatioiden osalta seuraavaa: KanTa-liittymisessä tarvittavat palvelut ja niiden toteuttamis- ja tuottamistapa arvioidaan ja suunnitellaan yhteistyössä alueen julkisen terveyden-huollon organisaatioiden kesken. Tällä tavoin voidaan parhaiten turvata suunnitteluun tarvittava resursointi, varmistaa eri osapuolten näkemys suunnittelun tueksi, sekä saavuttaa mahdollisimman järjestelmä/toimittajariippumaton puolueeton lopputulos. Alueellisessa ja paikallisessa liittymispalveluiden suunnittelussa huomioidaan olemassa olevien ratkaisujen hyödyntämismahdollisuudet ja myös muut alueellisten ja paikalliset sähköisten palveluiden tarpeet. Varsinaiset palvelut voidaan toteuttaa keskitetysti tai hallitusti hajautettuna. Lainsäädännön, KanTa-arkkitehtuurin sekä organisaatio- ja palvelurakennemuutosten vaikutuksia pyritään ennakoimaan ja näistä aiheutuvien muutosten läpivientiä tuetaan alueellisesti yhtenäisillä ja yhteentoimivilla tiedonsiirto- ja integraatioratkaisuilla. KanTa-palveluiden käyttöönoton edellyttämät tietoliikenneyhteydet ja tietoliikenteeseen palvelut (esim. valvonta- ja hallinta, tietoliikenteen tietoturvapalvelut) toteutetaan vähintään sairaanhoitopiirin alueen laajuisina yhteistoteutuksina ja hyödyntäen suljettuja asiakasverkkoja (ei Internet). Tällä tavoin voidaan valmistaa tiedonsiirtoyhteyksien sekä niihin liittyvien ylläpitopalveluiden kustannustehokas toteutus sekä varmistaa niiden skaalausmahdollisuudet KanTa-palveluiden myöhempien vaiheiden tarpeisiin. KanTa-tiedonsiirtoyhteydet tulisi toteuttaa päästä-päähän kahdennettuna vähintään niiden liittyjien osalta, joille KanTa-palvelut ovat toimintakriittisiä. Mikäli tiedonsiirtoyhteydet toteutetaan kahdentamattomana, tulisi käyttöönoton yhteydessä laatia suunnitelma ja varautua teknisesti ja toimittajien kanssa laadittavissa sopimuksissa myöhemmässä vaiheessa tapahtuvalle kahdentamiselle. Keskitetyn Integraatioratkaisun hyödyntäminen ereseptin käyttöönoton yhteydessä ei ole pakollista. Seuraavaan taulukkoon on koottu yksittäisen Kan- Ta-liittyjän suunnittelun ja vaihtoehtojen arvioinnin tueksi taulukko, jossa erilaisia liittymämalleja arvioidaan erilaisissa lähtö- ja tavoitetiloissa. Alla oleva taulukko on suuntaa antava. + = kyseinen skenaario sopii kyseiseen tilanteeseen tai edistää kyseistä tavoitetta 0 = kyseinen skenaario on neutraali kyseisen tilanteen tai tavoitteen suhteen - = kyseinen skenaario ei sovi erityisen hyvin kyseiseen tilanteeseen tai tavoitteeseen

55 55 Kunkin toimijan tulee itsenäisesti tarkemmin ja laajemmin arvioida oma lähtö- ja tavoitetilansa ja muodostaa tätä kautta täsmällisempi kuva itselleen sopivasta liittymismallista. Skenaariot Näkökulma, lähtötilanne tai tavoite A B C D E Organisaatiolla on vain yksi potilastietojärjestelmä Organisaatiolla on useita potilastietojärjestelmiä ne ovat samaa merkkiä Organisaatiolla on useita potilastietojärjestelmiä ne ovat useaa eri merkkiä Organisaation strategiaan kuuluu hyödyntää omaa integraatiopalvelua terveydenhuollon kansallisiin ratkai- suihin tai laajemminkin Organisaation strategiaan kuuluu hyödyntää usean organisaation yhteistä integraatiopalvelua terveydenhuollon kansallisiin ratkaisuihin tai laajemminkin Organisaatio pystyy tuottamaan/järjestämään palvelutasovaatimusten mukaisesti tarvittavat hallinta- ja val- vontapalvelut. Organisaatio ei pysty tuottamaan/järjestämään palvelutasovaatimusten mukaisesti tarvittavia hallinta- ja val- vontapalveluita Organisaatio ei halua eresepti käyttöönottovaiheessa investoida uusiin integraatioratkaisuihin, joiden hyödynnettävyys myöhempien KanTa-palveluiden käyttöönoton vaiheissa on epäselvä Organisaatiolla voi olla tarve esim. organisaatiomuutosten, kuntaliitosten, tietojärjestelmiin liittyvien muutosten (esim. tietojärjestelmien yhdistäminen, vaihto) tms. takia ohjata ereseptin käyttöön liittyvää viestiliikennettä joustavasti eri toimintayksiköihin ja tietojärjestelmiin Organisaatiolla ei toistaiseksi ole näköpiirissä tarvetta ohjata ereseptin käyttöön liittyvää viestiliikennettä joustavasti eri toimintayksiköihin ja tietojärjestelmiin Organisaation alueella on potentiaalisia organisaatioiden yhteisen integraatiopalvelun tuottaja/tuottajia Organisaatiolla ei ole toistaiseksi näköpiirissä potentiaalisia organisaatioiden yhteisen integraatiopalvelun tuottajia Organisaatiolla on tavoite toteuttaa KanTa-käytössä tarvittavat tietoliikennepalvelut usean organisaation yhteistoteutuksena

56 Liityntäpalvelun sanomankulkukaaviot ereseptin vaatimusmäärittelyssä on kuvattu keskeiset sanomankulkukaaviot potilastietojärjestelmän, Reseptikeskuksen ja apteekkitietojärjestelmän välillä, mutta vaatimusmäärittelyssä ei ole kuvattu sanomakulkuja liityntäpalvelun näkökulmasta. Seuraavaan on kuvattu kaikkein keskeisimmät integraatiopalvelun kautta toteutettavat sanomankulut terveydenhuollon organisaation ja liityntäpalvelun näkökulmasta. Rajaukset Tämän dokumentin sanomakulkujen kuvauksissa on tehty seuraavat rajaukset: Sanomakulut on kuvattu liityntäpalvelun näkökulmasta, kuvaustapa ei sisällä teknisiä yksityiskohtia Sanomakulut on kuvattu vain yleisellä ylätasolla, varsinaiset yksityiskohtaiset sanomakulut on kuvattu (ilman liityntäpalvelua) Open CDAdokumentissa Lääkemääräyksen Medical Records sanomat v Apteekkien osuus on jätetty pois, liityntäpalvelu liittyy vain terveydenhuollon organisaatioon ja Reseptikeskukseen Sanomakulkukaavioihin on kuvattu vain keskeisimmät prosessit, ei kaikkia Alla kuvattujen sanomakulkujen tarkoituksena on luoda kuva liityntäpalvelun roolista eresepti-sanomanvälityksessä yleisellä tasolla. Varsinaisessa toteutuksessa tulee käydä läpi kaikki sanomakulkuvariaatiot. Alla on kuvattu seuraavat sanomakulut (suluissa rooli, joka käynnistää sanomakulun): Virheettömät, onnistuneet sanomakulut o Lääkemääräyksen kirjoittaminen (Lääkäri) o Lääkemääräyksen katselu (Lääkäri) o Lääkemääräyksen korjaaminen/mitätöinti (Lääkäri) o Lääkemääräyksen uusimispyyntö (Apteekki) o Lääkemääräyksen uusimispyyntö (Apteekki) yyntö hylätään Virheitä sisältävät sanomakulut o Lääkemääräyksen kirjoittaminen (Lääkäri) virhe teknisessä siirrossa, Reseptikeskus o Lääkemääräyksen kirjoittaminen (Lääkäri) virhe sanoman sisällössä, Reseptikeskus o Lääkemääräyksen kirjoittaminen (Lääkäri) virhe teknisessä siirrossa, integraatiopalvelu o Lääkemääräyksen kirjoittaminen (Lääkäri) viive palvelussa, Reseptikeskus

57 57 o Lääkemääräyksen kirjoittaminen (Lääkäri) viive palvelussa, integraatiopalvelu o Virheellisiä tapauksia on käsitelty vain lääkemääräyksen kirjoittamisen tapauksessa. Muissa ereseptin prosesseissa kyseisiä virhetapauksia voidaan hyödyntää soveltaen Virheettömät, onnistuneen sanomanvälityksen sanomakulut Lääkemääräyksen kirjoittaminen (Lääkäri) Yksinkertaistettu kuvaus liityntäpalvelun roolista sähköisen lääkemääräyksen kirjoittamisessa. Lääkäri kirjoittaa potilaalle lääkemääräyksen potilastietojärjestelmässä. otilastietojärjestelmän sisäinen tai siihen liitetty liityntäratkaisu (ei kuvassa) muodostaa lääkemääräyksestä ereseptisanoman ja muodostaa yhteyden liityntäpalveluun (mikäli ulkoverkossa, salattu yhteys). Liityntäpalvelu toimii liityntäpisteenä ja luo synkronisen tunnelin tätä kautta aina Reseptikeskukseen saakka. Liityntäpalvelu lähettää lääkemääräyksen Reseptikeskukseen. Reseptikeskus vastaa sovellustason kuittauksella takaisin. Liityntäpalvelu välittää tämän potilastietojärjestelmälle. Synkroninen yhteys katkaistaan. Lääkemääräyksen katselu (Lääkäri) Lääkemääräyksen hakemisen periaatteet ovat vastaavat kuin lääkemääräyksen kirjoittamisen kohdalla.

58 58 Lääkäri hakee potilastietojärjestelmän kautta lääkemääräyksen kuvailutiedot. Tästä lähtee pyyntö liityntäpalvelulle, joka välittää sen Reseptikeskukseen. Reseptikeskus vastaa palauttamalla kyseiset kuvailutiedot. Liityntäpalvelu välittää nämä potilastietojärjestelmään. Dokumenttien hakeminen toteutetaan vastaavasti. Tässä tapauksessa pyynnön vastauksena saadaan joko kuvailutiedot tai palautettavat dokumentit. Erillistä muuta sovellustason kuittausta ei tarvita, koska liikenne on synkronista. Lääkemääräyksen korjaaminen/mitätöinti (Lääkäri) Lääkemääräyksen korjaaminen tai mitätöinti toteutetaan seuraavasti.

59 59 Lääkäri korjaa tai mitätöi olemassa olevan sähköisen lääkemääräyksen. Näihin käytetään omia sanomia, mutta periaate on molemmissa sama. Korjaus- tai mitätöintiviesti lähetetään potilastietojärjestelmästä liityntäpalveluun, joka välittää sen Reseptikeskukseen. Tämä palauttaa sovellustason kuittauksen liityntäpalvelulle, joka välittää sen puolestaan potilastietojärjestelmälle. On hyvä huomata, että lääkemääräyksen korjaamisessa Reseptikeskukseen siirtyy uusi korvaava lääkemääräys (ns. Document Replacement sanoma), kun taas mitätöinnissä siirtyy vain mitätöintiviesti. Lääkemääräyksen uusimispyyntö (Apteekki) Lääkemääräyksen uusimisessa sanomakulkuja on hiukan edellisiä enemmän.

60 60 Tässä oletetaan, että reseptin uusimispyyntö lähtee apteekista tai erityistapauksessa toiselta terveydenhuollon toimijalta. Liityntäpalvelun näkökulmasta viestiketjun lähteenä on kuitenkin Reseptikeskus. Uusimispyyntö tulee liityntäpalveluun, joka välittää 11 sen uusijan potilastietojärjestelmään. otilastietojärjestelmä vastaa sovellustason kuittauksella, jonka liityntäpalvelu välittää Reseptikeskukselle. Lääkäri käsittelee uusimispyynnön ja tekee päätöksen reseptin uusimisesta. Tästä tapauksesta lähtee potilastietojärjestelmästä kaksi viestiä sekä uusittu lääkemääräys että viesti uusimispyynnön käsittelystä. Liityntäpalvelu välittää nämä molemmat tiedot eteenpäin Reseptikeskukseen, joka vastaa kahdella erillisellä sovellustason kuittauksella. Lääkemääräyksen uusimispyyntö (Apteekki) yyntö hylätään Tämä on edellisen sanomakulun erityistapaus. 11 Mikäli asiakasorganisaatio ja liityntäpalvelu ovat sopineet, että liityntäpalvelu huolehtii uusimispyyntöjen poikkeusreitittämisestä esimerkiksi määräaikaisesti eri kohteeseen/yksikköön (esim. terveyskeskuksen remontti tms.), liityntäpalvelu voi tässä vaiheessa tehdä sanomamuunnoksen uusijaorganisaation OID-tunnukseen.

61 61 Sanomaliikenne on muuten vastaava kuin aikaisemmassa uusimispyynnössä, mutta lääkärin hylätessä reseptin uusimisen, potilastietojärjestelmästä lähtee käsittelyviestinä hylätty-viesti, joka välitetään Reseptikeskukseen. Uusittua reseptiä ei siis tässä mallissa lähde lainkaan. Reseptikeskus vastaa normaalisti sovellustason kuittauksella Virheitä sisältävien sanomanvälitysten sanomakulut Seuraavaan on koottu muutama tyypillinen virhetilanne erityisesti liityntäpalvelun näkökulmasta. Kaikki esimerkkitapaukset on laadittu koskemaan lääkemääräyksen kirjoittamista, mutta niitä voidaan soveltaa myös muihin tapauksiin. Lääkemääräyksen kirjoittaminen (Lääkäri) virhe teknisessä siirrossa, Reseptikeskus Seuraavassa oletetaan, että synkronisessa siirrossa tapahtuu tekninen virhe.

62 62 otilastietojärjestelmä lähettää lääkemääräyksen liityntäpalveluun, joka välittää sen edelleen Reseptikeskukseen. Jossakin viestinvälityksen vaiheessa tapahtuu tekninen virhe ja Reseptikeskus kuittaa tämän teknisellä virhekuittauksella liityntäpalveluun. Liityntäpalvelu välittää tämän teknisen kuittauksen potilastietojärjestelmään. otilastietojärjestelmä lähettää lääkemääräyksen uudestaan liityntäpalvelulle, joka välittää sen Reseptikeskukseen. Tällä kertaa siirto onnistuu ja Reseptikeskus vastaa liityntäpalvelun kautta onnistuneesta siirrosta potilastietojärjestelmälle sovellustason kuittauksella. Mikäli Kelan viestintämääritykset sallivat, tällainen tekninen virhe voidaan yrittää ratkaista myös vaihtoehtoisesti siten, että liityntäpalvelu tekee uudelleenlähetyksen potilastietojärjestelmän puolesta. Tämä edellyttää, että liityntäpalvelu säilyttää lähetettävää viestiä ns. viesticachessa kunnes se saa siihen vastaanottajalta sovelluskuittauksen. eriaate on, että sanoma poistetaan välimuistista, kun sovelluskuittaus saapuu.

63 63 Tässä vaihtoehtoisessa tapauksessa uudelleenlähetysvastuu on vain liityntäpalvelulla, jolloin esim. mahdolliset viiveet potilastietojärjestelmässä eivät viivästytä uudelleenlähetystä. Lääkemääräyksen kirjoittaminen (Lääkäri) virhe sanoman sisällössä, Reseptikeskus Mikäli sanomasisällössä on virhettä (esim. virheellinen OID-koodi tms.), liityntäpalvelu ei voi tehdä uudelleenlähetystä. Tässä tapauksessa Reseptikeskuksessa tulee sovellustason virhekuittaus virheellisestä sanomasisällöstä liityntäpalvelulle, joka lähettää sen eteenpäin potilastietojärjestelmälle. Siihen, miten sisällöltään virheellinen lähetys korjataan potilastietojärjestelmässä, ei oteta tässä kantaa. Yleisesti suositellaan käytettävän automaattitoimintoja, joissa manuaalisen tiedonsyötön aiheuttamat virheet minimoituvat, eikä tällaista virhetapausta synny. Mikäli joko potilastietojärjestelmä automaattisesti tai todennäköisemmin lääkäri manuaalisesti korjaa lääkemääräystä (tässä tapauksessa siis tämä ei ole lainkaan mennyt perille), potilastietojärjestelmä lähettää korjatun lääkemääräyksen (= uuden lääkemääräyksen lähettäminen) liityntäpalvelun kautta Reseptikeskukselle, josta saadaan taas liityntäpalvelun läpi potilastietojärjestelmälle sovellustason kuittaus onnistuneesta lääkemääräyksen vastaanotosta. Lääkemääräyksen kirjoittaminen (Lääkäri) virhe teknisessä siirrossa, integraatiopalvelu Seuraavassa oletetaan, että tekninen virhe tapahtuu jo potilastietojärjestelmän ja integraatiopalvelun välillä.

64 64 Tässä toimitaan kuten edelläkin kuvatussa teknisen virheen kuvauksessa, tällä kertaa virhe ei kuitenkaan näy lainkaan Reseptikeskukselle. Tekninen vikaviesti lähetetään vain liityntäpalvelusta potilastietojärjestelmään. Tässä oletetaan, että tekninen virhe poistuu ja liityntäpalvelu pystyy välittämään uudelleenlähetetyn viestin normaalisti Reseptikeskukselle. Reseptikeskus lähettää normaalisti sovellustason kuittauksen liityntäpalvelulle, joka välittää sen potilastietojärjestelmälle. Lääkemääräyksen kirjoittaminen (Lääkäri) viive palvelussa, Reseptikeskus Seuraavassa tarkastellaan tapausta, jossa Reseptikeskuksen päässä on viivettä, eikä reseptisanoma mene ajoissa perille tai Reseptikeskus ei saa lähetettyä sovelluskuittausta ajoissa.

65 65 otilastietojärjestelmä lähettää lääkemääräyksen liityntäpalveluun, joka välittää sen Reseptikeskukseen. Reseptikeskuksessa on jostakin syystä viive, eikä sovellustason kuittausta saada määräajassa potilastietojärjestelmälle asti. Määritysten mukaisesti tästä tulee viesti potilastietojärjestelmään ja lääkäri siirtyy kirjoittamaan lääkemääräyksen perinteisesti paperilla. otilastietojärjestelmän tulee tällöin lähettää lääkemääräyksen mitätöinti, jotta vältetään tilanne, jossa potilaalla on sekä paperi- että sähköinen lääkemääräys. otilastietojärjestelmän tulee jatkaa toistuvasti lääkemääräyksen mitätöintisanoman lähettämistä (ja liityntäpalvelun sen välittämistä) Reseptikeskukseen, kunnes Reseptikeskus vastaa ja lähettää sovellustason kuittauksen lääkemääräyksen mitätöinnistä. Lääkemääräyksen kirjoittaminen (Lääkäri) viive palvelussa, integraatiopalvelu Seuraavassa käsitellään tapausta, jossa viive aiheutuu liityntäpalvelussa.

66 66 Lääkäri kirjoittaa sähköisen lääkemääräyksen ja potilastietojärjestelmä lähettää tämän liityntäpalveluun. Tässä tapauksessa liityntäpalvelussa on viive, eikä se saa välitettyä sanomaa eteenpäin. Tällöin luonnollisesti sillä ei ole myöskään välittää mitään Reseptikeskuksen kuittausta potilastietojärjestelmään. Kuten edellä, lääkäri siirtyy kirjoittamaan paperireseptin ja potilastietojärjestelmä lähettää aikaisemman epäonnistuneen sähköisen lääkemääräyksen mitätöintisanoman liityntäpalvelulle. Liityntäpalvelu välittää lääkemääräyksen mitätöinnin Reseptikeskukseen, joka vastaa sovelluskuittauksella, jonka liityntäpalvelu välittää takaisin potilastietojärjestelmälle. 6. Liityntäpalvelun keskeiset prosessit Liityntäpalvelu on nimensä perusteella asiakkaan näkökulmasta kokonaispalvelu, ei pelkästään tekninen ratkaisu. Kokonaistoimivuus edellyttää teknisen toimivuuden lisäksi vähintään seuraavien prosessien ja toimintojen selkeää määrittelyä: Kontrolliprosessit o Muutoksenhallinta o Konfiguraationhallinta Tuki- ja ratkaisuprosessit asiakkaan yhteyshenkilöille o Asiantuntijatuki o Ongelmanhallinta o Vikatilanneviestintä Hallinnolliset prosessit o alveluun liittyminen o alveluyhteistyön hallinnolliset muutokset o alvelusta irtautuminen

67 67 Edellisten lisäksi liityntäpalvelun tuottajan tulee huolehtia muista ICTpalvelunhallinnan keskeisistä prosesseista kuten jatkuvuuden- ja käytettävyydenhallinta, tietoturvallisuudenhallinta, asiakkuudenhallinta, version/julkaisunhallinta jne. ITIL-malli ja ISO/IEC standardi antavat hyvät perusteet näiden prosessien määrittämiseen. Kaikkein olennaisimmat palvelu- ja laatuprosessit on kuvattu ylätasolla Liitteessä 4, Liityntäpalvelun tuottajan keskeiset prosessit. Näitä voidaan hyödyntää lähtökohtana palveluntuottajan määrittäessä prosessejaan. 7. Ratkaisun mitoitusperiaatteet Tässä kuvatut ratkaisun mitoitusperiaatteet pohjautuvat dokumenttiin Kantaliittymisohjeistuksen tarkennusprojekti, Dokumentaatio KanTa-liittymismallit ohjeistukseen. eresepti-palveluun sisältyvä liikenne on synkronista ja sanomapohjaista. Sanomat ovat kooltaan n kt (kilotavua). Mikäli käyttäjän toimenpide vaatii välitöntä palautetta reseptikeskukselta, saa potilaskertomusjärjestelmän tai apteekin tietojärjestelmän käyttäjän kokema viive kommunikoitaessa reseptikeskuksen kanssa olla 90 %:ssa tapauksia 3 sekuntia ja lopuissa 10 %:ssa tapauksia enintään 10 sekuntia. Tämä asetettu kokonaislatenssivaatimus (maksimiaika) sisältää myös sanomaliikenteen ja palvelinten prosessointiajan. KanTayhteyksien osalta suositellaan käytettävän em. dokumentin luvun kolme mukaisia laatuluokituksia Kansalliset volyymit Kansallisiin volyymeihin perustuvien arviolaskelmien mukaan, n. 70% eresepti-palvelun lääkemääräyksistä kirjoitetaan arkipäivisin klo Reseptien kirjoituksesta generoituva ruuhkahuippu valtakunnallisesti kaikki liittyjät huomioiden on n. 5 tapahtumaa/s. Reseptien lukutapahtumista generoituva liikennemäärä on arvioituna ruuhkahuipussa vastaavasti n. 5 tapahtumaa/s Liityntäpisteen mitoitusperiaate Ensivaiheessa on suositeltavaa määritellä hankittava liittymäkapasiteetti eresepti-palvelun tarpeiden mukaan, koska liittymäkapasiteetin nosto ohjelmallisesti on suoraviivaista suurikapasiteettiset kuituyhteydet ovat kustannuksiltaan moninkertaisia kupariyhteyksiin verrattuna siirtoteknologiat ja päätelaitteet voivat useamman vuoden sopimuskauden aikana muuttua, jolloin tiettyyn teknologiaan sitoutuminen hyvin pitkälle ajanjaksolle ei ole välttämättä järkevää teknologian kehittyessä liittymäkohtainen siirtokapasiteetin hinta tulee ajan myötä laskemaan. Edellä oleviin oletuksiin ja laskelmiin perustuen liityntäpisteen tulee koosta riippuen varautua ensivaiheen eresepti-liikenteessä seuraaviin volyymeihin:

68 68 suuret yhteistoteutukset 5-7 sanomaa /s keskisuuret 3-5 sanomaa /s. Yksinkertainen periaate liityntäpalvelun mitoittamiselle on: Liityntäpisteen tapahtumavolyymi = niiden kansalaisten lukumäärä, jotka kuuluvat liityntäpalvelun asiakkaiden toiminta-alueeseen / * kansallinen tapahtumavolyymi. 8. Valvonta- ja hallinta-arkkitehtuurin perusteet Valvonnan ja hallinnan yleiset periaatteet Suorituskykyarvoja ja vasteaikoja sähköisen lääkemääräyksen sanomaliikenteelle ei ole kansallisella tasolla määritelty. Kansallisissa ereseptin vaatimusmäärittelyissä on määritetty raja-arvot reseptin kirjoittamisen ja siitä saatavan kuittauksen väliselle päästä-päähän vasteajalle. ereseptin käyttöön liittyvän hallinnan ja valvonnan toteutus ei ole aivan yksinkertaista. Keskeisin haaste on, että palveluketjun eri osilla voi olla hyvin monia eri vastuutahoja. Jo pelkästään potilastietojärjestelmä koostuu erilaisista komponenteista, joilla on eri vastuutahoja (ks. alla): Taho 1 Taho 2 Taho 3 Taho 4 Taho 2 Tietokanta Ohjelmisto Verkko 99,5% Tietokantapalvelin Sovelluspalvelin Työasema 98% Yllä olevassa kuvassa oletetaan että palvelinten käyttöpalveluiden ja työasemapalveluiden toimittaja on sama. Tietokannan ja sovelluksen palvelevuudesta ja suorituskyvystä vastaavat joka tapauksessa tietokantavalmistaja ja sovellustoimittaja. alvelinten, tietoliikenteen ja työaseman suorituskyky ja käytettävyys voi olla eri tahojen hallinnoima, mutta näiden vastuujaon määrittämisessä liittyjän tietohallinnolla on enemmän liikkumavaraa. Kun tähän yksittäiseen järjestelmään liitetään vielä väistämätön potilastietojärjestelmään liitettävä eresepti-sanomanvälityskerros ja mahdolliset ulkoiset liityntäpalvelut sekä tietenkin Reseptikeskus, on hyvin vaikea löytää yksittäistä tahoa, joka pystyisi vastaamaan lääkärin kokemasta suorituskyvystä ja käytettävyydestä. Valvonta ja hallinta tuleekin pystyä määrittelemään loogisina ratkaisukokonaisuuksina ketjun eri osiin. ereseptin sanomaliikenteen valvonta- ja hallinta-arkkitehtuurin keskeiset periaatteet ovat: Sanomaliikennettä tulee valvoa viestiketjun kaikissa keskeisissä osissa Komponenttitasolla tulee hyödyntää JHS-174 palvelutasomäärityksiä ja laatumääreiden mittausmäärityksiä. alvelutasojen tulee perustua palvelutasosopimuksiin