SAINI-ARKKITEHTUURI Kansalaisen terveyteen liittyvä sähköinen asiointi ja interaktiiviset verkkopalvelut Teknisen ympäristön tavoitetila 23.11.2007 i (3)
SISÄLLYSLUETTELO 1 Johdanto... 1 1.1 Taustaksi...1 1.2 Tavoitteet...1 2 Arkkitehtuurimenetelmä... 2 2.1 Kuvaus arkkitehtuurimenetelmästä...2 3 Arkkitehtuurin lähtökohdat... 3 3.1 Reunaehdot ja periaatteet...3 3.2 Arkkitehtuuri- ja teknologiatrendit...4 4 Toiminta-arkkitehtuuri... 7 5 Tietoarkkitehtuuri... 7 5.1 Johdanto...7 5.2 Tietoarkkitehtuurin periaatteet...8 5.3 Tiedon luokittelu...9 5.4 Päätietoryhmät...10 5.5 Tietovarastot...13 5.6 Muita suosituksia...14 6 Tietoturva-arkkitehtuuri... 15 6.1 Jaottelu yleisesti...15 6.2 Yleiset suositukset...16 6.3 Jaottelu yksityiskohtaisemmin...16 6.3.1 Sähköinen allekirjoitus... 16 6.3.2 Tiedon salaaminen... 17 6.3.3 Tunnistaminen ja todentaminen... 17 6.3.4 Käyttövaltuushallinta... 18 6.3.5 Pääsynvalvonta... 19 6.3.6 Jälkikäteinen valvonta... 19 6.4 Näkökulmat...19 6.4.1 Asiakkaan näkökulma... 19 6.4.2 Järjestelmien näkökulma... 20 7 Palveluarkkitehtuuri... 20 7.1 Periaatteet palveluille...20 7.2 Palveluarkkitehtuuri osat...22 7.3 Palveluarkkitehtuurin osat ja luokittelu...23 7.4 Palvelukartta...24 8 Tietojärjestelmäarkkitehtuuri... 25 ii (3)
8.1 Johdanto...25 8.2 Järjestelmäkartta loogisella tasolla...26 8.3 Uudet tietojärjestelmät...27 9 Tekninen arkkitehtuuri... 28 9.1 Teknisen arkkitehtuuri periaatteet...28 9.2 Looginen arkkitehtuuri...29 9.3 Teknologiasalkku...29 10 Arkkitehtuurivaihtoehdot... 31 10.1 Johdanto...31 10.2 Vaihtoehto 1 Keskitetty malli...33 10.3 Vaihtoehto 2 hajautettu arkkitehtuuri...37 10.4 Vaihtoehto 3 Ohjatusti hajautettu arkkitehtuuri...40 11 Suositus... 44 11.1 Peruslinjaus...44 11.2 Saini- verkkopalvelu...44 11.3 Sektori-kohtaiset palvelut...44 11.4 Muita linjauksia...44 11.5 Jatkotehtäviä...45 12 Lähteet... 46 iii (3)
1 JOHDANTO 1.1 Taustaksi 1.2 Tavoitteet Tässä dokumentissa linjataan uusien monikanavaisten terveydenhuollon palvelujen teknisiä ratkaisuja. Saini-arkkitehtuuri määrittää yhteiset periaatteet kehitettäville tietopalveluille, sähköisen asioinnin ja interaktiivisten verkkopalveluiden järjestelmille. Dokumentti kuvaa tavoitearkkitehtuurin, joka on tarkoitettu kaikille terveydenhuollon verkkopalvelujen toteuttajille. Määrityksen painopiste on yhteiskäyttöisyyden kannalta keskeisimmissä arkkitehtuurin osa-alueissa, mutta dokumentti toimii myös Saini-palvelujen kokonaisarkkitehtuurin kuvauksena. Tämän dokumentin lopussa esitellään kolme vaihtoehtoista arkkitehtuurin periaateratkaisua ja arvioidaan niiden tarjoamia mahdollisuuksia ja rajoituksia. Tavoitetilaa laadittaessa on huomioitu tärkeänä lähtökohtana terveydenhuollon nykyinen IT-arkkitehtuuri ja käynnissä olevat järjestelmähankkeet, joista merkittävin on Kelan kansallisen arkiston toteutusprojekti. Nykytilanteen arkkitehtuurissa huomioonotettavia elementtejä ovat mm.: Potilastiedot ovat lähes 100-prosenttisesti jo sähköisessä muodossa Tiedot ovat hajallaan sadoissa eri tietovarastoissa terveydenhuollon eri organisaatioissa Kunnissa, sairaanhoitopiireissä, yrityksissä ja muissa terveydenhuollon organisaatioissa on käytössä lukuisia web-sivustoja, jotka pääosin sisällönhallintajärjestelmillä ylläpidettyjä terveydenhuollon tietopalveluja Käytössä olevista verkkopalveluista vain harvat on integroitu terveydenhuollon perusjärjestelmiin Käytetyt arkkitehtuuriratkaisut ovat kirjavia eivätkä yhteensopivia. Erilaisista lähinnä internet-pohjaisista sivustoista ja järjestelmistä on käyttökokemusta jo vuosien ajalta, mutta palvelut ovat hajallaan verkossa toisistaan ja taustajärjestelmistä irrallisina toteutuksina. Järjestelmien arkkitehtuurin hajanaisuus, standardien ja avointen rajapintojen puute sekä tekninen yhteensopimattomuus on johtanut työläästi ylläpidettäviin ja kehitettäviin verkkosovelluksiin. Tavoitetilan Saini-arkkitehtuuri pohjautuu prosessi- ja palvelu-kuvauksiin, jotka on kirjattu Saini ratkaisuehdotus dokumenttiin. Saini-arkkitehtuurin tavoitteena on yhtenäistää tulevien sähköisten asioinnin järjestelmien teknisiä ratkaisuja. Standardisoidut ratkaisut merkitsevät kustannussäästöjä järjestelmien suunnittelussa ja toteutuksessa sekä tehostavat varsinkin järjestelmien hallintaa ja ylläpitoa jatkossa. Saini-arkkitehtuuri toimii eri sidosryhmien ja toteutusta suunnittelevien tahojen yhteisenä tavoitetilana ohjaamalla ja koordinoimalla eri osapuolten toimintaa kohti yhtenäistä verkottunutta terveydenhuollon tietojärjestelmien verkkoa, jossa eri järjestelmissä olevia asiakastietoja voidaan hyödyntää kansalaisten palvelemiseksi paremmin ja tehokkaammin. 1 (46)
Palvelukeskeiseen arkkitehtuuriin perustuvat yhteiskäyttöiset yleisosat (esim. ajanvaraus) ja standardit rajapinnat ja tietorakenteet (esim. terveystili) näkyvät viimekädessä myös palveluja käyttäville kansalaisille yhdenmukaisena järjestelmien käytettävyytenä. Laadukkaiden ja monipuolisten palvelujen toteuttaminen edellyttää yleensä verkkopalvelujen integroimista terveydenhuollon perusjärjestelmiin, niiden tietovarastoihin ja toiminnallisuuteen. Kansallinen arkistojärjestelmä tullee jatkossa olemaan yksi keskeinen verkkopalveluja tukeva taustajärjestelmä. 2 ARKKITEHTUURIMENETELMÄ 2.1 Kuvaus arkkitehtuurimenetelmästä Kokonaisarkkitehtuuri menetelmänä sovelletaan Valtiohallinnon arkkitehtuurin suunnittelumenetelmää. Valtiohallinnon arkkitehtuurin suunnittelumenetelmä ei sovellu tähän määrittelyyn ilman soveltamista. Valtionhallinnon arkkitehtuurimenetelmä on suunniteltu käytettäväksi valtionhallinnossa ja tämä määrittely koskee myös kuntien, yksityisen puolen sekä kolmannen sektorin toimijoita. Tämän lisäksi on syytä keskittyä tämän määrittelyn kannalta tärkeimpiin osa-alueisiin. Valtiohallinnon arkkitehtuurin suunnittelumenetelmä sisältää kolme kuvaustasoa ja neljä arkkitehtuurinäkökulmaa. Tässä määrittelyssä on keskitytty ainoastaan kokonaisuuden kuvaustasolle. Tarkempien kuvausten tekeminen on jatkoprojektien vastuulla ja tämä tavoitetilan kuvaus sisältää vain ylätason linjaukset. Suunnittelumenetelmässä määritellyt kolme kuvaustasoa ovat Julkishallinta / kokonaisuus Klusteri / kohdealue Virasto / osa-alue. Tässä arkkitehtuurikuvauksessa on päädytty myös kolmeen toiminnantasoon, jotka ovat Kansallinen Sektori Organisaatio. Suunnittelumenetelmässä määritellyt neljä arkkitehtuurinäkökulmaa ovat toiminta-, tieto-, tietojärjestelmä- ja tekninen arkkitehtuuri. Valtiohallinnon arkkitehtuurin suunnittelumenetelmässä kuvattujen neljän arkkitehtuurinäkökulman lisäksi tähän projektiin on otettu lisäksi palvelunäkökulma ja tietoturvanäkökulma. Tietoturva on valittu omaksi näkökulmakseen sen vuoksi, että terveydenhuollossa tietoturva ja tietosuoja ovat erityisen tärkeitä. Kuvaamalla tietoturva-arkkitehtuuri erikseen on saatu kuvattua paremmin kokonaisuuden tietoturvaratkaisut. Palvelunäkökulma on kuvattu sen vuoksi, että arkkitehtuurin lähtökohdaksi on valittu palvelukeskeinen arkkitehtuuri ja sen kuvaaminen muilla näkökulmilla ei olisi ollut riittävän kattava. Suosituksena on, että verkkopalveluja kehitettäessä hyödynnetään Valtiohallinnon arkkitehtuurin suunnittelumenetelmää. 2 (46)
Saini-arkkitehtuuri perustuu palveluarkkitehtuurin (SOA) periaatteisiin. Palveluarkkitehtuurin suunnittelussa on sovellettu WM-datan palveluarkkitehtuurimenetelmää sekä yleisiä palveluarkkitehtuurien suunnittelukäytäntöjä. WM-datan palveluarkkitehtuurimenetelmän näkökulma lähtee kokonaisarkkitehtuurista ja ottaa holistisen toimintalähtöisen näkökulman palveluarkkitehtuuriin. Palveluarkkitehtuurimenetelmän lähtökohtana on katsoa kokonaisuutta palveluorientoituneesti ja pyrkiä ottamaan palvelunäkökulma kaikissa arkkitehtuurin näkökulmissa. 3 ARKKITEHTUURIN LÄHTÖKOHDAT 3.1 Reunaehdot ja periaatteet Arkkitehtuurimäärittelyn aikana on tunnistettu tässä kohdassa esitetyt reunaehdot. Määrittely on tehty näiden reunaehtojen sisällä, ellei toisin ole mainittu. Arkkitehtuurin määrittelyssä on huomioitu ValtIT:n arkkitehtuurinsuunnittelu menetelmässä kuvatut reunaehdot. Käytännössä tämä tarkoittaa etenkin saman terminologian käyttöä, arkkitehtuurin kuvauksen jaottelua kyseisen ohjeen mukaisesti sekä samojen periaatteiden käyttämistä. Arkkitehtuurin suunnittelussa on huomioitu alla listatut viranomaissuositukset ja ohjeet. Poikkeamista on mainittu erikseen. Valtionhallinnon tietoturvallisuus VAHTI http://www.vm.fi/vm/fi/04_julkaisut_ja_asiakirjat/01_julkaisut/05_valtionhallinnon_tietoturvallisuus/index.jsp JHS 129 Julkishallinnon verkkopalvelun suunnittelun ja toteuttamisen periaatteet http://www.jhssuositukset.fi/suomi/jhs129 JHS 129 Liite 5: Julkiset verkkopalvelut ja lainsäädäntö http://www.jhssuositukset.fi/intermin/hankkeet/jhs/home.nsf/pages/31a162b71b ED9C19C22570350047C6E6 VM: Sähköinen asiointi - Muistioita ja ohjeita http://www.vm.fi/vm/fi/13_hallinnon_kehittamnen/05_sahkoinen_asiointi/02_muistiot_ja_ohjeet/index.jsp Verkkopalvelujen esteettömyys http://www.tieke.fi/tuotteet_ja_palvelut/esteettomyys VM: Julkishallinnon lomakkeita ja sähköisiä asiointipalveluita, terveydenhuollon sektori: http://www.suomi.fi/suomifi/suomi/asiointi_ja_lomakkeet/?topicid=62 Arkkitehtuurin suunnittelussa on huomioitu seuraavien lakien ja asetusten vaatimukset. Kuvattu arkkitehtuuri seuraa kaikkia alla listattuja lakeja ja asetuksia. Directive 95/46/EC of the European Parliament and of the Council of 24 October 1995 on the protection of individuals with regard to the processing of personal data and on the free movement of such data Suomen perustuslaki (731/1999) Potilaslaki (785/1992) Laki sosiaalihuollon asiakkaan asemasta ja oikeuksista (812/2000) Sähköisen viestinnän tietosuojalaki (516/2004) Laki viranomaisten toiminnan julkisuudesta (621/1999) Arkistolaki (831/1994) 3 (46)
Henkilötietolaki (523/1999) Laki yksityisyyden suojasta työelämässä (759/2004) Viestintämarkkinalaki (393/2003) Rikoslaki 38 luku ja 34 luvun 9a pykälä Laki eräiden suojausten purkujärjestelmien kieltämisestä (1117/2001) Laki tietoyhteiskunnan palvelujen tarjoamisesta (458/2002) Laki sähköisestä asioinnista viranomaistoiminnassa (13/2003) Laki sähköisestä allekirjoituksesta (14/2003) Laki potilaan asemasta ja oikeuksista (785/1992) Sähköinen lääkemääräys (61/2007) Sosiaali- ja terveydenhuollon asiakastietojen sähköinen käsittely (159/2007) 3.2 Arkkitehtuuri- ja teknologiatrendit Tavoitetilan arkkitehtuurin kuvaamisessa on huomioitu tämän hetkiset arkkitehtuuri- ja teknologiatrendit. Näistä on pyritty parhaisiin käytäntöihin nojautuen valitsemaan ne, jotka tukevat parhaiten järjestelmän toiminnallisuutta. Trendit on selvitetty haastattelujen avulla sekä hyödyntäen eri tutkimuslaitosten raportteja (Gartner, Forrester ja Ovum). Tämän hetken tärkein trendi arkkitehtuurisesti sekä teknisesti on SOA (Service Oriented Architecture) eli palvelukeskeinen arkkitehtuuri. Palvelukeskeinen arkkitehtuuri tarkoittaa tietojärjestelmien toiminnallisuuden esittämistä palvelulähtöisesti ja näiden palveluiden hyödyntämistä uusien IT järjestelmien toteuttamisessa. Tällä hetkellä merkittävä osa organisaatioista on siirtymässä kohti palvelukeskeistä arkkitehtuuria ja käytännössä kaikki merkittävät järjestelmätoimittajat tukevat palvelukeskeistä arkkitehtuuria. Palvelukeskeisen arkkitehtuurin on todettu tuottavan organisaatiolle hyötyjä ja tarjoavan useissa tilanteissa toimivan arkkitehtuurimallin. Palvelukeskeisen arkkitehtuurin hyödyntämisestä terveydenhuollossa on käsitelty esityksissä Rajapinta- ja arkkitehtuuripohjaa joustaville ja liitettäville sovelluksille [SERYHT] ja Ydinprosessit ja ydinpalvelut. Hoitoprosessit sujuviksi osastojärjestelmien SOA-integraatioilla [YDIN]. Palvelukeskeiseen arkkitehtuuriin liittyy ns. Software-as-a-Service (SaaS) -malli tietojärjestelmien toimittamisessa. Tässä mallissa ohjelmiston toimittaja toteuttaa ratkaisun ja tarjoaa sen palveluna käyttäville organisaatioille yleensä Internetin ylitse. SaaS on terminä korvannut ASP- (Application Service Provider), On-Demand- ja Utility Computingtermit. Verkkojärjestelmissä tällä hetkellä trendinä on ns. Web 2.0 järjestelmät, jotka usein liitetään myös semanttisen webin kehitykseen. Itsessään termiä Web 2.0 ei ole tarkalleen määritelty, mutta sen mukaiset järjestelmät omaavat usein seuraavat ominaisuudet ([SOFTEV]): Tekniset Ajax Asynchronous Javascript And XML. Teknogia jolla voidaan toteuttaa käytettävämpiä verkkosovelluksia, pohjautuu XML teknologioihin ja Javascriptiin. RSS - Rich Site Summary. Teknologia joka mahdollistaa tiedon jakamisen eri verkkopalveluille tai käyttäjille, käytetään etenkin uutissivustoilla tai vastaavilla sivuistoilla. 4 (46)
Mashups. Tapa rakentaa sovelluksia, jotka koostuvat useista eri palveluista, verrattavissa portaaleihin. REST - Representational State Transfer. Ohjelmistoarkkitehtuuri tyyli, jota käytetään WWW-pohjaisissa järjestelmissä, Roy Fielding on kuvannut tämän termin tarkemmin Architectural Styles and the Design of Network-based Software Architectures artikkelissaan [REST]. Ei-tekniset Yksinkertaisuus Käyttäjien tuottama sisältö Hajautettu Avoin Käyttäjälähtöinen meta-data Osallistuminen. Web 2.0 verkkopalvelu normaalisti sisältää seuraavat ominaisuudet Palvelu toimii täysin WWW-selaimen kautta Käyttäjät omistavat datan/sisällön ja hallitsevat sitä palvelun kautta Arkkitehtuuri joka sallii käyttäjien laajentaa palvelua Rikas web-käyttöliittymä (Rich Internet Application, RIA) Lähtökohtana on usein yhteisöllisyys. RIA-sovellukset (Rich Internet Application) tarkoittavat WWW-sovelluksia, jotka hyödytävät esimerkiksi AJAX-tekniikkaa, jonka avulla ne pystyvät tarjoamaan vastaavan käyttökokemuksen kuin perinteiset työpöytäsovellukset. Arkkitehtuurisesti RIA-sovellukset toimivat siten, että data välitetään palvelimelta WWW-selaimelle ja toiminnallisuudesta merkittävä osa tapahtuu WWW-selaimella. Perinteisissä WWW-sovelluksissa toiminta tapahtui palvelimella, joka sai tarvittavan datan sekä pyynnön tehdä sille tietty toiminnallisuus. Verkkosovellusten suhteen uusi kehitystrendi on ns. Mashup järjestelmät. Nämä hyödyntävät usean eri verkkopalvelun tarjoamia palveluita ja tuottavat tällä tavalla uuden koostetun palvelun. Mashup ei ole sama kuin portaali. Kummankin ratkaisun tehtävänä on yhdistää tietoa useista eri lähteistä, vaikka lähestymistapa on hieman erilainen. Mashup-ratkaisuissa tieto yhdistetään usein selaimessa RIA-sovelluksien tapaan eikä palvelimella kuten portaaleissa. Open Source -pohjaiset järjestelmät ovat yleistyneet merkittävästi viimeisten viiden vuoden aikana. Aikaisemmin Open Source -järjestelmiä käytettiin lähinnä tukijärjestelminä, mutta yhä enemmän niitä käytetään myös muissa rooleissa. Avoin lähdekoodi on yleistynyt etenkin julkisten verkkojärjestelmien teknologisena alustana. Open Source -termille on useita määritelmiä, mutta yleisimmin käytetty on Open Source Initiativen määritelmä, joka määrittelee että Open Source -ohjelmistojen pitää täyttää seuraavat vaatimukset ([OPENIN]) Vapaa levitys Lähdekoodi on saatavilla Lisenssi sallii johdannaistyöt Alkuperäisen toteuttajan koodin eheys 5 (46)
Lisenssi ei saa syrjiä henkilöitä tai henkilöryhmiä Lisenssi ei saa estää ohjelmiston käyttöä tietyillä toimialoilla Lisenssi on mahdollista levittää Lisenssi ei saa olla ohjelmakohtainen Lisenssi ei saa rajoittaa muiden ohjelmistojen käyttöä Lisenssi ei saa olla teknologiariippuvainen. Open Source pohjaisuus voidaan nähdä kahdelta eri näkökulmalta. Toisaalta se on lisenssointimalli, joka antaa ohjelmiston käyttäjälle tietyt vapaudet ja toisaalta se voidaan nähdä ohjelmistotuotantotapana, jossa ohjelmiston toteuttaa sitä käyttävä yhteisö. Open Source tarjoaa sitä käyttäville organisaatioille enemmän vapauksia kuin perinteiset lisenssointimallit ja useissa tilanteissa se voi tuoda selkeitä etuja ja on siten syytä huomioida toteutusvaihtoehtoja määriteltäessä. Organisaatioiden ottaessa käyttöön SOA -arkkitehtuuria on usein törmätty ongelmiin tiedon omistajuuden ja hallinnan suhteen. Kun eri palvelut käsittelevät samaa tietoa tai tieto on liian syvällä tietojärjestelmässä, on tiedonhallinta haasteellista. Tähän on ratkaisuna ehdotettu Information-as-a-Service (IaaS) lähestymistapaa, jossa tietovarastoja käytetään palvelurajapintojen kautta. Merkittävänä trendinä on vielä organisaatioiden käsittelemän tiedon määrän kasvu. Organisaatioiden sisällä tiedon määrä kasvaa vuosittain noin 50 %. Tämä aiheuttaa yhä enemmän tarpeita tiedon elinkaaren hallintaan, tiedon löytämiseen sekä tiedon käsittelyyn. Suosituksena on että kuvatuista trendeistä hyödynnetään SOA- ja IaaSarkkitehtuureja sekä Web 2.0 -teknologioita. Open Source ratkaisut tulee huomioida valittaessa ratkaisualustoja. 6 (46)
4 TOIMINTA-ARKKITEHTUURI Liiketoiminta-arkkitehtuuri on muiden osa-arkkitehtuurien perusta ja lähtökohta. Seuraavassa kuvassa on yhteenveto Saini-ratkaisukuvauksesta. Kuva 1 SAINI-palvelut 5 TIETOARKKITEHTUURI 5.1 Johdanto Tietoarkkitehtuurin tärkeä perusta on Saini-sanasto, joka määrittelee kokonaisuuden kannalta keskeiset termit helpottaen kommunikointia eri sidosryhmien kesken. Selkeä yhteinen ydinsanasto on välttämätön tavoitetilan arkkitehtuurin toteutuksessa, koska monet asiat ovat uusia ja niihin liittyvät termit eivät ole vielä vakiintuneet käyttöön. Sainisanasto on kuvattu ratkaisukuvaus-dokumentissa. Tietoarkkitehtuuri on tärkeä osa-arkkitehtuuri Saini- toteutuksen kannalta. Suurin osa sähköisistä palveluista liittyy tiedon esittämiseen asiakkaalle tai tiedon käsittelyyn. Nykytilan tietoarkkitehtuurissa tiedot ovat hajaantuneet useisiin eri tietojärjestelmiin ja käyttö yli organisaatiorajojen on monissa tilanteissa hankalaa. Terveydenhuollossa on laadittu varsin kattavasti standardit eri asiakirjoille, mutta jalkautus eri tietojärjestelmätoimittajien tuotteisiin on vielä kesken. Tietojen siirtäminen tietojärjestelmien välillä on edelleenkin hankalaa ja työlästä. Merkittävin uusi käsite tietoarkkitehtuurissa on Personal Health Record eli terveystili, joka on kuvattu Saini ratkaisukuvauksessa. Tämän käsitteen suhdetta muihin käsitteisiin, sen sijaintia tietovarastoissa sekä siihen liittyviä arkkitehtuurihaasteita käsitellään tämän luvun alakohdissa. 7 (46)
5.2 Tietoarkkitehtuurin periaatteet Tietoarkkitehtuurin periaatteet on johdettu toiminnallisesta arkkitehtuurista, Sainiprojektin reunaehdoista sekä yleisistä arkkitehtuurin periaatteista. Periaatteiden tarkoituksena on tukea mahdollisimman kustannustehokkaan, käytettävän ja toimivan tietoarkkitehtuurin toteutumista. Jokaiselle tiedolle pitää olla aina omistaja, joka vastaa sen laadusta ja oikeellisuudesta. Lähtökohtana on että, siirrettäessä tietoa eri järjestelmien välillä sen omistajuus ei vaihdu, vaan alkuperäinen tiedon tuottaja vastaa sen oikeellisuudesta. Tämä on erityisen tärkeää terveystilin suhteen. Tiedon alkuperäinen tuottaja allekirjoittaa tiedon, jotta myöhemmin voidaan varmistaa sen alkuperäinen tuottaja sekä sen eheys. Tiedon allekirjoittaminen on tarkemmin kuvattu tietoturva-arkkitehtuuri -kappaleessa. Tiedon allekirjoittamisella tavoitellaan sitä että myöhemmässä vaiheessa kopioidusta tiedosta voidaan varmistaa sen muuttumattomuus. Verkkopalvelun kannalta periaate tarkoittaa, että verkkopalvelu luottaa tiedon tuottajiin, jos tieto on allekirjoitettu luotetulla sertifikaatilla. Verkkopalvelu ei pyri enää varmistamaan tiedon sisältöä, kun se on kerran tuotettu verkkopalveluun. Jos tarkistus halutaan tehdä virallisen tiedon osalta, niin tällöin se voidaan tarkistaa kansallisesta arkistosta. Eräs suurimmista haasteista käyttäjien kannalta on tiedon pirstaloituminen eri palveluihin sekä vaikeus tiedon siirtämiseen eri tietojärjestelmien välillä. Jotta tiedon siirto terveystilille sekä siitä muihin järjestelmiin olisi yksinkertaista suositellaan, että tieto siirretään rakenteisina asiakirjoina. Jotta yhteentoimivuus eri verkkopalvelujen välillä voidaan varmistaa, rakenteisten asiakirjojen on noudatettava yleisesti käytössä olevia standardeja. Kansalaisen kannalta olennainen tieto on tällä hetkellä useissa eri tietojärjestelmissä, joiden tulee jatkossa tukea kansalaisen tietojen siirrettävyyttä kunkin kansalaisen oman terveystilin kautta verkkopalveluissa käytettäväksi. Näiden tietojen siirto mahdollisimman pienin kustannuksin ja ilman vaativia muutoksia nykyisiin tietovarastoihin edellyttää tukeutumista standardi tietomuotoihin ja jo vakiintuneisiin käytäntöihin. Suosituksena on käyttää Suomen HL7 -yhdistyksen standardoimia rakenteisia asiakirja- ja viestimuotoja. 8 (46)
5.3 Tiedon luokittelu Karkealla tasolla verkkopalveluiden tiedot voidaan jakaa kahteen pääryhmään ja nämä kaksi pääryhmää kahteen aliryhmään. Tiedon pääryhmät verkkopalveluissa ovat informatiivinen ja henkilökohtainen tieto. Informatiivinen tieto tarkoittaa tietoa, joka sisältää ohjeita, artikkeleja, suosituksia, tietoa lääkkeistä tai sairauksista sekä muita vastaavia tietoja. Henkilökohtainen tieto taas sisältää viralliset potilasasiakirjat, henkilön itse syöttämät tiedot omasta terveydestään, henkilön perustiedot, ajanvaraustiedot sekä muut vastaavat tiedot. Henkilökohtainen tieto on aina luottamuksellista ja sen käsittelyä ohjataan lailla ja asetuksilla. Kuva 2 Tiedon luokittelu Karkealla tasolla verkkopalveluiden tiedot voidaan jakaa kahteen pääryhmään ja nämä kaksi pääryhmää kahteen aliryhmään. Tiedon pääryhmät verkkopalveluissa ovat informatiivinen ja henkilökohtainen tieto. Informatiivinen tieto tarkoittaa tietoa, joka sisältää ohjeita, artikkeleja, suosituksia, tietoa lääkkeistä tai sairauksista, mutta myös tietoa palveluista ja niiden käytöstä. Henkilökohtainen tieto taas sisältää viralliset potilasasiakirjat, henkilön itse syöttämät tiedot omasta terveydestään, henkilön perustiedot, ajanvaraustiedot sekä muut vastaavat tiedot. Henkilökohtainen tieto on aina luottamuksellista ja sen käsittelyä ohjataan lailla ja asetuksilla. Informatiivinen tieto voidaan jakaa karkeasti kahteen eri osaan. Toisaalta on yleinen informatiivinen tieto, jota ei ole kohdennettu tiettyihin asiakkaisiin, vaan on tarkoitettu kaikkien asiakkaiden käyttöön. Kontekstisidonnainen informatiivinen tieto taas sisältää tiedon siitä kenelle se on tarkoitettu. Konteksti voi olla tällöin asuinkunta, elämäntilanne, sairaudet sekä vastaavat tiedot. Jotta kontekstisidonnaista tietoa voidaan hyödyntää, pitää järjestelmällä olla tietoa asiakkaasta (elämäntilanteesta, sairauksista, jne). Nämä tiedot ovat luottamuksellisia, jolloin kontekstisidonnaisten tietojen käsittelyssä on huomioitava asiakkaan yksityisyyden suoja. Henkilökohtaiset tiedot voidaan jakaa kahteen aliryhmään niiden lähteiden pohjalta; viralliset asiakirjat ja itse kirjattu tieto. Viralliset asiakirjat ovat virallisia potilasasiakirjoja, tietoja potilastietojärjestelmistä sekä vastaavia tietoja, joita terveydenhuollon ammattihenkilöt käyttävät työssään. Itse kirjattu tieto on kansalaisen itse syöttämää tietoa omasta terveydestään. Itse kirjattu tieto voidaan edelleen jakaa kahteen pääryhmään, objektiivisiin tietoihin ja subjektiivisiin tietoihin. Objektiiviset tiedot tulevat suoraan tiedonkeruulaitteesta (verenpainemittari tms.) ja henkilöiden subjektiiviset näkemykset eivät vai- 9 (46)
5.4 Päätietoryhmät kuta niihin. Subjektiiviset tiedot ovat taas henkilöiden havaintoja ja huomioita esimerkiksi oireista ja toipumisesta itse syöttämiä. Tiedon käytössä suositaan objektiivista tietoa. Nykytilassa suurin osa verkkopalveluista keskittyy tarjoamaan yleistä informatiivista tietoa ja vähemmän käyttäjään suoraan liittyvää tietoa. Tämä informatiivinen tieto tuotetaan usein verkkopalvelusta vastaavan organisaation toimesta. Tavoitetilassa yleisen informatiivisen tiedon tulee olla laajasti yhteiskäyttöistä, mikä edellyttää, että tietosisällöt ovat helposti jaettavissa. Informatiivista tietoa tuottavat useat eri tahot, terveydenhuollon eri organisaatiot, lääketeollisuus, yritykset, viranomaiset, kolmas sektori jne. Tietojen yhteiskäyttö on tällä hetkellä enemmän satunnaista kuin järjestelmällisesti koordinoitua. Tavoitetilassa tietosisällön tuottamisesta ja ylläpidosta vastaa luotettu taho ja tietoa tarjotaan tehokkaasti yhteiskäyttöön. Saini- ratkaisukuvauksesta voidaan johtaa verkkopalvelun päätietoryhmät, jotka ovat seuraavat: Ajanvaraus Asiakkaan perustiedot Informatiivinen tieto Lokitiedot Lääkehoitotiedot Lääketiedot Oirepäiväkirja Omahoitotiedot Palvelun tuottajan tiedot Terveyskortti Valtuutus (katselu- ja kirjoitusoikeuden myöntäminen) Viestintätiedot Viralliset potilasasiakirjat Seuraavassa on kuvattu nämä tietoryhmät. Ajanvaraus- tietoryhmä sisältää ajanvaraukseen liittyvät tiedot. Ajanvaraustiedon omistaa se organisaatio, johon ajanvarauspalvelu liittyy. Jotta kansalaiselle voitaisiin tarjota yleinen ajanvarauspalvelu, on verkkopalvelutasolla oltava yhtenäinen tietosisältö ja tietojen esitystapa. Suosituksena on että ajanvarauksen tietojen osalta käytetään yhteisenä tietomallina terveydenhuollon ajanvarauksen esiselvityksen Liite 2:ssa kuvattua tietomallia ([STMAV]). Asiakkaan perustiedot sisältävät esimerkiksi yksilöivän tunnisteen, nimen, osoitteen, asuinkunnan, äidinkielen, syntymäajan, sukupuolen sekä vastaavat tiedot. (Kuvattu tarkemmin ydintiedoissa.) Verkkopalvelutasolla tämä tieto on oltava yhtenäinen. Tämän tiedon omistaa kansalainen asiakkaan perustiedoista vastaava organisaatio tai jos asiakas on itse nämä syöttänyt, niin asiakas. 10 (46)
Suosituksena on, että perustietojen osalta seurataan Ydintietomäärittelyä ([YDIN- TIE]). Informatiivinen tieto on yleistä terveyttä edistävää tietoa esimerkiksi terveellisistä elämäntavoista tai määrättyyn kontekstiin liittyvää esimerkiksi sairauskohtaista tietoa. Tätä tietoa tuottavat esimerkiksi Kansanterveyslaitos ja Duodecim. Informatiivisen tiedon omistaa sen tuottanut taho, joka vastaa myös sen oikeellisuudesta. Tätä tietosisältöä ei ole tärkeää harmonisoida, mutta rakenne on syytä yhtenäistää, jotta samaa informatiivista tietoa voitaisiin hyödyntää useissa eri verkkopalveluissa. Suosituksena on seurata KTL:n tervesuomi.fi portaaliin kehittämää tiedon rakennetta, jota eri sisällöntuottajat hyödyntävät jo nyt. Lokitiedot tarkoittavat tässä yhteydessä järjestelmän tietojen käytöstä keräämää lokitietoa, joka on tarkoitettu kansalaiselle.asiakkaalle. Lokitiedot eivät tässä siis tarkoita viranomaisille, palveluntarjoajille tai teknisille vastuuhenkilöille tarkoitettuja lokitietoja. Lokitiedot sisältävät mm. tiedon siitä, ketkä ovat katsoneet asiakkaan tietoja ja mitä palveluita asiakas itse on käyttänyt. Kukin kansalainen omistaa omat lokitietonsa. Palvelun sisällä lokitietojen sisältö on oltava yhdenmukainen. Suosituksena on, että lokitiedoille määritellään yhteinen tietomalli. Lääkehoitotiedot tarkoittavat tässä kohtaa lääkemääräyksiä, lääketoimitustietoja sekä niihin liittyviä tietoja. Lääkehoitotietojen rakenteena suositellaan käytettäväksi Suomen HL7 yhdistyksen standardoimaa CDA R2 rakennetta (Open CDA2007 -Lääkemääräyksen CDA R2 rakenne v.2.0). Terveystilillä olevat lääkehoitotiedot omistaa kansalainen, koska hän voi itse täydentää niitä muillakin kuin reseptitiedoilla. Reseptin lääkehoitotiedot tulevat kansallisesta eresepti palvelusta. Palvelussa erotetaan selkeästi viralliset lääkehoitotiedot itse kirjatuista lääkehoitotiedoista. Lääketiedot ovat tarkoittavat tietoa lääkkeistä kansalaiselle, niiden vaikutuksista sekä esimerkiksi tiedotuksia lääkkeisiin liittyen. Lääketiedot ovat käytännössä informatiivisen tiedon erikoistapaus, mutta niiden oikeellisuuteen liittyy suurempi vastuu kuin useisiin muihin informatiivisiin tietoihin. Tämän vuoksi niitä on syytä käsitellä erikoistapauksena. Lääketiedot omistaa organisaatio, joka on tuottanut lääketiedot. Oirepäiväkirja sisältää käyttäjän itse ylläpitämää vapaamuotoista tietoa. Oirepäiväkirjan on yksi terveystilipalvelu, jota voi täydentää tai jonka voi korvata erillisellä omahoitosovelluksella Oirepäiväkirjan tietorakenne on kuvattava yleisellä tasolla yhteensopivuuden takia. Toisin kuin omahoitotiedot oirepäiväkirja on pääasiassa subjektiivista itse kirjattua tietoa. Omahoitotiedot ovat kansalaisen itse ylläpitämää rakenteista tietoa, joka liittyy tiettyyn sairauteen tai terveyden ylläpitoon. Tiedot liittyvät läheisesti omahoitosovellukseen ja sen toiminnallisuuteen. Nämä tiedot omistaa kansalainen, joka on ne tuottanut. Näiden tietojen rakenne on standardoitava, jotta tietojen jakaminen palvelujen välillä on mahdollista. Palvelun tuottajan tiedot sisältävät tiedot organisaatioista, jotka tarjoavat terveydenhuollon palveluita kansalaiselle. Katso ydintietomäärityskäyttäjille. 11 (46)
Suosituksena on käyttää palvelun antajan tiedoista Ydintietomäärityksen mukaisia tietoja. Terveyskortti sisältää kansalaisen kannalta tärkeät terveydenhuoltoon liittyvät (mm. potilaskertomus) asiakirjat sekä muut tiedot. Terveyskortti on yläkäsite, joka sisältää mm. oirepäiväkirjan ja omahoitotiedot. Terveyskortin tietorakenne pitää standardoida, jotta terveyskortin siirtäminen järjestelmien välillä on mahdollista. Valtuutustiedot sisältävät kansalaisen tekemät valtuutukset muille henkilöille ja organisaatioille koskien oman terveystilinsä käyttöä. Valtuutukset ovat osa terveyskorttia. Tämän tiedon omistaa käyttäjä. Viestintätiedot sisältävät viestit kansalaisen ja palveluiden tarjoajien välillä. Nämä tiedot omistaa kansalainen ja palvelun tarjoajat. Viralliset potilasasiakirjat tarkoittavat tässä potilastietojärjestelmissä kansallisessa arkistossa olevien terveydenhuollon ammattihenkilöiden tekemiä potilasasiakirjoja, jotka on tarkoitettu etenkin ammattihenkilöille. Nämä potilasasiakirjat ovat käyttäjien saatavilla jatkossa kansalliseen arkistoon liittyvien verkkopalveluiden kautta. Virallinen potilaskertomustieto on kansallisessa arkistossa. Virallinen tieto on aina ammattilaisen potilasjärjestelmään kirjaamaa tietoa. Mikäli SAINI-palveluiden terveystilipalveluihin kertynyttä - potilaan itse kirjaamaa tietoa - halutaan viedä arkistoon, terveydenhuollon ammattilainen kirjaa sen potilasjärjestelmään, josta se tallentuu myös arkistoon Virallisten potilasasiakirjojen osalta verkkopalvelussa suositetaan noudatettavan kansallisen arkiston määrittelemiä standardeja sekä Kuntaliiton johdolla laadittuja ydintietomäärityksiä. ([YDINTIE]) Ydintiedot kattavat potilaskertomuksen keskeisimmät rakenteiset tiedot ([YDINTIE]), jotka tukevat potilaiden hoitoa, raportointia ja palveluprosessia sekä hoidon ja tutkimuksen laadun kehittämistä. Määritysten mukaisesti on sovittu tietojen vakio tallennusmuoto, jonka ansiosta tietoa pystytään siirtämään eri järjestelmien välillä ja sovellukset pystyvät hyödyntämään niitä sellaisenaan. Määrityksissä on sovittu tiedoista, niissä käytetyistä luokituksista sekä semantiikasta. Käytettävät luokitukset on koottu koodistopalvelimelle (http://sty.stakes.fi/fi/koodistopalvelu/koodisto.htm). Ydintietojen määritystyössä sovitaan myös käytettävistä näyttömuodoista, otsikoista ja teknisestä rakenteesta kansainvälisen HL7 CDA R2-standardin mukaisesti. Ydintietomääritysten lisäksi on tehty spesifisiä rakenteisten tietojen määrityksiä suun terveydenhuollossa, työterveyshuollossa, äitiyshuollossa, ensihoidossa ja päivystyksessä, psykiatriassa, lasten ja nuorten kasvun ja kehityksen seurannassa sekä muutamissa keskeisissä kansantaudeissa. Sähköisen potilaskertomuksen ydintietojen määrittelytyötä on tehty Suomen Kuntaliiton johdolla. Kuopion yliopiston, KYS:n ja Duodecimin asiantuntijoita on ollut mukana määrittelytyön projektiryhmässä. Tietoa kansallisen terveyshankkeen sähköisen potilaskertomuksen muista osahankkeista saa sosiaali- ja terveysministeriön sivuilta www.stm.fi. 12 (46)
5.5 Tietovarastot Arkkitehtuurin nykytilan kuvauksessa on kuvattu nyt käytössä olevia tietovarastoja. Alla on listattu tavoitetilassa tärkeimmät tietovarastot. Duodecim terveyskirjasto Käytössä oleva tietovarasto Validoitu tietopalvelu Vastuu: Duodecim eresepti Toteutuksessa oleva tietovarasto Vastuu: KELA Kansallinen arkisto Toteutuksessa oleva tietovarasto Tekninen vastuu: KELA Koodistopalvelu Olemassa oleva tietovarasto Vastuu: STAKES / KELA Lokipalvelu Uusi tietovarasto Pharmaca Fennica Olemassa oleva tietovarasto Vastuu: Lääketietokeskus Potilastietojärjestelmät Olemassa olevia tietovarastoja Vastuu: Terveydenhuollon organisaatiot Saavutettavuustiedot Suunnitteilla oleva järjestelmä Tervesuomi.fi Olemassa oleva tietovarasto Validoitu tietopalvelu Vastuu: Kansaterveyslaitos Terveystili Uusi tietovarasto Väestötietojärjestelmä Olemassa oleva tietovarasto Vastuu: Väestörekisterikeskus 13 (46)
Kuva 3 esittää päätietoryhmien tietojen alustavaa sijaintia em. tietovarastoissa. 5.6 Muita suosituksia Kuva 3 Päätietoryhmät tietovarastot Kuvassa harmaalla merkityt kohdat ovat kopioita tiedoista. Vihreällä pohjalla olevat merkit tarkoittavat että kyseinen tietovarasto on master kyseisen tiedon osalta. Tällä hetkellä suurin haaste tietoarkkitehtuurin kannalta on nykyisen tiedon käytettävyys. Tieto on hajaantunut useisiin tietovarastoihin ja yhteisen kuvan saaminen on usein erittäin hankalaa. Suositus on, että SAINI-tiedot taltioidaan mahdollisimman keskitettyihin tietovarastoihin. Tiedon tarpeetonta kopiointia ja hajauttamista tulee välttää. 14 (46)
6 TIETOTURVA-ARKKITEHTUURI 6.1 Jaottelu yleisesti Tietoturvallisuuden kehikkona käytetään tässä arkkitehtuurissa jaottelua: 1. sähköinen allekirjoitus (digital signature) 2. tiedon salaaminen (encryption) 3. tunnistaminen ja todentaminen (identification and authentication) 4. käyttövaltuushallinta (identity management) 5. pääsynvalvonta (authorization / access control) 6. jälkikäteinen valvonta (auditing / accounting) Kuva 4 Tietoturvan osa-alueet Sähköinen allekirjoitus mahdollistaa kaksi erilaista toiminnallisuutta. Henkilöön sidottu kehittynyt sähköinen allekirjoitus mahdollistaa lainvoimaista omakätistä allekirjoitusta vaativien prosessien sähköistämisen. Teknisenä menetelmänä sähköinen allekirjoitus mahdollistaa tiedon eheyden ja alkuperäisyyden osoittamisen. Tiedon salaaminen on menetelmä, jolla suojaudutaan tiedon päätymiseltä ulkopuolisten tahojen käsiin. Tunnistaminen ja todentaminen ovat tärkeässä osassa terveystili-palveluissa. Käyttäjän luotettava yksilöinti mahdollistaa liittymisen käyttövaltuushallintaan sekä pääsynvalvonnan ja jälkikäteisen valvonnan käytön. Todentamisella varmistutaan yksilöinnin oikeellisuudesta. Käyttövaltuushallinta ja käyttäjähallinta liittyvät läheisesti yhteen. Käyttäjähallinnassa hallitaan käyttäjään liittyviä tietoja, esimerkiksi osoite- ja puhelinnumerotietoja. Käyttövaltuushallinnassa hallitaan käyttäjän oikeuksiin ja oikeuksien elinkaareen liittyviä tietoja. Pääsynvalvonnassa käyttöä rajoitetaan käyttövaltuushallinnassa annettujen oikeuksien perusteella. Jälkikäteisellä valvonnalla seurataan käyttöä ja puututaan epäkohtiin niiden jo tapahduttua. Jälkikäteisen valvonnan päätarkoitus on täydentää muita tietoturvaratkaisuja. 15 (46)
6.2 Yleiset suositukset Asiakkaan sähköisessä asioinnissa todentaminen täytyy toteuttaa luotettavasti ja käytettävyydeltään korkeatasoisesti. Käytettävyyden nimissä tulee huolehtia, että toteutettaessa palveluita hajautetusti, eri toteutukset ovat keskenään yhdenmukaisia. Internet-pohjaisten palveluiden riskitekijät, niiden vaikutukset sekä niiden vastakeinojen vaikutukset tulee ottaa huomioon terveystili-palveluja toteutettaessa. Suosituksena on suorittaa riskianalyysi jo määrittelyvaiheessa eri palveluille. Esimerkiksi palvelunestohyökkäykset voivat estää palvelun käytön kaikilta käyttäjiltä, ja palvelunestohyökkäyksiltä suojautuminen liikennettä rajaamalla voi estää palvelun käytön myös osalta asiakkaista. Virallisten henkilökohtaisten tietojen osalta on huomioitava niiden perusvaatimukset, eli ([TERPKI]) Käyttäjien vahva tunnistaminen (identification/authenfication) Tietojen muuttumattomuus (integrity) Tietoturva (security, access control) Saatavuus (accessibility and availability) Vastuullisuus ja luotettavuus (accountability) Nämä vaatimukset on huomioitava myös itse syötettyjen tietojen osalta, kun niitä siirretään palveluiden välillä. Palveluiden sisällä on huomioitava etenkin käyttäjien vahva tunnistaminen, tietoturva sekä tietojen muuttumattomuus. 6.3 Jaottelu yksityiskohtaisemmin 6.3.1 Sähköinen allekirjoitus Sähköiseen allekirjoitukseen liittyy erilaisia palveluita, joista osa soveltuu keskitetysti toteutettaviksi ja joista osa on syytä toteuttaa hajautetusti. Erilaisia palveluita ovat: asiakkaan sähköinen allekirjoitus järjestelmän sähköinen allekirjoitus sähköisen allekirjoituksen tarkistaminen Asiakkaan sähköinen allekirjoitus on luonteeltaan hajautettu, mutta toteutettavissa myös keskitettynä palveluna. Se soveltuu toteutettavaksi osana samaa keskitettyä palvelua, jossa toteutetaan myös asiakkaan tunnistaminen ja todentaminen. Muut sähköisen allekirjoituksen palvelut ovat toteutettavissa yhden järjestelmän sisäisesti keskitettynä palveluna. Hajautettujen järjestelmien välillä yhteiseksi palveluksi nämä palvelut eivät sovellu, vaan esimerkiksi kahden erillisen järjestelmän kommunikoidessa keskenään sähköisesti allekirjoitetuilla sanomilla, tarvitsevat molemmat osapuolet kyvyn muodostaa ja tarkistaa sähköisiä allekirjoituksia. Julkisen avaimen infrastruktuuriin liittyy keskitettyjä palveluita, kuten sulkulistapalvelu ja aikaleimapalvelu. Sulkulistapalvelua voidaan tehostaa hajautetussa ympäristössä palve- 16 (46)
lun kahdentamisella ja välimuistikäytäntöjen avulla. Aikaleimapalvelun tehostamiseen soveltuu palvelun kahdentaminen, mutta eivät välimuistikäytännöt. Käytettävyyden nimissä tulee huolehtia, että asiakkaan sähköistä allekirjoitusta käytetään vain silloin kun se on todella tarpeen. Asiakkaiden sähköisen allekirjoituksen menetelmänä kansalaisvarmenne on suositeltava menetelmä kun se on laajalti käytössä. Kansalaisvarmenteen levinneisyys ja käyttövalmiudet eivät mahdollista nykyisellään laajaa käyttöä. Kansalaisvarmenteen levinneisyyden ja käyttövalmiuksien kehittäminen julkishallinnon toimesta on suositeltavaa. Suosituksena on että virallisten potilasasiakirjojen suhteen noudatetaan kansallisen arkiston käytäntöjä ja muiden tietojen osalta suositaan järjestelmien sähköistä allekirjoitusta. Tällä hetkellä ei ole edellytyksiä asiakkaiden sähköisille allekirjoituksille. Kun kansalaisille on tarjolle toimivia, laajasti käytössä olevia sähköisen allekirjoituksen palveluita ne otetaan käyttöön. 6.3.2 Tiedon salaaminen Tiedon salaamisen palvelu täytyy toteuttaa hajautetusti niissä järjestelmissä, joissa sitä hyödynnetään. Erillisten järjestelmien tulee hyödyntää paikallisia toteutuksia tiedon salaamisen palveluista. Tietoliikenteessä tiedon salaamismenetelmiä on käytettävä siirrettäessä tietoja palveluiden välillä. Käytettävyys asettaa osalle tietoliikennettä vaatimuksia vasteajan muodossa. Tekninen ympäristö pitää mitoittaa siten, että tiedonsiirron nopeus ei aiheuta käytettävyydelle haittaa. 6.3.3 Tunnistaminen ja todentaminen Täysin hajautettu tunnistaminen, jossa jokaisella järjestelmällä on oma tunnistamismenetelmänsä, on käytettävyydeltään huono, ylläpidollisesti raskas ja tätä kautta myös tietoturvallisuudeltaan heikko ratkaisu. Kehittyneemmät tunnistamismenetelmät pyrkivät saavuttamaan jommankumman, tai molemmat, seuraavista toiminnallisuuksista: yhtenäinen todentamiskäytäntö kirjautumisen jakaminen sovellusten välillä Menetelmiä toteuttaa yhtenäinen todentamiskäytäntö ovat keskitetty todentamisratkaisu ja yhtenäistetty todentamisratkaisu. Keskitetyssä todentamisratkaisussa eri palveluihin kirjaudutaan yhteisen keskitetyn järjestelmän kautta. Yhtenäistetyssä todentamisratkaisussa eri palveluissa käytetään samaa todentamismenetelmää. Kirjautumisen jakaminen sovellusten välillä, eli niin kutsuttu kertakirjautuminen (SSO, Single-Sign-On), on mahdollista toteuttaa keskitetyn todentamisratkaisun osana, tai luottamusverkoston (federation) avulla. Kertakirjautumisen tarve ilmenee tilanteissa, joissa yhden käyttäjän on tarve kirjautua useisiin eri palveluihin. Esimerkkinä kertakirjautumisesta on kun käyttäjä on kirjautunut terveystili palveluun, niin hän pääsee ilman uutta kirjautumista esimerkiksi Kelan palve- 17 (46)
luun. Kertakirjautuminen edellyttää toimiakseen luotettavasti, että käytettävät tietokoneet tai tunnukset eivät ole yhteiskäyttöisiä, tai että kertakirjautumisjärjestelmän istuntojen hallinta on toteutettu yhteiskäyttöisyys huomioon ottaen. Henkilön yksilöinti on keskeinen yhdistävä tekijä tunnistamisen ja todentamisen, käyttövaltuushallinnan ja jälkikäteisen valvonnan välillä. Ehdoton vaatimus on, että jokaisella järjestelmän tunnistetulla käyttäjällä on yksilöivä yksilöintitunnus, ja että käytettävät todentamismenetelmät yksilöivät käyttäjät yhteneväisesti tämän yksilöintitunnuksen kanssa. Yksilöintitunnuksissa kannattaa aina hyödyntää olemassa olevia menetelmiä mikäli mahdollista. Suosituksena on hyödyntää henkilötunnusta JHS159 mukaisesti [JHS159]. Kun sähköinen asiointitunnus (SATU) yleistyy, sen käyttö on suositeltavaa. Tällä hetkellä sähköisen asiointitunnuksen haltijoita on kuitenkin liian vähän, jotta sen käyttö olisi suositeltavaa. JHS159 mukaista käytäntöä noudatetaan myös järjestelmien identifoinnissa. Todentamismenetelminä PKI-pohjaiset menetelmät ovat suositeltavia, erityisesti jos sähköinen allekirjoitus on toivottu ominaisuus. Asiakkaan todentamismenetelmänä kansalaisvarmenne on suositeltava, mutta ei tällä hetkellä niin laajalle levinnyt, että se soveltuisi ainoaksi vaihtoehdoksi. Tupas-järjestelmä on levinnyt laajalle ja on turvallisuudeltaan riittävä todennusjärjestelmä, mutta ei tue sähköisiä allekirjoituksia. Konkreettisia suositeltavia todentamisratkaisuja ovat. Vetuma ja tunnistus.fi palvelut Kansalaisvarmenne ja Tupas todentamismenetelmät Tunnistus.fi:n ja Vetuman käyttö ei kuitenkaan sopimussyistä sovellu nykyisellään kaikille eri palvelutarjoajille. Voi olla tarpeen luoda uusia palveluita, tai laajentaa olemassa olevien palvelujen käyttöä. Hajautettuna toteutuksena suositettava vaihtoehto on luottamusverkosto (federation), jonka mukaisesti voidaan toteuttaa hajautettu tunnistaminen ja todentaminen, käyttövaltuushallinta sekä pääsynvalvonta. Luottamusverkoston keskeinen tekninen standardi on SAML (Security Assertion Markup Language), joka on käyttökelpoinen myös keskitetyissä ratkaisuissa. 6.3.4 Käyttövaltuushallinta Terveystili palveluissa tarvitaan käyttövaltuushallintaa, koska käyttöoikeudet eivät ole muuttumattomia ja yksinkertaisia. Käyttövaltuushallinta on mahdollista toteuttaa keskitettynä tai hajautettuna. Luottamusverkoston avulla voidaan toteuttaa paitsi kertakirjautuminen, myös hajautettua käyttövaltuushallintaa. Käyttövaltuushallinnan ja pääsynvalvonnan toteuttamisessa roolipohjaiset ratkaisut (role-base access control) ovat suositeltava tapa mallintaa käyttäjiä yhdenmukaisiin ryhmiin. 18 (46)
Terveystili-palvelun osalta käyttövaltuushallinta tapahtuu käyttäjän itsensä toimesta. Käyttäjä antaa valtuudet muille henkilöille päästä hänen terveystilinsä tietoihin. Pääsyä voidaan rajoittaa tietokohtaisesti. Käyttövaltuushallinnassa käytetään rakenteista kieltä käyttöoikeuksien kuvaamiseen. Suositeltava käyttöoikeuskuvauskieli on XACML. 6.3.5 Pääsynvalvonta Pääsynvalvonnalla rajoitetaan pääsy tietoon vain siihen oikeutetuille tahoille. Pääsynvalvonta täytyy toteuttaa jokaisessa järjestelmässä, joka sisältää suojeltavaa tietoa. Erityisesti henkilö- ja terveystiedot täytyy suojata hyvin. Pääsynvalvonta soveltuu yhden järjestelmän sisäisesti keskitettynä palveluna toteuttavaksi. Erillisten järjestelmien tulee hyödyntää paikallisia toteutuksia pääsynvalvonnan palveluista. Kun käyttöoikeudet ovat yksinkertaisia, on houkutuksena toteuttaa myös pääsynvalvonta yksinkertaisena. Suunnitteluvaiheessa on kuitenkin syytä analysoida käyttöoikeuksien muutostarpeet, ja tarvittaessa toteuttaa käyttöoikeuksienhallinta ja pääsynvalvonta siten, että käyttöoikeuksien muuttaminen jatkossa ei aiheuta tarpeettomasti merkittäviä muutoksia itse järjestelmään. 6.3.6 Jälkikäteinen valvonta Jälkikäteinen valvonta toteutetaan lokijärjestelmän avulla. Lokijärjestelmää käytetään myös menetelmänä toteuttaa raportointia ja järjestelmän teknistä valvontaa, jota tarvitaan esimerkiksi virhetilanteiden selvittämistä. Jälkikäteisessä valvonnassa on seuraavat kaksi käyttötapausta: 1. asiakas seuraa häntä koskevien tietojen käyttöä 2. valvova taho seuraa tietojen käyttöä kokonaisuutena Jälkikäteinen valvonta on mahdollista toteuttaa hajautetusti tai keskitetysti. SAINI- palveluissa painotetaan etenkin asiakkaan toimesta tapahtuvaa omatoimista lokien seurantaa. Palvelun tarjoajien lokien seuranta keskittyy pääasiassa teknisten murtautumisyritysten havaitsemiseen ja niiden estämiseen. 6.4 Näkökulmat 6.4.1 Asiakkaan näkökulma Asiakkaalle yllä kuvatusta jaottelusta näkyy selkeimmin todentaminen, jossa hän on tyypillisesti aktiivisena osapuolena. Käyttövaltuushallinta liittyy asiakkaan terveydenhuollon asiointiin valtuutusten ja kieltojen muodossa. Jälkikäteinen valvonta liittyy asiakkaan terveydenhuollon asiointiin omien tietojen käytön valvontaoikeutena. Sähköinen allekirjoitus liittyy asiakkaan terveydenhuollon asioinnissa niihin prosesseihin, joissa lain tai asetusten mukaisesti vaaditaan henkilön omakätinen allekirjoitus. Kaikki jaottelun osat osana terveydenhuollon järjestelmien toteutusta vaikuttavat siihen, luottaako asiakas järjestelmään. 19 (46)
6.4.2 Järjestelmien näkökulma Järjestelmien välisessä liikenteessä, jossa henkilökäyttäjä ei ole osapuolena, keskeisimmät tietoturvallisuuden toiminnallisuudet ovat sähköinen allekirjoitus, salaaminen sekä tunnistaminen ja todentaminen. Sähköinen allekirjoitus on käytössä tietojärjestelmissä tiedon eheyden ja alkuperäisyyden osoittamisessa. Suositus on, että sähköistä allekirjoitusta käytetään SOAP ja SAML -protokollista. Salaaminen, tunnistaminen ja todentaminen ovat käytössä tietojärjestelmien välisessä tiedonsiirrossa. Näitä käytetään TLS ja SSL -protokollissa. Järjestelmien välinen tietoliikenne on luonnollisesti raskasta, jos kaikki liikenne on tunnistettua, salattua ja allekirjoitettua. Suljetuissa järjestelmissä, jossa osapuolet ovat luotettuja, näistä toiminnallisuuksista usein tingitään tehokkuussyistä. Avoimissa järjestelmissä tehokkuutta joudutaan sen sijaan kasvattamaan laitteistolla. 7 PALVELUARKKITEHTUURI 7.1 Periaatteet palveluille Palveluarkkitehtuuri sopii hyvin verkkopalvelujen suunnitteluun ja kuvaukseen. Yksi suurimmista haasteista palveluarkkitehtuureissa on kuitenkin sopivien palvelukandidaattien löytäminen ja niistä konkreettisten palveluiden kehittäminen. Tässä kappaleessa on kuvattu palveluiden määrittelyn periaatteita. Jokaisen palvelun pitää noudattaa seuraavia kahdeksaa periaatetta Palveluiden pitää olla uudelleenkäytettäviä Palvelut jakavat formaalin sopimuksen Palveluiden välillä on löyhä sidonta Palvelut piilottavat sisällään olevan logiikan Palvelut ovat koostettavissa Palvelut ovat autonomisia Palvelut ovat pääasiassa tilattomia Palvelut ovat löydettävissä Palveluarkkitehtuurin pääasiallinen hyöty saavutetaan palveluiden uudelleenkäyttämisen kautta kustannussäästöinä ja järjestelmähankkeiden nopeutumisena. Palvelut suunnitellaan teknologiariippumattomasti eikä niiden toteuttamisen aikana tehdä olettamuksia palveluiden käyttöympäristöstä. Jokaisella palvelulla pitää olla kuvattuna formaali sopimus, joka kuvaa palvelun tarkoituksen, toiminnallisuuden, rajoitukset sekä vastaavat asiat. Formaali sopimus voi olla tekninen kuvaus. Jotta palvelut olisivat uudelleenkäytettäviä ja vaihdettavissa, niiden välillä pitää olla löyhä sidonta. Palvelut eivät saa olla tiukasti sidottuja toisiinsa, jotta ylläpito on joustavaa. 20 (46)
Palvelujen pitää piilottaa sisällään oleva toiminnallisuus rajapinnan taakse. Käytännössä tämä tarkoittaa sitä, että rajapintoja kuvattaessa niiden ei pidä paljastaa sisäistä toimintaansa. Palveluiden pitää olla koostettavissa; useita palveluja on voitava yhdistää joko uusiksi palveluiksi tai käyttää prosessimoottorin kautta yhteistoiminnallisesti. Tämä käytännössä vaatii, että palveluiden pitää olla autonomisia ja niiden välillä pitää olla löyhä sidonta. Palveluiden toteuttamisen helpottamiseksi ja toisaalta niiden koostettavuuden varmistamiseksi palveluiden tulee pääasiassa olla tilattomia. Tällöin palvelu ei ylläpidä tilaa kutsujen välillä. Poikkeuksena tästä ovat tietoja taltioivat tietopalvelut ja korkean tason prosessipalvelut. Palveluiden pitää olla löydettävissä, jotta niitä voidaan uudelleen käyttää ja jotta niistä voidaan koostaa uusia palveluita. Tämä tarkoittaa, että on olemassa palveluhakemisto ja siellä palvelusopimukset. Palveluiden käyttämisen osalta on kaksi vaihtoehtoista mallia, jotka ovat ns. kehityksen aikainen sidonta ja ajonaikainen sidonta lähestymistavat. Kehityksen aikainen sidonta - lähestymistavassa kehityksen aikana päätetään, mitä palvelua käytetään ja ajoaikaisesti etsitään pelkästään palvelun osoite. Ajonaikainen sidonta -mallissa ajoaikaisesti kysellään vaihtoehtoisia saatavilla olevia palveluja ja näistä valitaan sopivin. Johtuen tietoturvavaatimuksista on syytä että järjestelmä toimii ennustettavasti palveluiden käytön osalta. Suosituksena on että Saini-palveluiden suhteen käytetään kehityksen aikainen sidonta -mallia. Palveluiden rajapinnat voidaan jakaa käytännössä kahteen eri tyyppiin: funktionaalisiin ja dokumenttilähtöisiin. Funktionaaliset rajapinnat ovat vahvasti tyypitettyjä ja sisältävät tarkan tiedon, mitä palvelu ottaa vastaan. Dokumenttilähtöiset rajapinnat ottavat vastaan rakenteisen XML-dokumentin, jota käsittelevät. Suosituksena on että Saini-rajapinnat rakennetaan dokumenttilähtöisesti ja palvelut omistavat käyttämänsä datan. 21 (46)
7.2 Palveluarkkitehtuuri osat Palveluarkkitehtuurille on määritelty seuraavat loogiset osat SOA Sovelluksen käyttöliittymä Palvelu Palveluhakemisto Palveluväylä Sopimus Toteutus Rajapinta Logiikka Data Kuva 5 Palveluarkkitehtuurin osat ([SOAENT]) Palvelukeskeisen arkkitehtuurin tärkeimmät komponentit ovat Sovelluksen käyttöliittymä Palvelu Palveluhakemisto Palveluväylä Sovelluksen käyttöliittymä on käyttöliittymä jota kautta käyttäjä käyttää palveluita. Tämä käyttöliittymä on usein esimerkiksi portaali tai vastaava ratkaisu. Palveluhakemisto on tärkeä osa palveluarkkitehtuuria. Jotta palvelut ovat löydettävissä, niin ne pitää olla listattuna palveluhakemistoon. Palveluarkkitehtuuri sisältää aina loogisesti palveluväylän (ESB, Enterprise Service Bus). Palveluväylä tarkoittaa ratkaisua, jonka tehtävänä on yhdistää kaikki eri osapuolet ja palvelut. ESB mahdollistaa heterogeenisten teknologioiden, integraatiotapojen ja alustojen yhdistämisen. Tämän lisäksi se tarjoaa usein teknisiä infrastruktuuripalveluita, kuten loki, tietoturvaa, transformaatioita ja transaktionhallintaa. Palveluarkkitehtuurin palveluille määritellään seuraavat osat, joista se koostuu Sopimus Rajapinta Toteutus Toimintalogiikka Data 22 (46)