CASE: PlugIT- ja SerAPI-projektit

Esitys aiheesta: "CASE: PlugIT- ja SerAPI-projektit"— Esityksen transkriptio:

1 CASE: PlugIT- ja SerAPI-projektit
Palvelupohjainen sovelluintegraatio ja Web-sovelluspalvelut terveydenhuollossa: kokemukset ja mahdollisuudet CASE: PlugIT- ja SerAPI-projektit 3S-sovelluskehityssymposium, Juha Mykkänen Kuopion yliopisto, HIS-tutkimusyksikkö (terveydenhuollon tietojärjestelmien tutkimus- ja kehitysyksikkö) (viimeisin – lyhennetty - versio esityksestä:

2 sovellusten yhteentoimivuuden osaset
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€, 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 Uudet integrointitavat:
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 Uudet integrointitavat:
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 Integrointimallit – vaatimukset ja perusratkaisut
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. [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 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 [Mykkänen, Porrasmaa, Rannanheimo, Korpela: A process for specifying integration for multi-tier applications in healthcare. Int J Med Inf 2003:70(2-3): ] 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
Avoin koodistorajapinta Patologian pyyntö-komponentti Vaatimukset Yleiset käyttö- ja ylläpitotarpeet Paikalliset tarpeet (patologia-gastro) Tekniikkariippumaton Mallit standardeista korostuneet Vaatimustenhankinta osapuolilta Tekninen Hajautetut ydinpalvelut (http + XML) Paikallinen kirjasto (DLL, XML), komponentti Toteutukset Referenssitoteutus, alueellinen / organisaation toteutus Tuotetoteutus Integrointimalli Palvelupohjainen Tieto- ja palvelupohjainen (+käyttöliittymä) Päähyödyt Uudelleenkäyttö, vähent. päällekkäisyys, keskitetyt palvelut + tiedot Nopea toteutus, sovellusmuutosten pieni määrä, prosessihyödyt Muuta erityistä Standardien suora käyttö ei mahdollista, vaatii sovelluksilta mukautumista Ei standardia, tarkka ratkaisu erikoistilanteeseen Palvelupohjainen sovellusintegraatio ja web-sovelluspalvelut terveydenhuollossa

13 Kokemuksia monenvälisestä integroinnista /PlugIT
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 [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 Web Services: Procedural vs. document-oriented
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 [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 käyttökohteet joustavuus liitettävyys
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 Esimerkki: “Future-proof information systems” SOA:n avulla
Planning Web Apps. Patient Lookup, Service Hardware design, procurement and deployment Person Demographics NEW PERSON enumeration HDR prototype Standard Data CAIP Delivery Service Systems of Interest Naming / Directory Messaging HL7 Builder Utility Lookup Data standardization Cleanup Dynamic Routing Service Data Aggregation & Migration Site Preparation & Training Re-hosting of VistA Applications Removal of M systems Performance Tuning Person Identity Management Making HealtheVet VistA a reality requires the creation of many elements and the completion of many processes. These efforts vary in timing, impact and duration and form the building blocks of the new software environment. Over time, HealtheVet progressively becomes a reality as the elements become available and the processes are completed. 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/ Juha.Mykkanen@uku.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 Palvelupohjainen sovellusintegraatio ja web-sovelluspalvelut terveydenhuollossa