Järjestelmien integroinnista SOA:an

1. Järjestelmien integroinnista SOA:an SOA - Service Oriented Architecture, Helsinki, 29.3.2007 Juha Mykkänen, FT, tutkijatohtori Kuopion yliopisto, HIS-tutkimusyksikkö juha.mykkanen@uku.fi

2. Esityksen sisältö • Yhteentoimivuus: mistä se muodostuu • Eri tyyppisiin integrointivaatimuksiin vastaaminen • SOA ja standardointi • Palveluarkkitehtuurin hyödyt ja niiden arviointi • Konteksti: terveydenhuollon tietojärjestelmät • tietointensiivisyys, laajuus (puolet maailman käsitteistä liittyy lääketieteeseen / terveydenhuoltoon) • heterogeenisyys (esim. KYS 180 tietojärjestelmää, monet käytössä >10 v) - ei liikkeelle "puhtaalta pöydältä" • esityksessä poimintoja soveltavasta tutkimuksesta n. 7 v • komponentit -> sovellusintegraatio -> palvelupohjaisuus • väitöskirja "Specification of Reusable Integration Solutions for Health Information Systems", 01/07 • esityksen pyrky: integraatio SOA-näkökulmasta Järjestelmien integroinnista SOA:an

3. Konteksti: terveydenhuollon prosessit ja ohjelmistot • terveydenhuollon prosessit ja toiminta • useat prosessit vuorovaikutuksessa • paljon "poikkeuksia" usein pitkäkestoisissa prosesseissa • paljon ihmisten välistä kommunikaatiota, vain osa tehtävistä sovelluksissa / formalisoitavissa • asiantuntijuuden ja ammatillisten roolien korostuminen • eri organisaatioiden, ammattilaisten ja asiakkaiden osin ristiriitaiset tavoitteet • ohjelmistot ja tietojärjestelmät • runsaasti sovelluksia esim. sairaaloissa, heterogeenisyys • tiedon ja tietämyksen määrä kasvaa • säilytys-, saatavuus- ja turvallisuusvaatimukset olennaisia • runsaasti valmista pohjaa järjestelmissä ja aiemmin tehdyissä integraatioissa • uudet lähestymistavat sovitettava olemassa oleviin ratkaisuihin Järjestelmien integroinnista SOA:an

4. Taustaa: SerAPI: Palveluarkkitehtuuri ja web-sovelluspalvelut terveydenhuollon ohjelmistotuotannossa ja integraatiossa • Tekesin FinnWell-ohjelmaan kuuluva hanke, 3 vuotta, 9/04 - 8/07 • 14 yritystä, 4 shp/terv.huollon organisaatiota, 3 tutkimusyksikköä • Joustavuus ja liitettävyys: SOA ja web services • Keskeiset näkökulmat: Terveydenhuollon prosessit, Ohjelmistotuotteet, Teknologia-alusta • Avoimet ohjelmistorajapinnat ja integraatio: • mm. Kontekstinhallinta, Ajanvaraus, potilasryhmittelyt (DRG ja perusterveydenhuollon avohoidon potilasryhmitys), Päätöksentuki, OID, potilaslistat, käyttäjä- ja potilastietojen rajapinnat, koodistorajapinnat • Standardointi • HL7 Finland Common Services SIG taustaprojekti • Healthcare Services Specification Project (HL7 ja OMG-standardointijärjestöt) • Käytännössä: soveltamiskohteita ja tarpeita sairaaloista ja tuotteista, tuloksina palvelurajapintoja ja arkkitehtuurimäärityksiä, menetelmiä, esimerkkitoteutuksia ja selvityksiä, "katse yli seuraavan vuosineljänneksen" Järjestelmien integroinnista SOA:an

5. Keskeiset näkökulmat tarkemmin (SOA-viitekehys: monimutkaisen elefantin voi syödä vain pala kerrallaan) Järjestelmien integroinnista SOA:an

6. Yhteentoimivuus (interoperability)

7. Organisaatioiden toiminnan ja arkkitehtuurien kehitys Järjestelmien integroinnista SOA:an

8. Tietojärjestelmiin kohdistuvia tarpeita [Pekka Kähkipuro] Järjestelmien integroinnista SOA:an

9. Hankintavaihtoehtojen monipuolistuminen Osta valmis tuote Toteuta itse Teetä uusi järjestelmä Suunnitteluta ulkopuolisella Osta ja räätälöi järjestelmä Osta ja integroi komponentit Vuokraa ulkopuoliselta (ASP) Toteuta vanhan järjestelmän sovittimena Laajenna sovelluskehyksestä Kirjaudu käyttämään verkon kautta Järjestelmien integroinnista SOA:an

10. Yhteentoimivuus-käsitteen merkitykset Järjestelmien integroinnista SOA:an

11. Integrointitasot – mitä sovittava sovellusten yhdessä toimimiseksi Milloin? • järjestelmän elinkaari • toiminnallinen ja tietoarkkitehtuuri • sovellusarkkitehtuuri • tekninen arkkitehtuuri Mitä? Missä? Miten? • ratkaistava kaikissa sovellusintegraatio-tilanteissa [Peter Herzum, Oliver Sims] Järjestelmien integroinnista SOA:an

12. SOA what: interoperability • SOA: lähestymistapa, jossa tietojärjestelmät ja prosessit koostetaan sovelluspalveluista • SOA ei ole arkkitehtuuri, mutta arkkitehtuuri (osat, niiden suhteet ja kehittämisperiaatteet) erittäin keskeinen • muutosherkkyys, toimialavastaavuus, uudelleenkäyttö • SOA yhteistoiminnallisuuden kannalta • yhdistelmä: EAI, BPM ja komponenttipohjaisuus • järjestelmäkokonaisuuden hahmottaminen palveluina • rajapinta- ja sopimuskeskeisyys • SOA-kehityksen paikallisten tavoitteiden määrittely • missä määrin eri yhteentoimivuustavoitteita korostetaan • mitkä integrointitasoista vakioidaan (ja millä ratkaisuilla), mitkä sovitetaan tapauskohtaisesti - vain osa asioista rajapinnoissa (lisäksi infrastruktuuri, policy-määrittelyt, käyttöliittymät jne.) Järjestelmien integroinnista SOA:an

13. "...mutta kuinka missäkin tilanteessa saa kaikki nuo tasot ratkaistua?" Eri tyyppisiin integrointivaatimuksiin vastaaminen

14. Integrointimäärittelyn eteneminen [Mykkänen, Porrasmaa, Rannanheimo, Korpela: A process for specifying integration for multi-tier applications in healthcare. Int J Med Inf 2003:70(2-3):173-182.] Järjestelmien integroinnista SOA:an

15. Tietopohjainen tiedonsiirto tai kopiointi tietokannat, viestit, dokumentit, deklaratiivinen yksinkertaisuus, runsaasti käytetty ”business documents” Prosessipohjainen määriteltyjen ja keskitetysti ylläpidettyjen prosessien kerros prosessin koordinaattori (orkestraatio), prosessien hajauttaminen (koreografia) työnkulkujen ymmärtämisestä määrittelyyn ja ohjaukseen Palvelupohjainen jaetut toiminnot ja operaatiot, yhteiset palvelut (common services) rpc-pohjainen middleware, Web services, imperatiivinen uudelleenkäyttö, vähemmän päällekkäistä tietoa, toiminnallisuutta, ylläpitoa ja toteutustyötä Käyttäjälähtöinen yhdenmukainen näkymä moniin järjestelmiin portaalit, sovellusten synkronointi käytettävyys, personointi, monikanavaisuus jne. Integrointimallit – vaatimusten ja perusratkaisujen ensisijainen luonne [David Linthicum] Järjestelmien integroinnista SOA:an

16. Esimerkkejä integrointirajapinnoista Järjestelmien integroinnista SOA:an

17. ... esimerkkejä (jatkuu) Järjestelmien integroinnista SOA:an

18. SOA what: eri tyyppiset integrointitarpeet ja -ratkaisut • SOA:ssa korostetaan (usein) "suuria" rajapintoja ja dokumenttipohjaisuutta • public enterprise service (kumppanien välillä)? • "business activity + entity", sekä yleistetyllä että tarkalla tasolla • lisäksi otettava kantaa mm. • käyttäjätarpeet (vuorovaikutteisuus vs. "eräkäyttöinen" web-käyttöliittymä, portaalit, monikanavaisuus) • prosessikerros: linkitykset vanhoihin järjestelmiin ongelmallisia, prosessipalvelut, prosessimoottori vai koreografia • voidaan määritellä SOA-palveluina tai muuten arkkitehtuurissa • yhdenlaisilla palveluilla ei ratkaista kaikkea • arkkitehtuurin kerroksellisuus • palvelujen luokittelut (esim.): • integrointitapa • yleiskäyttöisyys: erityisesti YDINpalvelujen tunnistus ja uudelleenkäyttö • operaatioiden karkeajakoisuudessa vaatimuksista riippuvia eroja Järjestelmien integroinnista SOA:an

19. Esimerkki: nykytilanteeseen pohjautuva integrointiarkkitehtuuri ja eri tyyppisten integraatioiden tarve • keskitetyt, jaetut palvelut (ydinpalvelut) • lisäpalvelut, kontekstinhallinta jne. • löysästi kytketyt, yksiköiden ja organisaatioiden väliset palvelut [Mykkänen, Korpela, Ripatti, Rannanheimo, Sorri. Local, Regional and National Interoperability in Hospital-Level Systems Architecture. Meth Inf Med, 2007, in press] Järjestelmien integroinnista SOA:an

20. Palvelualustan vaikutukset suunnittelupäätöksiin • vaikuttaa • protokollasopimukset • rajapintojen syntaksi, kommunikaatioprotokollat, vaatimukset sovellusten teknisille adaptereille, joskus myös eri viestintämuotojen mäppäys mahdollista • reititys oikealle palvelulle vs. palvelurekisteri • loogisten osoitteiden asettaminen viestiin vs. palvelun käyttäjän vastuu paikallistaa vastaanottaja • ympäristön hallittavuus • keskitetty yhteys-, valvonta- (ja virhetilanne-) piste vai hajautetut integrointipalvelut • lisää joustavuutta ja erilaisia soveltamismahdollisuuksia, mutta myös uuden kerroksen järjestelmään ja eri soveltamistapoja • ei vaikuta • semanttiset ja toiminnalliset perusratkaisut (tietoelementtien ja kokonaisuuksien merkitykset, pl. yksinkertaiset yhdistelyt ja jaot, toiminnallisten vaatimusten perusluonne (integrointitapa)) Järjestelmien integroinnista SOA:an

21. "...mutta eikö jotain voisi saada valmiina, mitäs muut tekevät?" SOA ja standardointi

22. Standardit ja standardointi • standardi: tunnustetun osapuolen hyväksymä dokumentti, jossa on määritelty yleistä ja toistuvaa käyttöä varten sääntöjä, ohjeita tai piirteitä tuotteille, prosesseille tai palveluille • tavoitteet ja motivaatiot: • yhdenmukaistaminen (laatu, tehokkuus) • yhteensopivuus (palvelut, sovellukset, tekniikat) • objektiivisuus (mittaus, neutraalius, monenvälisyys) • oikeus (sääntely, tasapuolisuus) • johtoaseman luominen (kilpailuedut) Järjestelmien integroinnista SOA:an

23. Standardien osa-alueita (terveydenhuollon tietojärjestelmät) Järjestelmien integroinnista SOA:an

24. 1. HL7 versio 2, nykytila 2,67 Tavoitetaso 3,60 2. HL7 versio 3, nykytila 0,38 Tavoitetaso 2,80 3. CDA (Clinical Document Architecture), nykytila 1,43 Tavoitetaso 2,75 4. IHE (Integrating Healthcare Enterprice), nykytila 0,40 Tavoitetaso 1,50 5. DICOM, nykytila 1,29 Tavoitetaso 2,00 6. CCOW, nykytila 0,14 Tavoitetaso 1,50 7. Arden syntax, nykytila 0,00 Tavoitetaso 0,33 8. OMG Healthcare-standardit, nykytila 0,43 Tavoitetaso 0,33 9. HISA, nykytila 0,00 Tavoitetaso 0,33 10. Muut CEN TC 251 standardit, nykytila 0,43 Tavoitetaso 1,13 Järjestelmien integroinnista SOA:an

25. Esimerkki toimialakohtaisesta SOA-standardoinnista: Healthcare Services Specification Project (HSSP) • projekti terveydenhuoltospesifien palvelurajapintojen ja SOA-lähestymistapojen (teollisuus)standardointiin • taustalla suurten palvelutarjoajien (USA) ja eri maiden SOA-hankkeet • 2 järjestöä • HL7 (Health Level Seven), SOA SIG: toiminnalliset mallit, sisältö • OMG (Object Management Group), Healthcare DTF: tekniset mallit, toteutukset • palvelumäärityksiä mm. • RLUS (Record Locator and Update Service) • EIS (Entity Identification Service) • DSS (Decision Support Services) • CTS II (Common Terminology Services) • "pakko ratkaista": yhteisen lähestymistavan ja kehitysmenetelmän tarkentaminen, suhde moniin viesti- ja sisältöstandardeihin, ajan mittaan muodostuneiden "viestikerrosten" dekompositio • http://hssp.wikispaces.com/ Järjestelmien integroinnista SOA:an

26. SOA what - standardointi • näennäisesti vastakkaisia tavoitteita: joustavuus (SOA) vs. yhdenmukaisuus (standardit) • SOA-joustavuuden perustana kuitenkin modulaarisuus, avoimuus, sopimuksellisuus, joita kaikkia standardit tukevat • vaarana liika yleistäminen, "maximize reuse minimize use" • toimialastandardeilla (epäyhteensopivia) oletuksia arkkitehtuurista ja integrointimalleista - sovitusta tarvitaan • tekninen ja sisällöllinen (toiminnot, tiedot, semantiikka) taso • web services, WS-* tekniset edut selviä, mutta runsaasti soveltamistapoja • näkyvissä: siirtymä teknisistä standardeista sisällöllisiin: toimialakohtaiset viite- ja tietomallit, prosessimäärittelyt • tulossa: profiiliajattelu = toisiaan täydentävien standardien valinta + rajoitteita yleisten standardien soveltamiseen • ebXML, RosettaNet, WS-I, IHE integration profiles, HL7 + CEN TC251 semantic profiles, HL7 functional profiles Järjestelmien integroinnista SOA:an

27. "...mutta miten voin perustella SOA-lähestymistavan?" Palveluarkkitehtuurin hyödyt ja niiden arviointi

28. Ratkaisujen ja hyötyjen arviointi: tasot evaluointi (‘tekee oikean asian oikein’, arviointi käyttökontekstissa, suhteessa käytön tavoitteisiin) Kaikille uusille tekniikoille ja tuotteille validointi (‘tekee asian oikein’, ‘toimii käytännön tilanteessa’) verifiointi (‘määritysten mukaisesti’) [Saranummi N. Healthcare Technology Assessment and Evaluation. VTT Information Technology, 2003.] Järjestelmien integroinnista SOA:an

29. Lopputulos Kehittäminen Suunnittelu Valinta / Päätöksenteko Summatiivinen arviointi Ennen-jälkeen arviointi Formatiivinen arviointi Prosessi arviointi Tulosten ja vaikutusten arviointi Normatiivinen arviointi Arvioitavuuden arviointi Ennen-jälkeen arviointi Vaihtoehtojen arviointi Riskien analysointi Summatiivinen arviointi Normatiivinen arviointi OhjaaminenMittaaminen Tietojärjestelmien arviointitapoja Järjestelmien integroinnista SOA:an

30. SOA ja web services - tavoitellut hyödyt (joita analysoitu SerAPI:ssa, ei normalisoitu) • käyttäjäorganisaation hyödyt • toiminnallinen joustavuus, sovellusten uudelleenkäyttö, sovellusten parantunut liitettävyys, jo tehtyjen investointien hyödyntäminen, sovellushankinta- ja integraatiokustannusten aleneminen, tietojärjestelmäympäristön vähittäinen kehitys, prosessien määrittely ja tukeminen, järjestelmäympäristön tehostunut hallinta ja ylläpito, parantunut käytettävyys, tietotekniikan ja toiminnan lähentäminen • sovelluskehityshyödyt • uusien palvelujen ja sovellusten nopea toteuttaminen, integroinnin tehostuminen kumppanijärjestelmiin, palveluiden ja komponenttien uudelleenkäyttö, inkrementaalinen kehittäminen, kehitysympäristöjen valinnanvara, teknologian keveys ja opittavuus • tekniset hyödyt • tekninen joustavuus, infrastruktuurin uudelleenkäyttö, välineautomaatio, eri tekniikoilla tehtyjen sovellusten ja palvelujen liittäminen, sovelluspalveluiden ja hyödyntäjien löysä kytkentä, globaalien teknisten standardien käyttö, järjestelmien hajautus Järjestelmien integroinnista SOA:an

31. Mittarit ja suureet: tyypit ja aihealueet • tyypit: lukumäärämittarit, työmäärä- ja ajalliset mittarit, laadulliset mittarit, taloudelliset mittarit • osa-alueet: käyttäjä-ja asiakastyytyväisyys, käytettävyys ja saatavuus, toimintaprosessit, tiedot, kehitys- ja integraatioprosessi (toimittaja + asiakas), tekniset mittarit • yht. 126 eri kokoista suuretta ja mittaria, esim. • muutospyyntöjen määrä (ITIL) • palvelun saatavuus (availability) % • käyttäjäkokemukset (kysely) työnkuvan muutoksista • kassavirta-analyysi (sis. nykyarvo, diskonttokorko jne.) • Mean Time Between Failures (MTBF) • tietojen päällekkäiseen syöttöön käytetty aika Järjestelmien integroinnista SOA:an

32. Mittausesimerkki: järjestelmäympäristön tehostunut hallinta ja ylläpito • toisaalta mitataan organisaation "SOA-tasoa", toisaalta ylläpito- ja hallintatyön "tehoa" • tunnistettu asiaan liittyvät 46 (10+13+11+12) mittaria • valittu mitattavissa olevia, poistettu päällekkäisiä ja välillisiä mittareita, tavoitetasot määriteltävä mittareiden kautta • valitut 12 ydinmittaria (suluissa tavoitesuunta) • lukumäärä: päällekkäisten tietojen määrä eri järjestelmissä (), sovelluspalvelujen lukumäärä (), virhetilanteiden lukumäärä () • työmäärä ja ajalliset: MTTR (), sovelluspalvelujen saatavuus (), palvelujen vasteajat (), prosessimuutosten osuus, jotka voidaan tehdä ilman palvelujen muokkaamista (% ) • laadulliset: ylläpidon kokemat työnkuvan muutokset, tiedon eheys -mm. EUCS (), prosessien seurantatietojen saatavuus () • taloudelliset: ylläpitokustannukset (), IUM - Impacted User Minutes (), hankinta- ja integraatiokustannukset (keskipitkällä aikavälillä ) Järjestelmien integroinnista SOA:an

33. "...entäs sitten?" Yhteenveto

34. Organisaation SOA-paletti • strategiset tavoitteet: priorisointi, omistajuus, ydinprosessit ja -palvelut • viitearkkitehtuuri (kokonaisuuden jäsentämiseen) • osat (esim. SOMA): käyttöliittymät, prosessit, sovelluspalvelut, komponentit, järjestelmät, integrointiarkkitehtuuri, hallinta • paikalliset valinnat • pelisäännöt kuhunkin arkkitehtuurin osaan: tekniset käytännöt, hankintastrategiat, metadata, keskeiset standardit • uudelleenkäytettävä infrastruktuuri (tekniset alustavalinnat, ESB?) • kehitys / hankinta / integraatioprosessi • siirtymä tietokantapohjaisesta ajattelusta tehtäväpohjaiseen • toimialan asiantuntemuksen valtaistaminen kehitykseen • top-down (prosessikuvaukset) ja bottom-up ("valmiit" komponentit) yhdistäminen • strategiset kumppanuudet: ydinjärjestelmä + integraattori • lähtö- ja tavoitetasojen määrittely (kypsyysmallit) Järjestelmien integroinnista SOA:an

35. Viitearkkitehtuuri: esimerkki [Arsanjani A. Service-oriented modeling and architecture.] Järjestelmien integroinnista SOA:an

36. maksimoitu joustavuus plug and play-tarkkuus Kriittiset valinnat matala toteutuskynnys korkean tason yhdenmukaisuus vähäinen invasiivisuus standardienmukaiset hankinnat paikallinen sovittaminen = painotuksia monenvälisissä terveydenhuollon IT-hankkeissa Suomessa = esimerkki suuren USA:laisen terveyspalvelujen tarjoajan IT-strategiasta Järjestelmien integroinnista SOA:an

37. Yhteenveto: palveluarkkitehtuurin merkitys • SOA integraation syventäjänä: IT-integraatiosta tietojärjestelmien ja toiminnan yhdessä kehittämiseen • tarkempia ratkaisuja - kehitys lähemmäs käyttöä ja prosesseja • standardointi siirtymässä tekniseltä tasolta toimialakohtaisiin ratkaisuihin • web services ja standardit ratkaisevat vain jotkin integrointitasot - paljon jää edelleen paikallisesti tarkennettavaksi • tekniikat jo käytössä ja tulossa yhä enemmän varusohjelmistoihin • erilaisten integrointiratkaisujen tarve: ei vain yhdenlaisia palveluja • palveluarkkitehtuuri luo pohjaa mukautuville järjestelmille • ulkoistaminen, kumppanuudet, lainsäädännön muutokset, palvelujärjestelmän ja organisaatioiden muutokset • uudet tekniikat esim. Web 2.0, mobiilikäyttö, prosessimoottorit • alkuvaiheessa hyödyt uudelleenkäytöstä, sitten yhdenmukaisuudesta, myöhemmin mukautuvuudesta • ...mutta yhteentoimivuus on vain osa ratkaisua... • liiketoiminta-ajurit, riskit, elinkaari, hallinta, hallinta, hallinta, hallinta Järjestelmien integroinnista SOA:an

38. SOA-siirtymän päävaiheidenhyötymalli [Sprott D. Best Practice Report - The Business Case for SOA. CBDI Journal, June 2006. ] Järjestelmien integroinnista SOA:an

39. www.uku.fi/tike/his/serapi/ Kiitos Tämä työ on osa SerAPI-hanketta, johon osallistuvat Kuopion yliopisto, TEKES, Medici Data Oy, Datawell Oy, Fujitsu Services Oy, Pohjois-Savon sairaanhoitopiiri, WM-data Oy, Commit; Oy, Intersystems B.V. Finland, Mediconsult Oy, Microsoft Oy, Oracle Finland Oy, Satakunnan sairaanhoitopiiri, Bea Systems Oy, Helsingin ja Uudenmaan sairaanhoitopiiri, Kuopion kaupunki, Kustannus Oy Duodecim, Mawell Oy Juha.Mykkanen@uku.fi Järjestelmien integroinnista SOA:an

40. Hyvinvointi-IT:n tutkimus ja kehitys: Seminaari 12.6.2007 Helsingissä palvelut prosessit ja ohjelmistot SerAPI - ZipIT - Avointa - Export HIS - eHP - Äippä - Indehela Ilmoittautumiset ja lisätietoja: www.uku.fi/hyvinvointi-it Terveydenhuollon prosessit ja ohjelmistotuotanto 2007 -hankeryväs on hyvinvointitietotekniikan ja -tiedonhallinnan seitsemän tutkimushankkeen muodostama verkosto. Hankeryppään seminaarissa esitellään hankkeissa tehdyn tutkimuksen tuloksia. Mukana on myös puheenvuoroja terveydenhuollon tietotekniikan toimittaja-, asiakas- ja rahoittajaosapuolilta. Seminaari on maksuton ja on tarkoitettu erityisesti terveydenhuollon organisaatioiden päättäjille, asiantuntijoille ja ohjelmistotoimittajien edustajille.

41. Palveluarkkitehtuuri (Service-oriented architecture, SOA) • lähestymistapa, jossa tietojärjestelmät ja prosessit koostetaan sovelluspalveluista • ei ole arkkitehtuuri, mutta arkkitehtuuri (osat, niiden suhteet ja kehittämisperiaatteet) erittäin keskeinen • yhdistää sovellusintegraation (EAI), prosessien hallinnan (BPM) ja komponenttipohjaisuuden perusajatuksia • keskeiset piirteet • muutosherkkyys: pienemmistä palveluista koostetut ratkaisut helpommin muutettavissa ja mukautettavissa • toimialavastaavuus: ratkaisut toimialan asiantuntijoiden määriteltävissä (abstraktiotaso) • uudelleenkäyttö: vanhat sovellukset ja kerran toteutetut palvelut uusien ratkaisujen pohjana; vähittäinen kehittäminen • rajapinta- ja sopimuskeskeisyys Järjestelmien integroinnista SOA:an