Terveydenhuollon avoimet sovellusrajapinnat - yhteiset perusratkaisut



Samankaltaiset tiedostot
Työpöytäintegraatio ja palvelurajapinnat - tilanne Suomessa ja muualla

PlugIT-projektin työsuunnitelma 3. jaksolle EHDOTUS johtoryhmälle, Koko projektin keskeiset tehtävät

Esityksen sisältö Määrittelyjen mukaisuudesta varmistuminen - PlugIT-leima

PlugIT / Ydin: teemat ja jaksojen 2-6 suunnitelma ( )

Järjestelmäarkkitehtuuri (TK081702) Web Services. Web Services

Ajanvarauksen avoimet rajapinnat

Järjestelmäarkkitehtuuri (TK081702) Avoimet web-rajapinnat

Järjestelmäarkkitehtuuri (TK081702) Lähtökohta. Integroinnin tavoitteet

Avoimen ja yhteisen rajapinnan hallintasuunnitelma v.1.4

PerustA - Perustietovarantojen viitearkkitehtuuri. Liite 3: Tietojärjestelmäarkkitehtuurin. integraatioarkkitehtuuri

Tiedonsiirto- ja rajapintastandardit

Yliopistollisten sairaanhoitopiirien klusteri

PlugIT-projektin rajapintojen määrittely, dokumentointi ja hyväksyminen

Järjestelmäarkkitehtuuri (TK081702)

Yhteentoimivuutta kokonaisarkkitehtuurilla

Sisällys. Valtion tietotekniikan rajapintasuosituksia. XML:n rooleja sähköisen asioinnin tavoitearkkitehtuurissa. dbroker - asiointialusta

Alueellisia kokemuksia elektronisen kertomuksen käytöstä

Muutos Tutkimusyhteistyösopimukseen. PlugIT: Terveydenhuollon sovellusintegraatio

Master data tietojen ja kriteeristön sekä hallintamallin määrittely ja suunnittelu TRE:933/ /2011

Alkuraportti. LAPPEENRANNAN TEKNILLINEN YLIOPISTO TIETOJENKÄSITTELYN LAITOS CT10A Kandidaatintyö ja seminaari

Tietojärjestelmien integroiminen hyödyntämällä palvelupohjaista arkkitehtuuria. CASE: Metropolia. Jaakko Rannila & Tuomas Orama 1

Yhteentoimivuusalusta: Miten saadaan ihmiset ja koneet ymmärtämään toisiaan paremmin?

Aluetietojärjestelmien migraatio kansallisten palveluiden käyttöön

Avoimen ja yhteisen rajapinnan hallintamalli

Terveydenhuollon avoimet sovellusrajapinnat - käyttäjä- ja käyttöoike usrajapinnat

Navitas. ratkaisu sosiaali- ja terveydenhuollon sähköiseen tiedonvälitykseen. Aluetietojärjestelmän ytimessä

Kansallisen terveysprojektin tarpeiden tyydyttäminen - asiakas- ja toimittajanäkökulma

Taltioni teknisen alustan arviointi

Paikkatietorajapinnat IT arkkitehtuurin näkökulmasta

A Service-Oriented Architecture (SOA) View of IHE Profiles

Sosiaali- ja terveydenhuollon tiedonhallinnan alueellista kehittämistä ohjaava viitearkkitehtuuri Kuntajohtajakokous

Sovellusarkkitehtuurit

Alueellisen ja valtakunnallisen arkkitehtuurin yhteensovittaminen

Kiila-viitearkkitehtuuri. Jani Harju,

PILETTI. Tekninen vaatimusmäärittely. v. 0.2

Integrointi. Ohjelmistotekniikka kevät 2003

PSSHP:n suun terveydenhuollon järjestelmähankinta Kohti alueellisen toiminnan ja teknisen ympäristön yhdenmukaistamista

Yksityisen ja julkisen terveydenhuollon raja-aidat kaatuvat Miten hallita alueellinen potilastiedon välittäminen

Muutos Tutkimusyhteistyösopimukseen. PlugIT: Terveydenhuollon sovellusintegraatio

Tietojärjestelmät muutoksessa: Alueiden ja kuntien sote - kokonaisarkkitehtuurityö

Sosiaalihuollon asiakasasiakirjojen standardointi


Uutisjärjestelmä. Vaatimusmäärittely. Web-palvelujen kehittäminen. Versio 1.3

KODAK EIM & RIM VIParchive Ratkaisut

Sosiaalihuollon valtakunnallisten tjpalveluiden. I-vaihe

KANSALLISTEN MÄÄRITYSTEN HYÖDYNTÄMINEN POTILASTIETOJÄRJESTELMISSÄ Pegasos - hanke

Käyttäjien tunnistaminen ja käyttöoikeuksien hallinta hajautetussa ympäristössä

Harjoitustyö Case - HelpDesk

Sähköinen asiointi ja palvelut Miten tästä eteenpäin?

Kuntasektorin asianhallinnan viitearkkitehtuuri 1.0. Kuntamarkkinat Tuula Seppo, erityisasiantuntija

Liittymät Euroclear Finlandin järjestelmiin, tietoliikenne ja osapuolen järjestelmät Toimitusjohtajan päätös

UNA PoC-yhteenveto CGI Aino Virtanen

1 Muutosten taustaa Lääketietokantamuutosten strateginen päämäärä Muutokset Lääketietokannan tietosisältöön ja XML-skeemaan...

Vaatimusmäärittely Ohjelma-ajanvälitys komponentti

TOIMIJAREKISTERIN TOTEUTUKSEN JA YLLÄPIDON HANKINTA - HANKINNAN YKSI- LÖINTI HUOM!

Alkuraportti. LAPPEENRANNAN TEKNILLINEN YLIOPISTO TIETOJENKÄSITTELYN LAITOS Ti Kandidaatintyö ja seminaari

KJ-info Yhteinen Effica askelmerkit

G4-arkkitehtuuriryhmä. Kokonaisarkkitehtuurityöhön perustuvat kehittämiskohteet ja toimenpiteet. Juha Rannanheimo

Kuntien Kansalliseen palveluarkkitehtuuriin liittyminen. Kunta-KaPA

Järjestelmäarkkitehtuuri (TK081702) SOA, Service-oriented architecture SOA,

KAMU alueellisen laboratoriojärjestelmän käytännön toteutuksen arkea

Avoimet standardit ja integraatio

IT-OSAAJA, TIETOJENKÄSITTELYN ERIKOISTUMISOPINNOT

Käyttövaltuushallinnan hyödyt tehokkaasti käyttöön. Johanna Lampikoski, RM5 Software Juha Arjonranta, TeliaSonera Finland

Yhteentoimivuusvälineistö

Yhteiset maakunnalliset asiakas- ja potilastietojärjestelmäratkaisut

TOIMITUSSOPIMUS ASIAKAS- JA POTILASTIETOJÄRJESTELMÄSTÄ

Käytönvalvonnan yhtenäistäminen ja tehostaminen organisaation ja kansalaisen kannalta

Ydinpalvelurajapinnat (käyttäjä, käyttöoikeus, potilas): Tekninen liittymämäärittely http- ja XML-tekniikoilla Versio 2.

PerustA - Perustietovarantojen viitearkkitehtuuri. Liite 3: Tietojärjestelmäarkkitehtuurin. integraatioarkkitehtuuri

Ristiinopiskelun kehittäminen -hanke

Liiketoimintajärjestelmien integrointi

KANTA-TULEVAISUUS- SKENAARIOTYÖN TILANNEKATSAUS Riikka Vuokko, STM

Liiketoimintajärjestelmien integrointi

TYÖPYÖTÄINTEGRAATION AVOIMET SOVEL- LUSRAJAPINNAT

- Korkeakoulutuksen ja tutkimuksen (linkitetty) tietomalli

Kelan lääkärinlausuntolomakkeiden uudistaminen (LLAUS)

SEPA REFAKTOROINTI Antti Ahvenlampi, 57408L Erik Hakala, 57509T

Veronumero.fi Tarkastaja rajapinta

SUOMEN KUNTALIITTO RY

Opetus- ja koulutusyhteistyöhön liittyvä korkeakoulujen tietojärjestelmien yhteentoimivuuden kehittäminen ja arkkitehtuurityö

Tavoitteena vaikuttavat ja tasaarvoiset

HP OpenView ratkaisut toiminnan jatkuvuuden turvaajina

Työkalut ohjelmistokehityksen tukena

Muistitko soittaa asiakkaallesi?

Tehokasta palkanlaskentaa

Projektin tilannekatsaus

Yhteisen tiedon hallinta -hanke Eli YTI

Kokonaisarkkitehtuuri julkisessa hallinnossa. ICT muutostukiseminaari neuvotteleva virkamies Jari Kallela

Järjestelmäarkkitehtuuri (TK081702) Yritysarkkitehtuuri. Muutostarpeet

Mikko Rotonen on IT-kehitysjohtaja HUS Tietohallinossa ja APOTTI-hankkeen IT-osuuden projektipäällikkö.

Yhteentoimivuusalusta ja Sanastot-työkalu

Kohti paperitonta potilaskertomusta. Asko Nieminen Asiantuntijalääkäri PSHP Tietohallinto

SecGo. Sähköinen allekirjoitus ja sen käyttö. Ari-Pekka Paananen, SecGo VE Oy Director,technology

Tietojärjestelmä tuotantoympäristössä. Sovellusohjelmat Helsingin ammattikorkeakoulu Stadia / Tekniikka ja liikenne Vesa Ollikainen

Yhteinen kansallinen koodistopalvelu ( Suomi.fi koodistopalvelu )

SOLEA palvelupohjainen paikallisesti sovitettava kokonaisarkkitehtuuri. Service-Oriented Locally adapted Enterprise Architecture

Yhteentoimiva.suomi.fi - palvelukokonaisuuden ja työkalujen esittely

Perustietovarantojen rajapintaratkaisun sidosryhmät - yhteenveto PERA-määrittely Liite 2

OTM-HANKE. Opintohallinnon tietojärjestelmän modernisointi - tilannekatsaus

Transkriptio:

PLUGIT-HANKKEEN SELVITYKSIÄ JA RAPORTTEJA 7 STUDIES AND REPORTS OF THE PLUGIT PROJECT 7 Marko Sormunen, Jari Porrasmaa, Juha Rannanheimo, Juha Mykkänen, Saara Savolainen Terveydenhuollon avoimet sovellusrajapinnat - yhteiset perusratkaisut KUOPION YLIOPISTO SAVONIA-AMMATTIKORKEAKOULU KUOPIO 2004

Tekijät: Marko Sormunen Jari Porrasmaa Juha Mykkänen Saara Savolainen HIS-tutkimusyksikkö Kuopion yliopisto Juha Rannanheimo Savonia Business Savonia-ammattikorkeakoulu Myynti: Tietotekniikkakeskus / kanslia Kuopion yliopisto puh. 017-162 802 www.plugit.fi tike@uku.fi ISBN 951-781-473-9 (koko teos) ISBN 951-27-0226-6 (osa 7) ISBN 951-27-0246-0 (PDF) Kopijyvä Oy, Kuopio 2004

Sormunen, Marko; Porrasmaa, Jari; Rannanheimo, Juha; Mykkänen, Juha; Savolainen, Saara. Terveydenhuollon avoimet sovellusrajapinnat yhteiset perusratkaisut. PlugIT-hankkeen selvityksiä ja raportteja 7. 35 s. 2004. ISBN 951-781-473-9 (koko teos) ISBN 951-27-0226-6 (osa 7) ISBN 951-27-0246-0 (PDF) Tiivistelmä Osa terveydenhuollon organisaatioiden käyttämien sovellusten integrointitarpeista voidaan ratkaista käyttämällä ohjelmistopalveluja, joiden tarjoamien rajapintojen kautta useat sovellukset voivat hyödyntää keskitetysti ylläpidettyjä tietoja ja palveluita. Tässä selvityksessä kuvataan PlugIThankkeessa vuosina 2001-2004 selvitettyjä tarpeita ja kehitettyjä perusratkaisuja, jotka luovat perustan eri tarpeisiin vastaavien keskitettyjen ohjelmistopalvelujen kehittämiselle. Selvityksessä esitellään PlugIT-hankkeessa tunnistetut palvelurajapinnat, kuvataan keskitettyjen palveluiden tavoitteita ja niiden avulla tavoiteltavia hyötyjä, esitellään eri palveluiden yhteiset perusratkaisut, arkkitehtuuri ja rajapintatekniikat sekä hahmotellaan palvelumäärittelyiden tulevaisuuden ratkaisuja. Selvityksessä kuvattuja perusratkaisuja hyödyntävät eri kohteisiin tarkemmin määritellyt rajapinnat, joista on julkaistu erillisiä selvityksiä. Näitä tarkempia rajapintoja (ja niitä vastaavia selvityksiä) ovat Terveydenhuollon avoimet sovellusrajapinnat - käyttäjä- ja käyttöoikeusrajapinnat, Terveydenhuollon avoimet sovellusrajapinnat - potilasrajapinnat ja Terveydenhuollon avoimet sovellusrajapinnat - koodistorajapinnat. Yleinen kymmenluokittelu UDK: 681.3, 006 Asiasanat (YSA): tiedonhallinta, tietojärjestelmät, tietokannat, systeemityö, tiedonhallintajärjestelmät, ohjelmointi, terveydenhuolto, tietoteollisuus Medical Subject Headings (MeSH): medical informatics, information systems, information management, database management systems, software, health care sector, hospital information systems

Esipuhe Tämä selvitys on tehty PlugIT-hankkeessa vuosina 2001-2004. Selvityksen tavoitteena on kuvata tarpeet, tavoitellut hyödyt ja eri palveluille yhteiset ratkaisut, joiden pohjalta PlugIT-hankkeessa on määritelty sovellusten yhteisten palvelujen rajapintoja. Selvityksen pohjaratkaisuja on tarkennettu eri kohteisiin vastaavissa palvelumäärityksissä. Selvitys on suunnattu terveydenhuollon tietohallinnon ja sovellustuotannon ammattilaisille sekä järjestelmien hankinnasta sekä integroinnista vastaaville tahoille. PlugIT-hanketta ovat rahoittaneet ja siihen ovat osallistuneet TEKES, Mawell konserni, Medimaker Oy Ltd, Medici Data Oy, Mediweb Oy, Mylab Oy, Tietoenator Oyj, WM-data Novo Oyj, Atkos Oy, BEA Systems Oy, Commit; Oy, Enfo Oy, Fujitsu Services Oy, General Electric Healthcare CIS EMEA, Mediconsult Oy, Microsoft Oy, Oracle Finland Oy, Helsingin ja Uudenmaan sairaanhoitopiirin kuntayhtymä, Pirkanmaan sairaanhoitopiirin kuntayhtymä, Pohjois-Savon sairaanhoitopiirin kuntayhtymä, Pohjois-Pohjanmaan sairaanhoitopiirin kuntayhtymä, Satakunnan sairaanhoitopiirin kuntayhtymä, Varsinais-Suomen sairaanhoitopiirin kuntayhtymä, Kuopion kaupungin sosiaali- ja terveyskeskus sekä Siilinjärven ja Maaningan terveydenhuollon kuntayhtymä. Kiitämme projektiin osallistuneiden yritysten ja sairaaloiden edustajia sekä rajapintatyöhön osallistunteita työntekijöitä hyvistä ideoista ja näkökulmista. Kuopiossa 31. elokuuta 2004 Tekijät

Sisällys 1 JOHDANTO...8 1.1 Taustaa...8 1.2 Rajapintojen määrittely...9 1.3 Raportin sisältö ja käsitteet...9 2 YDINJÄRJESTELMIEN AVOIMET SOVELLUSRAJAPINNAT...12 2.1 Tavoitellut hyödyt...12 2.2 Tunnistetut integraatiokohteet...14 2.2.1 Työpöytäintegraatio ja kontekstinhallinta...14 2.2.2 Ydinpalveluiden sovellusrajapinnat...15 3 PALVELUKESKEINEN INTEGRAATIO JA PLUGIT-YDINPALVELUJEN PERUSRATKAISUT...18 4 PLUGIT-RAJAPINTOJEN TOTEUTUS HTTP/XML- TEKNIIKALLA...21 4.1 Arkkitehtuuri...21 4.2 HTTP-viestinnän asettamat rajoitukset...22 4.3 Esimerkki HTTP-sanomasta ja vastauksesta...23 4.4 Liittimien käyttö HTTP-viestinnän piilottamiseen...23 4.5 Ydinpalvelukutsujen XML-sisältökäytännöt...24 4.6 HTTP-sanomat ja turvallisuus...25 4.6.1 HTTPS (XML-sisällön suojaus kuljetustasolla)...25 4.6.2 XML-sisällön suojaaminen sovellustasolla...26 4.7 Ydinpalvelujen käyttökaavioita...27 4.7.1 Kupongin elinkaari...31 5 JATKOKEHITYS...33 6 LÄHTEET...34

1 JOHDANTO 1.1 Taustaa Terveydenhuollon tietojärjestelmiä käyttävät lääkärit, hoitajat, sihteerit ja tulevaisuudessa myös lisääntyvässä määrin potilaat. Monissa hoitotilanteissa ja muissa tehtävissä tarvitaan useita eri järjestelmiä, mutta toimintaa ei ole huomioitu riittävästi järjestelmien suunnittelussa. Tästä syystä samoja tietoja joudutaan kirjaamaan moneen järjestelmään. Toiminnot voivat olla päällekkäisiä tai niihin ei voida siirtyä sujuvasti eri järjestelmien välillä. Terveydenhuollon asiakkaiden tulisi kokea terveydenhuollon hoitoketju saumattomana, eivätkä eri palveluntuottajien väliset organisaatiorajat saisi haitata tiedon kulkua. Ohjelmistotoimittaja haluaisi pitää tuotteensa yhtenäisenä eri asiakkaiden välillä, sillä erilaisten versioiden ja konfiguraatioiden hallinta aiheuttaa lisäkustannuksia. Korpela ja Saranto ovat luokitelleet terveydenhuollon tietojärjestelmät palvelujärjestelmän rakenteen mukaisesti perusterveydenhuollon ja erikoissairaanhoidon tietojärjestelmiin. Erikoissairaanhoidon tietojärjestelmiin kuuluvat toimialariippumattomat hallinnon tietojärjestelmät ja potilastietojärjestelmät. Potilastietojärjestelmät voidaan jakaa potilashallinnon ydinjärjestelmiin ja yksikkö- tai käyttötarkoituskohtaisiin erillisjärjestelmiin. Laboratorion, radiologian, teho-osaston ja leikkausosaston tietojärjestelmät ovat esimerkkejä erillisjärjestelmistä. Potilashallinnon ydinjärjestelmiin kuuluvat kaikkialla hoitoprosessissa tarvittavat yleiset palvelut, esimerkiksi potilaan perustiedot, ajanvaraus ja sisäänkirjaus. (Korpela, Saranto 1999) Potilashallinnollisten tietojen avulla ohjataan ja avustetaan potilaan hoidon järjestämistä, hoitoon ottamista, potilaan tutkimusta ja hoitoa sekä hoidon päättämistä koskevaa tietoa. (Hartikainen ym. 2000) Erikoissairaanhoidossa potilashallinnon ydinjärjestelmät ovat perinteisiä tietojärjestelmiä, kuten Musti-, Aho- ja Sapo- tietojärjestelmät. Näiden tietojärjestelmien uusiminen on ajankohtaista lähivuosina ja vanhojen tietojärjestelmien tilalle ollaan hankkimassa esimerkiksi MD-Oberon tai Effica- potilastietojärjestelmää. (Hartikainen ym. 2002) Nykyisin erikoissairaanhoidossa käytössä oleviin potilashallinnon ydinjärjestelmiin on integroitu runsaasti erillisjärjestelmiä. Hallittu siirtymä uusiin ydinjärjestelmiin edellyttää hyvin määriteltyjä liittymiä ydinjärjestelmien palveluihin, jotta nykyiset ja tulevat erillisjärjestelmät saadaan yhteistoiminnallisiksi ytimen kanssa. Perusterveydenhuollossa tietojärjestelmätarpeet on ratkaistu yhden toimittajan kokonaisvaltaisella ratkaisulla (Finstar, Effica, Pegasos). Näihin tietojärjestelmiin sisältyy potilaskertomus ja niissä voidaan erottaa tietokokonaisuutena esimerkiksi potilastiedot (Tolppanen 1999). Muuttuvan toimintajärjestelmän, integroinnin, yhteistoiminnallisuuden ja eri tekniikoiden huomiointi ovat keskeisiä haasteita terveydenhuollon tietojärjestelmäkehityksessä (Kuhn, Giuse 2001). Erikoissairaanhoidossa integraation tarve on selkeä ja myös perusterveydenhuollossa tapahtuva uusien tautikohtaisten ja alueellisten tietojärjestelmien käyttöönotto aiheuttaa integraatiotarpeita. Esimerkiksi alueellinen diabetesjärjestelmä on koettu hyödylliseksi, mutta samojen tietojen kirjaaminen sekä diabetes- että potilastietojärjestelmään on ongelmallista (Häyrinen 2002). Terveydenhuollon organisaatioiden tietojärjestelmäympäristöt ovat hyvin monimuotoisia ja poikkeavat toisistaan. Jotta integraatiot saadaan toteutettua tehokkaasti, tarvitaan yhteistä sopimista kaikkien osapuolien välillä. 8 PLUGIT-HANKKEEN SELVITYKSIÄ JA RAPORTTEJA 7

1.2 Rajapintojen määrittely Tietojärjestelmiä voidaan pyrkiä muuttamaan yhteensopiviksi eri tavoin. PlugIT-hankkeessa on kehitetty malli avointen rajapintamäärittelyjen toteuttamiseen (Mykkänen ym. 2004b). Mallin tavoitteena on kolmikantayhteistyö hankkeen työntekijöiden, terveydenhuollon organisaatioiden ja yritysten välillä, jotta eri näkökulmat saadaan mukaan määrittelyihin. Tavoitteena on myös määrittelyjen tuottamisprosessin keveys. Lisäksi prosessiin on voitava tuoda yrityksissä tai terveydenhuollon organisaatioissa tehtyjä yhteentoimivuuden määrittelyitä (bottom-up) tai tuottaa toimintaprosessilähtöisen mallintamisen kautta uusia määrityksiä (top-down) integraatiotarpeisiin. PlugITissa määritellyssä integrointiprosessissa on neljä päävaihetta: projektinsuunnittelu, vaatimusmäärittely, liittymän määrittely ja toteutus. Määrittelyvaiheessa pyritään ensin tunnistamaan integrointiratkaisun sisältö ja perusratkaisut, minkä jälkeen siirrytään valituilla rajapintatekniikoilla tehtävään tekniseen määrittelyyn. Toteutusvaiheessa määritelty rajapinta toteutetaan ja otetaan käyttöön sovelluksissa. Määrittelyissä on pyritty kiinnittämään huomiota siihen, että järjestelmäkokonaisuuden tulee tukea myös koko organisaation toimintaa ja perustana tulee olla toimintalähtöiset tarpeet ja toiminnalliset vaatimukset. Tyypillisiä tavoitteita tämän dokumentin mukaisissa ratkaisuissa ovat, ettei käyttäjän tai ylläpitäjän tarvitse tehdä samoja toimintoja tai kirjata samoja tietoja useasti. Lisäksi määrittelyissä tulee huomioida osaltaan olemassa olevien järjestelmien toiminnallisuus, arkkitehtuuri ja tekniikka kuin myös käytettävissä olevat uudet tekniikat, standardit ja menetelmät. Tavoitteena on, että avointen rajapintamääritysten avulla integroinnista tulee sovellusriippumatonta, paikallinen räätälöinti vähenee ja kyseiset ratkaisut ovat uudelleenkäytettäviä. 1.3 Raportin sisältö ja käsitteet Tässä raportissa kuvataan PlugIT-hankkeessa kartoitetut yleiset vaatimukset ja kehitetyt ratkaisut, joihin hankkeen palveluiden rajapintamääritykset pohjautuvat. Tarkemmista rajapintamäärityksistä on julkaistu erilliset raportit (ks. luku 2.2) ja kussakin tarkemmassa määrittelyssä kuvataan tarkemmin, mitä tekniikoita järjestelmien välisen liittymän toteutuksessa käytetään, mitä toimintoja järjestelmät toisilleen tarjoavat ja mikä on ratkaisuun liittyvä tietosisältö näillä tekniikoilla. Luvussa 2 esitellään ydinpalveluiden perusteita, tavoiteltuja hyötyjä sekä luettelo PlugIT-hankkeen näihin palveluihin liittyvistä integrointikohteista. Luvussa 3 kuvataan palvelukeskeisessä integroinnissa huomioon otettavia seikkoja ja tehtyjen ratkaisujen perusteita. Luvussa 4 kuvataan rajapintojen määrittelyssä tehtyjä arkkitehtuurillisia ja teknisiä ratkaisuja, jotka ovat yhteisiä useille tuotetuista määrittelyistä. Luvussa 5 käsitellään rajapintojen jatkokehitykseen ja vastaavantyyppisten muiden integrointitarpeiden ratkaisuun liittyviä kysymyksiä. Taulukossa 1.1 on lueteltu muutamia raportissa käytettyjä käsitteitä. asiakassovellus, sovellus, erillisjärjestelmä, erillissovellus HTTP-lähettäjä Taulukko 1.1. Raportissa käytettyjä käsitteitä. Mikä tahansa terveydenhuolto-organisaation tietojärjestelmäkokonaisuuden osa, joka on tarkoitettu tietyn erityisen osatoiminnan tukemiseen. Voi olla erillinen kliininen tai potilashallinnollinen sovellus tai osa laajempaa kokonaisjärjestelmää, kertomusjärjestelmä, portaali, aluetietojärjestelmä, yms. Tämän dokumentin puitteissa tarkoittaa yleensä mitä tahansa sovellusta, joka on yhteydessä ydinpalveluihin. Komponentti, joka lähettää HTTP-sanoman johonkin ennalta määrättyyn verkko-osoitteeseen (URL) ja jää kuuntelemaan HTTP-vastausta. TERVEYDENHUOLLON AVOIMET SOVELLUSRAJAPINNAT - YHTEISET PERUSRATKAISUT 9

HTTP-vastaanottaja integraatio komponentti Itsenäinen, uudelleenkäytettävä ja selvästi rajattu ohjelmisto-osa, jota käytetään pienempänä osana tietojärjestelmän rakentamisessa. Komponentti tarjoaa palveluitaan (suorittaa tiettyjä tehtäviä) rajapintojen kautta. kontekstinhallintapalvelu, kontekstinhallinta kuljetustaso kuponki, sessiokuponki liittymä palvelukutsutoteutus palvelurajapinta palvelutoteutus Komponentti, joka kuuntelee jotain tiettyä TCP/IP-porttia ottaa vastaan HTTP-sanomia ja palauttaa HTTP-vastauksen. Järjestelmien eheyttämistä, sulauttamista tai yhtenäisen kokonaisuuden muodostamista, jolla pyritään tehostamaan järjestelmien käyttöä ja sitä kautta toimintaprosessia, jossa järjestelmiä käytetään. PlugIT-hankkeessa määritelty kontekstinhallintapalvelu toimii tietovarastona, jonne voidaan tallentaa tietoa kuten käyttäjän tunnistetiedot ja valittu potilas. Samalta työasemalta yhteyttä ottavat sovellukset voivat palvelun avulla jakaa ja synkronoida tietoa keskenään. Esimerkiksi sovellus voi käynnistyessään tarkistaa kontekstinhallintapalvelusta, onko samalta työasemalta jo jossain toisessa aktiivisessa sovelluksessa valittu potilas ja onko se potilas asetettu yhteiseen kontekstiin. Tällöin loppukäyttäjän ei tarvitse hakea käynnistyvässä sovelluksessa enää potilasta vaan potilaan tunnistetiedot voidaan hakea kontekstinhallintapalvelusta. Lisäksi kontekstinhallintapalvelu mahdollistaa kertakirjautumisen. Taso HTTP/XML -arkkitehtuurissa, joka hoitaa HTTP-sanoman toimittamisen HTTP-lähettäjältä HTTP-vastaanottajalle ja vastauksen palauttamisen lähettäjälle. Tilallisissa PlugIT-ydinpalveluissa jokaisella ydinpalveluja käyttävällä sovelluksella täytyy olla käytössään voimassa oleva kuponki. Kuponki on lisäksi varmennettu, jos se on yhdistetty johonkin varmennettuun käyttäjään/työasemaan tai jos se voidaan todeta varmennetuksi jollain muulla tavalla. Jokainen voimassa oleva kuponki liittyy siis johonkin työasemaan ja jokainen varmennettu kuponki liittyy lisäksi johonkin käyttäjään. Yhtymäkohta kahden tai useamman järjestelmän välillä, joka mahdollistaa tietojen siirron niiden välillä. Avoimella liittymällä tarkoitetaan useamman osapuolen hyväksymää, yhteisesti sovittua liittymää Yhden ydinpalvelukutsun toiminnallisuuden toteuttava luokka tai muu palvelu. Ohjelmistorajapinta, jonka kautta sovellus tarjoaa ohjelmistopalveluita (operaatioita, suorittaa tehtäviä) toiselle sovellukselle Ohjelmakomponentti, luokka tai muu kokonaisuus, joka sisältää itse palvelun toteutuksen eli toteuttaa palvelurajapinnan. Voidaan puhua esim. potilaan perustietojen hakupalvelusta 10 PLUGIT-HANKKEEN SELVITYKSIÄ JA RAPORTTEJA 7

rajapinta sovellustaso toiminnallinen määrittely ydinjärjestelmä ydinpalvelutoteuttaja ydinpalvelutoteutus Rajapinta (ohjelmointirajapinta = application programming interface, API) on järjestelmien tai niiden osien välinen kosketuspinta, jonka avulla eri osia liitetään yhteen. Kahden fyysisen tai abstraktin olion välinen tai ne yhteenliittävä käytäntö (Atk-sanakirja 2001). Tässä tarkoitetaan sovellusliittymää, jonka kautta ohjelmisto tarjoaa tai käyttää toisen (varus- tai sovellusohjelmiston) palveluja. Ohjelmointirajapinta on rajapinta, jota sovelluksen rakentaja käyttää sovelluksen rakentamisessa Taso HTTP/XML arkkitehtuurissa, jolla sovellus ja ydinpalvelutoteutukset toimivat. Toiminnallisessa määrittelydokumentissa keskitytään toiminnalliseen (käyttäjän tai kokonaisoptimoinnin) näkökulmaan, mutta myös olemassa olevien sovellusten toiminnallisuus ja niissä käytetyt arkkitehtuuriratkaisut saavat näkyä jonkin verran toiminnallisessa määrittelyssä. Pyrkimys on kuitenkin siihen, että eri tekniikoilla ja arkkitehtuureilla toteutetut sovellukset voivat noudattaa samaa toiminnallista liittymämäärittelyä. Terveydenhuollon organisaation (sairaalan tai terveyskeskuksen tms.) tietojärjestelmän ne osat, joissa ylläpidetään keskitetysti tärkeimpiä yhteisiä tietoja, kuten potilastietoja, käyttäjätietoja, koodistotietoja, yms. Voi olla yksi tai useampia erillisiä ydinkomponentteja tai - sovelluksia tai osa kokonaisjärjestelmää (esim. monoliittista perinnejärjestelmää). Osapuoli, joka toteuttaa ydinpalvelut. Palvelinsovellus, joka toteuttaa PlugIT-projektissa määritellyt ydinpalveluiden rajapinnat (käyttäjän varmennus-, käyttöoikeus-, profiili- ja koodistorajapinnat) tai osan niistä. TERVEYDENHUOLLON AVOIMET SOVELLUSRAJAPINNAT - YHTEISET PERUSRATKAISUT 11

2 YDINJÄRJESTELMIEN AVOIMET SOVELLUSRAJAPINNAT Yhtenä ratkaisuna järjestelmien yhteensopimattomuuteen pidetään keskeisempien tietojärjestelmätoimintojen integroimista ja yhteensovittamista (Picnic 2002). Terveydenhuollon järjestelmäkokonaisuus saadaan palvelemaan käyttäjiä entistä paremmin, kun ydinjärjestelmän ja erillisjärjestelmien välille toteutetaan liittymiä, jotka mahdollistavat yhteistoiminnallisuuden niiden välillä. Hajautettujen palvelujen tai komponenttien toteuttamista useiden sovellusten hyödynnettäväksi on jo aiemminkin kuvattu useissa eri yhteyksissä, mm. kehitysprojekteissa ja standardeissa. Hajautettujen palveluiden avulla vähennetään päällekkäisiä osia järjestelmissä käyttämällä esimerkiksi yhteistä käyttäjänhallinta- tai potilaskomponenttia eri toimittajien sovellusten osana. Ideana on, että erillisjärjestelmissä saadaan käyttöön kaikkien sovellusten tarvitsemat yhteiset ydinpalvelut tai -komponentit mahdollisimman helposti. Siksi näille palveluille on tarpeen määritellä avoimet rajapinnat, joilla tarkoitetaan useamman osapuolen hyväksymää, yhteisesti sovittua määritystä. Rajapintojen määrittelyssä tavoitteena ovat ratkaisut, jotka sopivat määriteltyihin integrointitarpeisiin siten, että ne voidaan toteuttaa eri ohjelmistoihin (PlugIT 2001). Tavoitteeseen päästään tekemällä määritykset yhteensopiviksi kansallisen ja kansainvälisen standardoinnin kanssa ja käyttämällä avointa määrittelyprosessia sekä avoimia tekniikoita. Terveydenhuollon sovellusten palvelumäärityksiin liittyvät merkittävimmät kansainväliset standardointiyhteisöt ovat Health Level 7 (HL7), European Committee for Standardization (CEN) ja Object Management Group (OMG). OMG ja CEN ovat määritelleet yleisen palvelun standardeja. OMG:n Healthcare Domain Task Force:n standardeissa ja CEN:in HISA-standardissa määritellään palveluita henkilön tunnistukseen sekä terveydentilaan liittyvien tietojen, käyttöoikeuksien ja sanastojen hallintaan. CEN:in HISAstandardi määrittelee myös palveluita, jotka liittyvät terveydenhuolto-organisaatioissa suoritettaviin toimenpiteisiin liittyviin tietoihin ja erilaisten resurssien hallintaan (Savolainen 2004). PlugIThankkeessa laadittiin kartoitusta standardeista ja arvioitiin, mitkä standardit soveltuvat käytettäväksi Suomessa. Yhteensopivuus kansainvälisten ja käytössä olevien standardien kanssa on eräs ohjelmistojen vientimahdollisuuksia edistävä tekijä (Mykkänen ym. 2004a). Määrittelyissä voidaan hyödyntää myös olemassa olevia ratkaisuja ja laajentaa niitä toiminnallisesti yhteensopivaksi muiden järjestelmien kanssa. Kun määrittelyt ovat avoimia, ydinpalveluja tai -komponentteja voivat suunnitella ja tuottaa kaupallisesti eri ohjelmistoyritykset. (PlugIT 2001). 2.1 Tavoitellut hyödyt Integraatioista (ydinpalvelut, kontekstinhallinta) saatavia hyötyjä voidaan tarkastella eri sidosryhmien, kuten potilaan, järjestelmän käyttäjän, ohjelmistoyrityksen ja terveydenhuollon organisaation näkökulmista (Kuva 2.1). Yhteisten palvelujen rajapintojen toteutuksista hyötyvät suoraan ohjelmistoyritykset ja terveydenhuollon organisaatiot. Välillisesti niistä on hyötyä myös tietojärjestelmien käyttäjille ja potilaille. Ohjelmistoyrityksen näkökulmasta yhteisesti sovitut rajapinnat vähentävät kahdenvälisen integraation tarvetta useimmin toistuvissa integrointitilanteissa, mikä osaltaan vähentää päällekkäisen työn tekemistä. Käyttöönottovaihe nopeutuu, jos asiakkaan järjestelmäympäristössä on saatavilla yleisiä rajapintoja toteuttavia ohjelmistoja. Jos liittymäpohjainen ajattelu viedään pidemmälle, voidaan yrityksen tekemä tuotekokonaisuus jakaa itsenäisiin osiin ja ohjelmistokehitystyötä voidaan tehdä rinnakkain eri osien välillä, tai nojautua kumppaneilta saatavien komponenttien tarjoamiin 12 PLUGIT-HANKKEEN SELVITYKSIÄ JA RAPORTTEJA 7

palveluihin. Nopeutuvan ohjelmistokehityksen ansiosta tuote saadaan nopeammin markkinoille. Lisäksi yritys on kilpailukykyinen myös kansainvälisillä markkinoilla, jos sen ohjelmistorajapinnat ovat toiminnallisesti yhteensopivia kansainvälisten standardien kanssa. Rajapintojen ansiosta sovelluksen tai sen osan sisäinen toteutus voidaan vaihtaa siten, että se ei aiheuta muutostarpeita naapurisovelluksiin. Rajapintoja voidaankin hyödyntää myös esim. siirryttäessä perinnejärjestelmistä uusiin järjestelmiin, jos samat rajapinnat toteutetaan sekä perinnejärjestelmään että sen tilalle tulevaan järjestelmään. Terveydenhuollon organisaatio eli palveluntuottaja saa nopeutuneen käyttöönoton lisäksi paremmat mahdollisuudet valita käyttöönsä sopivia sovelluksia osaksi kokonaisjärjestelmäänsä, ja voi tarvittaessa vaihtaa (osa)järjestelmän helpommin toiseen tuotteeseen. Palveluntuottaja voi helpommin yhdistellä eri toimittajien tekemiä sovelluksia haluamakseen kokonaisuudeksi tehostaakseen toimintaansa. Jos eri toimittajien tuotteet sisältävät yleisten määritysten mukaisia rajapintoja, paikallisesti tehtävät ratkaisut vähenevät, mikä puolestaan alentaa kustannuksia. Keskitettyjen rajapintojen avulla ylläpitotyö, jossa samoja tietoja päivitetään useisiin järjestelmiin, vähenee. Lisäksi tiettyä keskitettyä rajapintaa tarjoavaa ohjelmistoa voidaan pitää auktorisoituna tietolähteenä, joka toimii oikean ja ajan tasalla olevan tiedon sovittuna säilytyspaikkana. Suorat hyödyt Ohjelmistokehityksen nopeutuminen ja laadun paraneminen Päällekkäisen tiedon ja työn väheneminen Käyttöönoton helpottuminen Ohjelmistoyritys Terveydenhuollon organisaatio Välilliset hyödyt Järjestelmämuutosten rajaaminen Auktorisoidun tietolähteen nimeäminen Kilpailukyvyn paraneminen Kustannussäästöt ja toiminnan tehostuminen Käyttäjä Työnkulkua tukeva järjestelmäkokonaisuus Potilas Palvelun sujuvuuden paraneminen Kuva 2.1. Ydinpalvelujen käyttöönotossa tavoiteltuja hyötyjä. TERVEYDENHUOLLON AVOIMET SOVELLUSRAJAPINNAT - YHTEISET PERUSRATKAISUT 13

Hyötyjen toteutuminen edellyttää, että rajapinnat on toteutettu ydinjärjestelmään ja riittävän moniin erillisjärjestelmiin. Lisäksi rajapintojen täytyy olla niin tarkkoja, ettei tapauskohtaisia poikkeamia tarvita tai että poikkeukset ovat hallittavissa ilman vaikutuksia naapurisovelluksiin. Rajapintojen toteuttaminen parantaa järjestelmien yhteistoiminnallisuutta, minkä myötä käyttäjä voi helpommin siirtyä eri sovelluksesta toiseen ja samoja tietoja ei tarvitse kirjata useaan kertaan. Integroituvat sovellukset muodostavat yhtenäisen kokonaisuuden, joka tukee paremmin työnkulkua. Potilaan kannalta hyödyllistä on se, että hoitohenkilökunnalle jää enemmän aikaa keskittyä potilaiden hoitoon. Potilaan hoidon sujuvuus paranee, kun hoitotapahtumassa tarvittava tieto on oikeassa paikassa oikeaan aikaan. Yleisiä palvelurajapintoja voidaan usein hyödyntää myös suoraan asiakkaille kohdistetuissa ohjelmistoissa ja palveluissa. Onnistuneeseen rajapintojen määrittelyyn, tuottamiseen ja testaukseen ja standardien soveltamiseen tarvitaan menetelmiä ja menettelytapoja. PlugIT-hankkeen määrittely- ja toteutuskokemusten myötä on saatu aikaan validoituja menetelmiä ja ohjeita sekä avoimiin että tapauskohtaisiin järjestelmäintegraatioprojekteihin (Mykkänen ym. 2004a-c). 2.2 Tunnistetut integraatiokohteet PlugIT-hankkeessa tarkasteltavien ja määriteltävien rajapintojen valinnassa on hyödynnetty kansainvälisiä standardeja, erityisesti HL7- ja OMG Healthcare-standardeja (HL7 1999, Corbamed 2000, Savolainen 2004), Picnic-komponentteja (Picnic 2002) sekä tunnistettuja suomalaisen terveydenhuollon vaatimuksia. Kaikissa tunnistetuissa kohteissa määrittelyjä ei ole ollut valmiiksi saatavilla jo tehdyistä standardeista, vaan PlugIT-hankkeessa määritellyt rajapinnat ovat täsmentyneet hankkeen aikana eri osapuolten kanssa käydyissä keskusteluissa sekä puolivuosittaisten seminaarien työpajoissa. Tässä dokumentissa kuvattujen rajapintojen määrittelytyö alkoi marraskuussa 2002. Määriteltävissä kohteissa käynnistyi aluksi integrointivaatimusten kokoaminen, joka tehtiin yhteistyössä hankkeessa mukana olevien terveydenhuollon organisaatioiden ja ohjelmistoyritysten kanssa. Kohteissa on sovellettu hankkeen rajapintojen määrittely- ja pilotointiprosessia (Mykkänen ym. 2004b). Integrointivaatimukset koottiin analysoimalla nykytilaa sekä selvittämällä tavoitetilaa kyselyillä, tapaamisilla ja työpajatyöskentelyllä. Vaatimusten hankintaan käytettiin mm. järjestettyjä työpajoja, osapuolten välisiä tapaamisia ja keskusteluita sekä tehtyä terveydenhuollon ohjelmistotuotannon nykytilaselvitystä (Porali ym. 2004). Vaatimusmäärittelyjen pohjalta laadittiin tekniikkariippumattomia määrittelyitä, joissa esitettiin rajapintojen toiminta, tietosisältö ja perusratkaisumallit. Tekniikkariippumattomat määrittelyt toimivat pohjadokumentteina rajapintojen teknisille määrittelyille, joihin toteutukset puolestaan perustuvat (ks. myös luku 3). Tuotettuja rajapintamäärityksiä on pyritty myös pilotoimaan ja niihin liittyen hankkeessa on tuotettu mm. referenssitoteutuksia eri välineillä. Eri kohteissa tehtävässä määrittelytyössä on tehty tiivistä yhteistyötä muiden asiaan liittyvien kotimaisten hankkeiden kanssa ja hyödynnetty niiden tuottamia määrityksiä (esim. HL7- yhdistyksen Open CDA-määritykset, Stakesin kansallinen koodistopalvelu, Sähköisen potilaskertomuksen yhdenmukaiset rakenteiset ydintiedot -hanke), jotka ovat olleet käynnissä osin yhtä aikaa PlugIT-hankkeen kanssa. 2.2.1 Työpöytäintegraatio ja kontekstinhallinta Monissa tilanteissa on tarvetta tarkastella potilastietoja kokonaisvaltaisesti, yli sovellusrajojen. Potilaan tiedot ovat tyypillisesti useissa järjestelmissä, minkä seurauksena käyttäjän työasemalla voi olla tarpeen olla käynnissä yhtäaikaisesti useita eri sovelluksia. Järjestelmien välillä ei ole kuitenkaan ole ollut riittävästi yhteistoiminnallisuutta, minkä vuoksi käyttäjä joutuu tekemään useita sa- 14 PLUGIT-HANKKEEN SELVITYKSIÄ JA RAPORTTEJA 7

mankaltaisia toimintoja (mm. sisäänkirjautuminen, potilastietoihin siirtyminen, potilaan tietojen hakeminen) eri järjestelmiin. Työpöytäintegraation ja sen pohjana olevan kontekstinhallinnan on tarkoitus tuoda apua tähän ongelmaan. Työpöytäintegraatio määrittelee yleisen mallin työasemalla toimivien sovellusten visuaalisen integroinnin toteuttamiseen. Työpöytäintegraation tavoitteena on helpottaa erillisten järjestelmien yhtäaikaista käyttöä ja parantaa näin käyttäjän työprosesseja, joista tulee tehokkaampia ja paremmin työnkulkua tukevia. PlugIT-hankkeessa tuotetut työpöytäintegraatio- ja kontekstinhallintaratkaisut eivät ole osa sovellusten yhteisiä ydinpalveluita, mutta ne liittyvät läheisesti joihinkin tämän raportin ydinpalveluihin. PlugIT-hankkeen kontekstinhallintaratkaisuja kuvataan tarkemmin raportissa (Tuomainen ym. 2004). 2.2.2 Ydinpalveluiden sovellusrajapinnat Suomessa potilashallinnon ydinjärjestelmät ovat pääsääntöisesti kokonaisvaltaisia ratkaisuja, jotka sisältävät kaikkialla hoitoprosessissa tarvittavat yleiset tiedot ja perustoiminnot. Ydinjärjestelmät sisältävät tietoja, joita ylläpidetään keskitetysti, ja joita ei ole mahdollista päivittää erillisjärjestelmistä. Yhteistoiminnallisuuden saavuttamiseksi ydinjärjestelmän tulee tarjota palveluja muiden sovellusten käyttöön. Tällaisia useiden sovellusten tarvitsemia yhteisiä palveluja kutsutaan ydinpalveluiksi. Ydinpalvelujen avulla vähennetään päällekkäisiä osia, tietoja ja toimintoja järjestelmissä. Perusajatuksena on, että ydinpalvelu toteutetaan kerran organisaatioon ja sitä voidaan käyttää eri sovelluksista. Näin jokaisella sovelluksilla olisi käytössään oikeat, ajan tasalla olevat tiedot. Kun nämä palvelut tarjotaan avoimilla tekniikoilla määriteltyjen sovellusrajapintojen kautta, ne ovat sovitettavissa yhdenmukaisesti useisiin eri tekniikoilla tehtyihin ja eri-ikäisiin sovelluksiin. Erillisjärjestelmä C Erillisjärjestelmä B Erillisjärjestelmä A Käyttäjän hallintaliittymä Potilasliittymä jne. Ydinjärjestelmä Kuva 2.2. Ydinpalvelut. 2.2.2.1 KÄYTTÄJÄ- JA KÄYTTÖOIKEUSPALVELUT Käyttäjä-integrointikohteessa on määritelty rajapinnat terveydenhuollossa käytettävää käyttäjänhallintaa varten. Määrittelyjen pohjaksi kohteessa on tutkittu laajemmin käyttäjänhallintaan liittyviä toimialariippumattomia ratkaisuja. Tavoitteena on ollut, että valmiiden tunnistusjärjestelmien tulee olla liitettävissä kohteessa tuotettavan ratkaisun kanssa. Käyttäjänhallintaan liittyvät kiinteästi käyttäjän oikeudet, joten näitä kohteita on työstetty tiiviisti yhdessä. Käyttöoikeus-kohteessa on määritelty rajapinta terveydenhuollossa käytettäviin käyttöoikeuksienhallintajärjestelmiin. Rajapinnan kautta voidaan kysellä tunnistetun käyttäjän eri tyyppisiä oikeuksia (esim. liittyen tiettyihin sovelluksiin, tietojoukkoihin, rooleihin ja potilaisiin). Käyttöoikeusrajapinta tarjoaa laajennettavan mallin, jonka kautta voidaan erikseen määritellä tai standardoi- TERVEYDENHUOLLON AVOIMET SOVELLUSRAJAPINNAT - YHTEISET PERUSRATKAISUT 15

da haluttuja käyttöoikeuskyselyitä tai käyttää keskitettyä käyttöoikeuksien hallintaa sovelluskohtaisesti sovittavalla tavalla. Käyttäjä- ja käyttöoikeusrajapintojen tarkka määrittely on julkaistu raportissa (Sormunen ym. 2004). 2.2.2.2 KOODISTOPALVELUT Terveydenhuollon ohjelmistojen sisältämien tietojen luotettava siirto sovellusten välillä tai yhteismitallisen tiedon tuottaminen eri järjestelmistä vaatii, että sovellusohjelmistot voivat jakaa ja käyttää samoja koodistoja ja terminologioita erityisesti rakenteisen tiedon yhteydessä. Koodistojen epäyhteensopivuus, paikalliset ja sovelluskohtaiset koodistot sekä samojen koodistojen epäyhtenäiset versiot aiheuttavat runsaasti yhteensopivuusongelmia sovellusohjelmistojen välillä terveydenhuollossa. PlugIT-hankkeen Koodistorajapinnat-raportissa (Mykkänen ym. 2004d) esitetään määritellyt koodistojen ydinrajapinnat, joita käyttäen voidaan hyödyntää keskitettyjä nimikkeistöjä ja koodistoja erillisjärjestelmissä. Raportti sisältää taustatiedot, vaatimukset, tekniikkariippumattomat ratkaisut ja tekniset tarkennukset avoimille ohjelmistorajapinnoille keskitettyjen koodistopalveluiden käyttämiseksi. Rajapintoja toteuttamalla voidaan mm. vähentää päällekkäisen tiedon syöttöä eri järjestelmiin, päällekkäistä koodistojen ylläpitoa eri sovelluksissa, saada käyttöön samoja koodistoja ja yhtenäisiä koodistojen versioita eri ohjelmistoissa ja tuottaa uudelleenkäytettäviä ohjelmistopalveluita. Ratkaisuilla voidaan tukea ja täydentää Stakesin Kansallisessa koodistopalvelussa ylläpidettävien koodistojen (mukaan lukien organisaatioyksiköt) käyttöönottoa sovellusohjelmistoissa. Määritellyt rajapinnat perustuvat OMG:n kansainvälisten rajapintastandardien ja Kansallisen koodistopalvelun (ja sen siirtosanomien) tietosisällön hyödyntämiseen. Rajapinnat ovat riippumattomia käytetyistä koodistoista, ja myös terveydenhuollon ulkopuolisia koodistoja voidaan hyödyntää rajapintojen avulla. 2.2.2.3 POTILASTIETOPALVELUT Terveydenhuollon organisaatioissa kliinisten sovellusten tarvitsemat potilaaseen liittyvät perustiedot halutaan ylläpitää keskitetysti yhdessä paikassa, josta eri sovellukset saavat ne käyttöönsä liittymien kautta. Rajapintojen avulla sovellukset saavat aina kullakin hetkellä oikeat ja ajanmukaiset tiedot. Jotta tällainen yhteistoiminnallisuus toteutuisi, potilastietojen hakuun tarvitaan standardiliittymä. Uudelleenkäytettävyyden ja siirrettävyyden vuoksi halutaan määritellä yleistetty ratkaisu, jolloin liittymän voi periaatteessa suunnitella ja tuottaa kaupallisesti mikä tahansa ohjelmistoyritys. PlugIT-hankkeen Potilas-kohteessa on määritelty keskitetty rajapinta potilaan valintaan sekä potilaan henkilötietojen hakuun. Pohjana on käytetty mm. OMG:n Person Identification Service (PIDS) -standardia, joka tarjoaa palvelun potilaan tunnistukseen. Kohteessa tuotettua ratkaisua on mahdollista soveltaa myös kliinisissä tietojoukoissa, esimerkiksi laajentamalla toteutusta potilaan hoitoon liittyviin ydintietoihin, joita voivat olla mm. lääkitystiedot. Potilastietopalvelut nojautuvat osin kohdan 2.2.2.1 käyttäjä- ja käyttöoikeuspalvelun ratkaisuihin (käyttäjän yksilöinti, jota tarvitaan potilastietojen saantiin). Lisäksi potilastietojen hakuun soveltuva rajapinta on samanlainen kuin käyttäjätietoihin liittyvä. Potilastietopalveluiden tarkemmat määrittelyt löytyvät raportista (Rannanheimo ym. 2004). 2.2.2.4 MUUT PALVELUT Edellä kuvattujen rajapintojen lisäksi PlugIT-hankkeessa tunnistettiin myös muita ydinpalveluja. Kuitenkaan tässä vaiheessa niiden tarkalle määrittelylle ei löytynyt tarpeita tai riittävän selkeitä ja yksimielisiä vaatimuksia tai sisältöjä. 16 PLUGIT-HANKKEEN SELVITYKSIÄ JA RAPORTTEJA 7

Laskutusrajapinnat-kohteessa on taustaselvityksenä valmistunut Tuula Tuomaisen opinnäytetyö: Kunta- ja asiakaslaskutus terveydenhuollon toiminnan rahoituksessa (Tuomainen 2004), jossa on perehdytty mm. sosiaali- ja terveysministeriön selvitysmiesten tekemän sairaalalaskutusselvityksen kehitysehdotuksiin ja tutustuttu erillisen asiakaslaskutusjärjestelmän vaatimuksiin ja rajapintoihin. PlugIT-hankkeessa tunnistettiin myös tarve potilaskertomustietojen arkistointirajapinnalle. Arkistoinnin suhteen Suomessa tullaan käyttämään ainakin HL7-yhdistyksen CDA-määrittelyitä sekä sähköisen potilaskertomuksen sisältömäärittelyitä, joita työstettiin PlugIT-projektin aikana erillisessä hankkeessa (Häyrinen ym. 2004). TERVEYDENHUOLLON AVOIMET SOVELLUSRAJAPINNAT - YHTEISET PERUSRATKAISUT 17

3 PALVELUKESKEINEN INTEGRAATIO JA PLUGIT-YDINPALVELUJEN PERUSRATKAISUT Sovellusintegraatioratkaisuissa on paljon erilaisia lähestymistapoja. Kuitenkin voidaan tunnistaa muutamia perusintegrointimalleja (Linthicum 2003, tarkempi kuvaus ja vertailu myös raportissa Mykkänen ym. 2004b): Tietopohjaisessa integroinnissa sovelluksia integroidaan yksinkertaisen tietojenvaihdon avulla. Palvelupohjaisessa integroinnissa sovellukset jakavat yhteistä toimintalogiikkaa, metodeja tai sovelluspalveluita. Prosessipohjaisessa integroinnissa pyritään tuottamaan joukko helposti määriteltyjä ja keskitetysti ylläpidettyjä prosesseja. Käyttäjälähtöinen integrointi tarkoittaa eri järjestelmien yhdistämistä ja integrointia käyttäjän kannalta yhdenmukaiseksi kokonaisuudeksi. Luvun 2.2.1 Työpöytäintegraatioissa päätavoitteena on ollut tukea käyttäjälähtöistä integrointia, kun taas tässä raportissa käsitellyt ydinpalveluiden rajapinnat nojautuvat palvelupohjaiseen integrointimalliin. Palvelupohjaisessa integroinnissa sovellukset siis jakavat yhteistä toimintalogiikkaa metodien, operaatioiden tai sovelluspalveluiden avulla. Tämä saavutetaan määrittelemällä operaatioita, joita voidaan käyttää (siis integroida) useissa eri sovelluksissa, ja sopimalla infrastruktuurista, jota käytetään näiden operaatioiden kutsumiseen. Palvelut voivat sijaita keskitetysti palvelimella, tai niitä voidaan kutsua eri sovellusten välillä. PlugIT-hankkeen palvelurajapinnat on suunniteltu pyrkien keskitettyihin palveluihin. Tällöin palvelupohjainen malli vastaa erityisen hyvin vaatimuksiin päällekkäisen tietojen syötön, päällekkäisen ylläpidon ja päällekkäisen toteutustyön vähentämisestä. Uudelleenkäyttö on tärkeä tavoite palvelupohjaisessa integroinnissa. Eri sovelluksissa käytettävät yhteiset palvelut parantavat uudelleenkäyttöä ja vähentävät päällekkäisiä toimintoja ja tietoja eri sovelluksissa yhdenmukaistaen sovellusjoukkoa. Myös tietopohjaista, prosessipohjaista ja käyttäjälähtöistä integrointimallia voidaan tukea tehokkaasti määrittelemällä palveluita. Yhteiset (jaetut) palvelut tekevät sovelluksista enemmän riippuvaisia toisistaan ja tiukemmin integroituja kuin pelkkä tiedonvälitys järjestelmien välillä, mutta vähentävät päällekkäistä ylläpitotyötä ja päällekkäisten tietojen syöttämistä eri järjestelmiin. Palvelupohjaista integrointimallia on käytetty runsaasti organisaatioiden sisäisessä sovellusintegraatiossa, mutta esimerkiksi web-sovelluspalveluiden (Web services) yleistyessä se on lisääntymässä myös organisaatioiden välisessä integroinnissa. Palvelupohjaisen integroinnin välineet luovat uudelleenkäytettävän infrastruktuurin, joka mahdollistaa yhä useampien palveluiden jakamisen. Useiden sovellusten yhteisten palvelujen toteuttamisessa ja jakamisessa saavutetaan suurimmat hyödyt vasta, kun infrastruktuuri ja sen kautta käytettävät palvelut ovat käytössä riittävän monissa sovelluksissa. Palvelupohjaisen integroinnin hyötyjen saavuttaminen vaatii usein siihen osallistuvien sovellusten muuttamista, toisin kuin esim. tietopohjainen integrointi. Tämä voi vaikeuttaa etenkin perinnejärjestelmien integrointia palvelupohjaisesti. Toisaalta hajautetut sovellukset, jotka yleensä perustuvat etäohjelmakutsujen (Remote Procedure Call) käyttöön, voivat yleensä suhteellisen helposti tarjota toimintoja myös avointen palvelurajapintojen kautta yksinkertaisten sovittimien avulla. 18 PLUGIT-HANKKEEN SELVITYKSIÄ JA RAPORTTEJA 7

Käytännössä monet integrointiratkaisut yhdistelevät eri integrointimalleja. Integroinnin nykyinen trendi on tietopohjaisesta integroinnista kohti palvelupohjaista integrointia (Linthicum 2003). Tietopohjainen integrointi tarjoaa edullisen ratkaisun moniin integrointitarpeisiin, mutta pitkällä aikavälillä sovellusten tarjoamien palveluiden ja operaatioiden integrointi tuottaa suurempia hyötyjä. Palvelupohjaisen integraation käytöllä voidaan saavuttaa koostettuja järjestelmiä, jotka pitävät sisällään useiden sovellusten prosesseja ja tietoja. Esimerkiksi web-sovelluspalveluiden avulla sovellusten kehittäjät voivat määritellä sovellusliittymiä ja käyttää muiden sovellusten tarjoamia palveluita. Siirtyminen palvelupohjaiseen integrointiin on kuitenkin syytä toteuttaa vähittäin, ja rajata kerralla toteutettavat asiat riittävän pieniin osioihin, ja ottaa huomioon myös tilanteet, joissa ei voida nojautua toisesta ohjelmistosta saatavilla olevan palvelun käyttöön. OMG:n terveydenhuoltomääritykset (esim. PIDS, TQS) (Savolainen 2004) ja PICNICprojektin yleiset palvelut ovat esimerkkejä palvelupohjaisesta integroinnista terveydenhuollossa. Useiden PlugIT-hankkeessa määriteltyjen rajapintojen toiminnallisuuteen on otettu mallia palvelupohjaisista määrityksistä, kuten Person Identification Service (PIDS), Java Authentication and Authorization Service (JAAS) ja HL7 Common Terminology Services (CTS). Lisäksi palaute PlugIThankkeen osapuolilta sekä sovelluskehityksen yleinen suunta kohti palvelukeskeisyyttä (mm. Web services) ovat edistäneet palvelukeskeisen lähestymistavan käyttöönottoa. PlugIT-ydinrajapintojen integrointitavaksi on tarkennettu hajautetun ohjelmointirajapinnan kutsuminen ilman käyttöliittymää (Mykkänen ym. 2004b). Tämä integrointitapa soveltuu tilanteisiin, joissa järjestelmät tarvitsevat välitöntä vuorovaikutusta (synkroninen kutsutapa), ja yksi järjestelmä voi tarjota toisille ohjelmistopalvelun, jonka avulla suoritetaan tietty toiminto tai palautetaan käytettävää tietoa. Tapaa käytetään varsinkin palvelupohjaisissa ja prosessipohjaisissa integrointimalleissa. Tämä integrointitapa vaatii usein myös tehtävään liittyvän tietosisällön määrittelyä. Ohjelmointirajapinta on lähestymistapana hyödyllinen, kun integrointi vaatii käyttötilanteessa välitöntä tai nopeaa vastausta kutsutulta järjestelmältä. Se myös edellyttää, että kutsuttu palvelu on saatavilla ja löydetään tarvittaessa. Tällaiset ohjelmointirajapinnat eivät yleensä sovellu kovin suurten tietomäärien tehokkaaseen siirtoon, vaan tällaisissa tapauksissa kannattaa harkita esim. sanomapohjaista tai muuta tietokeskeistä lähestymistapaa. Hajautettu rajapinta edellyttää, että rajapinnan palvelun tarjoavassa sovelluksessa on palvelinosa, johon otetaan verkon yli yhteyttä. Tämä palvelinosa voi toimia esim. web-palvelimella tai sovelluspalvelimella. Hajautettu rajapinta helpottaa ylläpitotyötä tilanteissa, joissa palvelua päivitetään, koska palvelun toteutus ei sijaitse esimerkiksi erikseen jokaisen käyttäjän työasemalla vaan keskitetysti palvelimella. Palvelut voidaan määritellä tilattomina tai tilallisina. Tilallinen palvelu tarkoittaa, että palvelun on muistettava tiettyjä tietoja, joita edellisissä palvelukutsuissa on vaihdettu, ja operaatioita on esim. kutsuttava tietyssä järjestyksessä. Tilattomat palvelut eivät edellytä tiettyä suoritusjärjestystä eri operaatiokutsuille, eikä palvelutoteutuksen tarvitse esim. pitää kirjaa asiakassovellusten tai käyttäjien istunnoista. PlugIT-ydinpalveluista koodistopalvelut ovat tilattomia, muut ydinpalvelut säilyttävät sessiotietoa (käyttäjä- työasema- ja sovellustietoa) ja ovat tilallisia. PlugIT-hankkeessa käytetyn integrointiratkaisujen määrittelyprosessin (Mykkänen ym. 2004b) kannalta ratkaisun vaatimuksissa palvelupohjaisessa integroinnissa yksilöidään, kohdistuvatko määritellyt vaatimukset palvelua tarjoavaan vai sitä käyttävään sovellukseen. Palvelumääritykset määritellään ensin tekniikkariippumattomalla tasolla. Tällöin tunnistetaan palvelun tarjoamat operaatiot ja niihin liittyvä tietosisältö sekä sovellusten vastuut. Nämä määritellään siten, että ne ovat toteutettavissa eri rajapintatekniikoilla (Tekniikkariippumaton liittymämäärittely). Seuraavassa vaiheessa tekniikkariippumattomia rajapintoja tarkennetaan valituilla avoimilla tekniikoilla (Tekniset liittymämäärittelyt). Teknisten määrittelyjen pohjalta voidaan toteuttaa keskenään yhteentoimivia palvelun toteutuksia ja niitä käyttäviä asiakassovelluksia. Teknisten määritysten lisäksi on yleensä myös joitakin toteutuskohtaisia ratkaisun käyttöön liittyviä asioita, jotka tulisi mainita liittymämäärityksissä ja on syytä dokumentoida yhtenäisesti (Liittymän toteutuksen kuvaus). TERVEYDENHUOLLON AVOIMET SOVELLUSRAJAPINNAT - YHTEISET PERUSRATKAISUT 19

PlugIT-ydinrajapinnoissa hajautettujen rajapintojen määrittelyyn on hyödynnetty avoimia Internet-tekniikoita: HTTP:tä tiedonvälitykseen ja XML:ää tietosisällön ja operaatioiden määrittelyyn. Näiden tekniikoiden hyödyntäminen ei edellytä monimutkaista infrastruktuuria tai kalliita välineitä. HTTP-tekniikan avulla saavutetaan olemassa olevan Internet- ja verkkoinfrastruktuurin hyödyntäminen sekä mahdollisuus kutsuihin palomuuriohjelmistoista riippumatta, XML lisää mm. tuotettujen ratkaisujen joustavuutta ja laajennettavuutta. Sekä palvelimilla suoritettavat (esim. selainpohjaiset sovellukset tai muut palvelut) että työasemissa suoritettavat sovellukset voivat käyttää samoja hajautettuja rajapintoja yksinkertaisten HTTP-kutsujen avulla. Tällaisia yksinkertaisia web-palveluita voidaan toteuttaa käyttämällä eri www-palvelinten tarjoamia ohjelmointimahdollisuuksia ja http-protokollan perusoperaatioita (get, post, put). Näin toimittaessa web-palvelimet eivät palauta näytettävää web-sivua vaan sovitun muotoisen (esim. XML-) dokumentin, jota voidaan hyödyntää ohjelmallisesti. Useimmat webpalvelimet sopivat tällaisten palvelujen tarjoamiseen, käytettäviä välineitä voivat olla mm. Java Server Pages (JSP), Active Server Pages (ASP, ASP.NET), cgi, ISAPI, NSAPI, CSP ja monet XML:n käyttöä tukevat välineet. Kutsujen tekemiseen tarvitaan HTTP-kutsuihin kykeneviä kehitysvälineitä, joita on saatavilla useimpiin kehitysympäristöihin, ja XML-jäsentimiä tulosten käsittelyyn, ellei niitä käsitellä vain merkkijonoina. Välineistä löytyy lisätietoja mm. raportista (Karvinen ym. 2004). On myös mahdollista kapseloida hajautettujen ratkaisujen toteutus paikallisen liittymän avulla käytettäväksi, ks. luku 4.4. Käytettävän palvelun osoite on kiinnitettävissä yleensä asiakassovelluksen asennuksen yhteydessä. HTTP:n ja XML:n käyttö mahdollistavat edelleen palveluiden kapseloinnin ja tunnistamisen useilla eri tavoilla. PlugIT-ydinpalveluissa palvelu vastaa tiettyä URL-osoitetta, ja käytettävä rajapinta sekä sen tarvitsemat parametrit määritellään palveluosoitteeseen lähetettävässä XMLviestissä. PlugIT-ydinpalveluihin valittiin edellä kuvatun mukaisia integrointiratkaisuja laajasti mm. sovellusten kannalta matalan toteutuskynnyksen vuoksi. Teknisesti ratkaisut soveltuvat erityisen hyvin yksinkertaisiin tiedonsiirtoihin ja operaatiokutsuihin ja integrointiin eri tekniikoilla toteutettujen sovellusten välillä. Samoihin etuihin, joita PlugIT-ydinpalveluiden tekniikkavalinnoilla saavutettiin, pyritään myös web-sovelluspalveluissa (Web Services). Web services-tekniikoita tukevilla välineillä voidaan edelleen automatisoida suuri osa tarvittavasta ohjelmointityöstä ja piilottaa HTTP- ja XMLtekniikoiden käsittelyn yksityiskohdat sovelluksen tekijältä (ks. luku 5). 20 PLUGIT-HANKKEEN SELVITYKSIÄ JA RAPORTTEJA 7

4 PLUGIT-RAJAPINTOJEN TOTEUTUS HTTP/XML- TEKNIIKALLA PlugIT-hankkeessa tutkittiin ja vertailtiin erilaisia tapoja rajapintojen teknisiä määrittelyjä varten (Mykkänen ym. 2004e), ja valittiin laajasti käytettyjä mutta yksinkertaisia Internet-tekniikoita rajapintojen määrittelyihin ja toteutuksiin. Tässä kappaleessa kuvataan, miten PlugIT-ydinpalveluita toteutetaan ja käytetään HTTP-yhteyden ja XML-sisällön avulla. Ydinpalvelukutsut esitetään HTTP-sanomina, jotka kapseloivat XML-muotoisen datan, joka sisältää kutsuttavan ydinpalvelukutsun nimen ja sille annettavat parametrit. Ydinpalvelukutsun vastaus palautetaan HTTPvastauksen sisällä. 4.1 Arkkitehtuuri Tämä tekninen määritys perustuu HTTP-viestintään siten (Irwing ym., 1999), että 1. Asiakassovellus (tai lyhyemmin sovellus), joka käyttää ydinpalvelua, lähettää HTTPsanoman palvelutoteutukselle. HTTP-sanoma sisältää asiakassovelluksen muotoileman XML-sisällön joka kertoo kutsuttavan palvelun nimen ja tarvittavat parametrit. 2. Ydinpalvelutoteutus ottaa vastaan asiakassovelluksen lähettämän HTTP-sanoman, jäsentää sen sisältämän XML-sisällön ja ohjaa sisällön oikealle palvelukutsutoteutukselle (esim. ydinpalvelua tarjoavaa sovellusta). 3. Ydinpalvelutoteutus rakentaa palautettavan XML-sisällön ja palauttaa sen HTTP-vastauksen sisällä. 4. Asiakassovellus jäsentää HTTP-vastauksen sisältämän XML-sisällön eli palvelukutsun paluutiedot, ja käyttää niitä esimerkiksi saatujen tulosten näyttämiseen käyttäjälle tai virheilmoituksessa. Kuva 4.1. Palvelujen toteutus HTTP-viestinnän puitteissa. TERVEYDENHUOLLON AVOIMET SOVELLUSRAJAPINNAT - YHTEISET PERUSRATKAISUT 21

HTTP-viestien lähetyksessä suositellaan käytettävän HTTP POST-menetelmää, koska vaihtoehtoinen HTTP GET-menetelmä asettaa usein rajoituksia XML-sisällön pituudelle. HTTP POSTmenetelmällä XML-sisältö lähetetään suoraan asiakassovellukselta ydinpalvelutoteutukselle sellaisenaan ilman, että se sidotaan mihinkään parametriin. Lisäksi suositellaan HTTP-protokollan version 1.1 käyttöä. XML-sisällön merkistökoodauksessa HTTP-siirrossa suositellaan käytettäväksi UTF-8-koodausta. Jos käytetään jotain muuta merkistökoodausta, käytetty koodaus on dokumentoitava selkeästi. 4.2 HTTP-viestinnän asettamat rajoitukset HTTP:n tilattomasta luonteesta johtuen ydinpalveluja kutsutaan sovelluksen näkökulmasta synkronisesti, jolloin sovellus jää aina odottamaan vastausta tehtyään palvelukutsun. Ydinpalvelutoteutus on syytä kuitenkin rakentaa toimimaan siten että se pystyy vastaamaan usean sovelluksen yhtäaikaisiin kutsuihin. Lisäksi eri rajapintojen ydinpalvelutoteutuksia voidaan rakentaa hajautetuksi siten, että esimerkiksi varmennus- ja käyttöoikeuspalvelut (AuthenticateUser ja AuthorizationAccess -palvelut) ovat profiilipalveluista (IdentifyProfile- ja ProfileAccess palvelut) erillisiä palveluita ja voivat sijaita fyysisesti erillisillä palvelimilla. (Edellä mainittujen rajapintojen tarkat kuvaukset ovat raporteissa (Sormunen ym. 2004 ja Rannanheimo ym. 2004)). Kuva 4.2. HTTP-liikenne sovellusten ja ydinpalvelutoteutuksen välillä 22 PLUGIT-HANKKEEN SELVITYKSIÄ JA RAPORTTEJA 7

4.3 Esimerkki HTTP-sanomasta ja vastauksesta Oheisessa esimerkissä HTTP-sanoma on lähetetty osoitteeseen http://kettinki.uku.fi/httpservices. Sovellusohjelmoijan kannalta ainoastaan XML-sisällöllä on merkitystä: Muu osa on HTTPlähettäjän lisäämää metatietoa itse HTTP-sanomasta eli HTTP-otsikkotietoa. Luvussa 4.6 kuvataan kaikkien PlugIT-ydinpalveluiden yhteisiä käytäntöjä esimerkiksi käytettävien XML-elementtien suhteen. POST http://kettinki.uku.fi/httpservices HTTP/1.1 Host: laivuri27.uku.fi User-Agent: Mozilla/4.0 Content-Type: text/xml; charset=utf-8 <?xml version= 1.0 encoding= UTF-8?> <request xmlns= urn:plugit:commonservices > <interface>authenticateuser</interface> <method>getcoupon</method> <param> <manifest>193.167.225.27</manifest> <applicationname>plugit_demosovellus</applicationname> </param> </request> Ydinpalvelutoteutus palauttaa seuraavanlaisen vastauksen. Kuten HTTP-sanomassa, vastauksessakin sovellusohjelmoijan kannalta tärkein osa on itse XML-sisältö muun tekstin ollessa HTTPotsikkoa. HTTP/1.1 200 OK Content-Type: text/xml; charset=utf-8 <?xml version= 1.0 encoding= UTF-8?> <response xmlns= urn:plugit:commonservices > <coupon>fj2uc8a9</coupon> <authenticated>false</authenticated> </response> 4.4 Liittimien käyttö HTTP-viestinnän piilottamiseen Ydinpalvelutoteuttaja voi tarjota sovellusohjelmoijien työkaluiksi palveluliittimiä (sovittimet, adapterit, yhteyskomponentit), joiden avulla HTTP-sanomien ja XML-sisällön käsittely voidaan piilottaa sovellusohjelmoijalta. Kuvassa 4.3 on esitetty liittimien käyttöä asiakassovelluksen liittämisessä palveluun. Liittimen avulla siis ydinpalvelutoteutus saadaan näyttämään paikalliselta ohjelmakirjastolta, mikä helpottaa huomattavasti palvelun käyttöä, koska sovellusohjelmoijan ei tarvitse huolehtia HTTP-liikenteen tai XML-dokumenttien yksityiskohdista ja tekniikoista. Jokaiselle ydinpalvelulle voidaan tehdä tarvittaessa oma liitin, tai useita esim. eri ohjelmointikieliä tai -ympäristöjä varten. TERVEYDENHUOLLON AVOIMET SOVELLUSRAJAPINNAT - YHTEISET PERUSRATKAISUT 23