case: plugit- ja serapi-projektit 3s-sovelluskehityssymposium, 27.1.2005 juha mykkänen

Palvelupohjainen sovelluintegraatio ja Web-sovelluspalvelut terveydenhuollossa: kokemukset ja mahdollisuudet

CASE: PlugIT- ja SerAPI-projektit

3S-sovelluskehityssymposium, 27.1.2005Juha MykkänenKuopion yliopisto, HIS-tutkimusyksikkö(terveydenhuollon tietojärjestelmien tutkimus- ja kehitysyksikkö)

(viimeisin – lyhennetty - versio esityksestä: www.uku.fi/tike/his/serapi/mater/Mykkanen-3S.ppt)

Palvelupohjainen sovellusintegraatio ja web-sovelluspalvelut terveydenhuollossa 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)

Sovellusintegraation mallit ja kokemukset / PlugIT


Tuotteita, konsultointia

Tarpeita

Tuote-kehitys

Tuki & käytt.otto

Tekn. kehitys

Sovel-tava

tutkimus

Perus-tutkimus

Opetus

Ohjelmistoyritykset Palvelun tuottajat

Tj-tuettu palvelu

Tietoj. käytt.otto

Tietoj. tuki

Oppilaitokset, tutkimuslaitokset

Hyvinvointi-palveluja

Kansa-laiset

Tarpeita Tarpeita

Tekijöitä, menetelmiä

Kv. yhteys

Julkinen hallinto

Ohjausta, resursseja

Parempi elämä

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


PlugIT:n kohteena oleva ongelma: Ohjelmistoryväs

Palvelin

Sovellus A

Sovellus B

Käyttäjä X Potilas 1 A-tietoa

Käyttäjä X Potilas 1 B-tietoa

Käyttäjät Potilaat

Koodistot


Koodistot

Tiedot Tiedot

Palvelin

Työasema

• 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]


Context Mgr

Context

Käyttäjä X Potilas 1

Palvelin

Terveys-kertomus

Alue-tietojärj.

Käyttäjä liisalaak Potilas Matti M. Kertomustietoa

Käyttäjä llaakari Potilas Meikä, M. Alueen tietoa


Koodistot


Koodistot

Tiedot Tiedot

Palvelin

Työasema





(common services)


Palvelin Palvelin

Potil

as

Koo

dist

ot

Oik

eude

t

Käyttäjä X Potilas 1 Ydin- ja

muuta tietoa

Käyttäjä X Potilas 1

Ydintietoa

Työasema

Ydin-sovellus

Erityis-sovellus

Tied

ot

Käy

ttäjä

Er

ityis

-tie

dot





(common services)


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]


Integrointitasot – ratkaisun osaset

• järjestelmän elinkaari• toiminnallinen

arkkitehtuuri

• sovellusarkkitehtuuri• tekninen arkkitehtuuri

Te knise t liittymät

Te knine n infrastruktuuri

Sov e llusinfrastruktuuri

Toiminnallise t liittymät

Se mantiikka

Toiminnalline n v iite malli

Ke hitysprose ssin liittymät

• ratkaistava kaikissa sovellusintegraatio-tilanteissa

[Peter Herzum, Oliver Sims]


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.]

1 . K o hde alue e nanalys o in ti

2 .So ve l lusarkkite htuur intunnis tam ine n

3 . O le m as s ao le vie nso ve llus te n te kniiko ide n

tunnis tam ine n

4 . To im innall is te nli i t tym ie n tunnis tam ine n

5 . L i it tym äte kni iko ide nvalin ta

7 . To te utuks e s s akäyte t tävie n tuo tte ide n

valinta

6 . L i i t tym ie n m äär i t te ly

- inte gro in tivaatim uks e t-o le m as s ao le vie n s o ve llus te n to im innall i s uus

- so ve llus arkki te htuur i- s o ve l lus te n alus ta

- to im innall i s e t inte gro in tipis te e t- s e m antti s e t vaatim uks e t

to im ialans tandardi t

- te knis e ts tandard it

-uude t m e to dit , työ kalutja te kni ikat

- in te gro intipis te e tko hde arkki te htuur is s a

-o le m as s ao le va te knine n inf ras truktuur i

- te kn iikkar iippum atto m atli i t tym ät

-uus i s o ve l lus inf ras truktuur i- inte gro inti te kno lo giat

- te kn is e t l i i t tym ät

1. INTEGRAATIO-VAATIM UKSET

2. TEKNIIKKA-RIIPPUMATON

LIITTYMÄMÄÄRITTELY

3. TEKNINENLIITTY M Ä-

M ÄÄRITTELY

Vaatimukset + toiminnan

kehittäminen

Osallistuvien sovellusten

ratkaisut

Toimialan standardit

ja viitemallit

Tekniset standardit,

työkalut

Vaiheittainen tarkennus,mallit ja ohjeistus eri vaiheisiin,

tavoitteena ratkaisun kattavuus ja tarkkuus,mutta selkeä, helppokäyttöinen

ja toistuva menettely

--SOVELTUU SEKÄ AVOIMEENETTÄ TAPAUSKOHTAISEEN

INTEGROINTIIN


Monenvälinen integrointi – PlugIT-hankkeen malli

T a u sta -se lv itykse t

Nyky tila nkuvau s

Pilo to in ti-su u nn ite lma

- lue tte lointegraatiotarpeis ta

-ohjeet m äär i tte lyjentek em is een

-s is äl töm äär i tte lytm äär i tte lydok um entei l le

-es im erk k e jä m äär i tte lyis täer i tyyppis i inintegroin ti ti lanteis i in

-m al l i ra tk a is u ja- toteu tus väl ine i tä

-valm i i ta m äär i tte lyi tä-p i lo to inti-o lem as s a olevat tek ni ik a t-om a laatu- ja tuotantopros es s i

Pro je kti-su u nn ite lma

Sa ira a la ta i mu uth . o rg an isa a tio

Ko o rd in a a tto r i(P lu g IT)

Ohjelmisto -

yritysToiminnan

kehittäminen

Integrointi-tarve

Vaa timu s-mä är itte ly

L iittymänmä ä ritte ly

T o te u tu s(p ilo to in ti)

Tulosten hyväksy ntäKäy ttöönotto ja

soveltaminen

1. INTEGRAATIO-VAATIMUKSET

2. TEKNIIKKARIIPPUM ATONLIITTYMÄMÄÄRITTELY

3. TEKNINENLIITTYM ÄMÄÄRITTELY

4. LIITTYMÄNTOTEUTUKSEN KUVAUS

m ää ritte lytyö

m ä ä ritte lytyöm ää ritte ly ja

to te u tu s

-ty ön dokumentointi-arviointi- integrointiprosessinkehittäminen

-y leistäminen-menetelmänvalidointi

-s ub s tans s ios aam ine n-pi loto intik ohde-k äytetyt tek ni ik at- laa tuvaatim uk s et

ja tko ke h itys , u u de t ve rs io t

to te u tu stu o tte es s a

Avo ime tin te g ro in timää r itte lyt

ta p a u s ko h ta is e tin te g ro in tiva a tim u ks e t

[Mykkänen, Tikkanen, Rannanheimo, Eerola, Korpela. Specification Levels and Collaborative Definition for the Integration of Health Information Systems. Proceedings of Medical Informatics Europe 2003].

Kolmikanta-osaamisen

hyödyntäminen

Priorisointi, suunnittelu,

taustoitus

Avoimen ja uudelleen-käytettävänratkaisunmäärittely

Käyttöönotto-edut


Eri tyyppiset ratkaisutAvoin 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


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].


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


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


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ä

Web services ja SOA


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


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]


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ö


• ”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

Web-sovelluspalveluiden lupaukset..


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


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”


Esimerkki: “Future-proof information systems” SOA:n avulla

HealtheVet VistAPlanning

Web Apps.

PatientLookup,PatientService Hardware design, procurement and deployment

PersonDemographics

NEW PERSONenumeration

HDRprototype

StandardData

Service

CAIP

Delivery Service

Systemsof

Interest Naming /DirectoryService

MessagingService

HL7 BuilderUtility

PersonLookup

Data standardization

DataCleanup Dynamic Routing Service

Data Aggregation & Migration

Site Preparation & Training

Re-hosting of VistA Applications

Removal of M systems

Performance Tuning

Person Identity Management

[Ken Rubin / EDS]


Tekniset ratkaisut perustuvat toiminnan ja sovellusten vaatimuksiin

– [SerAPI-hanke, tutkimussuunnitelma]– Tekes, FinnWell-teknologiaohjelma, 13 yritystä, 4 terv.huollon organisaatiota, 3

tutkimusryhmää– 9/2004-8/2007?

– 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


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


Kiitos

• 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

[email protected]

www.uku.fi/tike/his/serapi/www.plugit.fi/

http://www.uku.fi/tike/his/serapi/



http://www.plugit.fi/

http://www.plugit.fi/

case: plugit- ja serapi-projektit 3s-sovelluskehityssymposium, 27.1.2005 juha mykkänen

Documents