Kuntien Tiera Oy Tammasaarenkatu 3 00180 Helsinki Y-tunnus 2362180-3 ALV-numero FI23621803 Kotipaikka Helsinki info@tiera.fi www.tiera.fi
Sisällys 1 Johdanto... 3 2 Pilotti ja sen tavoitteet... 4 2.1 Tavoitteet... 6 3 Pilotin toteutus... 7 3.1 Aikataulu... 7 3.2 Vaiheistus... 8 3.3 Rajaukset... 9 3.4 Riskienhallinta... 9 3.4.1 Riskianalyysi... 10 4 Pilotin kokemukset ja opetukset... 11 4.1 Vaatimukset... 12 4.2 Tulokset... 12 5 Pilotin yhteenveto... 18 6 Liitteet... 20 Versiohistoria: Versio Muutos Tekijä pvm 0.1 peruspohja tehty Tuula Kanerva 21.3.2014 0.2 Stilisointi Sanna Virtanen 2/20
1 Johdanto Suomessa käytössä olevat sosiaali- ja terveydenhuollon tietojärjestelmät kaipaavat uudistamista. Ne on pitkälti kehitetty paperimaailman prosessien pohjalta ja tilanteessa, missä ei ole ollut valtakunnallisia standardeja ohjaamassa ratkaisuja. Ongelmia on mm. käytettävyydessä, tiedon siirtymisessä järjestelmästä toiseen sekä ohjaustiedon saamisessa. Järjestelmät toimivat pääosin tiedon säilyttämisen välineenä ja ne ohjaavat heikosti käyttäjiä. Sähköisen asioinnin mahdollisuudet ovat osin jääneet käyttämättä. Espoossa on koko sosiaali- ja terveystoimessa käytössä saman toimittajan ratkaisu. Valtiovarainministeriö on parhaillaan luonnostelemassa projektisuunnitelmaa alueellisen sote-kokonaisarkkitehtuurin tekemistä varten. Projektin tavoitteena on tukea sosiaali- ja terveydenhuollon rakenteiden, toiminnan ja tietojärjestelmäratkaisujen kokonaisarkkitehtuurin kehittämistyötä sekä mahdollistaa työssä samanaikaisesti etenevien alueiden välinen yhteistyö ja tiedonvaihto. ICT2015-työryhmä ehdottaa tammikuussa 2013 julkaisussa raportissaan, että kansallisen palveluväylän arkkitehtuurin suunnittelu aloitetaan valtionvarainministeriön johdolla. Tavoitteena on samantapainen ratkaisu kuin Virossa on tehty, ja sen puitteissa eri toiminnoissa käytössä olevien järjestelmien tieto on saatavilla väylän kautta, avoimien rajapintojen yli kaikkiin samaa tietoa tarvitseviin järjestelmiin. Espoo ei osallistu sosiaalihuollon, perusterveydenhuollon ja erikoissairaanhoidon yhteisen asiakas- ja potilastietojärjestelmäpalvelun hankintamenettelyyn eli Apottihankintaan. Espoo jatkaa asiakastietojärjestelmien kehittämistä yhteensopivaksi Kantaarkiston ja kansallisen palveluväylän kanssa. Tavoitteena on useammista osista koostuva (modulaarinen) asiakastietojärjestelmä, jolloin saadaan parhaat mahdolliset ja kansallisesti yhteen toimivat ratkaisut eri toimintoihin siten, että tiedot ovat käytettävissä myös yli organisaatiorajojen. Espoo tulee rakentamaan sosiaali- ja terveydenhuollon tarvitsemat ratkaisut modulaaristen, yhteentoimivien sekä kansallisiin palveluihin liittyvien ja tukeutuvien tietojärjestelmien avulla. Tulevaisuudessa Espoon ratkaisu tukeutuu ajantasaisen, oikean ja riittävän potilastietojen saatavuuden osalta Kanta-palveluun sekä kansalliseen palveluväylään paikallisessa, alueellisessa ja kansallisessa yhteentoimivuudessa. Pidemmän tähtäimen tavoitteena on hyödyntää yhtenäistä tietojen siirron tapaa myös toimialarajat ylittäviin tarpeisiin. Väyläpohjaiseen arkkitehtuuriin siirtymällä Espoo haluaa edistää suomalaisen tietojärjestelmäosaamisen vahvistumista ja tietojärjestelmämarkkinoiden kehittymistä ja monipuolistumista. Espoon tavoitteiden saavuttamisen yksi keskeinen mahdollistaja on oikeiden ja ajantasaisten tietojen saatavuuden ja siirron varmistaminen. Viron kansallinen palveluväylä X-Road on todettu toimivaksi sekä konseptina että tuotannossa olevana ratkaisuna. Alueellisen yhtenäisen järjestelmän merkitys tulee kasvamaan huomattavasti kun potilaan vapaus valita lisääntyy sekä EU:n sisällä, että Suomen rajojen sisäpuolella. 3/20
Potilasdirektiivi (24/2011/EU) turvaa potilaalle vapaan oikeuden hakeutua käyttämään terveyspalveluja EU-maassa. Direktiivi on tullut voimaan 2011, mutta sitä on sovellettava 25.10.2013 mennessä. Suomessa on meneillään lakivalmistelu, jonka tavoitteena on saattaa voimaan uusi laki rajat ylittävästä terveydenhuollosta 1.1.2014. Lisäksi Espoon tavoitteena on luoda palveluväylästä arkkitehtuuritavoite ja periaateratkaisu tulevaisuudessa toteutettaville järjestelmäintegraatioille. Potilaan valinnanvapaudesta johtuvan tietojärjestelmien välisen automatisoidun tiedonsiirtotarpeen toteutumatta jääminen aiheuttaa sen, että potilastietojen siirtyminen paikasta toiseen on manuaalisen työn varassa. Ilman integraatioratkaisua, päällekkäisen tiedon tallentaminen eri tietojärjestelmiin (manuaalinen työ) jatkuu. Lisäksi ajantasaisen tiedon etsiminen / selvittäminen eri tietojärjestelmistä sekä virheellisen tiedon käsittely luo lisäkustannuksia. Espoo ja Lahti aloittavat kansallisen palveluväylän pilotoinnin Virossa käytössä olevan palveluväylän sopivuuden testaamiseksi Suomeen. -projekti on saanut alkunsa valtiovarainministeriön kansallisesta palveluväylähankkeesta. Kansallinen palveluväylä on tiedonvälityskonsepti, jossa eri toimintaympäristöjen palveluiden tarvitsema tieto on saatavilla avoimien rajapintojen yli kaikille tietoa tarvitseville palveluille. Tavoitteena on kehittää kuntakentällä olevan järjestelmäkirjon yhteentoimivuutta ja joustavuutta. Pilotit toteutetaan ensimmäisenä sosiaali- ja terveyspalveluiden järjestelmäkentässä. Pilottien toimintamalli pohjautuu VM:n suosituksiin, niiden toteuttajana toimii kuntien omistama Kuntien Tiera Oy ja rahoittajana Sitra. Yhteys Espoo-tarinaan (strategiaan) syntyy Espoon toimiessa edelläkävijänä kunnallisten palvelujen kehittämisessä. Palveluilta odotettua yksilöllisyyttä lisätään yhdistämällä sähköisiä palveluja uudella tavalla perinteisiin palveluihin. Lisäksi Espoo-tarinan valtuustokauden tavoitteiden kohdassa Asukkaat ja palvelut on asetettu tavoitteeksi, että Espoo toimii edelläkävijänä kyseisessä kansallisen palveluväylän kehittämisessä ja käyttöönotossa. 2 Pilotti ja sen tavoitteet Espoon pilotissa testattiin Viron X-road-ratkaisun sopivuutta sosiaali- ja terveydenhuollon palvelujen järjestämisessä ja tuottamisessa. Pilotti todentaa palveluväylän soveltumisen paikallisten integraatioiden toteuttamiseen sekä hoitotyön ydinjärjestelmien että niitä tukevien järjestelmien välillä. Tarpeellinen tieto on käytettävissä eri toimintoihin tarkoitettujen järjestelmien välillä. Espoo testasi palveluväylään perustuvaa tiedonsiirtoa eri järjestelmätoimittajien hoitotyötä tukevien järjestelmien välillä. 4/20
Pilotoinnin pohjaratkaisuksi valittu Viron kansallinen palveluväylä X-Road on todettu toimivaksi sekä konseptina että tuotannossa olevana ratkaisuna Virossa. Espoossa on tarkoitus saada hoitotyön ydinjärjestelmissä oleva tieto myös mobiilin kotihoidon toiminnanohjausjärjestelmän käyttöön Pilotti toteutettiin seuraavien järjestelmien välillä palveluväylän ylitse: kotihoidon toiminnan ohjauksen ja optimoinnin järjestelmä (Tiera Mobiili Kotihoito), potilastiedon perusjärjestelmä (Tieto Oyj:n Effica) sekä kotihoidon työvuorosuunnittelun järjestelmä (CGI:n Titania). Kuva 1.. Asiakkaan sovellus hakee palvelun hakemiston osoittamasta paikasta. Turvapalvelu tarkistaa asiakkaan oikeutuksen ja liikenne salataan asiakkaan ja palvelun välisen yhteyden osalta turvapalvelinten välillä palveluväylän varmennepalvelun tuottamilla varmenteilla. Palvelupyynnöt muotoillaan liityntäpalvelussa, jonne sovelluspalvelu palauttaa vastaukset ja liityntäpalvelin lähettää ne asiakkaalle palveluväylän kautta. Asiakkaan liityntäpalvelu purkaa sanoman palvelua pyytäneeseen kohdesovellukseen. 5/20
Espoon palveluväyläpilotin arkkitehtuuri Kuva 2. Espoon palveluväyläpilotin arkkitehtuuri. 2.1 Tavoitteet Espoon tavoitteena on rakentaa sosiaali- ja terveyshuollon tarvitsemat ratkaisut modulaaristen, yhteentoimivien sekä kansallisiin palveluihin liittyvien ja tukeutuvien tietojärjestelmien avulla. Espoon sosiaali- ja terveyshuollon ratkaisut perustuvat tavoitetilassa kansalliseen palveluväylään paikallisessa, alueellisessa ja kansallisessa yhteentoimivuudessa. Pidemmän tähtäimen tavoitteena on hyödyntää yhtenäistä tietojen siirron tapaa myös toimialarajat ylittäviin tarpeisiin. Espoon kansallisen palveluväylän pilotoinnissa on tavoitteena: Viron X-Road-ympäristön rakentaminen Tieran ylläpitoon X-Road-konseptiin liittyvän osaamisen siirtäminen Tieraan Espoon pilotoitavien järjestelmien liittäminen (liittymien rakentaminen) palveluväylään o Tiera (Fastroi): Mobiili kotihoito o Tieto: Effica: potilastietojärjestelmä o CGI: Titania: työvuorojärjestelmä Palveluväylään liitettyjen järjestelmien liittymien toimivuuden todentaminen (tietosisällön siirtäminen järjestelmästä toiseen) Palveluväyläpilotin (ratkaisun) dokumentaatio Luoda edellytykset tiedonvälitykselle yhteiskunnan eri toimijoiden (julkinen hallinto, yritykset ja kolmas sektori) palveluprosesseissa ja palveluprosessien välillä tiedon käyttövaltuudet huomioiden 6/20
Testata ja varmistaa kansallisen palveluväylän palveluväyläratkaisu paikallisessa, alueellisessa ja valtakunnallisessa laajuudessa sosiaali- ja terveyshuollon tietojärjestelmillä. Luoda mahdollisuus Espoon palvelutoiminnan kannalta keskeisten tietojen ja tietovarantojen hyödyntämisen ja yhteiskäytön lisäämiseen sekä parantamiseen ja luoda sille yhtenäiseen kokonaisarkkitehtuuriin perustuva tietoalusta Parantaa tietojen välittämisen kustannustehokkuutta Kehittää ja harmonisoida tiedonvaihtoa ja siten nopeuttaa Espoon palveluiden kehittämistä ja parantaa niiden tuottavuutta ja hyödyllisyyttä Perustaa ratkaisu joustavaan infrastruktuuriin, joka on suunniteltu teknisesti, loogisesti ja hallinnollisesti modulaariseksi ja joka mahdollistaa uusien palveluiden lisäämisen infrastruktuuriin helposti Lisätä edellytyksiä ja mahdollisuuksia toimintojen uudistamiseen ja innovaatioihin Testata vaatimukset ja askeleet tietojärjestelmän ja organisaation liittämiseksi osaksi palveluväylää Lisäksi pilotin tavoitteena on todentaa kansalliseen palveluväylään liittyvien yleisten hyötytavoitteiden toteutuminen: Systemaattisesti hallittava, hajautettu, toisiinsa löyhästi kytketty palveluverkosto, jossa viestintä perustuu kahdenväliseen viestintään Tuottaa turvallinen päästä-päähän -ratkaisumalli, jossa tietoturva voidaan varmistaa usealla eri tasolla On helposti laajennettavissa ja muunneltavissa sekä skaalattavissa volyymien kasvaessa Luo yhtenäisen käytännön tietojen vaihtoon Hyödyntää täysimääräisesti olemassa olevan tietojen vaihdon infrastruktuurin sekä ottaa huomioon toimialakohtaiset erityispiireet. 3 Pilotin toteutus 3.1 Aikataulu Projektin alkuperäisen aikatauluun verrattuna projekti myöhästyi kaksi kuukautta. Myöhästymisen syyt löytyvät projektin alusta ja oletettua pidemmistä sopimusneuvotteluista toimittajien kanssa. 7/20
Kuva 3. Projektin aikataulu. 3.2 Vaiheistus Pilottiprojektin vaiheistus noudatti seuraavaa vaiheistusta: Vaihe Vaiheen tarkoitus Vaiheen tehtävät Valmisteluvaihe 1. Projektin valmistelu Sopimukset asiakkaiden kanssa X-Road-osaajien hankinta kilpailuttamalla Projektin resursointi Espoon, Lahden ja Tieran asiantuntijoilla Projektin ohjausryhmän nimeäminen Suunnitteluvaihe 2. Suunnittelu Projektin suunnittelu Tarvittavien rajapintojen tilaus liittyvien järjestelmien toimittajilta Palvelimien tilaus X-Road-lisenssin hankinta (oikeuttaa Palveluväylän asennukseen) Suhde alueellisiin ja kansallisiin hankkeisiin määritelty Toteutusvaihe 3. Määrittely Rajapintamääritykset liittyvien järjestelmien toimittajien kanssa (Tieto, CGI, Fastroi) Arkkitehtuuri 8/20
4. Asennus Tuotantoympäristön pystytys Lopetusvaihe ja jälkiarviointi 5. Tekninen toteutus ja testaus 6. Osaamisen kasvattaminen 7. Projektin päättäminen ja jatkotoimenpiteistä sopiminen Tietoliikenneyhteyksien avaus X-Road asennus X-Road testaus Rajapintojen toteutus Toteutettujen rajapintojen testaus e2e-testaus Peruskoulutukset Tieran ja asiakkaiden resursseille (kouluttaja Virosta) Palvelun asennus yhdessä Tieran ja Viron resurssien kesken (kts. Asennusvaihe) Tarvittavat käännöstyöt ja räätälöinti palvelun dokumentaatiolle Yhteenveto pilotin kokemuksista ja ehdotus jatkotoimenpiteistä Päättäminen jatkotoimenpiteistä projektin ohjausryhmässä Pilotin loppuraportin kokoaminen 3.3 Rajaukset Projektissa oli kyse palveluväyläratkaisun pilotoinnista, joka ei sisältänyt tuotantoympäristön toteutusta. Pilotointi toteutettiin rajatulla tietosisällöllä (olemassa olevalla tietosisällöllä ja olemassa olevien rajapintojen vähäisillä muutoksilla). Projektin kuluessa ohjausryhmä rajasi kansallisen ulottuvuuden pois toteutuksesta, koska sen tekninen toteutus oli samankaltainen. Lisäksi tavoitteena oli toteuttaa potilastietojen siirto kansallisella tasolla Kanta-palvelun kautta. SSL-salaus turva- ja liityntäpalvelimien välillä oli rajattu pilotin ulkopuolelle. SSL-salausta testattiin sovellustoimittajan puolesta ja siinä yhteydessä todettiin tarpeelliseksi täsmentää dokumentointia em. toiminnan osilta. 3.4 Riskienhallinta Pilotin alussa määriteltiin mahdolliset riskit ja mietittiin toimenpiteitä, joiden avulla riskien toteutuminen voidaan välttää tai riskiä pienentää. Riskien toteutumista seurattiin koko pilotin ajan, ja tarvittavia korjausliikkeitä tehtiin tarpeen mukaan. 9/20
3.4.1 Riskianalyysi Riskinumero Riskin (toteutumisen) kuvaus Todennäk. 1-4 Vaikutus 1-4 Riskiluku (todennäk. *vaikutus) Toimenpiteet riskin poistamiseksi tai pienentämiseksi 1 Järjestelmätoimitta-jien sitoutuminen (eivät sitoudu tuotettavan ratkaisun mukaiseen toimintaan) 2 Kotihoidon toiminnanohjausjärjestelmän ja Efficapotilastieto-järjestelmän liittymärajapinnan muutosprojektin viivästyminen 3 Kustannusten ylittyminen (Tieran arvioimat alihankkijoiden rajapintojen rakentamiskustannukset ) 3 4 12 Toimittajien informointi, kokoukset ja koordinointi. Tarvittaessa palaveri yrityksen johdon ja asiakkaan johdon välillä. 3 3 9 Nopea päätöksenteko ja osallistuminen Mobiili kotihoidon projektin toteutuksen (ml. integraation) suunnitteluun. 2 1 2 X-Road-ratkaisun muutosten minimoiminen ja osallistuminen integraation suunnitteluun. 4 Osaa kokeiltavista ratkaisuista / tuotteista ei osata konfiguroida, tai ne osoittautuvat hankaliksi toteuttaa siten, että niiden toimivuudesta saataisiin totuudenmukainen kuva. Tehdään vääriä ratkaisuja / valintoja. 1 4 4 X-Road-ratkaisun muutosten minimoiminen 5 Palveluväyläpilotin toteuttamiseen (rajapintojen toteuttaminen on monimutkaista) varattu aika on liian lyhyt ja toteutusta ei saada tehtyä kyseisessä aikataulussa. Pilotointi viivästyy. 6 Perustaksi otettu valmisratkaisu ei taivu tarvittaviin muutoksiin helposti, aikataulu venyy. 7 Dokumentaatio ei ole riittävän selkeää. Pilotointiympäristön ja 1 3 3 Realistinen aikataulusuunnitelma ja X-Road-ratkaisun muutosten minimoiminen. 1 2 2 Vaihtoehtojen etsiminen akselilla Tiera, Espoo, Lahti, X-Roadtoimittaja, kansallinen palveluväylähanke 1 3 3 Oikolukeminen / tarkastaminen ennen vaiheen valmistumista. 10/20
Riskinumero Riskin (toteutumisen) kuvaus Todennäk. 1-4 Vaikutus 1-4 Riskiluku (todennäk. *vaikutus) Toimenpiteet riskin poistamiseksi tai pienentämiseksi sen komponenttien toiminnallisuudet kuvataan puutteellisesti tai moniselitteisesti. 8 Vastuullisella taholla ei ole vaadittua kompetenssia sille suunniteltuun tehtävään. Kehittäminen, toteuttaminen ja pilotointi viivästyvät. 9 Toteutus suunnitellaan sellaiseksi, että sen muuttaminen myöhemmässä vaiheessa on vaikeaa ja kallista. 10 Valittavat tekniset ratkaisut eivät ole pitkäikäisiä. Toteutusta joudutaan muuttamaan myöhemmässä vaiheessa. 11 Pilotointiympäristöstä tulee liian raskas. Ympäristöön on hankala kytkeytyä. 12 Palveluväylän toiminnallisuus soveltuu vain osalle potentiaalisesta käyttäjäjoukosta. Palveluväylän käyttö jää suppeaksi. 2 2 4 Oikea resursointi ja koulutus sekä toteutuksen dokumentointi. 1 2 2 X-Road ratkaisun muutosten minimoiminen ja toteutuksen (dokumentaation) tarkastaminen 2 2 4 X-Road ratkaisun muutosten minimoiminen ja toteutuksen (dokumentaation) tarkastaminen 1 3 3 X-Road ratkaisun muutosten minimoiminen ja toteutuksen (dokumentaation) tarkastaminen sekä testaus. 1 3 3 X-Road ratkaisun muutosten minimoiminen ja toteutuksen (dokumentaation) tarkastaminen sekä testaus. 4 Pilotin kokemukset ja opetukset projektin päätteeksi projektiryhmän kokemukset koottiin yhteen. Tähän kappaleeseen on koottu projektilaisten kommentteja ja huomioita palveluväylän pilotoinnista Espoossa. 11/20
4.1 Vaatimukset Vaatimusten osalta voidaan yhteenvetona todeta, että palveluväylän tiedonsiirron tulee täyttää samat vaatimukset kuin mitkä on määritetty KanTa-palveluratkaisulle. Tiedonsiirron osalta palveluratkaisun tulee täyttää julkisen hallinnon toiminnalle asetetut tietoturvavaatimukset. Erityisesti sosiaali- ja terveydenhuollon sektoriin kohdistuu lainsäädännön vaatimuksia, jotka tulee huomioida palveluväylän tiedonsiirron tietoturvavaatimuksissa. Deloitte kartoitti STM:n, THL:n ja Kelan edustajien kautta tiedonsiirtoon liittyviä tietoturvavaatimuksia. 4.2 Tulokset X-Road palveluväyläarkkitehtuuri tarjoaa joustavan ja turvallisen tiedonvälitysratkaisun, jonka tietoturvaratkaisut mahdollistavat luotettavan tiedonsiirron julkisen internetin yli. Esimerkiksi SOTE-alueen asettamat tietoturvavaatimukset luotettavalle tiedonsiirrolle pystytään täyttämään. X-Road ei ota kantaa siihen, mitä verkkoa tiedonsiirrossa käytetään. Julkisen verkon lisäksi tiedonsiirto voidaan toteuttaa hyödyntäen muita verkkoratkaisuja kuten Tuve-verkkoa. X-Road-ratkaisu ottaa kantaa käytettäviin reititys- ja tietoturvakäytäntöihin. Palvelutaso riippuu käytettävästä tietoverkosta ja operaattorista. Kansallisen palveluväylähankkeen yhteydessä tulee määrittää kriteerit, milloin muiden verkkoratkaisujen käyttäminen on perusteltua. Lisäksi tulee määrittää vaatimukset, jotka poikkeavaan verkkoratkaisuun liittyvän organisaation tulee täyttää (esim. VAHTI vaatimusten perustason täyttäminen). X-Road on Virossa käytössä oleva standardoitu palveluväyläratkaisu, joka mahdollistaa julkisen ja yksityisen sektorin hallinnoimien ja eri puolille hajautettujen tietokantojen yhdistämisen yhdeksi selkeäksi palvelukokonaisuudeksi. Tällä hetkellä palveluun on Virossa liittynyt yli 1000 organisaatiota, julkista rekisteriä ja tietokantaa. Käyttömääriltään suurimmat palvelut ovat sähköinen reseptijärjestelmä, ajoneuvoliikennerekisteri, vero- ja tulliviraston palvelut ja rajavalvonnan ylläpitämä Schengen-tietojärjestelmä. Palvelu perustuu tekniikasta ja alustasta riippumattomaan tiedonvälitykseen (SOAP-protokolla), joka mahdollistaa erilaisten tietokantojen ja tietojärjestelmien joustavan ja kustannustehokkaan liittämisen palveluun. Valitun ratkaisun ansiosta organisaatioiden ei tarvitse sitoutua yhteen tiettyyn tietokanta- tai järjestelmätoimittajaan. 12/20
Luotettavan tiedonsiirron takaamiseksi kaikki palveluväylää pitkin kulkeva liikenne salataan ja allekirjoitetaan digitaalisesti. Jokaisesta tapahtuneesta tiedonvälityksestä tehdään myös lokitietoihin kirjaukset, jotka mahdollistavat tiedonvälitystapahtumien todentamisen jälkikäteen. Organisaatiot vastaavat itse palveluväylään liitettyjen palveluiden käyttöoikeuksien hallinnoinnista. Tiedonsiirtoa varten ei tarvitse rakentaa omaa erillistä verkkoa, koska tiedonvälitys tapahtuu julkisen internetin yli. Julkisen verkon lisäksi tiedonsiirto voidaan toteuttaa hyödyntäen muita verkkoratkaisuja. Mikäli käytössä ei ole kaksisuuntaista https-varmistuspalvelua, on turvapalvelimeen yhteyttä ottavan liityntäpalvelimen tai palvelun kiistaton tunnistaminen haasteellista. Virossa käytetään y-tunnusta tunnistautumisessa. Pilotissa palveluväylän monitorointi nähtiin haasteena, kuten myös palveluväyläympäristön valvonta. Palveluväyläpilotin lokien arkistointia ei testattu (ei kuulunut pilotin scopeen) Lokit kahdella eri turvapalvelimella ja keskusserverillä tarvittaessa Lokeista mietittävä/huomioitava puuttuva/vajavainen lainsäädäntö mm. miten pitkään lokeja on sälilytettävä, kuka säilyttää jne. Turvapalvelinten pystytys oli helpohkoa, tosin turvapalvelimien hallintaa tarvitaan Turvapalvelimien pystytystä ja palveluväylään liittymistä helpottaisi selkeät speksit (voi olla melko mahdotonta luoda), standardinmukaisuus tai vähintään viitearvot Turvapalvelinkoulutuksessa tulee ohjeistaa kahdensuuntaisen http:n käyttö tarkemmin Turvapalvelinkoulutuksesta olisi saatu vielä enemmän hyötyä, jos olisi kommunikoitu tarkemmin koulutuksen kohderyhmä Turvapalvelinkoulutus olisi voinut olla etäkoulutus, puolet päivän sisällöstä oli osallistujille tuttua Prosessi liityntäpalvelimen varmenteen hankkimiseksi luotava Liintyntäpalvelinkoulutuksessa sovellusasennukset tehtiin ennakkoon Turvapalvelimen kahdentaminen parantaa palveluväylän vikasietoisuutta, mutta vaikuttanee palveluväylän hallintaan Pystytetty ja toimiva palvelu tarvitse vain vähän valvontaa/ ylläpitoa Kun ympäristössä ei ole kahdennuksia tai klustereita, sanoma voidaan menettää tulee olla mekanismi/hälytysjärjestelmä, joka varmistaa sanomien liikkumisen ongelmitta ja ongelmatapauksessa järjestelmä ilmoittaa siitä Pilotissa todettiin, että WSDL-auditointistepille on tarve. Mietittävä miten hallinnoidaan WSDL-kuvauksia 13/20
WSDL-kuvaukset, sisäänrakennetun ominaisuuden käyttäminen jos kuvaustiedoston nimi on muuttunut, ei mikään palveluväylän ekosysteemissä tee ilmoitusta minnekkään järjestelmässä, vaain yhteys ei vain toimi WSDL-kuvaukset ei sisällä toimivuuden tarkistusta Pilotissa palveluiden tarjoajien (palveluväylässä Provider) luominen todettiin olevan varsin suoraviivaista ja näin ollen Consumer- ja Provider-rooleille tulisi määritellä selkeämmät roolit (missä roolissa toimivat). Consumer käyttää palveluväylässä tarjolla olevaa tietoa ja provider puolestaan tarjoaa tietoa käytettäväksi palveluväylän kautta. Pääsy turvapalvelimeen puuttui, tarvittiin toinen osapuoli testaukseen. Mietittävä, voisiko turvapalvelinta todentaa jotenkin itse. Perusspeksien oltava valmiina ennen aloittamista, rajapinnat sovittava heti alussa Iso haaste muodostuu siitä, jos ei tiedetä mitä tietoa siirretään ja missä muodossa Jos siirrytään point-to-point -ratkaisusta palveluväyläratkaisuun, on testaus tehtävä ensin tietosisällöillä Palveluväylässä ei kannata testata liikuteltavaa dataa (tietosisältöä) Mietittävä palveluväyläympäristöjen määrä o Virossa testiympäristö ja tuotantoympäristö a-synkroninen datasiirto o Pilotoinnin testauksessa X-Road.eu -versio, toteutettu dns sec:illä (tämä on aina käytössä, halusi tai ei) Pilotin jälkeen rakentamiskustannukset olivat ennustettavissa melko hyvin. HL7-koodistot käytössä, perusspeksit joilla pääsee eteenpäin 120 GB testattu labroratorio-olosuhteissa 1% ajasta menee palveluväylän pystyttämiseen, 99% ajasta menee tietosisältöihin testaus ohjeistettava tarkasti, muuten tulee runsaasti iterointia Pilotin aikana todettiin, ettei X-Road-dokumentaatio vastannut kaikkeen tarvittavan selkeästi ja ohjaavasti, vaan enemmänkin esimerkinomaisesti. Teknisten yksityiskohtien tarkempi läpikäynti oli välttämätöntä. Teknisen ympäristön kuvaukset on tärkeä tehdä vaiheittain: kehitysympäristö/pilotointiympäristö/ tuotantoympäristö Kansallinen palveluväyläarkkitehtuuri -dokumentti suosittelee liityntäpalvelimen asentamista virtuaalisena virtuaalipalvelin alustaan. Pilotissa ei löydetty viitettä tähän väittämään. Espoo asensi kuitenkin pilotin ajaksi dedikoidun räkkipalvelimen. 14/20
Espoon palveluväyläpilotin hallinnointi ei tuottanut suurta työmäärää. Pilotti osoitti, että kuitenkin jo kolmen eri järjestelmän, useamman toimittajan/toimijan ja alle kahdenkymmenen henkilön projektissa jouduttiin harjoittelemaan hallinnointia. Mietittäviä seikkoja: Miten hallinnointi toteutetaan Suomessa? o Virossa RIHA (Riigi infosüsteemi haldussüsteem) vastaa palveluväylän hallinnasta Hallintaprosessi mietittävä: miten liitytään, miten ylläpidetään muutoksia ja miten irtaudutaan palveluväylästä Auditoinnit, kuka auditoi ja mitä auditoidaan? Miten hallinnoidaan sertifikaatteja? Miten autentikoidaan kaikki käyttäjät? Muita huomioita: Luottosuhteiden luominen sertifikaattien välille vie aikaa Palvelun tuottajan / asiakkaan nimeämiset (LY-tunnusten käyttäminen, URL:sta / rajapinnasta sopiminen) Lokien arkistoinia taustajärjestelmään ei testattu. Mitä päätetään lokituksista: kuka seuraa, kuka valvoo että lokitus toimii, miten haetaan tietoja lokeista, kuka saa hakea tietoja, kuinka kauan lokeja pitää säilyttää? Tietoliikennejärjestelyt: yhteydet on avattava, testattava ja kuitattava Informointitapojen kiinnittäminen ja määrittäminen: yleistä infoa, vastuuhenkilökohtaista WSDL-hallinnointi Ympäristön pystytyksen tuki Ympäristön valvonta (24/7, lokitukset, yhteyshenkilöt ) Yhtenäinen käsitteistö puuttuu (adapteri / liityntäpalvelin jne.) Tietoarkkitehtuurista päättäminen haasteellista, esim. potilaan perustiedot Efficassa, Pegasoksessa, Hilkka-kotihoidossa, Espoossa, Lahdessa ja Kanta - palvelussa eri sisältöisiä Teknisen ympäristön pystyttäminen (keskuspalvelut, turvapalvelin, liityntäpalvelin jne.) Päivitysten jakaminen (päivityksiä HTTPS-konfigurointeihin) Teknisen ympäristön pystyttäminen / turvapalvelimen käyttöjärjestelmä (Ubuntu 10.04 LTS) / tuetut laiteympäristöt Ubuntu ja virustorjunta yhteensopivuus (on esim. Sophos, mutta ei nähdä tarpeellisena. Palvelin on luonteeltaan sellainen, että sillä ei tiedostoja säilytetä. Suurempi uhka tietoturvalle muodostuu vanhasta käyttöjärjestelmästä ja mahdollisista palveluväyläkomponenttien haavoittuvuuksista.) Organisointi ja sidosryhmäyhteistyö oli helppoa, haasteellista on nykyisen toimintatavan muutokset 15/20
Pilotin aikana todettiin, että työssä tulee huomioida kansallinen palveluarkkitehtuuri, kansallinen palveluväylä sekä tunnistamisen ja muiden yhteisten kansallisten palveluiden kehittäminen. Tukipalvelut järjestettävä Ylläpidon aikainen tekninen tukipalvelu Integraatioiden mallintaminen/-kuvaaminen (KA-väline/-välineet/mihin ympäristöön) Integraatio strategia, periaatteet ja linjaukset sekä menetelmät ja standardit (kuka hallinnoi ja standardoi?) Laajemmat integraatioratkaisut / Espoon sisäiset integraatioratkaisut (erillisen integraatioalustan tarve)? Monitorointi tietosisältöön, triggerit, jonokäsittelyt ja adapterit eri tietomuodoille puuttuvat Tietoarkkitehtuuri puuttuu Sanomapohjaiset sanomat ja standardit Kansallisen palveluväylän tuotantoympäristön valmistumista odotellessa tulee miettiä: Etenemispolku, jotta siirtymäaikana työmäärät minimoidaan: XML-pohjaiset Webservice-rajapinnat muutettavissa pienimmällä työllä palveluväylärajapinnoiksi (ohjeistusta saatavilla) VAKAVA-hanke, tuoko tullessaan välineitä hallittuun monitoimittajamalliin käytettävyys? Määritettävä käyttötapaukset, joissa datan pitäisi liikkua kuntarajojen yli, mutta ei vielä liiku Kuvattava tavoitetila selvästi: mikä on asiakkaan ja mikä toimittajan vastuulla Kuntien tulee ymmärtää palveluväylään liittyvät integraatiot Kuntien tehtävä yhteistyötä käsite- ja loogisella tasolla, datasetti tasolla pohja joilla kuntien olisi helpompi liittyä palveluväylään Mitkä voisivat olla kehittämisprojekteja tai -suuntia? Jos kaikilla omat turvapalvelimet, auttaako liittymistä vai olisiko turvapalvelimet verkossa? (Perusarkkitehtuuri on rakennettu niin että jokaisella olisi oma turvapalvelin) Avoin turvapalvelin edellyttää pääsytä (accessia) myös serverille administraattorina (ei jokaisessa tapauksessa välttämätöntä, riittää että pääsee kiinni selainpohjaiseen hallintasovellukseen mikäli esim. palveluoperaattori huolehtii käyttöjärjestelmä ja X-road päivityksistä) Tietosisällön ymmärtämiseksi on tehtävä töitä ennen palveluväylä testaamista Palveluväylä vaikeuttaa tietosisällön todentamista Pilotissa tehtyjä johtopäätöksiä liittyen nykyisten palveluiden uudelleenkäyttöön ja hyödyntämiseen tai uusien palveluiden koostamiseen: 16/20
Palveluväylään liittyviä asioita tehdään monessa paikassa samaan aikaan. Palveluväylän käyttöönottamista autata, kun tiedetään mitkä kaikki asiat/ratkaisut ovat jo olemassa Lainsäädäntö Standardinmukaisuus Turvapalvelimen asennus/prosessi dokumentoitua, jotta asennus sujuu oikein ja ympäristö saadaan toimintakuntoon oikealla raudalla Määriteltävä palveluväylään liittymisen perusvaatimukset mitkä askeleet otettava webservice-pohjaiseen siirryttäessä Vastuumatriisit tulee kuvata tarkasti: kuka on vastuussa mistäkin palveluväylän osasta Palveluväylään siirtyminen ei ratkaiset sisällöllisiä yhteentoimivuuksia Koska palveluväylä on käytössä 24/7, se tulee toteuttaa korkean käytettävyyden ratkaisuksi Integraatiokustannusten aleneminen verrattuna kustannuksia point-2-point ratkaisuihin Palveluväylän todettiin parantavan tietojen saatavuutta ja ohjaavan yhteentoimivuuteen, mutta palveluväylä ei sen sijaan tuo mitään uutta sisällölliseen yhteentoimivuuteen. Käytettävä yleiskäyttöisiä ratkaisuja = monikäyttöisyys Tunnistettava uusien toiminnallisuuksien kustannukset Toimittajien väliset integraatiot, toimivat mokkulat, joilla integraatiot saadaan muuhunkin käyttöön Sanomien välittäminen ja liikuttaminen Pilotissa pohdittiin, voisiko olla esimerkiksi palveluväyläryhmiä: kuntatoimijaryhmä tietyillä palveluväylä-palveluntarjoajilla. Palveluväyläryhmien tarpeet olisivat samankaltaisia, ja näin ollen liittymät voisivat olla samoihin toimijoihin kaikilla (consumerit ja providerit). Näin sertifikaatit saataisiin kuntoon yhdellä kertaa. Palvelujen / intergraatioiden priorisointi palveluväylään liitettäessä mietittävä, vrt. kansalliset tietovarannot / kuntakohtaiset integraatiot Terveydenhuollon tietosisällöt hakusessa, KanTa (kansallinen terveydesarkisto) KanSa (kansallinen sosiaalihuollon asiakastietovaranto) Websphere-rajapinnat muutettava pienimmällä työllä palveluväylärajapinnoiksi Rajattu tietosisältö, rajatut sovellukset Onko vain yksi palveluväylä mahdollinen? Onko useiden palveluiden yhdistäminen liian haasteellista / mahdotonta? Useampi palveluväylä mahdollistaa samat domain-nimet, vrt. yhdistäminen ESB:llä, tulevassa versiossa mahdollistaa yhdistämisen + luottosuhteet Miten kaksi tai useampia palveluväyliä liitetään toisiinsa (esim. HUS Alli + palveluväylä) Tulee latency-ongelmia jos useampi palveluväylä ja tieto kulkee useamman palveluväylän läpi Yhteinen kehitystyö virolaisten kanssa 17/20
Kaikkea liikennettä ei voitane hoitaa palveluväylän kautta, esimerkiksi laboratorioiden HL7-liikenne Yhteisiä softakomponentteja Viron ratkaisun kanssa, osa pelkästään Suomessa kehitettäviä Keskuspalvelimissa tekstitiedosto määrittelee roolin, muu kaikki pakettina sisällä Pilotissa pohdittiin lisäksi, kannattaako Suomessa palveluväyläratkaisua hyödyntää sellaisissa käyttökohteissa, johon sitä ei ole Virossa alun perin suunniteltu (/ ei myöskään kaikilta osin välttämättä sovellu). Tietojärjestelmätoimittaja Nortal (Viro) antoi vastauksensa ratkaisun hyödyntämiseen liittyen: 1. Kuinka laajasti X-Roadia käytetään Viron terveydenhuollon organisaatiossa yhdistämään sisäisesti eri it-järjestelmiä (esim. kaksi itjärjestelmää samassa sairaalassa)? - X-roadia käytetään ulkoisiin yhteyksiin kansallisen tason integraatioissa (terveydenhuollon palveluntuottajien integrointiin kansallisiin rekistereihin, e- resepiin tai kansalliseen terveysrekisteriin). - X-roadia käytetään harvoin terveydenhuollon eri palvelutarjoajien integrointiin (esimerkiksi perhelääkäreiden integrointiin joihinkin sairaaloihin, jotka tarjoavat palveluja X-Roadille). - X-roadia ei käytetä saman sairaalan sisällä. Se johtuu X-Roadin arkkitehtuurista, se tarjoaa turvallisen yhteyden (internetin yli) kahden X- Roadin turvapalvelimen välillä. 2. Onko Viron sairaaloissa käytössä muita kolmannen osapuolen integraatioratkaisuja - Ei ole yhteistä alustaa sisäiseen integrointiin, kunkin sairaala päättää niistä itse. - Nortal käyttää räätälöityihin integrointeihin kolmannen osapuolen ESB ratkaisua. Samaa alustaa käytetään sisäisten järjestelmien integraatioissa ja ulkoisten palveluntarjoajien yhteyksien rakentamisessa X-Roadin kautta. 5 Pilotin yhteenveto Espoon pilotin aikana todennettiin, että palveluväylä-ratkaisu sopii sosiaali- ja terveydenhuollon palvelujen järjestämiseen ja tuottamiseen pilotin kohteessa. Samalla todennettiin, että palveluväylän vaatima tekninen ympäristö on rakennettavissa. Hyötytavoite Mittarit toteutumisen arvioimiseksi Mittarien nykyarvo/- tilanne Mittarien tavoitearvo 18/20
Hyötytavoite Toiminnan tehostuminen ja kustannussäästöt: Luotu edellytykset julkisen hallinnon, yritysten ja kolmannen sektorin väliselle tiedonvälitykselle palveluväylän avulla manuaalisen työn väheneminen prosessin nopeutuminen palveluiden kehittämisen nopeutuminen konseptin monistettavuus Toiminnan tehostuminen ja kustannussäästöt: Mahdollistaa uusien tietojärjestelmien ja organisaatioiden liittämisen palveluväylän piiriin sekä tietojen yhteiskäytön lisäämisen (helposti laajennettavissa ja muunneltavissa sekä skaalattavissa volyymien kasvaessa). Mittarit toteutumisen arvioimiseksi Toteutettu tietojen siirto Mobiilin kotihoidon ja Effican sekä Titanian välillä palveluväylän kautta. Projektidokumentaatio. Mittarien nykyarvo/- tilanne P2P-yhteydet, jokaista toimijaa varten Erilliset määrittelyt ja erilliset liittymät Mittarien tavoitearvo Määritelty, todennettu konsepti, miten kuka tahansa voi liittyä palveluväylään Monistettava liittymä (konsepti) samankaltaisten järjestelmien liittämiseksi palveluväylään Toiminnan tehostuminen ja kustannussäästöt: Teknisen ratkaisun kansallisen ulottuvuuden todentaminen (luo yhtenäisen käytännön tietojen vaihtoon, turvallinen päästä-päähän - ratkaisumalli). Toteutunut, turvallinen potilastietojen siirto Espoon ja Lahden välillä palveluväylän kautta. Manuaalinen tietojen siirto Olemassa olevan tiedon siirtäminen palveluväylän yli. Pilotin päätteeksi Espoo teki linjaukset palveluväylästä ja integraatioarkkitehtuurista. Lopputuloksena todetaan, että Espoo tukeutuu kansalliseen palveluväylään eikä toteuta paikallista palveluväylää (X-road). Nykyinen X-road-teknologia ei mahdollista väylien kytkemistä peräkkäin/rinnakkain. Kansallista palveluväylää käytetään Espoossa pääsääntöisesti ulkoisten integraatioiden toteuttamiseen, pääkohteena ovat tällöin kansalliset perustietovarannot. Kansallinen palveluväylä (X-road) ei ratkaise Espoon sisäisiä integraatiotarpeita, joten ne on ratkaistava toisella tapaa. Espoossa tarvitaan sisäinen integraatioalusta/palvelu (ESB), joka huolehtii organisaation sisäisistä integraatiotarpeista, sekä voi liittää myös Espoon omat järjestelmät kiinni kansalliseen palveluväylään. Palveluväylä ei sinänsä ratkaise tietojärjestelmien rajapintaongelmia, vaan rajapinnat on kehitettävä sekä teknisessä että sisällöllisessä mielessä. Sisäinen integraatioalusta mahdollistaa integraatioiden toiminnan hallinnan ja valvonnan (eri lähteistä tulevan tiedon yhteismitallistaminen). 19/20
Espoo kehittää yhtä yhtenäistä integraatioalustaa koko kaupungin tarpeisiin. Espoon uusi sairaala (EUS) toimii tässä pilottina. Koska integraatiotarpeita on runsaasti ympäri kaupunkia, ei ole tarpeen kehittää pistemäisiä ratkaisuja päällekkäin (tuottavuus, kyvykkyys, jne.). Kehittämisaikataulu sovitetaan EUS-projektin tarpeisiin. Espoo toimii lisäksi pilottina/edelläkävijänä kehittämässä sisäistä integraatioalustapalvelua yhdessä Tieran kanssa. Lähtökohtana on integraatioalustapalvelun tekninen ja sopimuksellinen skaalautuvuus koko kuntakentälle. Sisäisten integraatioiden, palveluväylään liittymisen ja kuntien tietojärjestelmien rajapintojen kehittämisen tarpeet ovat samankaltaisia kaikilla kunnilla. Tieran toimiessa operaattorina voidaan sama kehitystyö hyödyntää useamman kunnan kohdalla ja näin saavuttaa merkittäviä tuottavuus hyötyjä. 6 Liitteet Liite 1, Järjestelmäraportti Liite 2, X-Road_infra_Espoo 20/20