Terveydenhuollon komponentt ipohjainen soveiiusintegraat io, Juha Mykkänen, Kuopion YO

SUOMEN KUNTAUITTO Sosiaali - ja terveysyksikkö TERVEYDENHUOLLON 27. ATK-PAIVAT 4. - 5.6.2001 Sosiaali- ja terveydenhuollon tietotekniikan ja tiedonhallinnan tutkimuksen päivät Terveydenhuollon komponentt ipohjainen soveiiusintegraat io, Juha Mykkänen, Kuopion YO

Terveydenhuollon komponenttipohjainen sovellusintegraatio Juha Mykkanen, Kuopion yliopisto, atk-keskus, HS-yksikkö Juha.Mykkanen@uku.fi Tämä tutkimuspaperi pohjautuu paaosin Kuopion yliopiston Komponentti-FixIT-projektin julkaisun "Mykkänen J. Komponentti-FixIT: Terveydenhuollon komponenttipohjainen sovellustuotanto - toiminnallisuus, arkkitehtuuri, siirtymästrategiat ja välineet" [II järjestelmäintegraatiota käsitteleviin osiin. Abstrakti Järjestelmäintegraatio on eräs terveydenhuollon organisaatioiden ja IT-yriiysten suurimmista haasteista tietojärjestelmien kehittämisessä. Uusien sovellusohjelmistojen kayttöönottokustannuksista suuri osa aiheutuu kahdenvälisten sovellusintegraatioratkaisujen sopimisesta ja toteuttamisesta hyödyllisten - standardien kaytöstä huolimatta. Myöskaän pelkka jarjestelmien välinen tiedonsiirto esimerkiksi sanomien avulla ei riitä nykyisten saumattomuuteen pyrkivien toimintaprosessien kehittyessä, vaan jarjestelmien on kyettävä kutsumaan toiminnallisuutta yhteentoimivista järjestelmistä esim. yksittäisen järjestelmän vaikutusaluetta suurempien prosessien läpiviemiseksi. Uudelleenkaytettävät ohjelmistokomponentit tarjoavat uusia mahdollisuuksia jarjestelmien yhteentoimivuuden toteuttamiseen. Johdanto: jarjestelmaintegraation tarpeet ja integroinnin ongelmat Kuopion yliopiston Komponentti-FixIT -projektin osana on kartoitettu terveydehuollon järjestelmäintegraation tarpeita ja näkökulmia. Keskeisiä jarjestelmaintegraation tarpeita ovat päällekkäisen tiedon ja toiminnallisuuden vähentäminen sovelluksissa, olemassa olevan osaamisen ja teknologian hyödyntäminen, toimintaprosessien integrointi organisaation sisällä ja eri organisaatioiden välillä sekä visio jarjestelmien vähittäisestä jatkokehittämisestä uusien vaatimusten ilmaantuessa [LI. Toimintaprosessien sovelluksille ja niiden yhteistoiminnalle asettamat vaatimukset on kyettävä ottamaan huomioon entistä paremmin kehitettäessä uusia järjestelmiä, jotka tukevat asiakasorganisaatioiden muuttuvia toimintatapoja. Integrointi- ja monitoimittajaprojekteissa vaikeuksia aiheuttavat jarjestelmien ja toimittajien erilaiset toimintatavat ja tekniset ratkaisut sekä poikkeavat arkkitehtuurilliset oletukset [2] eri järjestelmissä. - Integroinnin läpiviemiseksi tarvitaan standardien ja toimintatapojen sopimista useilla eri tasoilla: on valittava käytettävä tekniikka, sovittava tarvittavasta teknisestä infrastruktuurista, sovellustason yleisestä tai yhteisestä infrastruktuurista, tarkoista järjestelmien välisistä liittymistä ja liittymien semantiikasta sekä jarjestelmien sisäisistä yhteentoimivuuteen vaikuttavista ratkaisuista. Tätä sopimista tukemaan tarvitaan yhtenäistä kehystä, jonka avulla eri tasojen ja protokollien huomiointi onnistuu jo sovellustuotantoprosessin aikana. Avoimet rajapinnat ja komponentit mahdollistavat entistä avoimemmat sovellusohjelmistomarkkinat [3]. Komponenttipohjainen sovellustuotanto perustuu eri lähteistä hankittujen komponenttien integrointiin toimiviksi sovelluksiksi, ja tarjoaa myös jarjestelmien väliseen integrointiin uusia mahdollisuuksia. Käytettävissä olevia integrointitekniikoita ovat myös mm. XML laajennuksineen, väliohjelmistostandardit, mallinnusvälineet ja -standardit, toiminnanohjaustuotteet, sovelluskehykset ja kehysarkkitehtuurit, kääretekniikat, liittymästandardit, integrointialustat ja ohjelmointikielet. Järjestelmien yhteentoimivuuden tasot Järjestelmien yhteentoimivuus ei ole pelkkä tekninen ongelma, vaan siihen sisältyvät myös sisällölliset, toiminnalliset ja arkkitehtuurilliset seikat. Yhteentoimivuusprotokolla (interaction protocol) on joukko sääntöjä, jotka määrittelevät kahden tietojärjestelmän välisen vuorovaikutuksen. Yhteentoimivuusprotokollat voivat

sisaltaa jarjestelmien välisten viestien muodon määrittelyja ja myös naiden viestien vaihtamiseen käytettäviä tekniikoita. Järjestelmät voivat olla vuorovaikutuksessa hyvin eri tavoin, alkaen hyvin löyhästi määritellyistä protokollista, jotka vaativat tulkkaamisen molemmissa päissä, tiukasti integroituun yhteistoimintaan, jossa järjestelmät kommunikoivat natiivisti, eli käyttäen identtisiä protokollia kaikilla tasoilla. Eri toimittajien tekemien jarjestelmien yhteentoimivuuden perusta ovat standardit tai yhteiset sopimukset. Järjestelmien rakentaminen standardien mukaisiksi voi lisätä jarjestelman toteuttamistyötä ja toteutuskustannuksia. Järjestelmien hankkijoiden vastuulla on suosia standardien mukaisia järjestelmiä, jotta organisaation järjestelmäkokonaisuudesta voidaan rakentaa jarjestelmien yhteentoimivuutta tukeva. Standardeja kehitetaan hyvin monitahoisiin vaatimuksiin lähtien yleisistä teknisistä mekanismeista ja terveydenhuollon viestien ja palveluiden määrittelyistä aina yleisiin luokituksiin, sanastoihin ja hoito-ohjeistoihin asti. Eri tasojen tunnistaminen on hyödyllistä yhteensovittamista suunniteltaessa ja kaytettavia tekniikoita ja standardeja valitessa. Tasot (alimmasta korkeimpaan) [4]: 1. Tekniset liittymat ovat ohjelmistomekanismeja, joilla kohdejärjestelmään ollaan yhteydessa. Tämän tason sopiminen tarkoittaa käytettävän tekniikan sopimista, esim. CORBA:n, RPC:n, DCE:n tai suoran SQL-kielen käyttöä jaettuun tietoon pääsemiseksi. Teknisen liittymän protokolla voi olla myös usean tekniikan yhdistelma, esim. XML:n käyttö CORBA-liittymän päällä. Tekninen liittymä voi olla tietokantapemsteinen, tiedostopohjainen yhdyskäytävä tai ohjelmointirajapinta (API) tai naiden yhdistelma. 2. Tekninen infrastruktuuri. Mahdollisuus kutsua teknisesti toisen jarjestelman liittymää ei poista kahden - jarjestelman välisen vuorovaikutuksen teknisiä ongelmia. Esim. kohdejärjestelmän on joko oltava käynnissä, jotta sitä voi kutsua, tai kohdeympäristön on tiedettävä, kuinka käynnistää kohdejärjestelmä kutsun tullessa. Se kuinka aktivointi tapahtuu, kuuluu teknisen infrastmktuurin vastuulle. Tekninen infrastruktuuri kattaa kahden jarjestelman välisen kommunikoinnin teknisen tuen, ja sisaltaa mm. virheidenkäsittelyn, nimeämisen, transaktiot jne. Teknisen infrastruktuurin eri protokollia voidaan lähestyä kahdella vastakkaisella arkkitehtuurimallilla: Mallituntemus: kutsuva järjestelmä tuntee kohdejärjestelman teknisen infrastruktuurin protokollan, ja protokolla on suunniteltu siten, että kutsuva järjestelmä voi mukautua kohdejärjestelman protokollaan. Esim. kutsuva järjestelmä voi tuntea kohdejärjestelman liittymän, jota voi kutsua transaktion aloittamiseksi ennen toiminnallisen liittymän kutsua. Kontekstituntemus: Kutsuvalla ja kohdejärjestelmällä on yhteisiä protokollia, ideaalitilanteessa myös kunkin protokollan konteksti. Esim. molemmat voivat olla osa teknistä transaktiokehystä, jossa molemmat järjestelmät pääsevät kunkin transaktion kontekstiin koska tahansa, tai konteksti voidaan siirtää helposti järjestelmästä toiseen. Transaktioon osallistuminen ei ole pelkästään aloituksen ja suorituksen ulkoistamista, vaan se voi olla hyvin yhteistoiminnallista mahdollistaen molempien jarjestelmien mukana olemisen yhdessä ja samassa transaktiossa. Sovellusinfrastruktuuri. Toiminnallisen yhteensopivuuden saavuttamiseksi tarvitaan soveiiusinfrastmktuuria, joka sisaltaa arkkitehtuuriset päätökset, käytännöt, liittymäkäytännöt ja suunnittelumallit. Kukin teknisen infrastruktuurin protokolla kääntyy joksikin sovellusinfrastruktuurin protokollaksi. Tällä alueella ei ole juuri standardeja, joten yleensä kehitetaan projektin tarpeisiin oma ratkaisu, joka vaatii tulkkausta tai sovitinta yhteentoimivuuden tukemiseksi. Sovellusinfrastruktuurin protokollia ovat esim. tapa, jolla joillekin ryhmille sallitaan operaatioita ja toisilta ne kielletään sekä usein teknisten tai toiminnallisten virhetilanteiden käsittely. 4. Toiminnalliset liittymat. Mikäli projekti on päättänyt, että liittymien määrittelyyn kaytetaan tiettyä tekniikkaa, tiedetään, millainen tekninen infrastruktuuri tarvitaan ja miten liittymää kutsutaan teknisesti. Tällöin ei kuitenkaan tiedetä mitään toiminnallisesta liittymästä. Esim. teknisiin ratkaisuihin ei kuulu se, onko operaatio haeqotilas vai lisaa-tutkimus. Toiminnallisessa liittymässä määritellään operaatioiden toiminnalliset nimet ja parametrit. Teknisten ja toiminnallisten liittymien muodot ovat suorassa yhteydessa toisiinsa: toiminnallisten liittymien määrittelyssä kaytetaan teknisen infrastruktuurin tarjoamia mahdollisuuksia. Toiminnallisen liittymän määrittely voidaan tehdäprosessoinnin mpin tai tiedon sypin avulla. Esim. HL7 ja EDIFACT keskittyvät tiedon siirtämisen standardointiin, kun esim. 0MG:n määrittelemät

toiminnalliset liittymät keskittyvät prosessointiin ja toiminnallisuuteen. Ohjelmointirajapintaa käyttävissä liittymissä nämä päätökset näkyvät operaatioiden nimien ja parametrien määrittelyissä sekä operaatioiden välisissä yhteyksissä. 5. Semantiikka. Kun toiminnallisista liittymistä on sovittu, on tarpeen sopia kunkin interaktion tarkasta merkityksesta. Pelkästään liittymiä tarkastelemalla ei operaation merkityksesta saa kuvaa. Toiminnan kannalta liittymän operaation merkitys on kuitenkin äärimmäisen tärkeä. Sama liittymä voi johtaa eri tapauksissa hyvin erilaiseen lopputilaan järjestelmissä, ja kutsujalle palautuvan tiedon merkitys voi poiketa paljonkin eri tapauksissa. Näin ollen alemmilla tasoilla tarkasti sovitulla liittymällä voi olla hyvin erilaisia merkityksia. Esim. komponentin operaatiolla luo-tilaus (in tilaus, out tulos) voi olla useita merkityksia: 1. Kohdejärjestelmä luo uuden tilaus-tietueen tietokantaan, ja tietue pitää sisällään tietoa tilauksesta. Operaation ja tilauksen täytäntöönpanon välillä ei ole yhteyttä. Kohdejärjestelmän muut osat eivät saa tietoa uuden tilaustietueen saapumisesta. Kutsuja ei saa tietoa siita, hyväksyttiinkö tilaus ja onko se käsiteltävänä, vaan siita, olivatko tiedot hyväksyttäviä. Jos kutsuja haluaisi tietoa toimitusaikataulusta, pitäisi kutsujan esim. kutsua toista liittymää. 2. Kohdejärjestelmä luo uuden tilauksen toiminnallisesti: tilaus aikataulutetaan ja siihen määritellään tarvittavat resurssit luonnin suorana seurauksena. Kutsuja saa operaation suorana tuloksena tietoa - operaation toiminnan tuloksesta. 6. Toiminnallinen viitemalli. Täyden yhteentoimivuuden saavuttamiseksi tarvitaan toiminnallinen viitemalli. Jos esimerkiksi kutsuvassa jarjestelmassa potilaan tunniste on 10 merkkia pitka, ja kohdejärjestelmässä 36 merkkiä pitka, kutsuva järjestelmä ei kykene käyttämään saamaansa tietoa oikein. Liittymillä voi siten olla hyvin suora suhde järjestelmän sisäiseen toteutukseen. Mikäli järjestelmillä ei ole yhteista toiminnallista viitemallia, niiden toiminnallisuus rajoittuu toiminnallisuuden pienimpään yhteiseen osajoukkoon. Järjestelmässä toiminnallinen viitemalli on yleensä täysin sisäinen: esim. ainoa tapa kohdejärjestelmän tietokannan lukemiseen tarkoitetun hakulauseen kirjoittamiseen on tietää kohdejärjestelmän tietokantakuvaus. 7. Kehitysprosessin liitiymat. On tilanteita, joissa jarjestelmassa tiedetään jo aikaisessa kehitysvaiheessa, minkä jarjestelmien kanssa yhteistoiminnallisuutta tarvitaan. Tällöin mukana olevien jarjestelmien rajoitukset ja mahdollisuudet voidaan ottaa huomioon jo varhain kehitysprosessissa. Esimerkiksi jotta järjestelmien yhteistoiminta on mahdollista jo suunnittelun ja kehitystyön aikana, voi olla tarpeen saada käyttöön toisen jarjestelman spesifikaatio, jotta jarjestelmien integrointi tai yhteistoiminnallisuus saavutetaan. Kehitysprosessin liittymien protokollat voivat ottaa kantaa myös jakeluun, kuten määritellä tarkasti sellaisten tiedostojen loogisen tai jopa fyysisen sijainnin, joita yhteistoiminnallisuuden toteuttamiseen tarvitaan. Integrointitavat Kukin integrointitaso voi vaatia useita protokollia, esim. teknisessä infrastruktuurissa voi olla turvallisuusprotokolla, transaktioprotokolla jne [4]. Kukin protokolla ja taso voidaan toteuttaa eri tavoin. 1. Integroitu yhteistoiminta saavutetaan, kun järjestelmillä on yhteinen protokolla. Esim. kaksi erillään kehitettyä järjestelmää voidaan saattaa toimimaan yhdessä tekemällä tarpeeseen yhteistoimintasovittimet. 2. Siltayhteistoiminta (bridged interaction) on yhteistoimintaa, jossa molemmat järjestelmät sopivat käyttävänsä yhteista formaattia joka voi poiketa molempien jarjestelmien omasta formaatista. Ulkopuolelta hankittujen tai yleisten sanomamäärittelyjen, esim. HL7-viestien tai XML-dokumenttien käyttäminen ovat esimerkkejä siltayhteistoiminnasta. 3. Koordinoitu yhteistoiminta on tilanne, jossa kohde- ja kutsuva järjestelmä vaihtavat informaatiota niiden yläpuolella olevan koordinaattorin avulla. Usein koordinaattori voi olla erillinen sovellus, joka koordinoi järjestelmien yhteistoimintaa. Yksinkertaisissa järjestelmissä se voi olla esim. käyttöliittymän toteuttava koodi.

4. Vdylayhteistoimintaan (bus-based interaction) perustuvassa yhteistoiminnassa protokolla ei kulje suoraan järjestelmien välillä, vaan yhteisen infrastruktuurin tason kautta. Tämä tarjoaa korkeimman joustavuuden tason, mutta vaatii ohjelmistojen tekijöiden välisen arkkitehtuurisopimuksen. Väyläyhteistoiminta on yleensä rakennettu järjestelmään alusta alkaen, kun esimerkiksi siltayhteistoiminta toteutetaan usein jalkikateen. Väyläyhteistoimintaa voidaan kayttaa myös toteuttamaan muita integrointitapoja. Lisäksi useat järjestelmät voivat kayttaa samaa väylää. Yhteisten verkossa sijaitsevien komponenttipalvelujen käyttö on väyläyhteistoimintaa. Taulukko 1. Liittymätasot, niiden yhteentoimivuusmallit, integrointitavat ja standardit [l] Integrointitaso Yhteentoimivuusmalli Integrointitapa Standardit Tekniset liittymät API-pohjainen Vayläpohjainen CORBA, COM+, EJB, MQ-series, XML Tekninen infrastruktuuri SoveIlusinfrastmktuuri Toiminnalliset liittymät Semantiikka Toiminnallinen viitemalli Kehitysprosessin Liittymät Kontekstipohjainen Yhteinen malli API-pohjainen Kontekstipohjainen Yhteinen malli Yhteinen malli Väyläpohjainen Vaylapohjainen Silta tai integroitu Väyläpohjainen, erityisesti yleinen varasto Väyläpohjainen, erityisesti yleinen varasto Väyläpohjainen EJB Component Model, CORBA Components Ei standardeja, yksittäisiä tuotteita kuten Forte HL7, OMG Healthcare, EDIFACT, X12 jne. Standardeja 1 määrittelyitä ilmestymässä? HL7 MM, ei kansallisia standardeja XMI, MOF Komponenttipohjainen integrointi Komponentit ovat itsenäisiä, uudelleenkäytettäviä ja selkeästi rajattuja ohjelmistokokonaisuuksia. Komponentti on itsenäisesti ennalta tunnettuun suoritusympäristöön rakennettava ja jaeltava ohjelmisto, jota käytetään komponenttiliittyman palvelujen avulla [3,4]. Komponentit rakennetaan yhteistoimiviksi muiden komponenttien kanssa, ja integroidaan toisiinsa järjestelmää koottaessa. Eri järjestelmiä integroitaessa voidaan integroinnissa kayttaa toisen järjestelmän - palveluita, mikäli yhteentoimivuus on suunniteltu ja komponenttiliittymät tehty käytettäviksi. Komponenttien yhteistoiminta voi olla joko suunniteltua tai tarpeen mukaan (ad hoc) rakennettua. Ad hoc - yhteistoiminnassa ei yleensä ole mallia, joka kuvaa yhteistoiminnan kokonaisuutena, vaan yhteistoiminnallisuus rakennetaan tiettya tarvetta varten usein jalkikateen. Yhteistoiminnan onnistuminen riippuu tällöin siitä, onko jarjestelmat suunniteltu avoimiksi ja valmiiksi ennakoimattomaan yhteistoimintaan. Tällaisen yhteistoiminnan rakentaminen on usein hyvin kallista ja monimutkaista ja voi tuottaa luotettavuus-, suorituskyky- tai turvallisuusongelmia. Yleensä tällöin toteutetaan muunnokset molemmissa järjestelmissä useissa protokollakerroksissa. Suunniteltua yhteistoimintaa käyttämällä yhteistoiminnallisuutta lähestytään ulkopuolisena tehtävänä, joka on kuitenkin osa toiminnallisuuden ongelman ratkaisua. Se vaatii sopivien kehitysprosessien ja välineiden olemassaoloa, toiminnan mallintamista sekä tiettya arkkitehtuuria yhteistoimintaan osallistuvilta järjestelmiltä. Järjestelmien välisessä integroinnissa komponenttitekniikalla on neljä päavaihtoehtoa [4]: 1. Yhteistoiminta mustana laatikkona toteutuu, kun järjestelmä näkee vain joukon liittymiä, jotka noudattavat sovittuja protokollia eri tasoilla. Jarjestelmien sisäinen toteutus voi tällöin olla käytännössä mitä

vain. Toimialakomponenteista koottuun järjestelmään on suhteellisen helppoa tehdä tarvittavat sovittimet tai yhdyskäytävät, jotta musta laatikko -yhteistoiminta toteutuu. Tämän tyyppinen yhteistoiminta voidaan toteuttaa esim.järjestelman yhdyskqtävän (system gateway) tai jarjestelman sovittimen (interoperability adapter) avulla. 2. Jos molemmat jarjestelmat on rakennettu toimialakomponenteista, voidaan halutessa käyttää jarjestelman sisäisen komponentin liittymiä. Tällöin on kyseessä valkea laatikko-yhteistoiminta: Tällaisessa yhteistoiminnassa on tunnettava toisen jarjestelman komponentin olemassaolo, käyttäytyminen ja identiteetti. Jos järjestelmillä on yhteisia komponentteja, tässä mallissa ne monistetaan sekä rakentamisen että suorituksen aikana molempiin järjestelmiin. 3. Yhteisiä komponentteja käyttämällä jarjestelmat jakavat komponentit, jotka löytyvät molemmista järjestelmistä. Nämä yhteiset komponentit voivat olla osa järjestelmää, joka on eri toimittajalta kuin yhteentoimivat jarjestelmat. Yhteiset komponentit voivat muodostaatoiminnallisen väylän, joka luo pohjan väylään liittyvien komponenttien liittymille. Sitä varten teknisen ja sovelluksen arkkitehtuurin on oltava yhteensopiva ja myös toiminnallisen arkkitehtuurin tärkeimpien osien. Tällaiseen yhteistoimintaan pyritään mm. seuraavassa luvussa esiteltävien terveydenhuollon yleisten palvelujen standardeilla. 4. Täysi integraatio tarkoittaa, että mitään komponenttia ei kopioida järjestelmien välillä, ja jarjestelmat eivät ole (ainakaan suorituksen aikana) erillisiä. Tama taso vaatii kuuden alimman protokollakerroksen hyvän alustuksen, ja raja sovellusten yhteistoiminnan ja komponenttien yhteistoiminnan välillä muuttuu häilyvaksi. Käytannössä tällöin jarjestelmat on rakennettu käyttäen samoja arkkitehtuuri- ja myös kehitysprotokollia, tai organisaatio on rakentanut kokonaisjärjestelmänsä samaan arkkitehtuuriin ja infrastruktuuriin sopivista toimialakomponenteista. Sovellusten integroinnissa komponenttitekniikalla on päätettävä jarjestelmien vastuista ja siitä, mitä jarjestelma käynnistää yhteistoiminnan ja kuinka yhteistoimintaa hallitaan. Sovellustason komponentit voivat olla yhteistyössä seuraavilla tavoilla: 1. Master-slave -yhteistoiminta: yksi järjestelmä on selkeästi kommunikaation aloittaja ja ainoa aktiivinen toimija, kun toinen on palvelujen tarjoaja. 2. Koordinoitu yhteistoiminta: kommunikaatio tapahtuu koordinoivan tahon kautta. 3. Yhdenvertainen (peer-to-peer) -yhteistoiminta: yhteistoiminnan muoto, jossa osallistuvat sovellustason komponentit voivat vapaasti ja suoraan kutsua toistensa palveluita. Tama tapa mahdollistaa suurimman joustavuuden, mutta on monimutkaisin ja kallein kaikissa jarjestelman elinkaaren vaiheissa. Arkkitehtuurin huomioiminen integroinnissa - Järjestelmien perustuessa yhä enemmän monitasoarkkitehtuureihin ja jaettujen palvelujen käyttöön myös jarjestelmien integrointiin avautuu uusia vaihtoehtoja. Esimerkkinä monitasoarkkitehtuurista on nelitasoinen arkkitehtuuri, jossa jarjestelma tai toimialakomponentti sisaltaa [1,4]: 1. Kayttäjäkerroksen, joka esittaa loppukäyttäjälle käyttöliittymän, 2. Työtilakerroksen, joka tukee yhden käyttäjän toimintaprosesseja, 3. Toiminta (enterprise)-kerroksen, joka tukee sovelluksen hajautettuja tai organisaation yleisiä ja yhteisia toimintaprosesseja, sisältäen usein yleiskäyttöisiä palveluita ja hajautettuja komponentteja ja 4. Resurssikerroksen, joka sisaltaa mm. jarjestelman tai toimialakomponentin tietokannan. Tallaisessa monitasoarkkitehtuurissa järjestelmiä voidaan integroida kaikilla arkkitehtuurin tasoilla. Käyttäjäkerroksen integrointi tarkoittaa jarjestelman käyttäjälle yhdenmukaisen ulkoasun ja käyttötavan (look-and-feel) luomista eri jarjestelmiin. Yleiskäyttöiset selainkäyttöliittymat ja organisaation asiantuntijaportaalit ovat esimerkkejä pyrkimisesta käyttäjäläheiseen integrointiin.

Työtilakerroksen työpöytäintegraatio on käyttäjän toimintatapojen yhdenmukaistamista jarjestelmien valilla. Esimerkkejä työpöytäintegraatiosta ovat ratkaisut, joissa kayttaja pääsee samoilla käyttäjätunnuksilla useisiin järjestelmiin, tai järjestelmät siirtyvät käsittelemään automaattisesti samaa potilasta, kun kayttaja valitsee potilaan jossain järjestelmässä. CCOW on terveydenhuollon työpöytäintegraatioon kehitetty standardi. Toimintakerroksen palveluintegraatio on yleensä (sovellus-)palvelintasolla tapahtuvaa jarjestelmien yhteentoimivuuden rakentamista. Perinteisesti palvelintason integraatio on tapahtunut esim. HL7-viestejä vaihtamalla järjestelmien välillä. Kuitenkin on saatavilla yhä enemmän myös yleisten palvelujen standardeja, (mm. OMG Healthcare DTF, CENMSA) jotka tarjoavat järjestelmille yhteistä toiminnallisuutta yhteentoimivuuden pohjaksi. Sovelluspalvelimilla sijaitsevat komponentit voivat toimia yleisten palvelujen oteuttajana. Kesurssikerroksessa yhteisen tietokannan avulla tapahtuva integrointi on yksi suurimmista jarjestelmien osittaista uusimista vaikeuttavista tekijöistä. Operatiivisten jarjestelmien välinen integrointi tulisikin pyrkiä toteuttamaan tätä tasoa korkeammilla arkkitehtuurin tasoilla. Uusina vaatimuksina resurssikerroksessa tapahtuvaan integrointiin ovat tulleet tietovarastot, tiedon louhinta ja OLAP-järjestelmät, joilla hyvinkin erilaisista tietokannoista on kyettävä tuottamaan yhdenmukaisia historiallisia ja tarkennettavia näkymiä päätöksenteon tueksi. Eri järjestelmiä integroitaessa suuria vaikeuksia aiheuttavat arkkitehtuurilliset yhteensopimattomuudet, jotka johtuvat järjestelmiä toteutettaessa tehdyistä arkkitehtuurillisista olettamuksista [2]. Nämä olettamukset ovat - usein suurelta osin dokumentoimattomia, käytetyistä välineistä tai projekti- tai henkilökohtaisista käytännöistä peräisin olevia toimintatapoja, joiden tiedostaminen ja määrittely ovat kuitenkin tarpeen integroinnin onnistumiseksi. Yhteenveto ja jatkosuunnitelmat Nykyiset integrointimenetelmät ja -tekniikat tarjoavat runsaasti mahdollisuuksia eri integrointitasoilla, eri tekniikoilla ja eri kerroksissa tapahtuvaan integrointiin. Jotta jarjestelmien integrointi onnistuisi, on alimmat integrointitasot ratkaistava joko standardien tai tilannekohtaisten ratkaisujen avulla. Kuhunkin integrointitilanteeseen tulisi olla saatavilla valmiita menetelmia ja kehyksiä protokollamallin määrittelyyn ja toteuttamiseen. Nykyisellään integroijan "työkalupakki" on puutteellinen, eikä ota huomioon kaikkia tarvittavia integrointitasoja. Varsinkaan sovellusinfrastruktuurin, semantiikan ja kehitysprosessin liittymien tasolla ei ole kattavia avoimia menetelmia yhteentoimivuuden toteuttamiseen, vaan on tukeuduttava tuotekohtaisiin tai kahdenvälisiin ratkaisuihin. Usein nämä ratkaisut vaikeuttavat sovellusten integrointia ja käyttöönottoa uusissa käyttöympäristöissä. Komponenttipohjaiseen sovellustuotantoon sisäänrakennettu sovellusten koostaminen olemassa olevista ohjelmisto-osista tarjoaa ratkaisuja myös sovellusten väliseen integrointiin. Karkeajakoisten toimialakomponenttien tai yleisten palvelujen yhteiskäyttö luo pohjan sovellusten entistä helpommalle yhteensovittamiselle. - Sovellusintegraation tarpeiden tukeminen tehokkaiden ja avoimien standardiratkaisujen avulla sovellusten arkkitehtuurissa sekä palvelin- että työpöytätasolla on suunnitteilla olevan uuden tutkimushankkeen pääteema. Hankkeessa pyritään kehittämään integrointia tukevia ohjelmistotuotantoprosessin menettelytapoja ja yleisiä rajapintamäärityksiä hyödyntäviä tekniikoita sovellusten integroimiseen käyttöönottoprojektien nopeuttamiseksi ja helpottamiseksi. Tässä työssä käytetään hyväksi Komponentti- FixIT -projektissa määriteltyä tavoitearkkitehtuuria ja siirtymäpolkuja. Hankkeessa on useita käytännönläheisiä osahankkeita sekä yhteisiä ratkaisuja tutkiva puiteprojekti. [II J. Mykkänen, "Komponentti-FixIT: Terveydenhuollon komponenttipohjainen sovellustuotanto - toiminnallisuus, arkkitehtuuri, siirtymästrategiat ja valineet". Kuopion yliopiston selvityksiä C. Luonnontieteet ja ympäi-istötieteet 7. 2000. [2] D. Garlan, R. Allen and J. Ockerbloom, "Architectural Mismatch: Why Reuse is so Hard," IEEE Software VOI. 12, no. 6, pp. 17-26, Nov. 1995. [3] A.W. Brown and K.C. Wallnau, "Engineering of Component-Based Systems," in Component-baxed Software Engineering, IEEE Computer Society Press, pp. 7-15, 1996. [4] P. Herzum and 0. Sims, Business Component Factory, New York, Wiley Computer Publishing, 2000.