Prosessit ja palvelut
Sponsored Links
This presentation is the property of its rightful owner.
1 / 64

Työpaja 3 SerAPI-työpajaseminaari 6.2.2006, Kuopio Juha Mykkänen, Heli Luostarinen, PowerPoint PPT Presentation


  • 82 Views
  • Uploaded on
  • Presentation posted in: General

Prosessit ja palvelut. Työpaja 3 SerAPI-työpajaseminaari 6.2.2006, Kuopio Juha Mykkänen, Heli Luostarinen, Pasi Riikonen, Assi Pöyhölä, Esa Paakkanen versio julkiseen jakeluun. Työpajan runko. aamupäivä (prosessit, sisällöt, käsitteet, tiedot, toiminta)

Download Presentation

Työpaja 3 SerAPI-työpajaseminaari 6.2.2006, Kuopio Juha Mykkänen, Heli Luostarinen,

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Prosessit ja palvelut

Työpaja 3

SerAPI-työpajaseminaari 6.2.2006, Kuopio

Juha Mykkänen, Heli Luostarinen,

Pasi Riikonen, Assi Pöyhölä, Esa Paakkanen

versio julkiseen jakeluun


Työpajan runko

  • aamupäivä (prosessit, sisällöt, käsitteet, tiedot, toiminta)

    • Prosessit ja palvelut-kohde: tavoitteet, tilanne jne.

    • Työpajan ja osallistujien tavoitteet

    • ProPa-tuotoksista lyhyesti

    • Prosessikuvausesimerkkejä eri lähteistä:

      • äitiyshuolto (lyhyesti) / SerAPI, VSshp ja ydintietomäärittelyt

      • endoskopia, leikkaussali / Satshp

      • gastroskopia / SerAPI/PlugIT

    • eri mallien vertailu suhteessa tavoitteisiin, keskustelu mm. työtoiminnan kuvaus, toimintojen linkitys ja kuvaaminen

  • iltapäivä (arkkitehtuuri, palvelualusta, integraatio)

    • palvelualustojen käyttö

    • prosessimoottorin käyttömahdollisuudet

    • palvelujen luokittelu ja arkkitehtuuri

    • tarkempaa esimerkin läpikäyntiä / Satshp

    • jatkotyön tarkennukset ja tarpeet


ProPa-tavoitteet

  • Mitä tehdään:

    • toimintaprosessien ja sovelluspalvelujen tunnistamista, nimeämistä, määrittelyä ja kuvaamista

  • Tavoitteet: ratkaisuja ja esimerkkejä:

    • prosessien ja toiminnan ymmärtämiseen

    • palvelujen tunnistamiseen ja erottamiseen prosessimallinnuksesta

    • SerAPI-määrittelykohteet keskittyneet rajapintojen bottom-up määrittelyyn, tässä prosessilähtöinen palvelumäärittely (top-down)


Osapuolten tavoitteita

  • esimerkkejä palvelupohjaisista ratkaisuista

  • esimerkkejä prosessien mallinnuksesta

  • osastojärjestelmien liittämisen toistettava malli

  • palvelupohjaisen arkkitehtuurin "blueprint"

  • prosessimoottorin kokeilu

  • palvelualustan käytön ja käyttökohteiden tarkennus

  • Business Activity Monitoring -tiedon kerääminen palvelualustan kautta

  • yleiskuva terveydenhuollon / sairaalan prosesseista

  • mihin keskitymme tänään?


ProPa-tuotokset

  • prosessien ja sovelluspalvelujen kuvauksia tilanteessa, joka liittyy konkreettiseen terveydenhuollon prosessiin ja palvelu/järjestelmähankintaan

  • ratkaisuja ja esimerkkejä - prosessien mallintamisesta, välineistä ja tekniikoista

  • tietoa prosessimallinnuksesta ja palveluarkkitehtuurin suunnittelusta terveydenhuollossa

  • Prosessikartta

  • Prosessiesimerkit (endoskopia ja äitiyshuolto)

  • Sovelluspalvelujen tunnistaminen + toiminnalliset määrittelyt

  • (Sairaalan) SOA-arkkitehtuuri

  • (siirtymä- ja migraatiovaihtoehdot, ohjeet jne.)


Tilanne

  • 09/06 SerAPIn Prosessit ja palvelut-työpaja

    • -> soveltamiskohteen käynnistys + tavoitteiden 1. tarkennus -> ProPa-kohdekuvaus

  • 11/06 esimerkkiprosessien valinta

  • tuotettu prosessikartan ja -esimerkkien luonnoksia

  • koottu materiaalia (palvelupohjaisen määrittelyn menetelmät ja ratkaisut, esimerkkiprosessit, palveluarkkitehtuurin mallit)

  • 02/07 tavoitteiden 2. tarkennus, ProPa-työpaja

  • yhteyksiä (osapuolten lisäksi)

    • ZipIT-hanke: toimintalähtöinen vaatimusmäärittelymenetelmä, työtoiminnan kuvaaminen

    • Healthcare Services Specification Project (SOA4HL7) -työ etenkin SOA-lähestymistavassa

    • SerAPI:n SOA- ja web services-soveltamisopas

    • kansallisen Ajanvarauksen esiselvityshanke


Työpajan tavoitteet

  • tarkentaa tavoitteita ja toimenpiteitä osallistujien kannalta:

    • nimettyihin soveltamistarpeisiin

    • yleisesti prosessimallinnukseen ja palvelujen määrittelyyn prosesseista

    • arkkitehtuurimäärittelyyn

    • prosessimoottorin ja alustan käyttöön

  • yleisistä kysymyksistä kohti "kuinka sovellamme käytännössä" -suunnittelua

  • jatkoa 09/06 työpajan asioille


Terveydenhuollon yleistetyt prosessit


Prosessikartta - yleinen taso (esh organisaatiossa)


Prosessikartta - pohja tarkennuksille

  • tarkempia esimerkkejä mm. gastroskopiaan ja äitiyshuoltoon myöhemmin aamupäivällä


Prosessimallinnuksen esimerkit

  • äitiyshuolto (laaja) ja endoskopia (rajattu) valittu osapuolten aloitteesta tarkemmiksi esimerkeiksi

    • molemmissa myös valmiin materiaalin hyvä saatavuus vaikuttanut valintaan

  • lisäksi osapuolten kuvauksia (esim. leikkaussali)

  • äitiyshuolto aamupäivällä lyhyesti esimerkkinä (kaikki tarvittavat osapuolet ei paikalla)

  • endoskopiasta tarkempaa esimerkkiä

    • aamupäivällä prosessimallien ja -tuotosten vertailua (Satshp endoskopian ja leikkaussalin mallinnus ja -integraatio + SerAPI / PlugIT-gastroskopia prosessikartta ja -kuvaukset)

    • yleistettävyys ja käyttökelpoisuus ratkaisujen + arkkitehtuurin + alustan suunnittelussa

    • iltapäivällä samoja esimerkkejä integrointi-, alusta- ja arkkitehtuurinäkökulmista?


Prosessikuvausten tuottaminen 1

  • Kuvataan prosessin tavoitteet

  • Nimetään prosessin omistaja (jos mahdollista)

  • Määritellään, mistä prosessi alkaa, mihin se loppuu ja mitä prosessi "tuottaa"

  • Tunnistetaan alustavasti prosessin päävaiheet (toiminnot) ja niiden järjestys, hyödyntäen esim. yleisiä hoito- ja tutkimus/toimenpideprosesseja

  • Tunnistetaan prosessin osallistujat

  • Kuvataan vaihe vaiheelta prosessin eri vaiheiden yhteydet muihin prosesseihin ja toimintoihin

  • Tuotetaan prosessikuva (esim. BPMN-notaatiolla), kuvassa esitetään keskeiset toimijat/yksiköt, prosessin vaiheet ja prosessin eteneminen eri vaiheiden välillä


Prosessikuvausten tuottaminen 2

  • Tarkennetaan, mitä tietoa prosessin eri vaiheissa liikkuu.

  • Tarkennetaan, onko jokin prosessin osa (aliprosessi) kuvattava tarkemmin omana prosessinaan. Aliprosesseille kuvataan edeltävät askeleet siten kuin ne soveltuvat.

  • Kuvataan vaihe vaiheelta prosessin eri vaiheissa tapahtuva tietotekniikan käyttö ja tapahtumat, jotka ovat rajapinta käyttäjän/prosessin ja tietotekniikan välillä.

  • Tunnistetaan / nimetään yleiset tietojärjestelmä- ja sovelluspalvelut, jotka liittyvät vaiheen 10 tapahtumiin.

  • Tunnistetaan tietojärjestelmät ja sovellukset, joista sovelluspalveluja voidaan tarjota

  • Tunnistetaan valmiit palvelumääritykset tai rajapinnat, joita voidaan hyödyntää tai soveltaa

  • Siirrytään tarkempaan sovelluspalvelujen määrittelyyn tai soveltamiseen


Prosessiesimerkkien läpikäyntiä

  • äitiyshuolto

    • SerAPI: toimintatarina äitiyshuollon palvelukokonaisuudesta (taustamateriaalina), synnytys-hoitokokonaisuuden prosessikartta

    • VSshp: palvelukokonaisuus- ja palvelutapahtuma-esimerkit

  • endoskopia ja leikkaussalijärjestelmät

    • Satshp: endoskopian ja leikkaussalin prosessit

    • SerAPI: gastroskopian prosessikartta, toimintatarina, prosessikuvaukset

  • pohjana jatkokeskustelulle, palvelujen määrittelylle, yleistämiselle, parhaiden käytäntöjen + tarkkuustason valitsemiselle jne.


Äitiyshuollon palveluketjun tärkeimmät osat

[Äitiyshuollon prosessi ja tietotarpeet: Saumattoman palveluketjun tietoteknisen tuen malliratkaisu - hankesuunnitelma, Silvennoinen, Korpela 2004]


Äitiyshuollon prosessikartta (esh)


Synnytys-hoitokokonaisuuden prosessikartta


Esimerkki äitiyshuollon palvelukokonaisuudesta

[Pirkko Kortekangas, 2006]


Esimerkki hoitokokonaisuuden tapahtumista/toiminnoista ja niiden tehtävistä

[Pirkko Kortekangas, 2006]


Äitiyshuollon rakenteiset tiedot

  • äitiyshuollon palveluketjun keskeiset rakenteiset tiedot

  • kuvaa myös äitiyshuollon tyypillisen palveluketjun

  • dokumentti sisältää prosessikuvauksia (eri lähteistä + päivitetty)

    • esim. synnytysvastaanotto ja synnytyksen hoito ->

    • [Äitiyshuollon sähköisen potilaskertomuksen rakenteiset tiedot, luonnos v1.1, 25.10.2006]


Prosessikuvausten esimerkkejä

  • Satakunnan shp:

    • endoskopian prosessit

    • leikkaussaliprosessit

  • ks. Satshp esitys

  • endoskopiaosion vertailu: gastroskopian prosessikuvaus -esimerkki / SerAPI

    • gastroskopian prosessikartta

    • gastroskopian prosessikaavioiden luonnokset

    • gastroskopian hoitoprosessin kuvaus / PlugIT


Gastroskopia-esimerkin kokemuksia ja pohdintaa

  • työpajan pohjamateriaalina hoitoprosessin kuvaus

  • lähdemateriaalin prosessikuvauksissa ei ole erittelyä, mitä loppujen lopuksi hoidetaan missäkin tarkalleen

  • olisi mahdollista jaotella organisaatiota toiminnallisesti tarkemmin esim. gastroenterologiassa, mitä missäkin (poliklinikka - mm. esitutkimus, vuodeosasto ja toimenpideyksikkö) - voi poiketa paikallisesti

  • prosessikartan "organisaatioyksiköt" voivat käytännössä sisältää useita toimipisteitä esim. sisätautien poliklinikka - tutkimusosasto

  • esi- ja jälkitoimenpiteet voivat poiketa, esim. tarvitseeko potilaan aina käydä poliklinikalla ennen ajanvarausta toimenpiteeseen

  • lääkityksen tilaus on tehtävä "jossain vaiheessa ennen tutkimusta", mutta ei välttämättä esim. heti ajanvaraukseen liittyen

  • tarvitaanko esim. skopiatoimenpiteen tarkempaa kuvausta?

  • hallinnolliset järjestelyt (esim. kuvataanko aina ilmoittautumisen tarkastus omana vaiheenaan ennen toimenpidettä)

  • jatkotarkennuksia mm. tietokokonaisuuksien erittely, tapahtumat, palvelujen, järjestelmien ja rajapintojen tunnistaminen


Keskusteluaiheita

  • nykytila vs. tavoitetila:

    • nykytilan ymmärtäminen välttämätöntä - mutta kuinka tarkalla tasolla?

    • miten syvälle on uppouduttava työtoiminnan kuvaamiseen?

    • onko SOA-lähestymistavassa itse asiassa kyseessä "hiukan parannetun nykytilan" mallinnus + toteuttaminen + jatkossa pienillä parannuksilla kehittäminen?

  • yleistäminen

    • välttämätöntä, jotta tietotekninen ratkaisu saadaan aikaan + etenkin jos pyritään sovelluspalvelujen uudelleenkäyttöön

  • hyvät käytännöt

    • kuvataanko prosessin käynnistävät tapahtumat osana prosessia?

    • prosessien ohjaus -> guideline, malli josta pitää voida poiketa?

    • prosessikartan toiminnallinen jaottelu esim. yksiköiden suhteen - pitäisikö "missä" erottaa "mitä"-kysymyksestä?


Keskustelu: työtoiminnan kuvauksen suhde prosessikuvauksiin

  • työtoiminta = esim. organisaatioyksikön, ammattiryhmän tai henkilön tekemät toiminnot tai tehtävät

  • poikkeaa prosessikuvauksesta: prosessi kulkee monien työtoimintojen läpi, työtoiminnassa toistuvat pienet osat useista eri prosesseista ja saman prosessin instansseista

  • työtoiminnan kuvaukseen eri kuvaustavat kuin prosessin (työnkulku, tiedonkulku, henkilöiden, materiaalin kulku) kuvaukseen

  • työtoiminnan kautta toisistaan täysin irralliset eri prosessit liittyvät toisiinsa ja vaikuttavat toisiinsa

  • työtoimintaa ei automaattisesti huomioida työnkulkujen ja tietovirtojen optimoinnissa ja automatisoinnissa


Keskustelu: tapahtuma/toiminto-käsitteen suhde prosessien kuvauksiin ja toteutuksiin

  • "palvelutapahtuma"-käsite on tietyn palvelun järjestäminen tai toteuttaminen - kansallisia määritelmiä liittyen mm. lainsäädäntöön, hoitojaksoihin ja ydintietoihin

  • prosessimallinnuksen kannalta tarvitaan toiminto (/ tapahtuma), joka kuvaa tietyn palvelun toteuttamiseksi tarvittavat tehtävät

    • terminä "toiminto" [JHS 152] tai "palvelutoiminto"?

    • ei "tapahtuma" (jolla prosessimallinnuksessa yleensä käännöksenä "event")?

  • jos yksi toiminto kuvataan tehtävinä, päästään riittävälle tarkkuustasolle palvelujen tunnistamista (/prosessin koordinointia?) varten?

  • toinen vaihtoehto keskittyä vain yksiköiden / toimintojen / ihmisen ja sovelluksen rajapintoihin

  • myös eri asiakirjat on saatava liittymään toisiinsa

    • palvelutoiminnon sisällä, hoitojakson, palvelukokonaisuuden sisällä...


Toiminto

[kansallinen ajanvarauspalvelu - käsitemalli (yleinen)]


Työpajan runko

  • aamupäivä (prosessit, sisällöt, käsitteet, tiedot, toiminta)

    • Prosessit ja palvelut-kohde: tavoitteet, tilanne jne.

    • Työpajan ja osallistujien tavoitteet

    • ProPa-tuotoksista lyhyesti

    • Prosessikuvausesimerkkejä eri lähteistä:

      • äitiyshuolto (lyhyesti) / SerAPI, VSshp ja ydintietomäärittelyt

      • endoskopia, leikkaussali / Satshp

      • gastroskopia / SerAPI/PlugIT

    • eri mallien vertailu suhteessa tavoitteisiin, keskustelu mm. työtoiminnan kuvaus, toimintojen kuvaaminen

  • iltapäivä (arkkitehtuuri, palvelualusta, integraatio)

    • viitearkkitehtuuri

    • tarkempaa esimerkin läpikäyntiä / Satshp <- tässä kohden?

    • palvelujen luokittelu

    • palvelualustojen käyttö

    • prosessimoottorin käyttömahdollisuudet

    • jatkotyön tarkennukset ja tarpeet


Iltapäivän lähestymistapa

  • viime kerralla keskityttiin mallinnusnotaatioiden lisäksi palvelupohjaiseen kehitysprosessiin

  • nyt prosessin sijaan (/ lisäksi) eri arkkitehtuurinäkökulmien pohjalta etenemistä

  • viitearkkitehtuurin kerrokset / näkökulmat

  • erityishuomion kohteena tänään:

    • palvelualustat

    • prosessimoottori

    • palvelujen luokittelu

  • sovelluspalvelut

  • järjestelmät

  • järjestelmien komponentit / rajapinnat

  • prosessikerros

  • käyttöliittymät

  • integraatioarkkitehtuuri

  • hallintamekanismit


Kertausta: vaiheet (soddm)

vaihtoehtojen tarkastelu prosessien toteuttamiseksi

tavoitteet, mittarit, lähtökohdat, suunnitelma

web-sovelluspalveluiden ja prosessien tunnistaminen ja määrittely asteittain

web-sovelluspalveluiden ja prosessien kehittäminen ja kuvaaminen, teknisten rajapintojen kuvaaminen, palveluja käyttävien osien kehittäminen

palvelutason seuranta, mittaus, raportointi, parantaminen

kehitettyjen palveluiden ja prosessien toiminnallisen oikeellisuuden ja täydellisyyden sekä yhteentoimivuuden testaaminen

web-sovelluspalveluiden käyttö, prosessien määrittelyjen mukainen suorittaminen

hallinta- (keskitetty/hajautettu), sertifiointi-, mittaus- ja laskutusmallien määrittely

palveluiden ja prosessien käyttöönotto sovelluksissa, käyttäjillä ja kumppaneilla

[Michael P. Papazoglou ja Willem-Jan van den Heuvel.International Journal of Web Engineering and Technology (IJWET), 2006.]


Viitearkkitehtuuri-käsittelyn runkona


Viitearkkitehtuuri: perusteet

  • viitearkkitehtuuri ohjaa miettimään ja ratkaisemaan tietyn tyyppisiä seikkoja kerrallaan, ei kaikkea yhtä aikaa

  • myös muiden seikkojen kuin "palvelut" huomiointi

  • "riittävän vähäinen" määrä kerroksia ja näkökulmia

  • pohjana useita arkkitehtuurikuvauksia, mukana useissa kuvauksissa näkyvät kerrokset / näkökulmat

    • esimerkkejä

  • ei "ainoa oikea" lähestymistapa

    • lisäksi tarvitaan mm. kehitysprosessin ja hallinnan näkökulmia

    • esim. CBDI "meta model for service architecture and engineering" -näkökulmat:

      • business modelling, solution modelling, specification of BSA, service specification detail, planning and provisioning policy, implementation, deployment, runtime

  • tässä vaiheessa kuitenkin keskitytään vielä lähinnä analyysi- ja suunnitteluvaiheeseen


Viitearkkitehtuuri: ehdotus

[Arsanjani A. Service-oriented modeling and architecture.]


Viitearkkitehtuurin soveltaminen:sovelluspalvelut (services)

-palvelujen luokittelu

-hiukan määrittelyprosessista

-palvelujen tunnistamisesta lisää "alakerrosten" yhteydessä


Palvelujen luokittelun perusteet

  • luokittelun tarkoitus: samantyyppisiä ratkaisuja samantyyppisiin tarpeisiin

  • kaikki palvelut eivät voi olla samantyyppisiä (ja ratkaisuissa tarvitaan muutakin kuin palveluja)

  • erilaisia luokittelulähtökohtia

    • teknisyys ja yleiskäyttöisyys: infrastruktuuri / ydinpalvelut / lisäpalvelut

    • arkkitehtuurin kerrokset + karkeajakoisuus: järjestelmäpalvelut, business services, process services

    • palvelun kattamien integrointivaatimusten ensisijainen luonne: tietopalvelut, toiminnalliset palvelut, käyttäjäkeskeiset palvelut, prosessipalvelut

    • toiminnallinen luokittelu: tekniset palvelut (viestinvälitys), yleispalvelut (ajanvaraus), toimintokohtaiset palvelut (radiologian sovelluspalvelut)

    • rakenteisuuden ja "epävarmuuden" aste


Palvelujen luokittelu - ehdotus

  • luokittelu tehty lähinnä services-kerrosta varten hyödyntäjänäkökulmasta

  • luokitellaan tunnistettavat palvelut kahden erillisen näkökulman mukaisesti [SOA4HL7, Herzum&Sims, CBDI, RM-ODP, Linthicum]

  • palvelun integrointitapa - koska tarvitaan erilaisia palveluita

    • prosessipalvelu: toteuttaa suoraan prosessia tai osaprosessia

    • tietopalvelu: liittyy suoraan tietokokonaisuuteen, tietyn tyyppisiin dokumentteihin jne.

    • toiminnallinen palvelu: keskeistä tarjottava toiminnallisuus (business capability)

    • tukipalvelu

  • palvelun yleiskäyttöisyys - koska on määriteltävä uudelleenkäyttöä

    • yleispalvelut - hyödynnettävissä hyvin monien eri tyyppisten palvelujen, sovellusten ja prosessien toteutuksissa (utility service)

    • ydinpalvelut - monissa prosesseissa ja yksiköissä / sovelluksissa hyödynnettäviä toiminnallisia tai tietopalveluja (common service)

    • erikoispalvelut - tiettyihin erikoistilanteisiin vastaavia toimintoja, voi olla osasto/sovellus/tehtäväkohtainen (specialized service)


Esimerkkejä (eri kokoisia)

  • kansallinen arkistopalvelu (tieto- ja ydinpalvelu)

  • DRG-ryhmittelijä (toiminnallinen- ja erikoispalvelu)

  • viestinvälityspalvelu (tuki- ja yleispalvelu)

  • kontekstinhallinta (toiminnallinen- ja yleispalvelu)

  • kansallinen koodistopalvelu (tieto- ja yleispalvelu)

  • koodistojen CodeAPI-rajapinnan toteuttava palvelu sairaalassa (toiminnallinen- ja ydinpalvelu)

  • alueellinen viitetietopalvelu (tieto- ja yleispalvelu)

  • ajanvarauspalvelu (toiminnallinen- ja ydinpalvelu)

  • diabetes-hoitoketjua ohjaava käypä hoito-palvelu (prosessi- ja erikoispalvelu)

  • sosiaalihuollon yleinen asiointiprosessin ohjauspalvelu (prosessi- ja yleispalvelu)

  • keskitetty käyttöoikeuksien hallintapalvelu (toiminnallinen- ja ydinpalvelu)


Palvelujen suunnittelu: vaiheet (1/2)

Lähtökohtana vaatimukset ja olemassa olevat sovellukset + ratkaisut

  • tarvittavan toiminnallisuuden kartoitus (vaatimukset, prosessit)

  • palvelun rajaus ja päävaatimusten valinta

  • sisällöllisten standardien ja valmiiden mallien tutkiminen + valinta

  • osallistuvien sovellusten vastuiden määrittely

    • keskittyminen vain palvelun tarjoajaan - uudelleenkäyttö?

  • rajapintojen tunnistaminen ja toimintojen ryhmittely niihin


Palvelujen suunnittelu: vaiheet (2/2)

  • toimintokohtaisesti operaatioiden "koko" + tarvittava / käytettävissä oleva infrastruktuuri

  • vuorovaikutuksen määrittely (rajapinta + käyttäjä)

  • palvelukuvauksen määrittely (rajapinnat, toiminnot, tiedot)

  • pakollisten ja vapaaehtoisten ominaisuuksien ja sallittujen laajennusten määrittely

  • vaatimusten tarkentaminen teknisille määrittelyille ja toteutuksille

     tuloksena palvelun rajapinnan määrittely ja suuntaviivat teknisille ratkaisuille


  • palvelu- ja viestimäärittelyn toimenpiteet (valkea) ja tuotokset (värillinen)

  • A generic process for HL7 Messaging Dynamic Model and SOA approach (viestinvälityksen ja palvelulähestymistavan lähentämistä)

  • [Healthcare Services Specification Project: Services and the HL7 V3 Messaging Dynamic Model, v. 0.98]


Viitearkkitehtuurin soveltaminen:integrointiarkkitehtuuri+ hallintamekanismit

-erityisesti palvelualusta (ESB)


Integrointiarkkitehtuurin rajapintojen ja liitäntöjen tyyppejä

  • keskitetyt, jaetut palvelut (ydinpalvelut)

  • lisäpalvelut, kontekstinhallinta jne.

  • löysästi kytketyt, yksiköiden ja organisaatioiden väliset palvelut

[Mykkänen, Korpela, Ripatti, Rannanheimo, Sorri. Local, Regional and National Interoperability in Hospital-Level Systems Architecture. Meth Inf Med, 2007, under revision]


Palvelualustojen käyttö

  • palvelualusta (ESB) perusteet [mukaillen Gartner + Bea + Chappell]:

    • lähettäjien ja vastaanottajien välissä (intermediary)

    • ohjelmistojen välinen kommunikointi

      • aina SOAP/http

      • yleensä myös viestipohjainen middleware (MOM)

      • eri viestinvälitysmallit: synkroninen, ei-synkroninen, publish/subscribe

    • tukee Web services-standardeja (XML, WSDL, SOAP, http)

    • reititys (mm. palveluntarjoajien löytäminen / korvaaminen, ajonaikainen sidonta)

    • muunnokset (tietomuotojen + viestinvälitysprotokollien välillä)

    • metatietojen käyttö (osoitteet, rajapinnat, skeemat, policy-määrittelyt)

    • seuranta (esim. Business Activity Monitoring, tekninen toimivuus, SLA-valvonta), turvallisuusominaisuudet

    • (usein) prosessimoottorin käyttö

    • ESB ei ole yhtä kuin hub and spoke-integrointialusta: myös integrointikomponentit hajautettu palveluiksi palveluväylän kautta


Palvelualusta: Basic SOA [SOA4HL7]


Palvelualusta: Orchestrated (& statically & dynamically intermediated) SOA [SOA4HL7]

Static

intermed.

Dynamic

intermed.


Palvelualustan vaikutukset suunnittelupäätöksiin

  • vaikuttaa

    • protokollasopimukset

      • rajapintojen syntaksi, kommunikaatioprotokollat, vaatimukset sovellusten teknisille adaptereille, joskus myös eri viestintämuotojen mäppäys mahdollista

    • reititys oikealle palvelulle vs. palvelurekisteri

      • loogisten osoitteiden asettaminen viestiin vs. palvelun käyttäjän vastuu paikallistaa vastaanottaja

    • ympäristön hallittavuus

      • keskitetty yhteys-, valvonta- (ja virhetilanne-) piste vai hajautetut integrointipalvelut

    • lisää joustavuutta ja erilaisia soveltamismahdollisuuksia, mutta myös uuden kerroksen järjestelmään ja eri soveltamistapoja

  • ei vaikuta

    • semanttiset ja toiminnalliset perusratkaisut (tietoelementtien ja kokonaisuuksien merkitykset, pl. yksinkertaiset yhdistelyt ja jaot, toiminnallisten vaatimusten perusluonne (integrointitapa))


Filosofinen ero (tai USA-Ruotsi-maaottelu)


Palvelualustojen käyttöön liittyviä kysymyksiä

  • palvelujen (toiminnallisessa) määrittelyssä tehtävät oletukset alustan hoitamista seikoista

    • esim. "pyynnön vastaanottajan" määrittelyn eri tasot - onko osa palvelun rajapintaa vai alustan / hakemiston hoidettava asia?

    • kulkeeko "kaikki" palvelualustan kautta, vai tehdäänkö suoria liitäntöjä esim. ydinpalveluihin - esim. kontekstinhallinta ei ole ESB-palvelu?

  • vaatimusten luonne

    • esim. vuorovaikutteisuus vs. viestipohjaisuus

    • infrastruktuuriresurssit vs. sovellushankintaresurssit

  • policy-määritysten suhde toiminnallisiin määrityksiin

    • periaatteessa kaikki voi olla joko rajapintaa tai konfiguraatiota

  • arvio [Bea]: 20 palvelun sovellukset onnistuvat vielä point-to-point-tavalla, laajemmat sovellukset vaativat keskitetyn väylän

  • mitä erityisesti jää "yhteisesti sovittavaksi" palvelualustoja käytettäessä

    • sisältö ja perusratkaisut

    • toiminnalliset palvelumäärittelyt


Viitearkkitehtuurin soveltaminen:prosessikerros (business process / choreography)

-erityisesti prosessimoottori


Viitearkkitehtuurin soveltaminen: business process / choreography

  • vaihtoehtoja

    • prosessimoottori - orchestration

      • keskitetty prosessin ohjaus, oma kerros arkkitehtuurissa, prosessin osana olevien palvelujen ei tarvitse tuntea prosessimäärittelyä

    • prosessin dokumenttien kunkin osapuolen tuntemat prosessimäärittelyt - choreography

      • hajautettu prosessin ohjaus, kaikkien osapuolten mukauduttava määrittelyihin

      • prosessimäärittelyjä voi myös kuljettaa dokumenttien "mukana"?

    • erikseen rakennetut prosessipalvelut osana arkkitehtuuria - kuten prosessimoottori

    • käyttöliittymäsovellus (myös vanhat sovellukset) / asianhallintasovellus / portaali prosessin ohjaajana


Prosessimoottorin käyttökohteet ja edellytykset

  • prosessimoottori: keskitetty prosessin kontrolloija

  • ohjaa ennalta määritellyllä tavalla viestien ja vastausten liikkumista

  • säilyttää tiedon prosessin tilasta

    • prosessin seuranta, poikkeamien hallinta ym.

    • teknistä tietoa prosessien etenemisestä, virhetilanteista jne.

    • toiminnallista tietoa prosessien kulusta, läpimenoajoista, määristä jne.

  • prosessin askelten deterministinen määrittely

    • tunnettava, kuinka prosessi etenee

    • ottaa usein kantaa sekä tiedonkulun että työnkulun etenemiseen

    • prosessimäärittelyn hienojakoinen karkeustaso


Esimerkki: prosessimoottori kansallisessa arkistossa

  • prosessien suorittaminen, arkiston osajärjestelmien riippuvuuden vähentäminen, uusien osien helppo lisääminen, prosessien muuttaminen, prosessien tilan ylläpito ja valvonta

  • arkistopalvelun sisäisen toimintalogiikan määrittelyt, suorittaminen ja valvonta

[KANTA - Kokonaisarkkitehtuuri, Arkkitehtuurimäärittely v0.9]


Prosessimoottorin käyttöön liittyviä kysymyksiä

  • määrittely prosesseihin, joita kontrolloivat ihmiset tai joita kontrolloivat olemassa olevat järjestelmät

    • määritelläänkö terveydenhuollon prosesseja niin tarkasti, että niistä saadaan "koordinoituja"?

    • vai luodaanko prosessimoottoriin "kehysprosessit", joiden yksityiskohtiin ei kiinnitetä prosessitasolla huomiota?

    • logiikan päällekkäinen toteutus prosessimoottorissa ja tietojärjestelmissä?

  • BPEL:in käyttö prosessien kuvauskielenä?

    • BPEL4WS: rajoittuminen web-palvelujen kutsumiseen (myös prosessi on web-sovelluspalvelu) - palvelualustoihin voidaan liittää myös muilla tavoin teknisesti toteutettuja palveluita

    • saatavilla myös välinekohtaisia kuvaustapoja ja yhteisiä notaatioita, joilla ei yhtä vahvaa tekniikkasidontaa

      • esim. BPMN:stä ja useista välineistä määritelty siirtymä ja vastaavuudet BPEL:iin

  • keskitetylle orkestroinnille myös vaihtoehtoja: koreografia / itinerary, jossa viestin mukana kulkee "prosessimäärittely", portaalit, prosessipalvelut?


Johtopäätöksiä etenemiseen prosessimoottoreista

  • prosessimoottorin käyttökohteeksi on suosiolla valittava sähköisen tiedon käsittelyprosessi, EI terveydenhuollon organisaation työnkulku tai asiakasprosessi?

    • "prosessikuvaukset" tarkennettava / muunnettava hienojakoisiksi tiedonkäsittelyprosesseiksi

    • keskittyminen tiedonkäsittelytapahtumiin, työtehtävien erottaminen tiedonkäsittelytehtävistä

    • tavoite tiedonkäsittelyn ja välityksen ohjaus, seuranta, mahd. automatisointi

  • TAI yleistetyn työnkulun kuvaus prosessimoottoriin?

    • ja monien manuaalisten vaiheiden ja poikkeustilanteiden huomiointi

    • abstraktit prosessit, joiden yksityiskohdista ei välitetä prosessimoottoritasolla, asianhallintaprosessit?

    • tavoite "saumakohtien" seuranta, risteämispisteiden hallinta, ei automatisointi

    • ei niinkään kyse, tarvitaanko CT-kuva vai ei, vaan milloin se tarvitaan?


Viitearkkitehtuurin soveltaminen:järjestelmät (operational systems)ja niiden rajapinnat (enterprise components)

-lyhyesti

-perustuen edellisen kerran materiaaliin


Viitearkkitehtuurin soveltaminen: enterprise components

  • bottom-up -palvelujen tunnistaminen

    • pohjana esim. järjestelmäkartta

    • tarvittavaan prosessiin liittyvien toimintojen ja tietojen tunnistaminen sovelluksista

    • käytettävissä olevat palvelut

    • tarvittavien muutosten tai laajennusten määrittely

  • top-down -palvelujen tunnistaminen

    • pohjana riittävälle tasolle kuvatut tavoitetilan prosessit

    • palvelujen, rajapintojen ja operaatioiden määrittely prosessikuvauksista

  • toteutusstrategiat

    • hankinta, osto, vuokraus, mukauttaminen (adapteri)...

    • "sen pitää pyöriä meillä"?


"Käytettävissä oleva"?

  • tuotteeseen toteutettu "palvelurajapinta"

    • Web service-rajapinta

      • edelleen tarvitaan WS-I ja yhdenmukainen arkkitehtuuri

    • http/XML ja (HL7-)viestirajapinnat

  • saatavilla oleva rajapintamäärittely

    • rajapintastandardit

      • teknisellä tai "vain toiminnallisella" tasolla määritellyt

    • saatavilla olevat WSDL-kuvaukset (toimittajat, käyttäjät)

  • tuotteesta löytyvä "valmis" toiminnallisuus ilman rajapintaa

    • käyttöön integrointialustalla "sopivasta kohdasta"?

    • adapteritoteutus, sovelluksen muokkaaminen?

  • tunnistetut palvelutarpeet, roadmap-dokumentit


"Käytettävissä olevat palvelut"? - tilanne

  • tuotteeseen toteutettu "palvelurajapinta"

    • Web service-rajapinta

      • edelleen tarvitaan WS-I ja yhdenmukainen arkkitehtuuri

    • http/XML ja (HL7-)viestirajapinnat

  • saatavilla oleva rajapintamäärittely

    • rajapintastandardit

      • teknisellä tai "vain toiminnallisella" tasolla määritellyt

    • saatavilla olevat WSDL-kuvaukset (toimittajat, käyttäjät)

  • tuotteesta löytyvä "valmis" toiminnallisuus ilman rajapintaa

    • käyttöön integrointialustalla "sopivasta kohdasta"?

    • adapteritoteutus, sovelluksen muokkaaminen?

  • tunnistetut palvelutarpeet, roadmap-dokumentit

PALJON

SOVELLUKSIA,

TARVITAAN

INTEGROINTI

/ SOVITUSTYÖTÄ

VÄHÄN

SOVELLUKSIA,

PLUG AND PLAY


Operational systems-esimerkki (HUS)

[Mykkänen, Korpela, Ripatti, Rannanheimo, Sorri. Local, Regional and National Interoperability in Hospital-Level Systems Architecture. Meth Inf Med, 2007, under revision]


Sovellustasolta toimintojen tunnistaminen: Musti/Upo

UPO

Henkilötietojen

käsittely

Lähetetietojen

käsittely

Ajanvaraus

Työohjelmat

Ajan-varaus

Vastaan-otto-aikojen siirto

Potilaan tiedot

Lähet-teen muut tiedot

Resurssit

mm. huone

laite

henkilö

Kalenteri

mm. kuukausi, viikko, päivä, klo

Potilaan vallinta

entisillä

tiedoilla

haku

Uuden potilaan valinta

Uuden potilaan tietojen kirjaaminen

Potilaan tietojen katselu

Entisten muutos-ten käsittely

Potilaan tietojen muutta-minen

Ennakkoajanvaraus potilaskohtainen kiinnittäminen

Vapaat ajat

Lisäksi muita toimintoja yhteensä 13 kohtaa

Ajan sito-minen / vapaut-taminen


Viitearkkitehtuurin soveltaminen: presentation

-lyhyesti


Käyttöliittymät ja SOA: vaihtoehtoja

  • suosikkivastaus: portaali (usein integroituna ESB-infrastruktuuriin)

    • uusissa sovelluksissa usein suositeltavaa?

    • portletit tarjolla "pikkukäyttöliittymiksi" palveluihin

  • vanhat järjestelmät

    • sellaisenaan? muutoksia / hyötyjä vain muualle kuin sinne, missä järjestelmää käytetään?

    • muokattuna? mitä ulkoiseen prosessilogiikkaan, mitä jää järjestelmään?

    • integrointi mahdollista myös käyttöliittymätasolla - ohittaa SOA-palvelut

  • asiainhallintajärjestelmä yhdistettynä prosessin ohjaukseen?

  • siirtyminen "yhteisestä työasemasta" henkilökohtaiseen käyttöliittymään (tilanteeseen sopivalla laitteella)?

    • työpöydän hallinta - edelleen useita sovelluksia yhtä aikaa?

    • mistä voi ostaa sovelluspalveluja sovellusten sijaan?


Yhteenveto + jatkotyö


Jatkotarkennukset ja keskeisimmät tarpeet?

  • tässä esitetyn viitearkkitehtuurin pohjalta tarkennus osapuolten käytännön tarpeisiin?

    • arkkitehtuuripelisääntöjen tarkennus

    • esimerkkien kautta palvelu- ja alustamäärittelyjen tarkennus

  • eteneminen prosessimäärittelyistä palvelujen tunnistamiseen ja määrittelyyn?

    • siirtyminen tietokantakeskeisestä ratkaisujen tuottamisesta tehtäväpohjaiseen?

    • riittävä tarkkuustaso, tasapaino työnkulun, tiedonkulun, työtoiminnan välillä?

    • näkökulmat: käyttäjä, tietohallinto, sovellustuottaja, integraattori

    • sovelluspalvelujen luokittelun toimivuus

    • ESB-ratkaisujen vaikutus määrittelytasoon (toiminnallinen / tekninen)

    • palvelulistaus esimerkkikohtaisesti, top-down ja bottom-up

    • palvelukohtaisesti hankinta- ja toteutusvaihtoehdot

  • migraatio, nyky- ja tavoitetilakuvaukset

  • moniin osioihin paljon valmista pohjaa!


Kiitos

  • SerAPI-osapuolet: TEKES, Medici Data Oy, Datawell Oy, Fujitsu Services Oy, Pohjois-Savon shp, WM-data Oy, Commit; Oy, Intersystems B.V. Finland, Mediconsult Oy, Microsoft Oy, Oracle Finland Oy, Satakunnan shp, Bea Systems Oy, Helsingin ja Uudenmaan shp, Kuopion kaupunki, Suomalainen Lääkäriseura Duodecim, Mawell Oy, Oy Prowellness Ltd.

vs.

www.centek.fi/serapi/


  • Login