CASE: PlugIT- ja SerAPI-projektit 3S-sovelluskehityssymposium, 27.1.2005 Juha Mykkänen

1. Palvelupohjainen sovelluintegraatio ja Web-sovelluspalvelut terveydenhuollossa: kokemukset ja mahdollisuudet CASE: PlugIT- ja SerAPI-projektit 3S-sovelluskehityssymposium, 27.1.2005 Juha Mykkänen Kuopion yliopisto, HIS-tutkimusyksikkö (terveydenhuollon tietojärjestelmien tutkimus- ja kehitysyksikkö) (viimeisin – lyhennetty - versio esityksestä: www.uku.fi/tike/his/serapi/mater/Mykkanen-3S.ppt)

2. Esityksen sisältö • sovellusten yhteentoimivuuden osaset • integrointiratkaisujen määrittely (PlugIT) • joitakin kokemuksia ja opetuksia (PlugIT) • web services ja SOA (SerAPI) • Konteksti: terveydenhuollon tietojärjestelmät • tietointensiivisyys, laajuus (puolet maailman käsitteistä liittyy lääketieteeseen) • heterogeenisyys (esim. KYS 180 tietojärjestelmää, monet käytössä >10 v) Palvelupohjainen sovellusintegraatio ja web-sovelluspalvelut terveydenhuollossa

3. Sovellusintegraation mallit ja kokemukset / PlugIT

4. PlugIT-hanke:Terveydenhuollon sovellusintegraatio, 2001-2004 • 4 tutkimusyksikköä, 15 ohjelmistoyritystä, 8 terv.huollon organisaatiota • Kansallinen TEKES-rahoitteinen hanke, 2 M€, 1.10.2001-31.8.2004 • Tulokset: rajapintoja, integrointimenetelmiä, osaamista Palvelupohjainen sovellusintegraatio ja web-sovelluspalvelut terveydenhuollossa

5. PlugIT:n kohteena oleva ongelma: Ohjelmistoryväs • Lääkäri tai muu terveydenhuollon ammattilainen joutuu käyttämään useita järjestelmiä saman potilaan asian hoitamiseen. • Joka järjestelmällä on omat käyttäjätunnuksensa, potilastietonsa, koodistonsa, jne. • Uudet integrointitavat: • työpöytäintegraatio (kontekstinhallinta) • yhteiset ohjelmistopalvelut (common services) [Mikko Korpela] Palvelupohjainen sovellusintegraatio ja web-sovelluspalvelut terveydenhuollossa

6. Lääkäri tai muu terveydenhuollon ammattilainen joutuu käyttämään useita järjestelmiä saman potilaan asian hoitamiseen. • Joka järjestelmällä on omat käyttäjätunnuksensa, potilastietonsa, koodistonsa, jne. • Uudet integrointitavat: • työpöytäintegraatio (kontekstinhallinta) • yhteiset ohjelmistopalvelut (common services) Palvelupohjainen sovellusintegraatio ja web-sovelluspalvelut terveydenhuollossa

7. Lääkäri tai muu terveydenhuollon ammattilainen joutuu käyttämään useita järjestelmiä saman potilaan asian hoitamiseen. • Joka järjestelmällä on omat käyttäjätunnuksensa, potilastietonsa, koodistonsa, jne. • Uudet integrointitavat: • työpöytäintegraatio (kontekstinhallinta) • yhteiset ohjelmistopalvelut (common services) Palvelupohjainen sovellusintegraatio ja web-sovelluspalvelut terveydenhuollossa

8. Tietopohjainen tiedonsiirto tai kopiointi tietokannat, viestit, dokumentit, deklaratiivinen yksinkertaisuus, runsaasti käytetty Prosessipohjainen määriteltyjen ja keskitetysti ylläpidettyjen prosessien kerros integrointipalvelimet, oliopohjainen middleware, (prosessin koordinaattori) 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, kontekstinhallinta (sovellusten synkronointi) käytettävyys, personointi jne. Integrointimallit – vaatimukset ja perusratkaisut [David Linthicum] Palvelupohjainen sovellusintegraatio ja web-sovelluspalvelut terveydenhuollossa

9. Integrointitasot – ratkaisun osaset Milloin? • järjestelmän elinkaari • toiminnallinen arkkitehtuuri • sovellusarkkitehtuuri • tekninen arkkitehtuuri Mitä? Missä? Miten? • ratkaistava kaikissa sovellusintegraatio-tilanteissa [Peter Herzum, Oliver Sims] Palvelupohjainen sovellusintegraatio ja web-sovelluspalvelut terveydenhuollossa

10. Integrointimäärittelyn eteneminen Vaatimukset + toiminnan kehittäminen Osallistuvien sovellusten ratkaisut [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.] Vaiheittainen tarkennus, mallit ja ohjeistus eri vaiheisiin, tavoitteena ratkaisun kattavuus ja tarkkuus, mutta selkeä, helppokäyttöinen ja toistuva menettely --SOVELTUU SEKÄ AVOIMEEN ETTÄ TAPAUSKOHTAISEEN INTEGROINTIIN Tekniset standardit, työkalut Toimialan standardit ja viitemallit Palvelupohjainen sovellusintegraatio ja web-sovelluspalvelut terveydenhuollossa

11. Monenvälinen integrointi – PlugIT-hankkeen malli Kolmikanta- osaamisen hyödyntäminen Priorisointi, suunnittelu, taustoitus Käyttöönotto- edut Avoimen ja uudelleen- käytettävän ratkaisun määrittely [Mykkänen, Tikkanen, Rannanheimo, Eerola, Korpela. Specification Levels and Collaborative Definition for the Integration of Health Information Systems. Proceedings of Medical Informatics Europe 2003]. Palvelupohjainen sovellusintegraatio ja web-sovelluspalvelut terveydenhuollossa

12. Eri tyyppiset ratkaisut Palvelupohjainen sovellusintegraatio ja web-sovelluspalvelut terveydenhuollossa

13. 9 tiimiä, 13 integrointikohdetta (2002), joista 9 kohdetta tuotti integrointimäärityksiä Yhteiset ydinpalvelut (5 rajapintatiimiä) Käyttäjä ja oikeus Potilas- ja kliiniset tiedot Koodistot, terminologiat ja organisaatiot Laskutus Potilaskertomusarkisto Työpöytäintegraatio (1 tiimi) Kontekstinhallintapalvelut Sovellusten käynnistys konteksti välittäen Erityisalueiden vaatimukset (2 tiimiä) Kotihoidon tiedon tarpeet Äitiyshuollon palveluketju Kahdenvälinen komponentti-integraatio (1 tiimi) Gastroskopia– patologia integraatio Kokemuksia monenvälisestä integroinnista /PlugIT [Mykkänen, Porrasmaa, Korpela, Häkkinen, Toivanen, Tuomainen, Häyrinen, Rannanheimo. Integration Models in Health Information Systems: Experiences from the PlugIT project. Medinfo 2004]. Palvelupohjainen sovellusintegraatio ja web-sovelluspalvelut terveydenhuollossa

14. Kokemukset: Integrointiratkaisujen määrittely ja toteutus • Integrointialueen tuntemus välttämätöntä ratkaisun määrittelyssä • Kiireellisimmät integrointitarpeet mukaan ensimmäiseen iteraatioon (määrittelystä toteutukseen), uudet versiot • Määrittely ja toteutus järkevää erottaa omiksi “projekteikseen”, varsinkin avoimissa määrittelyissä (toteutushyödyt, kilpailuetujen suojelu) • Uusien ratkaisujen ja tekniikoiden vähittäinen sisäänajo, migraatio sovelluksille ja asiakkaille, referenssitoteutukset Palvelupohjainen sovellusintegraatio ja web-sovelluspalvelut terveydenhuollossa

15. Kokemukset: Standardit ja tuotekohtaiset seikat • Standardeilla, tekniikoilla ja välineillä vaikutuksia monille eri tasoille, mutta eri osapuolilla ei resursseja arvioida kaikkia vaikutuksia • Top-down: Toimialakohtaisten standardien tulisi perustua yleisiin avoimiin standardeihin • Bottom-up: Ratkaisujen sitominen/kerääminen olemassa olevista sovelluksista, yleistäminen avoimeksi (suunnittelukäytännöt, harmonisointi, standardointiprosessi) • Ratkaisujen arviointi ja sertifiointi tarpeen, ulkoinen taho • Joustavuus (heterogeenisyys) avoimilla tekniikoilla ja tiedon erottamisella toiminnallisuudesta Palvelupohjainen sovellusintegraatio ja web-sovelluspalvelut terveydenhuollossa

16. Kokemukset: Monenväliset integrointihankkeet • Osallistujilla “eri aloilta” erilaiset taidot, erilainen kieli • Johdon sitoutuminen – vaatimukset, resurssit, aikataulu • Tutkimusosapuoli neutraali moderaattori määrittelyssä, “konsultti” toteutuksessa • Toteutus/tilaajakohtaiset seikat (jakelu, ylläpito, omistajuus) erilleen avoimista määrityksistä Palvelupohjainen sovellusintegraatio ja web-sovelluspalvelut terveydenhuollossa

17. Web services ja SOA

18. Hajautetun väliohjelmiston (Middleware) historiallinen kehityskaari • etäohjelmakutsut (RPC) • transaktiot mukaan -> TP Monitors (Tuxedo jne.) • olio-ominaisuudet TP Monitoreihin -> oliosanomavälittimet (CORBA, COM, RMI) • viestijonot TP Monitoreihin -> MOM, message-oriented middleware (MSMQ, MQSeries, monet integrointialustat jne.) • Internet-tekniikat mukaan -> Web services • ja niille ensimmäisenä etäohjelmakutsut… • ei revoluutio, vaan evoluutio Palvelupohjainen sovellusintegraatio ja web-sovelluspalvelut terveydenhuollossa

19. Proseduraalinen Bottom-up, sovellusintegraatio Consumer, provider, registry Nojautuu rpc-pohjaiseen middlewareen Nykyiset SOAP, WSDL ja UDDI-määritykset Dokumenttipohjainen Top-down, sähköinen kaupankäynti Tavoitteena kuvata kaikki liiketoiminnan tiedonvaihdossa tarvittavat asiat, mukaanlukien tekniset ratkaisut Message-oriented middleware (MOM) Esim. ebXML Web Services: Procedural vs. document-oriented [Gustavo Alonso] Palvelupohjainen sovellusintegraatio ja web-sovelluspalvelut terveydenhuollossa

20. Web-sovelluspalveluiden lupaukset • ”Alusta- ja tekniikkavaihtoehtojen tuki” • totta, merkki-, XML- ja Internet-pohjaisille sovelluksille runsaasti toteutusvälineitä eri alustoille • ”universal description of interfaces + communication with anything rpc-enabled” • ”Yleisten, laajalti levinneiden tekniikoiden hyödyntäminen” • totta, Internet-tekniikat laajasti käytössä (myös terveydenhuollossa) • ”Löysä kytkentä sovellusten välillä” (loose coupling) • RPC-tavan palveluiden käyttö on tiukkaa kytkentää, löysäämistä dokumenttien tai tietopohjaisen käytön (kopioinnin) avulla • XML:ssä löysä kytkentä lisää joustavuutta mutta myös sovelluskohtaista toteutustyötä • kytkentää tiukennetaan tietotyyppien (mm. Schema) ja lisämäärittelyjen (mm. käytettävät SOAP-lisätasot) kautta • ”Palvelut ovat itsensä kuvaavia” • XML-taso: metatason (kuvailutiedon) merkitys on edelleen sovittava sovellusten välillä ”<person>” (XML-merkkaus voi helpottaa ihmisen ymmärtämistä) • WSDL-taso: vaikka liittymän (muuttunut) määritys luetaan haluttaessa, on toteutus silti tehtävä / muutettava vastaamaan määritystä • (vasta) tutkimusaiheena semanttinen web, yleisten ontologioiden määrittely ja käyttö Palvelupohjainen sovellusintegraatio ja web-sovelluspalvelut terveydenhuollossa

21. Web-sovelluspalveluiden lupaukset.. • ”Palvelut löydetään dynaamisesti ajon aikana” • onnistuu rekistereitä käyttämällä, onko kuitenkaan tavoitteena, myös mediaattoreiden / integrointialustojen avulla reititykset ja muunnokset • ”Toimittajariippumattomuus” • ”peruspiirteitä” käyttämällä yhteentoimivuus ilman suuria muutoksia • epäyhteensopivuuksia, standardien versiot ja ”pinot”, puutteellinen standardituki • ”Kevyt teknologia, helppo opittavuus” • pitää paikkansa yksinkertaisimpien käyttömallien kohdalla (XML+http, XML-RPC) + välineet tekevät paljon WSDL-SOAPin joillain tyyleillä • jo SOAPin laajennusten käytössä paljon opiskeltavaa ja sovittavaa • määritysten ja versioiden lukumäärän jatkuva kasvu, määritysten väliset suhteet • WSDL usage styles • SOAP ja WSDL-versioiden yhteensopimattomuss • ”step back for interoperability”: WS-I Palvelupohjainen sovellusintegraatio ja web-sovelluspalvelut terveydenhuollossa

22. Lupaukset ja myytit… • ”Globaalit, kaikkialla käytettävät standardit” • eivät tule korvaamaan jo tehtyjä ratkaisuja (EDI, HL7 jne.) • ratkaisut rakennetaan olemassa olevien sovellusten päälle -> niiden vaikutus näkyy myös uusilla tekniikoilla • suorituskyky • ”lisäkerroksia” muutenkin monimutkaisiin järjestelmiin • XML (tiedonsiirto, DOM-parserit) • ”Web-sovelluspalvelut normaaleina sovelluksina” • ”tietokoneiden käyttämiä sovelluksia”, ei käyttöliittymää kutsun seurauksena • tavoitteena A2A (RPC) tai B2B (dokumentit) (ei B2C) • luottamuskysymykset sovellusten välillä (ulkoiset web-palvelut) • Uudet välineet tukevat, vahvuutena alustaneutraalius, web-tekniikat • Paisuneet odotukset, standardoinnin hajanaisuus, lastentaudit Palvelupohjainen sovellusintegraatio ja web-sovelluspalvelut terveydenhuollossa

23. SOA • lupaukset • joustavuus • prosessien erilaisuus, toiminnan muutokset, paikalliset vaatimukset • liitettävyys • sovellusten itsenäiset toteutusratkaisut, uudelleenkäyttö • käyttökohteet • proseduraalinen / dokumenttityyli? • integrointimalli? • web services ja SOA ratkaisevat vain jotkin integrointitasot – paljon jää edelleen projektikohtaisesti tarkennettavaksi • käyttö onnistuu sekä ”integrointiliimana” että ”tulevaisuuden sovellusalustana” Palvelupohjainen sovellusintegraatio ja web-sovelluspalvelut terveydenhuollossa

24. Performance Tuning Removal of M systems Re-hosting of VistA Applications Data standardization Site Preparation & Training CAIP Person Lookup Person Identity Management HDR prototype Data Cleanup Data Aggregation & Migration Systems of Interest Dynamic Routing Service NEW PERSON enumeration Naming / Directory Service Messaging Service HL7 Builder Utility Standard Data Service Patient Lookup, Patient Service Person Demographics Delivery Service Web Apps. Hardware design, procurement and deployment Planning Esimerkki: “Future-proof information systems” SOA:n avulla HealtheVet VistA [Ken Rubin / EDS] Palvelupohjainen sovellusintegraatio ja web-sovelluspalvelut terveydenhuollossa

25. Tekniset ratkaisut perustuvat toiminnan ja sovellusten vaatimuksiin • Tuettava organisaation muuttuvia työnkulkuja ja prosesseja • mukautuvilla, uudelleenkäytettävillä ja tehokkaasti kehitetyillä sovelluksilla ja integrointiratkaisuilla • joissa hyödynnetään avoimia ja yhdenmukaisia palveluita, arkkitehtuuria ja infrastruktuuria • [SerAPI-hanke, tutkimussuunnitelma] • Tekes, FinnWell-teknologiaohjelma, 13 yritystä, 4 terv.huollon organisaatiota, 3 tutkimusryhmää • 9/2004-8/2007? Palvelupohjainen sovellusintegraatio ja web-sovelluspalvelut terveydenhuollossa

26. Yhteenveto • sopivan tekniikkajoukon ja käyttötavan valinta erilaisiin vaatimuksiin • aluksi käyttöön pisimmälle standardoituneet osat: perus-http(s)-pohjaiset palvelut, XML, perus-SOAP ja sitten: • keveys, avoimuus, nopea toteutus, ohjelmakutsut (RPC-tyyli) • laajennettavuus, varmennukset, reititykset, viestit (dokumentit) • Web-sovelluspalvelut ja palveluarkkitehtuuri sovellustuotannossa ja –integraatiossa • palvelut oikeaan paikkaan, WS ei sovi kaikkeen (tarpeet), migraatio • tieto-, palvelu-, käyttäjä- ja prosessi-integraatio – erilaiset palvelut ja käyttötavat erilaisiin tarpeisiin • mukautettavuuden tarve: future-proof vai ad-hoc? • palvelujen keskitys vai tiedonvälitys? • palvelun karkeustaso, integraation tiukkuus? • jne. • ratkaisujen perustuminen toiminnan tarpeisiin ja prosesseihin Palvelupohjainen sovellusintegraatio ja web-sovelluspalvelut terveydenhuollossa

27. Kiitos www.uku.fi/tike/his/serapi/ www.plugit.fi/ • Tämä työ on osa SerAPI-hanketta, johon osallistuvat 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 Palvelupohjainen sovellusintegraatio ja web-sovelluspalvelut terveydenhuollossa