Terveydenhuollon sovellusintegraatioratkaisujen

Transkriptio

1 PLUGIT-HANKKEEN SELVITYKSIÄ JA RAPORTTEJA 4 STUDIES AND REPORTS OF THE PLUGIT PROJECT 4 Juha Mykkänen, Jari Porrasmaa, Juha Rannanheimo, Tomi Tikkanen, Marko Sormunen, Mikko Korpela, Kristiina Häyrinen, Anne Eerola, Heidi Häkkinen, Marika Toivanen Terveydenhuollon sovellusintegraatioratkaisujen määrittely KUOPION YLIOPISTO SAVONIA-AMMATTIKORKEAKOULU KUOPIO 2004

2 Tekijät: Juha Mykkänen (myös toim.) Jari Porrasmaa Marko Sormunen Mikko Korpela HIS-tutkimusyksikkö, Tietotekniikkakeskus Kuopion yliopisto Juha Rannanheimo Savonia Business Savonia-ammattikorkeakoulu Kristiina Häyrinen Heidi Häkkinen Shiftec, Terveyshallinnon ja talouden laitos Kuopion yliopisto Tomi Tikkanen Anne Eerola Marika Toivanen Tietojenkäsittelytieteen laitos Kuopion yliopisto Myynti: Tietotekniikkakeskus / kanslia Kuopion yliopisto puh tike@uku.fi ISBN (koko teos) ISBN (osa 4) ISBN (PDF) Kopijyvä Oy, Kuopio 2004

3 Mykkänen, Juha; Porrasmaa, Jari; Rannanheimo, Juha; Tikkanen, Tomi; Sormunen, Marko; Korpela, Mikko; Häyrinen, Kristiina; Eerola, Anne; Häkkinen, Heidi; Toivanen, Marika. Terveydenhuollon sovellusintegraatioratkaisujen määrittely. PlugIT-hankkeen selvityksiä ja raportteja s ISBN (koko teos) ISBN (osa 4) ISBN (PDF) Tiivistelmä Terveydenhuollon sovellusintegraatioratkaisujen määrittelyyn tarvitaan menetelmiä sekä standardointia että projektikohtaisten integrointiratkaisujen määrittelyä varten. Tämä raportti dokumentoi PlugIT-hankkeessa vuosina integrointiratkaisujen määrittelyssä käytettyjä menetelmiä ja malleja ja kokoaa kokemuksia hankkeen integrointikohteista ja -tiimeistä. Raportissa esitellään pohjana käytettyjä prosesseja ja viitemalleja, kuvataan yleiskäyttöinen integraation määrittelyprosessi, annetaan tarkennettuja toimintaohjeita ja malleja prosessin eri vaiheisiin, käsitellään esimerkkejä integrointiratkaisujen tuottamisesta erityyppisissä tilanteissa ja vedetään yhteen kokemuksia integrointitiimeistä. Raportti liittyy kiinteästi muihin PlugIT-hankkeen integraatioon liittyviin tuotoksiin erityisesti Standardien arviointi ja valinta terveydenhuollon sovellusintegraatiossa ja Avointen integrointiratkaisujen hyödyntäminen, toteuttaminen ja testaus raportteihin. Raportti ei sisällä eri tiimeissä tuotettuja integrointimäärityksiä tai tiimikohtaisia tuloksia, jotka löytyvät PlugIT-projektin muista julkaisuista. Yleinen kymmenluokittelu UDK: 681.3, 006 Asiasanat (YSA): tiedonhallinta, tietojärjestelmät, systeemityö, terveydenhuolto, tietoteollisuus Medical Subject Headings (MeSH): medical informatics, information systems, information management, software, hospital information systems

4

5 Esipuhe Tämä selvitys on tehty PlugIT-hankkeessa vuosina Selvityksen tavoitteena on tarjota integrointi- ja standardointiprojekteille erityisesti terveydenhuollossa menetelmiä, malleja ja kokemuksia integraatioratkaisujen tuottamista varten. Selvitys on suunnattu integrointiratkaisujen määrittelyyn, toteutukseen tai hankintaan osallistuville ja sen kuvaamia menetelmiä voidaan hyödyntää myös muilla sovellusalueilla kuin terveydenhuollossa. 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ä. Tekijät kiittävät kaikkia Tiimitiimin menetelmäkehitykseen osallistuneita. Kiitämme myös projektiin osallistuvien yritysten ja sairaaloiden edustajia hyvistä ideoista ja näkökulmista. Kuopiossa 30. elokuuta 2004 Tekijät

6

7 Sisällys 1 JOHDANTO JA TAUSTA PlugIT-hankkeen integrointi- ja menetelmätarpeet Integroinnin määrittelyyn ja toteutukseen liittyvät tarpeet ohjelmistotuotannon nykytilaselvityksessä Ohjelmistojen integraatioprosessit ja -mallit Model-Driven Architecture (MDA) HL7 Development Framework (HDF) Integrating the Healthcare Enterprise (IHE) Sovellusten yhteentoimivuuden viitemallit ISO Reference Model for Open Distributed Processing (RM-ODP) Seitsemän tason yhteentoimivuusmalli Hajautettu viitearkkitehtuuri Integrointimallien luokittelu INTEGROINTIRATKAISUJEN MÄÄRITTELY: YLEISKUVA Integrointiratkaisun määrittely ja dokumentointi Integrointiprosessin tavoitteet Yleiskuva integrointimäärittelyistä Integrointiprojektin dokumentit Uudelleenkäytettävät määrittelydokumentit Yhteenveto integrointidokumenteista Yhteistoiminnallinen ja avoin integrointi Määrittelyjen yleistäminen ja avoimuus Määritysten hyväksyminen Moniammatillinen avoin integrointimäärittely INTEGROINTIVAATIMUKSET Integrointivaatimukset integrointiprosessissa Yleistä vaatimusmäärittelyistä Toiminnalliset ja ei-toiminnalliset vaatimukset Käyttäjävaatimukset, systeemin vaatimukset ja sovellusalueen vaatimukset Vaatimusten hankinta Vaatimusten hankintamenetelmiä Kohdealueen jäsentämisen ja kuvaamisen menetelmiä Vaatimusten dokumentointi Integrointivaatimukset-dokumentin rakenne Yksittäisten vaatimusten kuvaaminen Vaatimusten hallinta...59

8 4 TEKNIIKKARIIPPUMATTOMAT LIITTYMÄMÄÄRITTELYT Tekniikkariippumattomat liittymämäärittelyt integrointiprosessissa Tekniikkariippumattomien liittymien määrittely Integrointimallit Määrittelyn vaiheet Tekniikkariippumattomien liittymien dokumentointi Tekniikkariippumattomat liittymämäärittelyt -dokumentin rakenne Järjestelmien yhteistoiminnallisuuden yleiskuvan havainnollistaminen Toimintojen dokumentointi Tietosisällön ja käsitteiden dokumentointi Pakolliset ja puuttuvat arvot ja tiedon merkitys TEKNISET LIITTYMÄMÄÄRITTELYT Tekniset liittymämäärittelyt integrointiprosessissa Teknisten liittymien määritteleminen Eri integrointitavoille soveltuvia tekniikoita Integrointitekniikoiden valinta Teknisten liittymien dokumentointi Tekniset liittymämäärittelyt -dokumentin rakenne Teknisten liittymien määrittely eri tekniikoilla Työasemalla sijaitsevat DLL-kirjastot Web-pohjaiset liittymät Web-sovelluspalvelut XML:n käyttö tietosisällön merkkauksessa LIITTYMÄN TOTEUTUKSEN KUVAUS Liittymän toteutuksen kuvaus integrointiprosessissa Liittymän toteutuksen kuvauksen määritteleminen Liittymän toteutusten dokumentointi Liittymän toteutuksen kuvaus -dokumentin rakenne ESIMERKKEJÄ INTEGROINTIRATKAISUJEN MÄÄRITTELYSTÄ Esimerkki: Patologian pyyntö Tilaus-pyyntö -liittymän taustaa Tilaus-pyyntö integrointiprojekti Yleistäminen ja hyödyntäminen Yhteenveto Esimerkki: Avoimet koodistorajapinnat Koodistomäärittelyjen eteneminen Integrointivaatimukset ja tekniikkariippumattomat määrittelyt Tekniset määrittelyt ja toteutukset Yhteenveto KOKEMUKSIA PLUGIT-PROJEKTIN INTEGROINTIKOHTEISTA Integrointitiimien yhteenveto Integraatioratkaisujen määrittely ja toteutus Standardit ja projektikohtaiset käytännöt Moniammatilliset ja monenväliset integrointiprojektit Yhteenveto LÄHTEET...117

9 1 JOHDANTO JA TAUSTA 1.1 PlugIT-hankkeen integrointi- ja menetelmätarpeet PlugIT-hanke on vuosina toteutettu valtakunnallinen Tekes-rahoitteinen tutkimus- ja kehittämishanke, joka tuottaa avoimia ohjelmistorajapintojen määrityksiä sekä niihin liittyviä menetelmiä ja osaamista terveydenhuollon ohjelmistoyrityksille ja niiden asiakkaille. Hankkeen tavoitteena on tukea terveydenhuollon palvelutoimintaa ohjelmistotuotannon palveluketjun kautta, paremmin integroituvien ohjelmistokokonaisuuksien avulla (PlugIT 2004). Tutkimuksen sekä rajapintojen määrittelyn ovat toteuttaneet neljä Kuopion Centekin yksikköä yhteistyössä 15 ohjelmistoyrityksen, kuuden sairaanhoitopiirin (mukaan lukien kaikki yliopistolliset sairaanhoitopiirit) sekä kahden kunnan tai kuntayhtymän kanssa. Terveydenhuollon tietojärjestelmien integrointi on useiden ongelmien yhdistelmä, jossa kullakin organisaatiolla ja sovelluksella on omia ratkaistavia kysymyksiään. Teknisesti ja toiminnallisesti kirjavien sovellusten integrointia tarvitaan tietojärjestelmien kehittämiseksi sekä terveydenhuollon ammattilaisia että asiakkaita palveleviksi järjestelmäkokonaisuuksiksi. Näiden tavoitteiden saavuttamiseksi tarvitaan vähittäisiä ja osallistavia ohjelmistojen suunnittelumenetelmiä (Kuhn, Giuse 2003). Sovellusten integrointimenetelmissä on perinteisesti keskitytty tiukasti rajapintojen ja tiedonsiirron määrittelyyn, integrointi on nähty kiinteänä osana ohjelmistotuotantoa, tai niissä ei ole otettu riittävästi huomioon nimenomaan integrointiratkaisuihin vaikuttavia seikkoja (esim. Kruchten 2000, Juric ym. 2000). Integroinnissa käytettävät standardit jättävät yleensä suuren osan ratkaisuun vaikuttavia seikkoja projektikohtaisten ratkaisujen varaan. Sovellusten ja niissä käytettyjen tekniikoiden suuri määrä ja monimuotoisuus, perinnejärjestelmät ja yhtenäisen arkkitehtuurin puuttuminen ovat yleisiä tilanteita terveydenhuollon sovellusintegraatiossa. Monet integrointiprojektit tuottavat tuote- tai organisaatiokohtaisia ratkaisuja, joiden uudelleenkäyttö on työlästä ja kallista. PlugIT-hankkeen eräänä tavoitteena oli vähentää kallista paikallista sovitustyötä sovellusten integroinnissa. Tässä dokumentissa käytettyyn integraatioratkaisujen määrittelymenetelmään on kerätty kevyt mutta kattava tapa määritellä uudelleenkäytettäviä integrointiratkaisuja terveydenhuollon sovellustuotantoon. Käytetty lähestymistapa hyödyntää useita teoreettisia viitemalleja, mutta pyrkii käytännönläheisiin ohjeisiin, malleihin sekä selkeään määrittelyprosessiin integroinnin määrittelyssä. Menetelmän kehittämisessä on hyödynnetty PlugIT-hankkeen integrointikohteita, jotka tunnistettiin projektin alkupuolella, ja jotka ovat tuottaneet erilaisia määritysdokumentteja, integrointiratkaisuja ja selvityksiä projektin aikana. Tunnistetut integrointikohteet valittiin, priorisoitiin ja ryhmiteltiin integrointitiimeihin projektin aikana. Kunkin tiimin vastuulla on ollut yksi tai useampi integrointikohde, ja tiimien yhteistä kokemustenvaihtoa sekä menetelmäkehitystä varten on kokoontunut erityinen kokoava tiimi (Tiimitiimi), jonka menetelmätyöhön tämäkin selvitys perustuu. PlugIT-hankkeen integrointikohteet jaoteltiin tiimeihin vuonna 2003 seuraavasti (kohteiden ryhmittely ja työnkuva muuttui eri tiimeissä projektin aikana jonkin verran): TERVEYDENHUOLLON SOVELLUSINTEGRAATIORATKAISUJEN MÄÄRITTELY 9

10 Sovellusten yhteiset ydinpalvelut (8 kohdetta): käyttäjä- ja käyttöoikeusrajapinnat -tiimi potilas- ja kliiniset tiedot -tiimi koodisto- ja organisaatiorajapinnat -tiimi laskutusrajapinnat -tiimi sähköisen potilaskertomuksen arkistointirajapinnat -tiimi. Työpöytäintegraatiotiimi (2 kohdetta): kontekstinhallinta sovelluksen avaus konteksti välittäen. Sovellusaluekohtaiset vaatimustenhallinta- ja kartoitusmenetelmät (2 kohdetta): kotihoito-tiimi äitiysneuvolan palveluketju -tiimi. Pyyntö-tilaus-komponentti erityistilanteeseen (gastroskopia patologia). Eri tiimien tuottamia tuloksia kunkin tiimin kohdealueeseen liittyen löytyy useista julkaisuista: Terveydenhuollon avoimet sovellusrajapinnat - yhteiset perusratkaisut (Sormunen ym. 2004a), Terveydenhuollon avoimet sovellusrajapinnat - koodistorajapinnat (Mykkänen ym. 2004e), Terveydenhuollon avoimet sovellusrajapinnat - käyttäjä- ja käyttöoikeusrajapinnat (Sormunen ym. 2004b), Terveydenhuollon avoimet sovellusrajapinnat - potilasrajapinnat (Rannanheimo ym. 2004), Työpöytäintegraation avoimet sovellusrajapinnat (Tuomainen ym. 2004), Kotihoidon tiedon tarpeet (Toivanen ym. 2004a), Avointen integrointiratkaisujen hyödyntäminen, toteuttaminen ja testaus (Mykkänen ym. 2004d). Tähän selvitykseen on siis koottu kokemuksia eri tiimeissä tehdystä määrittelytyöstä sekä esitelty useissa tiimeissä hyödynnettyä (ja kokemusten pohjalta kehitettyä) integraatioratkaisujen määrittelymenetelmää. Tähän dokumenttiin erityisen läheisesti liittyviä muita PlugIT-hankkeen selvityksiä ovat Standardien arviointi ja valinta terveydenhuollon sovellusintegraatiossa (Mykkänen ym. 2004c) ja Avointen integrointiratkaisujen hyödyntäminen, toteuttaminen ja testaus (Mykkänen ym. 2004d). Tämän selvityksen luvussa 1 esitetään sekä teoreettista että projektikohtaista taustaa ja johdantoa integrointimenetelmille. Luvussa 2 annetaan yleiskuva integrointiratkaisujen määrittelystä, määrittelytyön tuotoksista ja sen vaiheista. Siinä käsitellään myös PlugIT-hankkeen malleja ja kokemuksia avoimesta ja moniammatillisesta määrittelytyöstä sekä hankkeessa käytettyä määritysten hyväksymismenettelyä. Luvuissa 3-6 käsitellään tarkemmin integrointimäärittelyiden ja toteutusten eri vaiheita: integrointivaatimuksia, tekniikkariippumattomia määrittelyitä, teknisiä määrittelyitä ja toteutuksia. Luvussa 7 esitellään esimerkkejä kahdesta erityyppisestä integrointiratkaisusta, jossa dokumentin menetelmiä on hyödynnetty. Luvussa 8 on vielä koottu eri tiimien yhteisiä kokemuksia PlugIT-hankkeen ajalta. 10 PLUGIT-HANKKEEN SELVITYKSIÄ JA RAPORTTEJA 4

11 1.2 Integroinnin määrittelyyn ja toteutukseen liittyvät tarpeet ohjelmistotuotannon nykytilaselvityksessä PlugIT-hankkeen puitteissa tehtiin alkuvuodesta 2003 kysely, jossa kartoitettiin terveydenhuollon tietojärjestelmien vaatimusmäärittelyn, ohjelmistotuotannon ja ohjelmistojen käyttöönoton ongelmia sekä keskeisimpiä kehittämiskohteita. Lomakekyselyn kohderyhmänä olivat kaikki PlugIThankkeessa mukana olevat terveydenhuollon organisaatiot ja ohjelmistoyritykset. Terveydenhuollon organisaatioita oli yhteensä 16 kappaletta, joista 12 tietojärjestelmäyksikköä ja 4 käyttäjäorganisaatiota. Ohjelmistoyrityksiä oli mukana 13. Tähän dokumenttiin on poimittu kyselyn tuloksista osiosta Tekniikka ja toteutus integrointiin liittyviä tuloksia. Kyselyn tarkemmat tulokset on esitetty kootusti lähteessä (Porali ym. 2004). Vastaajien (n=8) mielestä integroinnin suurimpia ongelmia ovat: asiakkaan ympäristöt aina erilaisia integroitavien järjestelmien erilaisuus hankaluudet neuvotella toteutustapa työn määrä suhteessa saatavaan korvaukseen sanomien määrittely standardit / standardoinnin puute lainsäädäntö kaupalliset syyt yhteistyön puute testauksen raskaus vähäinen osaaminen työpöytäintegraatiostandardien kypsymättömyys. Vastaajien (n=4) mielestä integroinnin kehittämiskohteita ovat: työpöytäintegraation standardien ja toimintamallien vakiinnuttaminen sähköinen potilaskertomus Web Service tekniikat palvelupohjaisuus sanoman välityksen sijaan Toteutuksen suurimpina ongelmina mainittiin (n=2): liian tiukat aikataulut resurssipula Valmiskomponenttien suurimmat puutteet ja hyödyntämisen esteet vastaajien mielestä ovat: komponenttien huono laatu huono tuki- ja päivityspalvelu sopivien komponenttien löytyminen standardien puute valmiskomponentteja ei ole oma yritys tuottaa, ei tarvitse ostaa, apu lähellä ongelmatilanteissa ulkomaiset toimittajat tietoturva TERVEYDENHUOLLON SOVELLUSINTEGRAATIORATKAISUJEN MÄÄRITTELY 11

12 Valmiskomponenttien käyttöä voitaisiin vastaajien mielestä lisätä, jos komponenttien valmistus ja myynti olisi vakiintunutta liiketoimintaa terveydenhuollon ohjelmistot ja tiedot olisivat standardoituja Tärkeimpiin integrointikohteisiin kohdistuvien kysymysten vastauksissa oli painotettu varsinkin rajapintoja elektronisen potilaskertomuksen hallintaan, käyttäjän tunnistamista, käyttöoikeuksien hallintaa, sisäänkirjautumista ja asiakkaan suostumuksen hallintaa. Kahdenvälisesti sovittavana asiana sekä nyt että tulevaisuudessa nähdään asiakasorganisaation organisaatioyksiköt ja organisaatiorakenne. Sisällölliset vastaukset (mitä integraatioita tulisi jatkossa sopia avointen standardien pohjalta) näkyvät osaltaan edellisessä luvussa esitellyssä valittujen integrointikohteiden luettelossa. Tässä katsotaan kuitenkin tarkemmin integrointitapoihin ja -tekniikoihin liittyviä tuloksia sekä sitä, mitkä asiat sovitaan standardien pohjalta, mitkä kahdenvälisesti. Useimmiten nykyisin käytössä oleva integrointitapa on määräajoin eräsiirtona tapahtuvat tiedonsiirrot. Usein käytettyjä tapoja ovat myös tiedon välitys tietoalueen tai tietokannan kautta ja samaan koneeseen asennettujen sovellusten välinen integrointi. Tavoitetilassa teknologioista käytetyin olisi XML-pohjainen integrointi. Myös komponenttipohjainen integrointi tulee olemaan suosittua. Näiden kahden taso tulee nousemaan merkittävästi. Suhteellisesti eniten tasoaan tulee kasvattamaan Web Service -tekniikka Selvityksen mukaan useimmiten standardien tai yleisten määritysten pohjalta sovittavia asioita ovat nykyisin tietoelementtien muoto ja pituus, käytettävät viestit tai operaatiot ja jokaisen ohjelmakutsun vastaus tai kuittaus. Selvityksen mukaan käytetyin terveydenhuollon standardeista, nyt ja tavoitetilassa, on HL7 versio 2. CDA:ta (Clinical Document Architecture) ja DICOM:ia käytetään harvoin. Muiden standardien käyttö on satunnaista. HL7:n versio 3:n käyttö tulee kasvamaan merkittävästi. Myös CDA:n käyttö tulee tavoitetilassa olemaan nykyistä yleisempää. Huomattavasti tasoaan tulee kasvattamaan työpöytäintegraation CCOW-standardi (ks. kuva 1.1). Integroinnissa hyödynnettävät terveydenhuollon standardit nykytila tavoitetaso Kuva 1.1. Integroinnissa hyödynnettävät terveydenhuollon standardit 12 PLUGIT-HANKKEEN SELVITYKSIÄ JA RAPORTTEJA 4

13 1. HL7 versio 2 2. HL7 versio 3 3. CDA (Clinical Document Architecture) 4. IHE (Integrating Healthcare Enterprise) 5. DICOM 6. CCOW 7. Arden syntax 8. OMG Healthcare-standardit 9. HISA 10. Muut CEN TC 251 standardit Yleisistä teknisistä standardeista käytetyin on XML. Seuraavana tulevat muut standardit, joita ovat, vastaajien mukaan: EJB, Web Serviceä, SOAP, UDDI, WSDL ja J2EE. Muita vaihtoehtoina annettuja standardeja käytetään joskus tai harvemmin. Tavoitetilassa eniten käytettyjä ovat muut standardit, myös XML näyttää säilyttävän hyvin asemansa. XML Schema ja XML DTD ovat nykyistä käytetympiä. Muiden vaihtoehtoina annettujen standardien käyttö tulee pysymään satunnaisena (ks. kuva 1.2). Integroinnissa hyödynnettävät yleiset ja tekniset standardit nykytila tavoitetaso Kuva 1.2. Integroinnissa hyödynnettävät yleiset ja tekniset standardit 1. XML, nykytila 2. XML Schema 3. XML DTD 4. HTML 5. LDAP 6. PKI-standardit 7. OMG (CORBA) IDL 8. Muut standardit TERVEYDENHUOLLON SOVELLUSINTEGRAATIORATKAISUJEN MÄÄRITTELY 13

14 Kahdenvälisesti toimittajien välillä sovitaan nykyisellään useimmiten viestin tai operaatioiden kutsumisessa käytetystä tekniikasta, tietosisällön eri osissa käytetyistä koodistoista ja tarkasta tietosisällöstä. Tavoitetilassa halutaan sopia entistä useammin erityisesti virhetilanteiden käsittelystä. Lähes aina sovitaan myös järjestelmien toiminnallisista vastuista, integroinnissa käytetyistä ulkoisista tuotteista, ratkaisun ylläpitovastuista ja ratkaisun konfiguroinnista. Jatkossa entistä enemmän toimittajien välillä halutaan sopia erityisesti virhetilanteiden käsittelystä ja asiakkaan suostumuksen hallinnasta. Itsenäisesti tai asiakkaan vaatimusten mukaan yleisimmin sovittavia asioita ovat: ratkaisun ylläpitovastuu, tietoliikenne järjestelmien välillä sekä ratkaisun konfigurointi. 1.3 Ohjelmistojen integraatioprosessit ja -mallit Nykyaikaisessa ohjelmistotuotannossa painotetaan usein sovellusten ja niiden osien uudelleenkäyttöä ja helppoa sovitettavuutta (sovellusten koostaminen). Useimmissa ohjelmistotuotantoprosesseissa integroinnin erityiskysymyksiä ei ole kuitenkaan otettu systemaattisesti huomioon. Integrointi on nähty yleensä kiinteänä osana ohjelmistotuotantoa, tai prosessissa ei ole otettu riittävästi huomioon vanhojen sovellusten vaikutuksia, teknistä erilaisuutta tai päällekkäisyyksiä (esim. Kruchten 2000, Juric ym. 2000). Komponenttipohjaiset menetelmät soveltuvat joustavien ja monimutkaisten ohjelmistokehitysprojektien työkaluksi (ks. esim. Riekkinen ym. 2004), mutta edellyttävät yhteisen komponenttimallin käyttöä ja osien keskitettyä hallintaa. Näitä edellytyksiä on harvoin käytössä integrointiprojekteissa, joissa korostuvat ympäristön heterogeenisyys ja sovellusten itsenäisyys. Esimerkiksi RUP (Rational Unified Process) (Kruchten 2000) on runsaasti huomiota saanut tarkka ja yksityiskohtainen prosessi, joka perustuu inkrementaaliseen ja iteroivaan elinkaarimalliin muistuttaen spiraalimallia. Prosessi käyttää UML:n käyttötapauksia, keskittyy ohjelmistoarkkitehtuuriin ja jakaa sovellustuotannon useisiin pieniin projekteihin (iterations), joiden tulokset ovat uusia piirteitä (increments). Kukin iteraatio keskittyy tärkeimpiin riskeihin ja tuottaa valittujen käyttötapausten toteutukset. Alussa luodaan tärkeimmistä toiminnoista pintapuolinen toteutus. Prosessin alkuvaiheessa iteraatiot tuottavat yleensä uusia versioita sovelluksen toteutettuihin osiin, loppuvaiheessa tuloksina on uusia piirteitä sovelluksiin. RUP on kuitenkin usein nähty kohtalaisen raskaana ohjelmistokehitysmallina, ja se kohdistuu uusien sovelluksen tuottamiseen, ei niinkään olemassa olevien integrointiin. Seuraavaksi tässä luvussa käsitellään tarkemmin kolmea ohjelmistotuotannon tai -integraation menetelmäkokonaisuutta tai menettelytapaa, joissa on korostettu integraation merkitystä ja helposti integroituvien ratkaisujen tuottamista. Malleja on sovellettu PlugIT-hankkeen integrointimenetelmien kehityksessä Model-Driven Architecture (MDA) Model Driven Architecture (MDA) on OMG:n (Object Management Group) kehittämä konsepti, jonka tavoitteena on korottaa integrointi- ja sovellustuotannon määrittelyiden abstraktiotasoa kuvaamalla, kuinka järjestelmät tulisi integroida (Allen 2002). MDA:n kehityksessä on ollut mukana lähes kaikki keskeiset ohjelmistoalan yritykset ja toimijat. MDA ei ole täysin uusi keksintö, vaan se yhdistää jo olemassa olevia toimittajariippumattomia OMG-teknologioita (XMI, MOF, UML) yhdeksi menetelmäksi, ja näin ollen vahvistaa UML:n (Unified Modeling Language) asemaa sovelluskehitysprosessissa. Suurimpia ongelmia järjestelmäsuunnittelussa on ollut prosessien ymmärtämisessä sekä niihin liittyvän tiedon ja prosessien ja tietojen välisten suhteiden kuvaamisessa. MDA:n ideana on saada mallinnuksen avulla kuvattua nämä tärkeimmät osat, jolloin järjestelmien keskeiset osat on suunniteltu. Näistä malleista hyödynnetään tarvittavia osia sovelluksissa. On olemassa erilaisia vä- 14 PLUGIT-HANKKEEN SELVITYKSIÄ JA RAPORTTEJA 4

15 lineitä, jotka generoivat sovelluksia tai ainakin hyvin paljon valmista koodia UML-malleista (Process to Application-konsepti). Tavoitteena MDA:ssa on erottaa systeemien toiminnalliset määrittelyt niihin liittyvistä erilaisista teknisistä toteutuksista (ks. kuva 1.3). Pääpaino on arkkitehtuurin suunnittelussa ja pysyvien ratkaisujen tuottamisessa. Suunnittelu, kehitys ja ylläpito pohjautuu liiketoimintaprosesseihin (OMG 2004). MDA-suunnittelu on mallikeskeistä ja mallit muodostavat kolmikerroksisen hierarkian: Computation Independent Business Models Platform Independent Models Platform Specific Models Kuva 1.3. MDA:n mallien väliset muunnokset. Computation Independent Business Models-tasossa mallinnetaan toimintaprosessit ilman tietoteknisiä ominaisuuksia. MDA:n perusajatus on, että näihin prosesseihin määriteltävät järjestelmät mallinnetaan kahdessa tasossa. PIM-taso on alustariippumaton (ei riipu toteutusteknologiasta) ja ajatuksena siis on muodostaa kohdealueesta erilaisia teknologiariippumattomia (Platform Independent Model, PIM) kuvauksia UML-notaation mukaisesti. Liiketoimintalogiikka mallinnetaan tässä alustariippumattomassa osassa. Korkean tason PIM-mallit eivät sisällä toteutusten yksityiskohtia. PIM-mallin ei siis tarvitse sisältää kaikkia sovelluksen yksityiskohtia: esimerkiksi sovellusten hajautus, yhtäaikaisuus, tapahtumankäsittely ja turvallisuus voidaan lisätä tarkempiin malleihin tai ottaa käyttöön jakeluun liittyvinä konfiguraatioina, jos käytössä on MDA:ta tukevia sovelluspalvelimia. Kun käytössä oleva teknologia on valittu, ylemmän tason mallit kiinnitetään tiettyyn toteutukseen (Platform Specific Model, PSM) erilaisten sääntöjen avulla (mappings) (ks. kuva 1.4). PSM-mallissa lisätään rajauksia (constraints) PIM-malliin. Tähän alustariippuvaiseen osaan siis mallinnetaan teknologia- ja järjestelmäriippuvaiset osat. Yhdestä PIM-mallista voidaan luoda yksi tai useita PSM-malleja. PSM-malli sisältää toteutusrakenteita tietylle toteutustekniikalle. Esimerkkejä ovat tietokantamalli tai EJB-komponenttimalli. OMG on määritellyt joukon profiileja, joilla varmistetaan että tietystä PIM-mallista voidaan generoida rajapintoja erilaisille väliohjelmistoalustoille. Viimeisessä vaiheessa PSM-malli muunnetaan koodiksi. Koska PSM vastaa läheisesti tiettyä tekniikkaa, muunnos on yksinkertainen (ks. kuva 1.5). Väliohjelmistoista ja OMG:n standardeista lisätietoja löytyy mm. raportista (Mykkänen ym. 2004b). TERVEYDENHUOLLON SOVELLUSINTEGRAATIORATKAISUJEN MÄÄRITTELY 15

16 Kuva 1.4. Tekniikkakohtaisten mallien generointi PIM-mallista. Kuva 1.5. Toteutusten generointi PSM-malleista. Välineet MDA:n toteuttamiseen (mm. Rational Rose) tarjoavat mappausvaiheessa teknologiaspesifiset toiminnallisuudet ja ominaisuudet, jotka generoidaan toteutukseen. Käytännössä on havaittu ettei yleispäteviä, kaikkiin arkkitehtuureihin sopivia komponentteja pystytä toteuttamaan, mutta MDA:n avulla samojen määrittelyjen mappaamista eri arkkitehtuureihin voidaan helpottaa. MDA:n teknologiariippumattomista UML-malleista voidaan mm. määritellä komponentteja eri ympäristöihin (ks. kuva 1.6). Kuva 1.6. UML-mallin siirto eri tekniikoille XMI:n kautta. 16 PLUGIT-HANKKEEN SELVITYKSIÄ JA RAPORTTEJA 4

17 MDA:n avulla pyritään tuottamaan pysyvämpiä ja paremmin uudelleenkäytettäviä ratkaisuja. MDA mahdollistaa myös mallien uudelleenkäytön. Ennen kaikkea se säilyttää yhteyden analyysi- ja suunnitteluvaiheesta toteutukseen määrittelemällä säännöt, joilla suunnittelumallit kuvautuvat eri toteutuksiksi (ks. kuva 1.6). Näin mallihierarkiassa eri tasojen välille muodostuu yhdestä moneen suhteita, eri tasojen välinen yhteys (jäljitettävyys) säilyy ja mallit ovat keskenään ristiriidattomia. UML:n ja generoitavan koodin välissä voidaan välineistä riippuen käyttää esim. XMI:tä (XML Metadata Interchange), jota käytetään UML-mallien (tai tarkemmin: Meta-Object Facility (MOF) - spesifikaation mukaisten mallien) tallettamiseen ja jakeluun. XMI:n käyttöä puoltaa se, että se on yleisin UML:ää tukeva tiedonsiirtoformaatti ja XML-pohjaisena kielenä se on hyödynnettävissä standardityökaluilla. MDA:n hyödyt tulevat ilmi myös myöhemmin, kun sovellusta kehitetään edelleen seuraavaan versioon. Hyvin mallinnettu projekti mahdollistaa myös tarvittaessa uusien teknologioiden nopean käyttöönoton, sillä sovelluksen sisältämä koodi on eroteltuna mallinnetuista olioista. Jos halutaan ottaa käyttöön uutta teknologiaa, mallinnetut oliot voidaan vaihtaa koskematta räätälöityyn ohjelmakoodiin. Kunnianhimoisena tavoitteena MDA:ssa on suunnitella mallipohjaisia arkkitehtuureja, jotka ovat käytössä 20 vuotta, ainoastaan mappaukset eri alustoille vaihtuvat. Esimerkiksi UML-ohjattu sovelluspalvelin ei käyttäisi suoraan API-rajapintoja vaan mallia. Koska malli on alustariippumaton, se toimisi minkä tahansa UML-ohjatun sovelluspalvelimen kanssa. MDA:ssa on useita piirteitä, joita CASE-menetelmät korostivat 80-luvulla: molemmissa pyritään helpottamaan sovelluskehitystä automatisoimalla koodin generointia. MDA vaatii, että käytetty UML-mallinnuskieli on riittävän tarkkaa, jotta sillä voidaan määritellä toteutuksiin asti vaikuttavia malleja. UML muodostaa yhteisen määrittelykielen, ja jotkut välineet tarjoavat jopa mahdollisuuden jäljittää ohjelmistovirheitä (debugging) mallitasolla. MDA asettaa paljon vaatimuksia käytettäville välineille ja sovelluskehitykselle (esim. koodimuutosten vaikutus malliin, erot, puutteet ja epäyhteensopivuudet UML:n ja toteutustekniikkakohtaisten rakenteiden välillä, sovelluskehityksen muuttaminen koodaamisesta mallintamiseen jne.). Vaikka useita MDA:ta tukevia välineitä on saatavilla, niiden yleistyminen on vielä vähintäänkin epävarmaa. PlugIT-hankkeessa MDA-konseptia on hyödynnetty ottamalla siitä kehitettäviin menetelmiin hyödyllisiksi nähtyjä piirteitä, joita ovat etenkin: tekniikkariippumattoman ja tekniikkakohtaisen määrittelyn erottaminen toisistaan, mikä mahdollistaa sisällöllisesti samojen ratkaisujen toteutuksen eri rajapinta- ja toteutustekniikoilla, integraatioratkaisujen vaiheittainen tarkentaminen, kussakin vaiheessa lisättävien lisärajausten avulla. mallinnusmenetelmät HL7 Development Framework (HDF) HL7 Message Development Framework on HL7:n kehittämä menetelmä, jonka tarkoituksena on kuvata prosessi HL7-sanomien rakennukseen, toimintojen (trigger event) kuvaamiseen ja muiden sanomaintegraatiossa tarvittavien tuotosten luomiseen (kuva 1.7). Message Development Framework perustuu CEN TC215:n tekemään työhön. Message Development Framework tullaan korvaamaan HDF:llä (HL7 Development Framework), joka sisältää prosessikuvaukset myös muiden HL7:n standardien (CDA, CCOW, Arden Syntax) toteuttamiseen. HDF on osa HL7:n versiota 3, joka sisältää myös RIM (reference information model) -käsitemallin ja vahvan linkityksen määriteltyihin sanastoihin ja terminologioihin (Heitmann ym. 2002). TERVEYDENHUOLLON SOVELLUSINTEGRAATIORATKAISUJEN MÄÄRITTELY 17

18 Application Role Trigger Event RIM Instantiate Storyboard Sender Receiver D-MIM Triggers Restrict References Interaction R-MIM Example Restrict HMD Restrict Storyboard Example Content Message Type Kuva 1.7. Kaaviokuva HL7 MDF:n (Message Development Framework) tietomallin tuottamisesta Viestien suunnittelu perustuu monien tietomallien käyttöön. Kuvan 1.7 tietomallit ovat: RIM (Reference Information Model), yhteinen jaettu tietomalli, josta kaikki muut mallit luodaan, D-MIM (Domain Message Information Model), tietyn sovellusalueen tarkennettu viestimalli, R-MIM (Refined Message Information Model), tarkennettu viestin tietomalli, HMD (Hierarchical Message Description), viestimallista tarkennettu viestin hierarkkinen kuvaus. Kuten MDA-konseptiin, myös HL7 Development Framework:iin liittyy mallinnus varsin keskeisenä osana, ja suunnittelu on tekniikkariippumatonta (ks. kuva 1.8). Mallinnus lähtee liikkeelle ns. normaaliin tapaan vaatimusmäärittelystä käyttötapauskuvauksineen. RIM-mallin pohjalta mallinnetaan tarkennettu toimialan (domain) kuvaus. Seuraavaksi määritellään järjestelmien väliset vuorovaikutussuhteet, joiden perusteella luodaan sanomien rakennekuvaus. Reference Model Repository on varasto, jonne mallit kootaan, ja sieltä aiemmin luotuja malleja voidaan käyttää uudelleen. HL7 version 3 viestien määrittelyssä on seuraavat vaiheet (Heitmann ym. 2002): 1. Kirjoitetaan esimerkki (storyboard, esim. kuvan 1.8 käyttötapausmallien paikalla) sovellusalueelta, josta käy ilmi kuinka tietoa siirretään tai tulisi siirtää kyseessä olevassa tilanteessa. Tavoitteena on ymmärtää, mitkä toimijat osallistuvat toimintaan, miten, mitkä ovat heidän tietotarpeensa, ja kuinka he hyödyntävät tietokonetta tehtävässä. Myös kuvaus on osa määrityksen dokumentointia. 2. Sovellusroolit: esimerkistä tutkitaan, millaista järjestelmien välistä kommunikaatiota tarvitaan. Järjestelmiä käsitellään tyyppeinä (sairaalatietojärjestelmä, laboratoriojärjestelmä jne.) ja suuret järjestelmät jaetaan pienempiin toiminnallisiin osiin (esim. ajanvaraus, laboratorio suuressa sairaalajärjestelmässä). Tuotettuun esimerkkiin merkitään erityisesti siinä tarvittu tiedonvälitys (esim. A kysyy B:ltä tuloksia, B vastaa). Kustakin tiedonvälityskohdasta päätetään, mikä on siirrettävän tiedon pääsisältö (esim. lähete, rtg-tutkimuksen tulokset, tilaus jne.). Näiden tietojen perusteella listataan sovellusten roolit. 18 PLUGIT-HANKKEEN SELVITYKSIÄ JA RAPORTTEJA 4

19 Kuva 1.8. HL7 version 3 mallit ja niiden tuottaminen (Heitmann ym. 2002). 3. Piirretään karkean tason yhteistoimintakaavio, jossa sovellusroolit ovat laatikoita ja tietovirrat suunnattuja nuolia niiden välillä. Kukin nuoli kuvaa interaktiota, ja sillä on tunniste, laukaiseva tapahtuma (trigger event), ja siirtyvän viestin nimi tai yhteenveto. 4. Tapahtumat (trigger events), sovellusroolit, viestityypit ja interaktiot lisätään tietokantaan (publication database), jossa säilytetään käytetyt viestit ja muut määrittelyt uudelleenkäyttöä varten. 5. Kullekin interaktiolle määritellään viestin sisältö. Yleistä sanastoa käyttäen listataan tietoelementit, jotka on siirrettävä (esim. lähete, jossa mukana potilaan henkilötiedot, lähettävä lääkäri, etäkonsultaatiopyyntö, laboratoriotutkimuspyyntö viimeisten 10 päivän aikana tehdyistä tutkimuksista jne.) 6. Järjestetään ja strukturoidaan kohdan 5 listat, tavoitteena dokumentoida interaktioiden ja tietojen riippuvuudet, tietoelementtien mahdollinen ryhmittely jne. 7. Ryhmittelyn perusteella päätetään, mitkä tietokokonaisuudet suunnitellaan itse, ja mitkä hankitaan valmiina aikaisemmista määrittelyistä tai muista ryhmistä. 8. Itse suunniteltavat tietojoukot luokitellaan RIM- tai R-MIM-mallien mukaisiin luokkiin: Toiminnot (Acts), Toimintosuhteet (Act-relationships), Osallisuudet (Participations), Entiteetit (Entities), Roolit (Role-relationships), Muut (Other or undetermined) 9. Käytetään välineiden (Visio) viestimalli (R-MIM) -notaatiota ja luodaan kustakin R-MIMmallin osasta kaavio. Kaavioon otetaan mukaan kunkin osan todennäköiset tai tärkeimmät tietoelementit. Kullekin luokalle määritellään tunnistekoodi, ja toiminnoille myös tapahtumakoodi (mood code, esim. onko kyseessä suoritettu, aiottu, tavoite, riski, mahdollisuus tms.). 10. Linkitetään kaavion osiot yhteen R-MIM-mallin dokumentoimiseksi. TERVEYDENHUOLLON SOVELLUSINTEGRAATIORATKAISUJEN MÄÄRITTELY 19

20 HL7:n V3-metodologia on tarkoitettu lähinnä viestistandardien määrittelyyn, mutta se on sovellettavissa myös muun tyyppisissä integrointitilanteissa. Erityisen käyttökelpoisia piirteitä ovat: rikas tietomallien käyttö, nojautuminen määriteltyihin sanastoihin, käytettyjen mallien ja niiden osien talletus varastoon tai tietokantaan uudelleenkäyttöä varten, käyttötapausten ja sovellusalueen kuvausten käyttö määrittelyn alkuvaiheessa, sovellusroolien ja interaktioiden tunnistaminen ja varastointi, harmonisointi ja palaute käytettyjen viitemallien jatkokehittämiseksi standardoinnissa Integrating the Healthcare Enterprise (IHE) IHE (Integrating the Healthcare Enterprise) on integrointikonsepti, joka on lähtöisin USA:n radiologien yhteisöstä. IHE on keskittynyt vuodesta 1999 radiologiaan ja viestipohjaisiin (HL7 ja DI- COM) integrointeihin, mutta sen integrointimallit (integration profiles) tarjoavat hyvän korkeamman tason mallin yhteistoiminnalle yleisemminkin. IHE:n peruskäsitteitä ovat: Ohjelmistojen yleisnimet, komponentit (Actors): ohjelmisto-osat, jotka ovat keskenään kommunikoivissa rooleissa järjestelmien välillä, Transaktiot (Transactions): järjestelmien välillä välitettävät viestit, Integraatioprofiilit (Integration Profiles): komponenttien ja transaktioiden ryhmiä, joiden avulla suoritetaan määriteltyjä työnkulkuja (workflows). IHE:n tavoitteena on parantunut tiedonkulku ja edistyneen usean järjestelmän yli ulottuvan toiminnallisuuden määrittely (yhteinen toiminnallinen viitemalli). IHE sisältää integrointimalleja (integration profiles), joissa on tunnistettu eri integrointitilanteiden osallistuvat järjestelmät (actors) ja niiden vuorovaikutus (transactions) ja vastuut (ks. kuva 1.9). Vuorovaikutuksessa on viittauksia joko HL7 tai DICOM-standardeihin. IHE ei ole itsessään standardi eikä tuote. (Wein ym. 2002) IHE-profiileja noudattamalla integrointiratkaisut määritellyille työnkuluille toimivat työnkulun suhteen tarkasti määritellyllä tavalla yhteen. Lisäksi integrointiprofiilit helpottavat toimittajan ja asiakkaan kommunikaatiota, koska niiden avulla määritellään, mitä työnkulkuja ja mitä komponentteja kussakin integrointiratkaisussa kuhunkin järjestelmään liittyy. IHE-organisaatio koostuu monista terveydenhuollon ja varsinkin radiologian yhteisöistä (RSNA, EAR, ECR, HIMSS, EuroPACS, yli 30 yritystä). Käyttäjät ja toimittajat pyrkivät yhdessä integrointiin. Vuosittain käydään läpi prosessia, jossa tutkitaan työnkulkuja, valitaan standardeja ja kirjoitetaan työnkulkuja ja profiileja IHE-määrityksiin. Connectathon-nimisessä tapahtumassa (esim. osallistujina vuosina toimittajaa Euroopassa, 30 USA:ssa) ja demotilaisuuksissa eri toimittajien järjestelmät liitetään profiilien perusteella yhteen. Näitä tilaisuuksia varten tarvitaan asiantuntemusta sekä IHE:stä, HL7:stä että DI- COM-standardista. Useimmat integrointistandardit keskittyvät vain yhteen transaktioon unohtaen kokonaiskuvan yhteistoiminnasta, eivät ota juuri kantaa miten "oikeaan" integrointitilanteeseen tehdään ratkaisu ja sallivat liikaa vaihtelua. Ostajat voivat selkeästi määritellä vaadittuja integrointivaatimuksia IHE:n avulla ja voivat lisätä tarjouspyyntöihin viittauksia IHE:en tai kysyä mitä komponentteja ja profiileja mikäkin tuote sisältää. Näin pyritään myös saamaan määrittelyjä käyttöön ja tuotteisiin. IHE:n nykyiset määritykset keskittyvät integraatioon radiologiassa. Suunnitelmissa on IHE:n toinen vaihe, jossa IHE:n aluetta laajennetaan kattamaan horisontaalisia palveluita (potilaan rekisteröinti, tilaukset, master patient index, clinical patient record). Myös CCOW oli tulevaisuuden suunnitelmissa. Kolmannessa vaiheessa lisätään radiologian lisäksi muita vertikaalisia palveluita (mm. 20 PLUGIT-HANKKEEN SELVITYKSIÄ JA RAPORTTEJA 4

21 laboratorio, patologia, kardiologia). Myös eurooppalaisten tarpeita tuodaan esiin, mm. osoitteessa Kuva 1.9. IHE:n integrointiprofiilit (HIMSS, RSNA 2002). IHE:n käyttökokemusten mukaan integrointiprofiileja otetaan käyttöön yksi kerrallaan ja soveltaminen oikeaan hoito-ongelmaan on tärkeää. IHE:n käyttöönotossa on suoritettu mm. seuraavia toimenpiteitä (Wein ym. 2002): toiminnallisen työnkulun analyysi tietovirrat, nykyisten ja tavoiteltujen komponenttien ja transaktioiden määrittely, nykytilan ja tavoitetilan eroavuusanalyysistä johdetut vaatimukset käyttäjien odotusten hallinta tuotteiden tukemien aktorien, transaktioiden ja integraatioprofiilien listaaminen (esim. PACSjärjestelmät sisältävät yleensä ainakin Image manager, Image archive ja Image displaykomponentit) sertifiointi IHE:n jatkotyössä on tarvetta parantaa suorituskykyvaatimusten kuvausta ja saada profiileihin ja määrittelyihin lisää kliinisiä sovelluksia. IHE:ltä löytyy matriisi eri tuotteista, josta selviää mikä tukee mitäkin profiilia. Tällä hetkellä käytössä ovat HL7 versio 2.x-pohjaiset ratkaisut, mutta HL7:n versio 3:a halutaan käyttää tulevaisuudessa. IHE:n turvallisuus on suunniteltu HIPAA-määritystä varten. IHE kattaa useankin eri standardin määrittelemiä tietoja ja toimintoja varsinkin, kun sitä laajennetaan suunnitelmien mukaisesti horisontaalisten palveluiden puolelle (turvallisuus, tilaukset, TERVEYDENHUOLLON SOVELLUSINTEGRAATIORATKAISUJEN MÄÄRITTELY 21

22 EPR, CCOW). Toistaiseksi se on kuitenkin varsin radiologia-keskeinen, ja hyödyntää pelkästään DICOM- ja HL7-viestistandardeja. IHE-lähestymistavan erityisiä vahvuuksia ovat: kokonaiskuvan ja työnkulun huomiointi, korkean tason yhteentoimivuusmalli, esim. HL7 ja DICOM katsovat vain kahta järjestelmää kerrallaan viittaaminen tarkempiin teknisiin standardimäärittelyihin kussakin transaktiossa käytännön testaus järjestelmiin tehtyjen toteutusten välillä nykytilan kuvaaminen suhteessa tavoitetilaan ja vaatimusten johtaminen näiden eroista. 1.4 Sovellusten yhteentoimivuuden viitemallit Kuten aiemmin mainittiin, standardit kattavat vain osan integrointitilanteessa ratkaistavista asioista. Sovelluksia integroitaessa on löydettävä vastaukset mm. seuraaviin kysymyksiin: Mitä: Mitkä tiedot ja toiminnot pitää jakaa tai siirtää sovellusten välillä? Kuinka nämä seikat huomioidaan integrointimäärittelyissä? Missä: Mihin kohtiin osallistuvien sovellusten arkkitehtuurissa ja työnkuluissa integrointiratkaisu sijoittuu? Kuinka osallistuvien järjestelmien, käyttäjien ja muiden toimijoiden vastuut integrointiratkaisusta määritellään? Kuinka: Mikä on tilanteeseen sopivin integrointimalli ja mitkä ovat konkreettiset integroinnissa käytettävät tekniikat ja standardit? Millaista teknistä infrastruktuuria tarvitaan integrointiratkaisun toteuttamiseen? Milloin: Voidaanko yhteentoimivuutta ja integrointia tukea jo järjestelmien ja niitä tukevan infrastruktuurin kehityksen ja hankinnan yhteydessä? Edellyttävätkö integrointiratkaisut jo varhaista huomiointia järjestelmien määrittelyssä ja suunnittelussa vai toteutetaanko niitä esim. järjestelmän käyttöönoton jälkeen erillään varsinaisesta kehitystyöstä? Näiden seikkojen huomiointiin PlugIT-hankkeen määrittelyissä on hyödynnetty useita viitemalleja, joista tässä esitellään muutama ISO Reference Model for Open Distributed Processing (RM-ODP) ISO:n määrittelemässä RM-ODP-mallissa (Reference Model for Open Distributed Processing) määritellään useita näkökulmia, joita sovelletaan tässä järjestelmien välisen yhteistoiminnan määrittelyssä (ISO/IEC 1995): Enterprise-näkökulma keskittyy järjestelmään ja sen ympäristöön erityisesti järjestelmän tarkoituksen, sen kattaman sovellusalueen ja toimintojen ja sääntöjen (policies) näkökulmasta. Information-näkökulma keskittyy järjestelmän sisältämään tietoon, sen semantiikkaan ja käsittelyyn. Computational-näkökulma keskittyy rajapintoihin, joiden avulla järjestelmiä jaetaan keskenään kommunikoiviin osiin tai olioihin ja hajautetaan. Engineering-näkökulma keskittyy mekanismeihin, joilla tuetaan järjestelmän osien tai olioiden hajautettua kommunikointia ja teknistä suunnittelua. Technology-näkökulma keskittyy järjestelmän tekniikkavalintoihin. RM-ODP-mallia on sovellettu tämän dokumentin integrointimenetelmien lisäksi mm. Standardien arviointi ja valinta terveydenhuollon sovellusintegraatiossa -raportissa (Mykkänen ym. 2004c), jossa on myös kuvattu tarkemmin eri näkökulmia. 22 PLUGIT-HANKKEEN SELVITYKSIÄ JA RAPORTTEJA 4

23 1.4.2 Seitsemän tason yhteentoimivuusmalli Järjestelmien yhteentoimivuus ei siis ole pelkkä tekninen ongelma, vaan siihen sisältyvät myös sisällölliset, toiminnalliset ja arkkitehtuurilliset seikat. Eräs käyttökelpoinen malli integrointiratkaisujen määrittelyyn on seitsentasoinen järjestelmien yhteentoimivuusmalli (Herzum, Sims 2000, ks. kuva 1.10). Eri tasojen tunnistaminen on hyödyllistä yhteensovittamista suunniteltaessa ja käytettäviä tekniikoita ja standardeja valitessa. Tämän dokumentin mukaisissa integrointimäärittelyissä on tavoitteena, että kunkin tarvittavan tason (kuusi alinta) tärkeimmät seikat on ratkaistu ja dokumentoitu viimeistään toteutuksen yhteydessä (eri tasoisissa ja eri seikkoihin vastaavissa määrittelyissä). Myös tätä viitemallia on käsitelty tarkemmin standardien yhteydessä lähteessä (Mykkänen ym. 2004c). Kehitysprosessin liittymät Toiminnallinen viitemalli Semantiikka Toiminnalliset liittymät Sovellusinfrastruktuuri Tekninen infrastruktuuri Tekniset liittymät Kuva Seitsentasoinen yhteentoimivuusmalli (Herzum, Sims 2000). Mallissa on järjestelmien yhteentoimivuuden suhteen tunnistettu seuraavia tasoja: 1. Tekniset liittymät: ohjelmistomekanismit ja tekniikat, joilla kohdejärjestelmään ollaan yhteydessä. Esimerkkejä näistä tekniikoista ovat CORBA, RPC, DCE, SQL-kieli, XML jne. Protokolla voi olla myös usean tekniikan yhdistelmä, esim. XML:n käyttö yhdessä COR- BA:n kanssa. Tekninen liittymä voi olla tietokantaperusteinen, tiedostopohjainen yhdyskäytävä tai ohjelmointirajapinta (API) tai näiden yhdistelmä. 2. Tekninen infrastruktuuri. järjestelmien välinen kommunikoinnin tekninen tuki, mm. virheidenkäsittely, nimeäminen, transaktiot, monet turvallisuuspiirteet, kohdejärjestelmän aktivointi jne. Kutsuva järjestelmä voi joko mukautua kutsuttavan järjestelmän protokollaan (mallituntemus) tai järjestelmillä on yhteisiä protokollia ja tieto siitä missä tilanteissa niitä käytetään (kontekstituntemus). 3. Sovellusinfrastruktuuri. Toiminnallisen yhteensopivuuden saavuttamiseksi tarvitaan sovellusinfrastruktuuria, joka sisältää arkkitehtuuriset päätökset, käytännöt, liittymäkäytännöt ja suunnittelumallit. Standardien puutteen vuoksi tällä alueella yleensä kehitetään projektin tarpeisiin oma ratkaisu, joka vaatii tulkkausta tai sovitinta yhteentoimivuuden tukemiseksi. Esimerkkejä tämän tason ratkaisuista ovat integrointipisteet kunkin sovelluksen sovellusarkkitehtuurissa (ks. esim. luku 1.4.3) ja teknisten tai toiminnallisten virhetilanteiden käsittely. 4. Liittymien sisältö (toiminnalliset liittymät). Teknisiin ratkaisuihin ei kuulu esimerkiksi se, onko operaatio hae_potilas vai lisaa_tutkimus. Toiminnallisessa liittymässä määritellään operaatioiden toiminnalliset nimet ja parametrit tai siirrettävät tietoelementit. Toiminnallis- TERVEYDENHUOLLON SOVELLUSINTEGRAATIORATKAISUJEN MÄÄRITTELY 23

24 ten liittymien määrittelyssä käytetään integrointitekniikoiden tarjoamia mahdollisuuksia. Eri standardit määrittelevät sisältöjä eri tavoin, esimerkiksi HL7 ja EDIFACT keskittyvät siirrettävän tiedon sisällön standardointiin (RM-ODP-mallin Information-näkökulma), kun esim. OMG:n määrittelemät toiminnalliset liittymät keskittyvät prosessointiin ja toiminnallisuuteen (RM-ODP:n Computational-näkökulma). Ohjelmointirajapinnoissa nämä päätökset näkyvät etenkin operaatioiden nimien ja parametrien määrittelyissä. 5. Semantiikka. Kun toiminnallisista liittymistä on sovittu, on tarpeen sopia kunkin interaktion tarkasta merkityksestä. Pelkästään liittymiä tarkastelemalla ei operaation merkityksestä saa kuvaa. Saman niminen liittymä voi johtaa eri tapauksissa hyvin erilaiseen lopputilaan järjestelmissä, ja kutsujalle palautuvan tiedon merkitys voi poiketa paljonkin eri tapauksissa. Myös eri tietoalkioiden koodauksessa käytettävät mittayksiköt ja koodistot kuuluvat semanttiseen yhteentoimivuuteen. 6. Toiminnallinen viitemalli. Täyden yhteentoimivuuden saavuttamiseksi tarvitaan toiminnallinen viitemalli. Se kuvaa järjestelmän oletuksia, kuten käsitteiden väliset suhteet, tunnisteet ja niiden esitysmuoto (pituus, muoto jne.), jotka ovat usein suorassa suhteessa järjestelmän sisäiseen toteutukseen. Poiketen (Herzum, Sims 2000) -lähteestä, toiminnallista viitemallia on sovellettu siten, että se voi olla myös järjestelmien välillä jaettava, esim. yhteisen sovellusalueen kattava malli toimialan tietosisällöstä tai prosesseista, kuten HL7 RIM tai IHE:n integraatioprofiili. 7. Kehitysprosessin liittymät. Jos tiedetään jo aikaisessa kehitysvaiheessa, minkä järjestelmien kanssa yhteistoiminnallisuutta tarvitaan, mukana olevien järjestelmien rajoitukset ja mahdollisuudet voidaan ottaa haluttaessa huomioon jo varhain kehitysprosessissa. Esimerkiksi voi olla tarpeen saada käyttöön jokin toisen järjestelmän spesifikaatioista, jotta järjestelmien integrointi tai yhteistoiminnallisuus helpottuu. Kehitysprosessin liittymien protokollat voivat ottaa kantaa myös jakeluun. Myös joillakin standardeilla (esim. CEN env13606, sähköisen potilaskertomuksen tiedonsiirto) voi olla niin laajoja vaikutuksia sovelluksiin, että standardi on otettava sovellusten suunnittelussa keskeiseksi lähtökohdaksi. Tasot 1-6 on sovittava järjestelmiä integroitaessa joko standardin tai tapauskohtaisen käytännön avulla. Mallin eri tasoilla on määritelty yhteentoimivuusprotokollia (interaction protocol). Yhteentoimivuusprotokolla on joukko sääntöjä, jotka määrittelevät kahden tietojärjestelmän välisen vuorovaikutuksen. Yhteentoimivuusprotokollat voivat sisältää järjestelmien välisten viestien muodon ja merkityksen määrittelyjä ja viestien vaihtamiseen käytettäviä tekniikoita. Yhdellä tasolla voidaan käyttää myös useita protokollia. 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. Erilaisia malleja, joilla protokollia sovitetaan, ovat: integroitu yhteistoiminta (I): järjestelmät jakavat saman protokollan tai niillä on yhteinen osa kahdenvälinen silta (P): molemmat järjestelmät mukautuvat ulkoiseen protokollaan, kuten viestimäärittelyyn koordinoitu yhteistoiminta (C): järjestelmiä ohjaa ja koordinoi niiden yläpuolella toimiva koordinaattori väyläyhteistoiminta (B): järjestelmien yhteistoimintaprotokolla perustuu yhteisesti käytettyyn infrastruktuuriin (väylään), esim. oliosanomavälittimen käyttöön. Tietyn tason ratkaisuilla ja standardeilla on usein myös vaikutuksia useille mallin tasoille. Suhteessa RM-ODP malliin, tietty RM-ODP-mallin näkökulma voi näkyä useilla seitsemän tason mallin tasolla. 24 PLUGIT-HANKKEEN SELVITYKSIÄ JA RAPORTTEJA 4

25 1.4.3 Hajautettu viitearkkitehtuuri Seitsentasoisen mallin tasolla 3 (sovellusinfrastruktuuri) on päätettävä, mitkä ovat osallistuvan sovelluksen integrointipisteet sen sovellusarkkitehtuurissa. Sovellusarkkitehtuuri on yleensä tuote- tai välinekohtainen, mutta kommunikointia varten olemme joissain integrointimäärittelyissä käyttämään viitearkkitehtuuria, jonka hajautuskerrokset ovat tunnistettavissa ainakin loogisina tasoina monissa hajautetuissa järjestelmissä. Arkkitehtuuri on mukailtu lähteestä (Herzum, Sims 2000). Viitearkkitehtuurissa on useita kerroksia, joilla kullakin on määritellyt vastuut. Kaksi ylintä kerrosta tukee yksittäistä käyttäjää, kaksi alinta useita yhtäaikaisia käyttäjiä. Viitearkkitehtuurin kerrokset ja niiden vastuut ovat (ks. kuva 1.11): User-kerros (U), jossa sijaitsee sovelluksen käyttöliittymä. Käyttöliittymä on yleensä graafinen ja sijaitsee loppukäyttäjän työasemalla, mobiililaitteessa tai selaimessa. Sovelluksen kehittäjä rakentaa käyttöliittymän käyttäen alempien kerroksien ohjelmistojen palveluita, mutta käyttöliittymät voivat syntyä myös automaattisesti metatiedon perusteella. Käyttöliittymäkerros voi integroida useita alempien kerrosten palveluita, ja integrointiratkaisut voivat sisältää (ohjelmistoliittymien lisäksi tai niiden sijaan) myös käyttöliittymiä. Workspace-kerros (W), joka tukee yhden käyttäjän tarpeita sovelluksessa. Ohjelmalogiikka, joka tukee yksittäistä käyttäjää, rakennetaan yleensä tähän kerrokseen. Useissa sovelluksissa sovelluksen tila ja käyttäjäläheiset integrointiratkaisut (kuten käyttökontekstin integrointi) rakennetaan tähän kerrokseen. Kerros sijaitsee yleensä fyysisesti joko käyttöliittymän yhteydessä työasemalla (rich client, fat client, työasemasovellus) tai esim. web-palvelimella (thin client, selainkäyttöliittymä). Enterprise-kerros (E) tukee useita yhtäaikaisia käyttäjiä, ja on yleensä tietoverkon kautta yhteydessä sovelluksen yhden käyttäjän osiin. Se sisältää tyypillisesti jaettua sovelluksen toimintalogiikkaa, palveluita ja transaktioita. Sovelluksen monet laatuominaisuudet (tehokkuus, turvallisuus, transaktiot jne.) riippuvat vahvasti tästä kerroksesta. Kerroksessa käytetty infrastruktuuri voi sisältää sovellusaluekohtaisia tai yleisiä jaettuja palveluita, kuten asynkronista viestinvälitystä, tapahtuma- (event) tai transaktiopalveluita, terveydenhuollon sovellusten yleisiä palveluita. Fyysisesti kerros sijaitsee yleensä (sovellus)palvelimella. Ylemmissä kerroksissa voi olla eri tekniikoilla tai eri laitteisiin toteutettuja käyttöliittymiä, jotka hyödyntävät samoja Enterprisekerroksen palveluita. Tämän kerroksen hajautetut palvelut ja niiden rajapinnat tarjoavat vahvan pohjan sovellusten integroinnille. Single user domain Enterprise domain User tier Workspace tier Enterprise tier Resource tier System 1 Web user interface (browser) Web server application (web server) Enterprise application (web / application server) Database (database server) W-E System 2 Common service (application server) Legacy system wrapper (application server) R-U System 3 Legacy system user interface (terminal emulator) Legacy server-side application (database server) Legacy database (database server) user interface framework workstation / web server EE application server / enterprise EE persistence framework / resource EE Execution environment (EE) Kuva Viitearkkitehtuurin kerrokset, esimerkkejä integrointipisteistä (Mykkänen ym. 2003). TERVEYDENHUOLLON SOVELLUSINTEGRAATIORATKAISUJEN MÄÄRITTELY 25