Sovellusintegraatiosta palveluarkkitehtuuriin

1
Sovellusintegraatiosta palveluarkkitehtuuriin

• ERP System Integration, Helsinki, 29.3.2007
• Juha Mykkänen, FT, tutkija
• Kuopion yliopisto, HIS-tutkimusyksikkö
• juha.mykkanen_at_uku.fi

2
Esityksen sisältö

• Yhteentoimivuus mistä se muodostuu
• Eri tyyppisiin integrointivaatimuksiin
  vastaaminen
• Palveluarkkitehtuurin hyödyt ja niiden arviointi
• SOA ja standardointi
• 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) - ei liikkeelle "puhtaalta
  pöydältä"
• esityksessä poimintoja soveltavasta tutkimuksesta
  n. 7 v
• komponentit -gt sovellusintegraatio -gt
  palvelupohjaisuus
• esityksen pyrky integraatio SOA-näkökulmasta

3
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"

4
Keskeiset näkökulmat tarkemmin (SOA-jäsennin
monimutkaisen elefantin voi syödä vain pala
kerrallaan)
5
Tietojärjestelmiin kohdistuvia tarpeita
Pekka Kähkipuro
6
Yhteentoimivuus (interoperability)
7
Yhteentoimivuus-käsitteen merkitykset
8
Integrointitasot mitä sovittava sovellusten
yhdessä toimimiseksi
Milloin?

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

Mitä?
Missä?
Miten?

• ratkaistava kaikissa sovellusintegraatio-tilanteis
  sa

Peter Herzum, Oliver Sims
9
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.)

10
Eri tyyppisiin integrointivaatimuksiin vastaaminen
"...mutta kuinka missäkin tilanteessa saa kaikki
nuo tasot ratkaistua?"
11
Integrointimäärittelyn eteneminen

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

12
Integrointimallit vaatimusten ja
perusratkaisujen ensisijainen luonne

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

• 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

David Linthicum
13
Esimerkkejä integrointirajapinnoista
14
... esimerkkejä (jatkuu)
15
SOA what eri tyyppiset integrointitarpeet ja
-ratkaisut

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

16
Palveluarkkitehtuurin hyödyt ja niiden arviointi
"...mutta miten voin perustella
SOA-lähestymistavan?"
17
Arviointi ja mittaaminen tasot
Saranummi N. Healthcare Technology Assessment and
Evaluation. VTT Information Technology, 2003.
18
Tietojärjestelmien arviointitapoja
19
SOA ja web services - tavoitellut hyödyt (joita
analysoitu SerAPIssa, 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

20
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

21
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 (10131112)
  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ä ?)

22
SOA ja standardointi
"...mutta eikö jotain voisi saada valmiina, mitäs
muut tekevät?"
23
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)

24
Standardien osa-alueita (terveydenhuollon
tietojärjestelmät)
25

• 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

• 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

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

27
Yhteenveto
"...entäs sitten?"
28
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)

29
Kriittiset valinnat

• maksimoitu joustavuus plug and
  play-tarkkuus

matala toteutuskynnys korkean tason
yhdenmukaisuus vähäinen invasiivisuus
standardienmukaiset hankinnat paikallinen
sovittaminen
painotuksia monenvälisissä terveydenhuollon
IT-hankkeissa Suomessa
esimerkki suuren USAlaisen terveyspalvelujen
tarjoajan IT-strategiasta
30
Yhteenveto

• SOA integraation syventäjänä IT-integraatiosta
  tietojärjestelmien ja toiminnan yhdessä
  kehittämiseen
• web services ja standardit ratkaisevat vain
  jotkin integrointitasot - paljon jää edelleen
  paikallisesti tarkennettavaksi
• tieto-, palvelu-, käyttäjä- ja prosessi-integraati
  o erilaiset palvelut ja käyttötavat erilaisiin
  tarpeisiin
• liikkeelle "pikavoitoista" tai "kipupisteistä"
• (vaihtoehto infrastruktuurin pitkäjänteinen
  kehittäminen)
• early learning - integration - reengineering -
  cultural integration
• 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

31
Kiitos
www.uku.fi/tike/his/serapi/

• 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