Tietoliikenneyhteydet 1 (36) Liittymismallit KanTa-palveluihin LIITE 1 KanTa-tietoliikenneyhteyksien suunnittelu ja toteutus Dokumentin muutoshistoria Versio Pvm Tekijä / hyväksyjä Kuvaus 1.0 KunTo
Tietoliikenneyhteydet 2 (36) Sisällys LYHENNELUETTELO JA TERMISTÖ...3 1 Johdanto...5 2 Tietoliikenneverkon toteutusmalli...7 2.1 Yleiset vaatimukset...7 2.1.1 Tietoliikenteen yleiset tietoturvavaatimukset...7 2.1.2 Liikenteen salausvaatimukset liittyjän verkossa...7 2.1.3 Käyttöönotettavien KanTa-palveluiden asettamat kapasiteettivaatimukset...9 2.2 Verkon looginen rakenne...10 2.2.1 Tausta...10 2.2.2 Esitetty malli tietoliikenneratkaisusta...10 2.3 Liittymismalliesimerkit...14 2.3.1 Esimerkki 1...14 2.3.2 Esimerkki 2...16 2.3.3 Esimerkki 3...17 2.3.4 Esimerkki 4...18 2.4 Liittyminen runkoverkkopalveluun...19 2.4.1 Toimenpiteet tietoliikenneoperaattorin suuntaan...19 2.4.2 Toimenpiteet liittyjän tietoliikenneverkoissa (kahdennettu/kahdentamaton liittymä)...19 3 Tietoliikenneyhteyksien mitoitus, laatuvaatimukset ja suositukset...23 3.1 Yleistä...23 3.2 Liittymäkapasiteetin suhde käytettävään siirtomediaan...23 3.3 Mitoitusperusteet...24 3.3.1 Mitoitusperusteet eresepti-palvelun tarpeisiin perustuen...24 3.3.2 Huomiot mitoituksessa earkisto-palvelua varten...25 3.4 Laatuvaatimukset ja suositukset...27 3.4.1 Yleistä...27 3.4.2 Palveluaika...28 3.4.3 Käytettävyys...28 3.4.4 Palveluvaste...29 3.4.5 Liikenteen tekniset laatuluokitukset...31 3.4.6 Esimerkkiliittymätyypit määritellyillä palvelutasoilla...32 3.4.6.1 Esimerkki A: Toiminnaltaan kriittinen liittymätyyppi...32 3.4.6.2 Esimerkki B: Toiminnaltaan vähemmän kriittinen liittymätyyppi...33 4 Tietoliikenneyhteyksien ja palveluiden tuotannonaikainen valvonta...34 4.1 Yleistä...34 4.2 Valvonnan toteutus...35 4.2.1 Liittymien perusvalvonta...35 4.2.2 Liittymien kuormitusstatistiikan valvonta...36
Tietoliikenneyhteydet 3 (36) LYHENNELUETTELO JA TERMISTÖ BGP CE Core GLBP GW Host HSRP ICMP IP ITU-T KanTa Kela LAN Latenssi MPLS PING Border Gateway Protocol, tietoliikenneoperaattoreiden runkoverkoissa käyttämä tiedonsiirtoprotokolla Customer Equipment, operaattorin runkoverkkopalveluun liittyvän asiakaan asiakaslaite, joka on operaattorin ylläpidossa Tietoliikenneoperaattorin runkoverkko Gateway Load Balancing Protocol, lähiverkoissa hyödynnettävä, vikasietoisen reitityspisteen tarjoava protokolla Gateway, yhdyskäytävä Isäntäkone, esimerkiksi yksittäinen palvelinlaite Hot Standby Routing Protocol, lähiverkoissa hyödynnettävä, vikasietoisen reitityspisteen tarjoava protokolla Internet Control Message Protocol, protokolla, jonka avulla voidaan välittää informaatiota mm. tietoverkon häiriötilanteista Internet Protocol, internetprotokolla International Telecommunication Union Standardization sector, kansainvälinen standardointielin Kansallinen Terveysarkisto Kansaneläkelaitos Local Area Network, lähiverkko Viive (esimerkiksi sanoman kokema viive sen välittyessä tietoliikenneverkon lävitse) Multiprotocol Label Switching, hyvin yleinen menetelmä IP-pakettien nopeaan siirtoon tietoliikenneoperaattoreiden runkoverkoissa Packet Internet Groper, IP-verkon työkalu, jolla voidaan testata määrätyn isäntäkoneen saavutettavuutta. Hyödyntää ICMP-protokollaa
Tietoliikenneyhteydet 4 (36) PKI Probe RTT SP SLA SNMP SSL/TLS VLAN VoIP VPN VRF VRRP Public Key Infrastructure, julkisen avaimen infrastruktuuri Mittalaite, jota hyödynnetään verkon ja palveluiden laadun mittauksessa. Asennetaan liittyjän lähiverkkoon Round Trip Time, kiertoaikaviive Service Provider, palveluntarjoaja Service Level Agreement, palvelutasosopimus Simple Network Management Protocol, verkonhallintaprotokolla Secure Sockets Layer/ Transport Layer Security, protokollat tiedonsiirtoosapuolen autentikointiin ja siirrettävän tiedon salaukseen Virtual Local Area Network, kytkintekniikka, jonka avulla voidaan luoda toisistaan virtuaalisesti eriytettyjä lähiverkkoja kytkinverkon sisällä Voice over Internet Protocol, termi tekniikalle, jossa puheliikennettä välitetään IP-verkon ylitse IP-protokollaa hyödyntäen Virtual Private Network, virtuaalinen yksityisverkko, yleistermi tekniikalle, jossa tietoliikenneverkon osapuolten välinen kommunikointi välitetään julkisen tai muutoin jaetun verkon ylitse näennäisesti yksityisessä (suljetussa) verkossa VPN Routing and Forwarding, teknologia, joka mahdollistaa useiden reititys-tauluinstanssien samanaikaisen käytön reitittimessä. Reititystauluinstanssit ovat toisistaan täysin erillisiä ja mahdollistavat näin eriytettyjen verkkojen toteuttamisen. Käytetään yleisterminä kuvaamaan myös suljettua asiakasverkkoa tietoliikenneoperaattorin (MPLS)-runkoverkon sisällä. Virtual Router Redundancy Protocol, lähiverkoissa hyödynnettävä, redundanttisen reitityspisteen tarjoava protokolla
Tietoliikenneyhteydet 5 (36) 1 Johdanto Tämä dokumentti sisältää tiedonsiirtoyhteyksien järjestämiseen liittyviä ohjeita ja suosituksia KanTa-palveluihin liittyville organisaatioille. Dokumentti tarkentaa Kelan Liittymismallit KanTa-palveluihin -ohjetta, ja se on ensisijaisesti kirjoitettu KanTapalveluihin liittyville terveydenhuollon organisaatioille. Dokumentin tarkoituksena on esitellä ratkaisumalleja, joiden avulla erikokoiset Kan- Ta-liittyjät (ja niiden tietojärjestelmät) voivat liittyä KanTa-palveluihin tietoturvallisesti, toteuttaa tiedonsiirtoyhteydet ja niihin liittyvät ylläpitopalvelut laadukkaasti ja kustannustehokkaasti sekä varmistua yhteyksien skaalautuvuudesta KanTa-palveluiden tulevia vaiheita varten. KanTa-palveluilla tarkoitetaan terveydenhuollon valtakunnallisia tietojärjestelmäpalveluita, joita ovat sähköinen resepti (eresepti) sähköinen potilastiedon arkisto (earkisto) kansalaisten omien resepti- ja potilastietojen katselu verkossa tukipalvelut, kuten terveydenhuollon tunniste- ja varmennepalvelut sekä koodistopalvelu. KanTa-palvelut tuottaa Kela. Tunniste- ja varmennepalveluista vastaa Sosiaali- ja terveysalan lupa- ja valvontavirasto (Valvira) ja koodistoista Terveyden ja hyvinvoinnin laitos (THL). Palveluihin liittyviä osapuolia on useita. Niihin kuuluvat eri terveydenhuollon toimijat (mm. kaupunkien terveyskeskukset, sairaalat, perusterveydenhuollon ja erikoissairaanhoidon kuntayhtymät ja yksityiset lääkäriasemat) sekä pääja sivuapteekit. Kokonaisliittyjämäärä on varsin suuri. Liittyjäorganisaatiot ovat kooltaan erisuuruisia ja organisaatioiden tietojärjestelmäympäristöt ovat keskenään vaihtelevia. KanTa-liittyjillä on käytössään useita eri tietojärjestelmiä, jotka liikennöivät KanTapalveluihin päin. Potilastietojärjestelmä voi liikennöidä KanTa-palveluihin joko suoraan tai erillisen integraatioratkaisun kautta. Liikennöintiä tapahtuu myös KanTapalveluista potilastietojärjestelmiin päin, esim. reseptin uudistamispyynnön lähettämisen yhteydessä. Tällaisista KanTa-liittyjän tarjoamista palveluista käytetään ohjeistuksessa nimitystä vastaanottopalvelut. Tämä dokumentti rajautuu potilastietojärjestelmän ja KanTa-palvelun välisiin tietoliikenneyhteyksiin, eikä siinä oteta kantaa esim. työasemien ja tietojärjestelmien välisiin yhteyksiin. Dokumentissa keskitytään ensisijaisesti eresepti-palvelun käyttöönoton ja käytön asettamiin vaatimuksiin. Kuitenkin keskeiset jatkokehitystarpeet, kuten liitty-
Tietoliikenneyhteydet 6 (36) mien ja yhteyksien skaalautuminen earkisto-palvelun tarpeisiin, on pyritty huomioimaan. Määrittelytyö toteutettiin marraskuun 2009 ja helmikuun 2010 välisenä aikana. Tämä dokumentti on esimerkinomainen ohje, jota KanTa-palveluihin liittyvä organisaatio voi halutessaan käyttää tietoliikenneyhteyksien suunnittelun tukena. Dokumentissa ei määritellä uusia liittyjiä tai tietoliikenneyhteyksien toteuttajia koskevia vaatimuksia, vaan kaikki dokumentissa viitatut tai esitetyt vaatimukset pohjautuvat Kelan ja muiden KanTa-palvelujen tuottajien sekä sosiaali- ja terveysministeriön asettamiin vaatimuksiin.
Tietoliikenneyhteydet 7 (36) 2 Tietoliikenneverkon toteutusmalli 2.1 Yleiset vaatimukset 2.1.1 Tietoliikenteen yleiset tietoturvavaatimukset Kaikki potilastietojärjestelmien ja KanTa-palveluiden väliset tiedonsiirtoyhteydet on suojattava siten, ettei ulkopuolisilla ole mahdollisuutta päästä käsiksi siirrettävään tietoon. Liikenne liittyjän potilastieto- tai apteekkijä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 kaikki osapuolet tulee tunnistaa luotettavasti. Tunnistaminen on pakollista organisaatioiden välisessä tiedonsiirrossa, kun käytetään muita kuin sisäverkon yhteyksiä. Jos 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 kuitenkin että konesalin- 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 (PKI) ja palvelinvarmenteita. Kelan ja varmennepalveluiden tuottajien ohjeistuksessa on yksityiskohtaisempaa tietoa varmenteiden hankkimisesta ja varmentamisen teknisestä toteutuksesta. 2.1.2 Liikenteen salausvaatimukset liittyjän verkossa Tiedonsiirron suojaus- ja salausvaatimukset koskevat myös liittyjän verkossa/verkoissa toteutettavaa KanTa-palveluihin liitetyn potilastietojärjestelmän ulkoista tiedonsiirtoa niiltä osin, kun tiedonsiirto koskee KanTa-palveluihin tai -palveluista tapahtuvaa liikennöintiä. Liittyjän verkon tietoliikenteellä tarkoitetaan esimerkiksi potilastietojärjestelmän ja integraatioratkaisun välistä liikennöintiä (jos käytetään erillistä integraatioratkaisua). Tietojärjestelmien ja integraatioratkaisun välisiä yhteyksiä on esitetty loogisella tasolla kuvassa 1.
Tietoliikenneyhteydet 8 (36) Kuva 1. Potilastietojärjestelmien ja integraatioratkaisun (integraatiojärjestelmä) välinen liikennöinti. Kuvassa 1 liittyjien (Organisaatiot A,B,C ja D) KanTa-palveluihin näkyvä KanTaliityntäpiste sijaitsee integraatioratkaisussa, josta muodostettavat yhteydet on autentikoitu ja salattu hyödyntämällä Valviran palvelinvarmennetta. Integraatioratkaisu sijaitsee tässä esimerkissä liittyvän organisaation (Organisaatio D) lähiverkossa. Muiden alueellisten organisaatioiden tietojärjestelmät liikennöivät KanTa-palveluihin tämän välitysjärjestelmän kautta. Järjestelmien välinen verkko (kuvassa IP ) voi olla käytännössä mikä tahansa IP-protokollaa välittävä verkko tai useampi verkko. Asetettujen vaatimusten mukaisesti, potilastietojärjestelmän ja integraatioratkaisu 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 vastaavan tasoista teknologiaa. Toteutuksessa suositellaan hyödynnettävän Valviran palvelinvarmenteita, mutta tämä ei ole pakollista. Liikenteen salausta/autentikointia ei edellytetä, jos: potilastietojärjestelmän ja integraatioratkaisun välinen yhteys kulkee kokonaan saman konesaliverkon sisällä ja konesalin tietoturva on asianmukaisesti toteutettu
Tietoliikenneyhteydet 9 (36) potilastietojärjestelmän ja integraatioratkaisun välinen yhteys kulkee dedikoitua point-to-point -linkkiä (esim. vuokrakuitu) pitkin. Liikenteen salausvaihtoehdot ja eri liittyjätyypit kuvauksineen on esitetty kappaleessa 2.4. 2.1.3 Käyttöönotettavien KanTa-palveluiden asettamat kapasiteettivaatimukset Toimeksiannon lähtökohtana oli huomioida ensisijaisesti eresepti-palvelun käyttöönoton asettamat vaatimukset tiedonsiirtoratkaisuille sekä arvioida earkisto-palvelun käyttöönoton tuomia näihin tiedonsiirtoratkaisuihin kohdistuvia kehitys/ muutostarpeita. eresepti-palveluun sisältyvä liikenne on synkronista ja sanomapohjaista. Sanomat ovat kooltaan n. 5 40 kt (kilotavua). Jos 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. KanTa-tietoliikenneyhteyksien osalta suositellaan käytettävän tämän dokumentin luvun kolme mukaisia laatuluokituksia. Tehtyjen arviolaskelmien mukaan, n. 70 % eresepti-palvelun lääkemääräyksistä kirjoitetaan arkipäivisin klo 8 16. 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. Kappaleessa 3.3 on arvioitu eresepti-palvelun käytön mitoitusvaatimuksia tietoliikenteen kannalta.
Tietoliikenneyhteydet 10 (36) 2.2 Verkon looginen rakenne 2.2.1 Tausta KanTa-palveluihin liitettävät tietojärjestelmät liitettävät tietojärjestelmineen sijaitsevat eri organisaatioiden ja toimittajien konesaliympäristöissä eri puolilla Suomea. Ohjeistuksessa pyritään siihen, että liittyjien hyödyntämät tietoliikenneratkaisut perustuvat yhteisesti sovittuihin liittymisvaihtoehtoihin, joiden käyttöönottomalleista on myös sovittu eri osapuolien välillä. 2.2.2 Esitetty malli tietoliikenneratkaisusta Tässä dokumentissa esitetyn ohjeistuksen runkona toimii suljettuihin asiakasverkkoyhteyksiin tai dedikoituihin yhteyksiin perustuva malli. Ohjeistuksessa on kuvattu myös liityntämalli, joka on toteutettu julkisen internetverkon ylitse. Julkisen terveydenhuollon organisaatioille suositellaan kuitenkin suljettuihin asiakasverkkoihin tai dedikoituihin ratkaisuihin perustuvia liityntämalleja. Suljetulla asiakasverkolla tarkoitetaan pelkästään jonkin asiakkaan käyttöön rakennettua virtuaalista yksityisverkkoa (asiakaskohtainen VPN, Virtual Private Network), joka rakennetaan laitteistokonfiguraatioiden avulla tietoliikenneoperaattorin runkoverkon päälle. Suljetun asiakasverkon sisällä välitetään ainoastaan asiakkaan dataa, eikä liikennöinti muista asiakasverkoista tai internetistä käsin ko. asiakasverkkoon ole mahdollista. Operaattorin suljettu asiakasverkko mahdollistaa siis liikenteen eriyttämisen muusta operaattorin verkossa siirrettävästä liikenteestä ja tarjoaa siten sovitun kaistan tarjoavan tiedonsiirtokanavan. Tietoliikenneoperaattorit hyödyntävät suljettujen asiakasverkkojen toteutuksissa nykyisin lähinnä MPLS VPN (Multiprotocol Label Switching VPN) ja VRF (VPN Routing and Forwarding) -teknologioita. Näillä teknologioilla siirrettävää liikennettä ei salata, vaan se siirretään muusta liikenteestä eriytetyssä virtuaaliverkossaan. Tekniikat mahdollistavat myös liikenteen priorisoinnin ja luokittelun runkoverkon sisällä, jos asiakas näin haluaa. Tässä suunnitelmassa ei kuitenkaan oteta tarkemmin vaatimuksena kantaa siihen, mitä teknologioita operaattori runkoverkossaan suljettujen asiakasverkkojen toteutukseen käyttää, koska nämä voivat tulevaisuudessa myös vaihtua. Dokumentin kuvauksissa kuitenkin viitataan selkeyden vuoksi nykyisin käytössä oleviin teknologioihin. Termiä VRF käytetään topologiakuvissa synonyyminä suljetulle asiakasverkolle esitysteknisistä syistä. Tämä on puhekielessä myös varsin usein käytetty termi suljetulle asiakasverkolle. Esitetyllä suljetulla asiakasverkkomallilla on edellytyksenä, että liikennöintiin osallistuvat osapuolet liittyvät valitun operaattorin asiakasverkkoon omilla runkoverkon liittymillään. Käytännössä Kelan palvelukeskukseen tulee siis toteuttaa oma runkoverkkoliittymänsä ja vastaavasti kullekin liittyjäorganisaatiolle tai organisaatioiden yhteis-
Tietoliikenneyhteydet 11 (36) toteutuksille omansa. Liittyjäorganisaatioiden liittymät voivat olla organisaatiokohtaisia tai organisaatioiden yhteenliittymälle toteutettuja. Tässä dokumentissa esitetyssä mallissa eri liittyjäorganisaatioiden tai yhteenliittymien on mahdollista hankkia (tai kilpailuttaa) yhteydet omilta runkoverkko-operaattoreilta paikallisesti mm. kustannus- ja saatavuussyistä johtuen. Suomessa on tällä hetkellä käytännössä neljä eri tietoliikenneoperaattoria, joilla on kyky tarjota runkoverkkopalvelua valtakunnallisesti. Kelan palvelukeskukseen toteutetaan ns. nieluliittymät vähintään näiden neljän operaattorin runkoverkkoon. Kukin liittyjä liikennöi KanTapalveluihin valitun runkoverkko-operaattorin runkoverkkoa pitkin, jonkin nieluliittymän lävitse. Tämä toteutusmalli on esitetty kuvassa 2. Kuva 2. Malli esitetystä tietoliikenneratkaisusta (huom. dedikoituja yhteyksiä ei ole kuvattu). Kuvassa 2 on käytetty liittyjän verkossa yksinkertaisuuden vuoksi vain potilastietojärjestelmiä, vaikka yhteys voidaan muodostaa myös integraatioratkaisun kautta. Kuvassa 2 on esitetty esimerkkityyppisesti neljän eri KanTa-liittyjän liikennöinti KanTapalveluihin eri operaattoreiden runkoverkkojen kautta. Kuvassa 2 esitetyt potilastietojärjestelmät voivat olla joko liittyjän omassa tai toimittajalle ulkoistetussa konesaliympäristössä. Kummassakin tilanteessa liittymistapa operaattorin suojattuun asiakas-
Tietoliikenneyhteydet 12 (36) verkkoon säilyy kuitenkin samana. Useampi liittyjäorganisaatio voi käyttää myös yhteistä liityntää runkoverkkopalveluun (kuvan esimerkissä Liittyjät A1 ja A2 ). Suositus onkin että KanTa-palveluiden käyttöönoton edellyttämät tietoliikenneyhteydet ja tietoliikenteeseen palvelut (esim. valvonta- ja hallinta, tietoliikenteen tietoturva) toteutetaan vähintään sairaanhoitopiirin alueen laajuisina yhteistoteutuksina, jolla voidaan varmistaa tiedonsiirtoyhteyksien sekä niihin liittyvien ylläpitopalveluiden kustannustehokas toteutus sekä yhteyksien skaalausmahdollisuudet KanTa-palveluiden myöhempien vaiheiden tarpeisiin. Toteutusta suunniteltaessa tulisi arvioida voidaanko olemassa olevia esim. alueellisia tiedonsiirtoratkaisuja hyödyntää KanTatietoliikenneyhteyksien toteuttamiseen. Kuvassa 2 kukin operaattori toteuttaa oman nieluliittymänsä Kelan palvelukeskukseen. Kelan palvelukeskuksessa kunkin operaattorin vastuu ulottuu palvelukeskuksen tiloissa sijaitseviin operaattorikohtaisiin CE-reitittimiin. Vastaavasti liittyjäpuolella liittyjän valitseman operaattorin vastuu ulottuu liittyjän tiloissa sijaitsevaan CEreitittimeen. Toteutusmallissa on pyritty siihen, että liittymät on toteutettu annetut vaihtoehdot huomioiden mahdollisimman yhdenmukaisella tavalla. Toteutusmallissa kukin liittyjä liittyy suljettuun asiakasverkkoon täysin vastaavalla toteutustavalla (operaattorista riippumatta). Mallin arkkitehtuuri on siis yhdenmukainen kaikille liittyjille, mutta siirtoteknologiat (kuitu-/ kupariyhteydet) ja yhteysnopeudet voivat poiketa toisistaan. Liittyjälle toteutettavan suljetun asiakasverkon liittymään sidotaan halutut kapasiteetti- ja laatuvaatimukset (sisältäen liittymän siirtokapasiteetin ja palvelutason). Nämä määräytyvät liittyjäkohtaisten tarpeiden mukaisesti. Näitä tarpeita käsitellään dokumentissa erikseen myöhemmin. Verkkoteknisesti suljetun asiakasverkon ulottaminen eri liittyjien lähiverkkoihin on melko suoraviivaista. Kelan palvelukeskukseen toteutettavat operaattoreiden runkoverkkoliitynnät (vikasietoisuuden vuoksi kahdennettua) toimivat verkon nieluliittyminä. Ne määritellään ja toteutetaan heti toteutustyön alkuvaiheessa ja pysyvät staattisina myös jatkossa. Niihin sidottuja kapasiteetti- ja laatumääreitä voidaan muokata ohjelmallisesti/sopimuksellisesti myös tulevaisuudessa. Kelan palvelukeskuksessa sijaitsevien KanTa-palveluiden lisäksi samaa KanTapalvelukeskusyhteyttä käytetään terveydenhuollon varmennepalveluihin sisältyvään attribuuttipalveluun tapahtuvaan liikennöintiin. Liittyjäorganisaatioiden ei tarvitse toisin sanoen järjestää erillistä liittymää kyseiseen palveluun. Varmennepalveluihin sisältyvään sulkulista-palveluun liikennöidään internetverkon yli, eli toisin sanoen siihen ei voida liikennöidä KanTa-palvelukeskusyhteyksien kautta. Toistaiseksi myös KanTa-
Tietoliikenneyhteydet 13 (36) palveluihin sisältyvään koodistopalveluun liikennöidään internetverkon kautta. Koodistopalvelua ei käytetä KanTa-palveluiden käytössä reaaliaikaisesti. Verkkoon lisätään uusia KanTa-liittyjiä tarpeen mukaan, jolloin operaattori tekee konfiguraatiotyön vastaavasti uuden liittyjän tietoliikenneliittymään. Uusi KanTa-liittyjä konfiguroidaan tietoliikenneoperaattorin toimesta automaattisesti (tilauksen mukaisesti) osaksi suljettua asiakasverkkoa. Operaattorin tulee ennen liittämistä kuitenkin varmistaa, että asiakas on oikeutettu liittymään KanTa-palveluiden käyttäjäksi. Kelalle tulee ilmoittaa asiakkaan liittämisestä ja pyydettäessä toimitettava listaus kaikista liitetyistä. Kuvattu looginen KanTa-liittyjän liittymistapa suljettuun asiakasverkkoon on täysin riippumaton seuraavista tekijöistä: toimijan koko potilastietojärjestelmien lukumäärä potilastietojärjestelmä hyödyntää/ ei hyödynnä erillistä integraatioratkaisua keskitetty/organisaatiokohtainen liityntäpiste (palvelinvarmenne) keskitetty/organisaatiokohtainen tietoliikenneliittymä. Runkoverkkojen ulottamisesta Kelan konesaleihin sekä liittymismalleista sovitaan ennakolta operaattoreiden kanssa Kelan toimesta.
Tietoliikenneyhteydet 14 (36) 2.3 Liittymismalliesimerkit Tässä dokumentissa käytetään esimerkkeinä neljää eri liittymismallia. Liittymismalliesimerkit on kuvattu seuraavissa kappaleissa. Kelan KanTa-liittymismallit -dokumentissa on myös kuvattu myös liittymismallivaihtoehtoja liittyvän organisaation näkökulmasta. Koska tässä luvussa kuvatut esimerkit on kuvattu ensisijassa liittymisratkaisun tietoliikennetoteutuksen näkökulmasta, eivät mallit ole täysin yhteneväisiä kahden dokumentin välillä. Alla on kuvattu Kelan Kan- Ta-liittymismallit -dokumentissa olevat liittymismallit sekä niitä lähinnä tässä dokumentissa vastaavat esimerkit. KanTa-liittymismallit -dokumentin Tämän dokumentin lähin vastaava esimerkki liittymismalli Liittyminen oman viestinvälitysratkaisun kautta esimerkki 3 Liittyminen suoraan omassa hallinnassa olevasta potilas-tieto- tai apteekki- esimerkki 1 järjestelmästä Liittyminen ulkoistetun liityntäpisteen esimerkki 2 kautta Ulkoistettu tietoliikenne esimerkki 1 Pienen organisaation liittyminen internetin kautta esimerkki 4 2.3.1 Esimerkki 1 Esimerkissä 1 usea KanTa-liittyjä hyödyntää keskitettyä tietoliikenteen koontipistettä (CE-reititin) runkoverkkoon liittyessään. Malli soveltuu pienistä, keskisuurista tai suurista organisaatioista koostuville yhteenliittymille. Mallissa tyypillisesti yksi organisaatioista järjestää tietoliikenneyhteydet muille liittyjille tai tietoliikenneyhteydet kilpailutetaan yhteishankintana. Esimerkissä 1 KanTa-liityntäpisteet määritellään liittyjän puolella suoraan potilastietojärjestelmiin (tai näiden yhteyteen), jotka sijaitsevat organisaatioiden lähiverkoissa tai organisaation IT-palveluntarjoajan konesaliympäristössä. ( Organisaatio A, Organisaatio B, Organisaatio C, Organisaatio D ). Tällöin kukin tietojärjestelmä muodostaa SSL/ TLS-yhteyden suoraan KanTa-palveluihin. Tietoliikenneoperaattorin runkoverkkoon liitytään Organisaatio D:n verkon kautta. Esimerkin 1 mukainen liittymismalli on esitetty kuvassa 3.
Tietoliikenneyhteydet 15 (36) Kuva 3. Esimerkin 1 mukainen liittymismalli. Selvyyden vuoksi todettakoon, että kuvan 3 Operator MPLS tarkoittaa valitun operaattorin runkoverkkoa. Salattu yhteys välitetään edelleen operaattoriverkkoon toteutetun suljetun asiakasverkon sisällä. IP-verkko/IP-verkot organisaatioiden välillä voi olla toteutettu esim. jaettuja operaattorin runkoverkkoyhteyksiä (yhteyksillä välitetään usean asiakkaan liikennettä, toisistaan eriytettynä) pitkin. Erillistä tietoliikenteen salausta näiltä yhteyksiltä ei edellytetä, kun salaus toteutetaan sovellustasolla SSL /TLS:ää hyödyntäen.
Tietoliikenneyhteydet 16 (36) 2.3.2 Esimerkki 2 Esimerkki 2 kuvaa usean KanTa-liittyjän yhteenliittymää, joka hyödyntää keskitettyä integraatioratkaisua KanTa-palveluihin liikennöidessään. Malli soveltuu pienistä, keskisuurista tai suurista organisaatioista koostuville yhteenliittymille. Mallissa tyypillisesti yksi organisaatioista järjestää tietoliikenneyhteydet ja integraatioratkaisun muille liittyjille tai tietoliikenneyhteydet ja integraatioratkaisu kilpailutetaan yhteishankintana samassa yhteydessä tai erillisesti. Integraatioratkaisu on ylläpidossa jollakin liittyjällä tai 3. osapuolen (ITpalveluntarjoaja) lähiverkossa. Tietoturvavaatimusten täyttymiseksi liittyjien puolella, kukin tietojärjestelmä muodostaa erikseen palvelinvarmenteisiin pohjautuvan SSL/ TLS-yhteyden (tai muun vastaavaa tietoturvatasoa toteuttavan yhteyden) integraatioratkaisulle. Integraatioratkaisusta muodostetaan edelleen oma salattu yhteytensä KanTa-palveluihin. Esimerkin 2 mukainen liittymismalli on esitetty kuvassa 4. Kuva 4. Esimerkin 2 mukainen liittymismalli. IP-verkko/ IP-verkot organisaatioiden välillä voi olla toteutettu esim. jaettuja operaattorin runkoverkkoyhteyksiä pitkin. Tietoliikenteen salausta näiltä yhteyksiltä ei edellytetä, jos se toteutetaan sovellustasolla SSL/TLS:ää hyödyntäen.
Tietoliikenneyhteydet 17 (36) 2.3.3 Esimerkki 3 Esimerkki 3 kuvaa kooltaan keskikokoista KanTa-liittyjää tai usean liittyjän yhteistoteutusta, jossa integraatioratkaisu sijaitsee samassa lähiverkossa (konesaliympäristö) KanTa-palveluihin liitettävien potilastietojärjestelmien kanssa. Tapauksessa, jossa konesalin sisäisestä tietoturvasta on huolehdittu vaatimusten mukaisesti, ei Valviran varmenteella tapahtuva potilastietojärjestelmän ja integraatioratkaisun välisen tiedonsiirron autentikointi ja salaus ole pakollista. Liikenne organisaation konesalista Kelan palvelukeskukseen toteutetaan suljettua asiakasverkkoa pitkin. Esimerkin 3 mukainen liittymismalli on esitetty kuvassa 5. Kuva 5. Esimerkin 3 mukainen liittymismalli.
Tietoliikenneyhteydet 18 (36) 2.3.4 Esimerkki 4 Esimerkin 4 liittymismalli soveltuu ainoastaan pienille yksittäisille liittyjäorganisaatioille. Tässä mallissa KanTa-liittyjä liikennöi KanTa-palveluihin julkisen Internet-liittymän ylitse (jolloin liittymää ei liitetä osaksi suljettua asiakasverkkoa). Yhteyden autentikointi ja salaus toteutetaan Valviran palvelinvarmenteella ja SSL/TLS-tekniikoita hyödyntäen niin, että liityntäpiste liittyjän verkossa määritellään suoraan tietojärjestelmään kuten esimerkin 1 tapauksessa. Jos tätä esimerkkiä käyttävä organisaatio tarjoaa vastaanottopalveluita (esim. uudistamispyyntöjen vastaanotto), tulee sillä olla käytössään kiinteä ja julkinen IP-osoite. Esimerkin 4 mukainen liittymismalli on esitetty kuvassa 6. Kuva 6. Esimerkin 4 mukainen liittymismalli.
Tietoliikenneyhteydet 19 (36) 2.4 Liittyminen runkoverkkopalveluun 2.4.1 Toimenpiteet tietoliikenneoperaattorin suuntaan Kun uusi liittyjä haluaa liittyä osaksi suljettua asiakasverkkoa (tässä ei huomioida nyt liittymätyypin 4 tapauksia), hankkii liittyjien yhteenliittymä tai yksittäinen liittyjä tietoliikenneoperaattorilta uuden liittymän tai olemassa olevaan liittymään tilataan virtuaaliverkko, joka ulotetaan KanTa-palveluihin. Uusi liittymä liitetään olemassa olevaan suljettuun operaattorin asiakasverkkoon. Liittymä hankitaan halutulla palvelutasolla ja siirtokapasiteetilla joko kahdennettuna tai kahdentamattomana. Liittymään sidottava siirtokapasiteetti määräytyy KanTa-palveluiden tiedonsiirtotarpeisiin perustuen. Palvelutaso- ja siirtomääreitä käydään lävitse tarkemmin luvussa 3. 2.4.2 Toimenpiteet liittyjän tietoliikenneverkoissa (kahdennettu/kahdentamaton liittymä) Liittyjän verkossa tulee määritellä liikenne, joka halutaan asiakasverkkoon ja edelleen Kelan palveluihin päin välitettäväksi. Käytännössä liittyjän verkossa tulee hyödyntää VLAN- ja reititystekniikoita, jotta halutun liikenteen määritteleminen ja ohjaaminen asiakasverkkoon on mahdollista. Kuva 7 ja sen alla oleva selventävä teksti esittää tarvittavat toimenpiteet kahdentamattoman liittymän tapauksessa. Kuva esitetään karkealla tasolla, koska liittyjäorganisaatioiden verkkoympäristöt ovat toteutustavaltaan keskenään poikkeavia.
Tietoliikenneyhteydet 20 (36) Kuva 7. Liittyjän liittyminen suljettuun asiakasverkkoon (kahdentamaton toteutus). Tietojärjestelmällä on nykyisin käytössä jokin gateway (GW) -laite (reititin/ reitittävä kytkin/ palomuuri), joka välittää liikenteen muista verkoista tietojärjestelmään ja toisinpäin (kuvassa GW on palomuuri). Kun uusi liittymä otetaan käyttöön, tulee tietojärjestelmän KanTa-palveluihin kohdistuva sanomaliikenne reitittää tältä GW:ltä uudelle liittymälle. Käytännössä GW:llä tulee kertoa reitityssäännöllä, että Kelan palvelut löytyvät uuden CE-laitteen LAN-interfacen takaa. Reitityssäännössä kerrotaan joko yksittäisen Kelan palvelimen host-reitti tai vaihtoehtoisesti koko verkkoblokki. Nykyisen GW:n ja CE:n välille toteutetaan reititysverkko, joka on omassa VLANverkossaan.
Tietoliikenneyhteydet 21 (36) Tämän VLANin liikenne liitetään suljettuun asiakasverkkoon (VRF). Tietojärjestelmän GW:ksi voidaan määritellä halutessa myös suoraan CE-laite, jos halutaan, että liikenne ei kulje minkään nykyisen GW-laitteen kautta. Tämävaatii palvelimeen erikseen reittitiedon ja uuden fyysisen/virtuaalisen interfacen. On myös mahdollista, että potilastietojärjestelmän GW:n ja CE-laitteen välillä on useampia reitittäviä laitteistoja. Näissä tapauksissa GW:lle tehdään vastaavalla tavalla reitityssääntö, jossa kerrotaan next-hop -osoite johon liikenne välitetään Kelan palveluihin liikennöitäessä (ja vastaavasti muihin välin reitittäviin laitteisiin). Viimeisen reitittävän laitteen (ennen CE:tä) ja CE-laitteen välille toteutetaan aiemmin mainittu reititysverkko omassa VLAN:issaan. Kuva 8 ja sen alapuolinen selventävä teksti esittää liittyjän verkkoinfrastruktuurin toteutuksen kahdennetussa tapauksessa (kuva jälleen karkealla tasolla). Kuva 8. Liittyjän liittyminen suljettuun asiakasverkkoon (kahdennettu toteutus).