Palvelupohjainen sovelluintegraatio ja Web-sovelluspalvelut terveydenhuollossa: kokemukset ja mahdollisuudet

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ä gt10 v)

3
Sovellusintegraation mallit ja kokemukset / PlugIT
4
PlugIT-hankeTerveydenhuollon 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

5
PlugITn 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
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)

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)

8
Integrointimallit vaatimukset ja perusratkaisut

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

• 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

David Linthicum
9
Integrointitasot ratkaisun osaset
Milloin?

• järjestelmän elinkaari
• toiminnallinen arkkitehtuuri
• sovellusarkkitehtuuri
• tekninen arkkitehtuuri

Mitä?
Missä?
Miten?

• ratkaistava kaikissa sovellusintegraatio-tilanteis
  sa

Peter Herzum, Oliver Sims
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
  200370(2-3)173-182.

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ääri
ttely
Mykkänen, Tikkanen, Rannanheimo, Eerola,
Korpela. Specification Levels and Collaborative
Definition for the Integration of Health
Information Systems. Proceedings of Medical
Informatics Europe 2003.
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
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.
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

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

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ä

17
Web services ja SOA
18
Hajautetun väliohjelmiston (Middleware)
historiallinen kehityskaari

• etäohjelmakutsut (RPC)
• transaktiot mukaan -gt TP Monitors (Tuxedo jne.)
• olio-ominaisuudet TP Monitoreihin -gt
  oliosanomavälittimet (CORBA, COM, RMI)
• viestijonot TP Monitoreihin -gt MOM,
  message-oriented middleware (MSMQ, MQSeries,
  monet integrointialustat jne.)
• Internet-tekniikat mukaan -gt Web services
• ja niille ensimmäisenä etäohjelmakutsut
• ei revoluutio, vaan evoluutio

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
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
• XMLssä 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ä ltpersongt
  (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ö

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 (XMLhttp, 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

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 -gt 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

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

24
Esimerkki Future-proof information systems
SOAn avulla
HealtheVet VistA
Ken Rubin / EDS
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?

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-integraati
  o 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

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_at_uku.fi