Palveluarkkitehtuurin soveltaminen terveydenhuollossa. Osa 2: prosessien ja palvelujen määrittely ja suunnittelu

Transkriptio

1 Palveluarkkitehtuurin soveltaminen terveydenhuollossa Osa 2: prosessien ja palvelujen määrittely ja suunnittelu Tekijät Päiväys Juha Mykkänen, Heli Luostarinen, Assi Pöyhölä, Esa Paakkanen, Marko Suhonen, Liisa Klemola, Annamari Riekkinen, Mika Tuomainen, Pasi Riikonen, Ritva Silvennoinen

2 Palveluarkkitehtuurin soveltaminen terveydenhuollossa Sisällysluettelo 1 Johdanto Näkökulmat palveluarkkitehtuuriin SerAPI-hankkeessa Prosessitaso Sovellustaso Tekniikkataso Dokumentin eri osien sisältö Palvelupohjainen kehittämisprosessi Alkuselvitys Analysointivaihe Suunnitteluvaihe Toteutus- ja testausvaihe Paketointi-, käyttöönotto- ja suoritusvaihe Viitearkkitehtuuri ja sovelluspalvelujen mallit Viitearkkitehtuuri Sovelluspalvelut (services) Palvelujen tunnistaminen suunnat: olemassa olevat järjestelmät ja prosessimäärittelyt Palvelujen luokittelu Palvelujen dokumentointi ja kuvaaminen Palvelujen toteutus- ja hankintavaihtoehdot (enterprise components) Käytettävissä olevien palvelujen tunnistaminen Sovelluspalvelujen hankinta ja kehittäminen Palvelujen tuottaminen taustajärjestelmistä (operational systems) Prosessikerros Ihmistä tukeva järjestelmä ja ihmisen tukema prosessi Vaihtoehtoja prosessikerroksen toteutukseen Käyttöliittymät Integrointiarkkitehtuuri Palvelujen ja järjestelmien liitäntätavat Palvelualustat Muita esimerkkejä terveydenhuollon palvelupohjaisesta integrointiarkkitehtuurista

3 Osa 2: prosessien ja palvelujen määrittely ja suunnittelu 4 Esimerkit prosessimallinnuksesta ja sovelluspalvelujen tunnistamisesta Prosessien mallinnus Prosessikuvausten tasot Prosessikuvausten tuottamisen vaiheet Prosessien kuvaustavat Endoskopian mallinnusesimerkki Endoskopian yleiskuva Endoskopian prosessitaso Prosessien toimintotaso Tekojen ja välineiden taso Palvelukuvaukset Lähetteen tietomäärittely Käytössä olevat tietojärjestelmät Äitiyshuollon mallinnusesimerkki Äitiyshuollon yleiskuva Äitiyspoliklinikan mallinnusesimerkki Synnytys-hoitokokonaisuus (erikoissairaanhoito) Äitiyshuollon prosesseihin liittyvät tietojärjestelmät Yhteenvetoa endoskopia- ja äitiyshuolto -esimerkeistä Mallikeskeisten kehitysmenetelmien arviointi Model-Driven Architecture (MDA) Prosessien mallinnus BPMN- ja BPEL-kielten avulla HL7 Development Framework Arvioinnin tulokset Yhteenveto Palveluarkkitehtuurin kehitystilanne terveydenhuollossa Palveluarkkitehtuurin ja prosessimallinnuksen vaikutukset kehittämistyöhön Jatkotyön tarpeet

4 Palveluarkkitehtuurin soveltaminen terveydenhuollossa Esipuhe Palveluarkkitehtuurin potentiaaliset hyödyt ovat houkuttelevia ja niiden saavuttaminen kiinnostaa. Monissa organisaatioissa ja niiden välisissä hankkeissa, julkisessa hallinnossa ja tuotteiden sisäisissä malleissa harkitaan tai kokeillaan sovelluspalveluja ja palvelurajapintoja. Prosesseja halutaan mallintaa, kehittää ja automatisoida. Mutta kuinka ratkaisut tulisi mallintaa ja määritellä? Mitkä ovat palvelupohjaisen arkkitehtuurin perusosat? Kuinka prosessimallinnuksesta siirrytään palvelupohjaisten ratkaisujen määrittelyyn ja toteuttamiseen? Miten huomioidaan olemassa olevat sovellukset? Millä tavalla ja kuinka tarkasti prosesseja on kuvattava? Tähän dokumenttiin on koottu SerAPI-hankkeen ( ) aikana tehtyjä selvityksiä, työpapereita ja esimerkkejä palvelupohjaisten ratkaisujen kehittämisen lähestymistavasta, kehittämisprosessista, viitearkkitehtuurista ja sen eri pääosista sekä prosessien mallinnuksesta. Lisäksi dokumentti sisältää esimerkkikuvauksia ja prosessimalleja kahden kohdealueen prosessilähtöisestä mallinnuksesta ja tuloksia useista hankkeen työpajoista. Osa esimerkkikuvauksista on ZipIT-hankkeen työntekijöiden kanssa yhteistyössä tuotettua materiaalia. Dokumenttiin on myös liitetty poimintoja muutamista SerAPI-hankkeen kansainvälisesti julkaisuista artikkeleista ja kansainvälisestä yhteistyöstä Healthcare Services Specification Project-hankkeen kehittämismallin ja eri dokumenttimallien tuottamisessa. Monet näistä seikoista liittyvät palvelupohjaisten ratkaisujen suunnitteluun, arkkitehtuurin kehittämiseen, prosessien ja sovelluspalvelujen mallintamiseen ja määrittelyyn sekä eri sovellusten ja palvelujen integrointiin. Dokumentti on toinen osa "SOA- ja web services -soveltamisoppaasta", joka SerAPI-hankkeen peruslähestymistapaa mukaillen sisältää kolme osaa. Ensimmäiseen osaan on koottu erityisesti tavoiteltuihin hyötyihin, arviointiin ja käyttäjäorganisaation tarve- ja hankintanäkökulmiin liittyviä seikkoja. Toinen osa sisältää kokoelman palvelupohjaisten ratkaisujen ja arkkitehtuurien kehittämiseen liittyviä malleja ja esimerkkejä. Kolmas osa koostuu useista erillisistä tuotoksista ja sisältää etenkin web-sovelluspalvelutekniikoiden teknisiin soveltamistapoihin liittyviä selvityksiä, kokeiluja ja suosituksia. Työ liittyy SerAPI-hankkeeseen (Palveluarkkitehtuuri ja Web-sovelluspalvelut Terveydenhuollon Ohjelmistotuotannossa ja -integraatiossa), jossa tutkitaan ja kehitetään web-sovelluspalvelujen ja palvelupohjaisen arkkitehtuurin hyödyntämistä terveydenhuollon tietojärjestelmätarpeisiin ja sovellusintegraatioon ja uusiin sekä olemassa oleviin ohjelmistotuotteisiin. Hanketta ovat rahoittaneet Tekes (päätös nrot 40437/04, 40353/05, 40251/06) sekä 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, Softera ratkaisut Oy, Helsingin ja Uudenmaan sairaanhoitopiiri, Kuopion kaupunki, Kustannus Oy Duodecim ja Mawell Oy. Tekijät kiittävät kaikkia oppaan aihepiiriä kommentoineita osapuolia sekä erityisesti Prosessit ja palvelut -mallintamiskohteiden työstöön ja työpajoihin osallistuneita. 4

5 Osa 2: prosessien ja palvelujen määrittely ja suunnittelu 1 Johdanto Terveydenhuollossa käytetyissä sovelluksissa samoja tietoja syötetään ja kopioidaan käsin tai ylläpidetään useisiin eri järjestelmiin. Käyttäjien uusiin tarpeisiin vastaaminen ohjelmistoissa vie kauan aikaa, koska ohjelmistojen versiokehityssyklit ovat pitkiä, ja muutos- ja lisäyspyyntöjä on paljon. Järjestelmien käyttöönottoprojektit aiheuttavat häiriöitä terveyspalvelujen tuotannossa ja monet käyttöönotot viivästyvät tarvittavien korjausten tai varmistusten vuoksi. Tutkimus- ja kehityshankkeissa tuotetaan käyttökelpoisia IT-ratkaisuja erityistilanteisiin, mutta ratkaisuja ei saada liitettyä olemassa oleviin järjestelmiin. Terveydenhuollon organisaatioissa mallinnetaan hoidon ja hallinnon prosesseja, mutta tietojärjestelmät eivät taivu tukemaan määriteltyä tavoitetilaa. Edellä mainitut ovat hieman kärjistettyjä ja yleistettyjä esimerkkejä arkipäiväisistä ongelmista terveydenhuollon tietojärjestelmien kehittämisessä ja käytössä. Näihin ongelmiin on haettu ratkaisuja muun muassa käyttäjien koulutuksen, hankintakäytäntöjen kehittämisen ja uudenlaisten ratkaisujen kehittämistapojen kautta. Lisäksi tietojärjestelmätuotteita pyritään kehittämään siten, että edellä kuvatut ongelmat vähenevät. Yksi lupaavimmista uusista lähestymistavoista tämäntyyppisten ongelmien helpottamiseen on palveluarkkitehtuuri. Ympäristössä, jossa sekä toiminta että tietotekniikka ovat monimutkaisia, tarvitaan rakenteellisia ratkaisuja, jotka tarjoavat mahdollisuuden reagoida sujuvasti muuttuviin tarpeisiin ja toimintaympäristöön sekä uusiin hoito- ja tutkimusmuotoihin. Samoin tarvitaan kehittämismalleja, jotka lähentävät tietotekniikan kehittämistä toiminnan kehittämiseen ja piilottavat kehittämisen tavoitteiden kannalta epäolennaisia yksityiskohtia mahdollistaen ratkaisujen sujuvan määrittelyn ja toteutuksen. Samalla ei kuitenkaan voida heittää pois jo kehitettyjä ja hankittuja ratkaisuja, vaan lähestymistavan on tuettava vähittäistä siirtymistä kohti uutta ympäristöä ja valmiiden ratkaisujen uudelleenkäyttöä soveltuvin osin. Palveluarkkitehtuurin soveltamisella pyritään saavuttamaan monia yllä oleviin haasteisiin vastaavia tehokkuus-, liitettävyys- ja uudelleenkäyttöhyötyjä, joita on käsitelty mm. tämän oppaan osassa 1 "Palveluarkkitehtuurin soveltaminen terveydenhuollossa - Osa 1: Hyödyt, kustannukset, arviointi ja hankinnat". Hyötyjen saavuttaminen vaatii kuitenkin järjestelmällistä lähestymistapaa. Palveluarkkitehtuurissa on runsaasti erilaisia elementtejä, joiden määrittelyä ja toteuttamista varten on järkevää tarkastella kerrallaan tiettyä osaa monimutkaisesta järjestelmä- ja arkkitehtuurikokonaisuudesta. Järkevä kokonaisuuden osiin jakaminen esimerkiksi viitearkkitehtuurien avulla auttaa ratkaisujen tarkentamisessa, mutta myös kokonaiskuvan säilyttämisessä. Lisäksi on otettava huomioon arkkitehtuurin ja sen osien elinkaari: esimerkiksi sovelluspalveluja määritellään ja käsitellään hyvin eri tavoin riippuen siitä, ollaanko kuvaamassa sovellusaluetta, tutkimassa olemassa olevien sovellusten ja komponenttien uudelleenkäyttöä, määrittelemässä uusia palveluista koostettuja sovelluksia tai tarkkailemassa prosessien ja palvelujen käyttöastetta ja toimivuutta. Palveluarkkitehtuurin suunnittelussa on korostettu myös prosessien mallintamista ja kuvaamista siten, että ratkaisut ja sovelluspalvelut palvelevat prosessien ja toiminnan kehittämistä. Tämä vaatii kuvaus- ja mallinnustapoja, joilla pystytään kuvaamaan tarvittavalla tarkkuustasolla kohdealueen toimintaa ja prosesseja sekä liittämään niiden tietoteknisiä ominaisuuksia uudelleenkäytettäviin sovelluspalveluihin. SerAPI-hankkeessa monet soveltamiskohteet ovat keskittyneet selkeisiin tunnistettuihin rajapintatarpeisiin, joissa lähtökohtana on ollut selvä sovellusten välinen rajapinta, joka palvelee tiettyä pientä osaa monissa eri prosesseissa tai tukee käyttäjiä ja tietohallintoa käyttötilanteen tiedon tarpeissa tai päällekkäisyyksien vähentämisessä (esim. ajanvaraus, potilasryhmittelyt, koodistorajapinnat, kliininen päätöksenteon tuki) (ks. Näissä soveltamiskohteissa ei kuitenkaan ole päästy kuvaamaan laajemmin kohdealueen prosesseja tai tutkimaan niiden toteuttamista toisiinsa liitettävien sovelluspalvelujen avulla. Vuonna 2006 hankkeessa käynnistettiin Prosessit ja palvelut - soveltamiskohde, jossa kuvattiin valituilla kohdealueilla esimerkkejä prosessien mallinnuksesta ja 5

6 Palveluarkkitehtuurin soveltaminen terveydenhuollossa määrittelystä sekä sovelluspalvelujen tunnistamisesta ja määrittelyistä prosessikuvausten pohjalta. Tätä varten selvitettiin ja kehitettiin myös monia malleja viitearkkitehtuuria, palvelupohjaista kehitysprosessia ja prosessien kuvaamista varten. Tämä dokumentti kuvaa monia näistä malleista. Kohdealueiden valinta perustui hankkeen osapuolten ajankohtaisiin kehityskohteisiin. Dokumentissa kuvataan järjestelmällisiä lähestymistapoja palveluarkkitehtuurin määrittelyyn ja hyödyntämiseen sekä sen liittämiseen prosessien mallinnukseen ja järjestelmien integrointiin. Esitetyt lähestymistavat perustuvat valmiisiin malleihin sekä tekijöiden työhön palvelu- ja komponenttipohjaisten ratkaisujen, rajapintojen ja standardien kehittämisessä Suomessa ja kansainvälisesti, sekä aiemmin tuotettuun materiaaliin. (web-sovelluspalvelujen suunnittelusta, standardien arvioinnista ja valinnasta, integrointiratkaisujen määrittelystä, palveluarkkitehtuurista, sillä tavoitelluista hyödyistä sekä hyötyjen arvioinnista 1 ). Esitettyjä malleja täydennetään ja sovelletaan eri tavoin, ja niitä voi yhdistää erilaisiin määrittely- ja toteutusmenetelmiin. Mallit nojautuvat suurilta osin valmiiseen tutkimusryhmän ja osapuolten materiaaliin, mutta ei mihinkään yksittäiseen ratkaisumalliin tai teknologia-alustaan. Malleja on sovellettu erityisesti SerAPI-hankkeen Prosessit ja palvelut -soveltamiskohteen yhteydessä, ja monet dokumentissa kuvatuista malleista on valittu SerAPI-hankkeen työpajojen tai kommentointikierrosten yhteydessä. Esitettyjä malleja on mahdollista täydentää ja soveltaa eri tavoin, ja niitä voi yhdistää erilaisiin määrittely- ja toteutusmenetelmiin. 1.1 Näkökulmat palveluarkkitehtuuriin SerAPI-hankkeessa SerAPI-hankkeessa tutkitaan palvelupohjaista lähestymistapaa terveydenhuollon ohjelmistokehityksessä ja -integraatiossa. Palvelupohjaisuus ja palvelupohjainen arkkitehtuuri eivät tarkoita ainoastaan synkronista pyyntö-vastaus periaatteella tapahtuvaa, web-sovelluspalvelutekniikoilla toteutettavaa kommunikointia sovelluspalvelujen välillä, vaan sillä viitataan lähestymistapaan niin palvelujen määrittelyssä, suunnittelussa, toteutuksessa ja käyttöönotossa kuin ylläpidossakin käytettävien tekniikoiden ja menetelmien osalta. Näin määriteltynä palveluarkkitehtuuri sisältää siis paljon muutakin kuin web-palveluina toteutettavat sovelluspalvelut. Uusien tekniikoiden valinta ja soveltaminen terveydenhuollon toimintaympäristössä vaatii tiukan teknisen tarkastelun sijaan lähestymistapaa, jossa toiminnan vaatimukset sekä sovellusten ja tuotteiden näkökulma ohjaavat teknisiä ratkaisuja. SerAPI-hankkeessa palveluarkkitehtuuria tarkastellaan Gartnerin esittämistä palvelun tarjoajan, palvelun hyödyntäjän, palvelujen tuotannon ja palvelujen hallinnan näkökulmista (Smith 2002). Tässä luokittelussa käytetyn teknisen (platform) tarkastelun lisäksi samaa luokitusta voidaan käyttää palveluarkkitehtuuriin osallistuvien sovellusten ja tuotteiden (application) ja sovellusten tukemien toimintaprosessien (process) näkökulmasta. Näiden näkökulmien vaatimukset vaikuttavat prosesseihin, sovelluksiin ja tarvittavaan tekniseen alustaan (Mykkänen ym. 2007a; kuva 1). Lisäksi vaatimukset painottuvat eri tavoin riippuen siitä, tarkastellaanko organisaation sisäistä vai organisaatioiden välistä palveluarkkitehtuuriratkaisua. 1 Ks. (Mykkänen ym. 2004; Riekkinen 2005; Honey ym. 2006a, Mykkänen ym. 2007a; Mykkänen, Tuomainen 2007; Tuomainen ym. 2007). 6

7 Osa 2: prosessien ja palvelujen määrittely ja suunnittelu Kuva 1. Palvelun tarjoajan, hyödyntäjän, tuotannon ja hallinnan näkökulmat sovelluspalvelujen kehittämisessä prosessi-, sovellus- ja alustatasolla (Mykkänen ym. 2007a). Lyhyesti esitettynä palveluarkkitehtuuri linkittyy kolmeen kerrokseen prosessi-, sovellus ja tekniikka seuraavasti. Prosessinäkökulman mukaan toiminnasta ja toimintaprosesseista johdetaan toimintaa tukevien palvelujen kuvauksia ja vaatimuksia, jotka sovellusnäkökulman mukaisesti määritellään ohjelmistorajapintoina eli sovelluspalveluina. Sovelluspalvelut puolestaan suunnitellaan siten, että ne voidaan toteuttaa erilaisilla tekniikoilla ja välineillä. Toteutetut palvelut voidaan ottaa käyttöön erilaisissa ympäristöissä hyödyntäen tekniikoiden ja välineiden tarjoamia mahdollisuuksia. SerAPI-hankkeessa kootaan palveluarkkitehtuuriin liittyviä suunnittelunäkökohtia edellä esitettyjen tarkastelutasojen (prosessi, sovellus ja tekniikka) ja näkökulmien (tarjoaja, hyödyntäjä, tuotanto ja hallinta) mukaisesti. Tässä luvussa tarkastelutasot ja näkökulmat esitellään lyhyesti, ja myöhemmin SerAPI-hankkeen aikana suunnitteluperiaatteita kuvataan tarkemmalla tasolla eri tuotoksissa. Alimpien tasojen ratkaisujen tarkentamisessa tehtäviä suunnittelupäätöksiä on kuvattu tarkemmin mm. artikkelissa (Mykkänen ym. 2007a) Prosessitaso Prosessinäkökulma tarkoittaa sitä, että palvelut suunnitellaan aina toiminnan lähtökohdista, jolloin toiminnan vaatimukset otetaan paremmin huomioon myös palvelut toteuttavissa teknisissä ratkaisuissa. Prosessitasolla tarkastellaan siis kohdetoiminnan tai toimialan liiketoiminta- ja palveluprosesseja, jotka teknisestä näkökulmasta edustavat kaikkein abstrakteinta tasoa. Prosessitasolla palvelun tarjoajia ovat esimerkiksi terveydenhuollon ammattilaiset, jotka tarjoavat asiakkailleen sekä erilaisia terveyden ylläpitoon ja sairauksien hoitoon liittyviä palveluja että toisille ammattilaisille tarkoitettuja palveluja. Näin terveydenhuollon palvelujen hyödyntäjiä ovat potilaat ja toiset terveydenhuollon ammattilaiset. Palveluja tuotetaan erilaisissa terveydenhuollon prosesseissa, joista esimerkiksi potilaanohjaus on eräs keskeinen prosessi. Lisäksi tarvitaan erilaisia perustoimintoja tukevia prosesseja, kuten ajanvaraus tai laskutus. Nämä tukiprosessit tarjoavat palveluja perusprosesseille, jolloin tästäkin kokonaisuudesta voidaan erottaa palvelujen tarjoaja (tukiprosessi) 7

8 Palveluarkkitehtuurin soveltaminen terveydenhuollossa hyödyntäjä (perusprosessi) tuotanto (tukiprosessi) -näkökulmat. Mikään näistä palvelujen tarjoaminen, hyödyntäminen tai tuottaminen ei voi kuitenkaan toteutua pitkällä aikavälillä ilman palvelujen hallintaa, eli toiminnan seurantaa ja ohjausta. Tuottamisessa välineinä käytetään myös ohjelmistoja ja sovelluksia, jotka voivat sisältää sovelluspalveluita. Sovelluspalvelujen tuotannossa prosessilähestymistapa tarkoittaa sitä, että toiminnasta, toimintaprosesseista ja olemassa olevista sovelluksista määritellään ja dokumentoidaan toimintoja ja vaatimuksia edellä mainittujen neljän näkökulman (tarjoaja, hyödyntäjä, tuotanto ja hallinta) mukaisesti. Prosessitasolla palvelujen määrittelyssä ja suunnittelussa on otettava huomioon esimerkiksi toimialakohtaiset vaatimukset, periaatteet ja rajoitukset. Esimerkiksi terveydenhuollon hoitoprotokollat, toiminnassa ja järjestelmissä tarvittavat tietosisällöt ja niihin liittyvät turvallisuusvaatimukset jne. toiminnan ja työn luonne (tehtävät, ympäristö, työnkulut, työvälineet). Esimerkiksi terveydenhuollossa hallinnollinen työ, hoitotyö ja lääketieteellinen hoito. prosessien ja toimintatapojen kehittämisen näkökulma. Esimerkiksi terveydenhuollossa organisaatioiden sisäisten toimintaprosessien ja organisaatioiden välisten saumattomien hoitoketjujen kehittäminen. erilaiset mittaamiseen ja seurantaan liittyvät tekijät. Esimerkiksi lainsäädännön vaatimien erilaisten raporttien ja tilastojen tuottaminen, toiminnan tehokkuuden mittaaminen ja seuraaminen jne. palvelujen ylläpidettävyys muutostenhallinnan ja joustavuuden (mukautettavuuden) kannalta. Esimerkiksi toimintojen koko eli karkeajakoisuus tietojärjestelmän osien vaihdettavuuden ja itsenäisen kehittämisen kannalta. toimintojen yhdistäminen (ja uudelleenyhdistäminen) tarkoituksenmukaisiksi ja tehokkaiksi prosesseiksi (orkestrointi). Esimerkiksi, kuinka samoja palveluja voidaan hyödyntää erilaisissa prosesseissa Sovellustaso Toimintaprosessitasolla palvelujen tuottamisessa, tarjoamisessa, hyödyntämisessä ja hallinnassa käytetään paljon tietojärjestelmiä ja sovelluksia, mikä palvelukeskeisessä suunnittelulähestymistavassa linkittää prosessitason sovellustasoon. Prosessitason palvelun tarjoajat, esimerkiksi terveydenhuollon ammattilaiset, käyttävät sovelluksia apuna tuottaessaan palveluja sekä asiakkaille että toisille terveydenhuollon ammattilaisille. Tietojärjestelmiä tarvitaan myös toiminnan ohjauksessa (logistiikka, laskutus ym.), seurannassa ja raportoinnissa. Lisäksi nykyään myös potilaat hyödyntävät yhä enemmän tietojärjestelmiä ja internetiä omaan terveyteen tai sairauden hoitoon liittyvissä asioissa. Osa prosessitason palveluista toteutetaan tai niitä tuetaan sovellustason palvelujen avulla. Tavoitteena on yhdistää organisaation tai organisaatioiden prosesseja lisäarvon saavuttamiseksi. Usein lisäarvoa saavutetaan tiedon liikkuvuuden ja prosessien hallinnan parantumisella sekä manuaalisten prosessien automatisoinnilla. Prosessin määrittelyssä sovitaan eri toimintojen loogisesta järjestyksestä sekä muodostetaan säännöt, joilla toiminnoista toiseen siirrytään. Samoin määritellään, mitä tietoa ja missä muodossa siirtyy eri toimintojen välillä. (Karvinen ym. 2004) Sovellustasolla palvelujen tarjoajia ovat ohjelmistot ja sovellukset. Palvelujen hyödyntäjiä ovat toiset sovellukset sekä käyttäjät, jotka konkreettisesti käyttävät sovelluksia eri organisaatioissa. Palveluarkkitehtuurin kannalta sovellusnäkökulma tarkoittaa siis ennen kaikkea sitä, että sovellukset ja 8

9 Osa 2: prosessien ja palvelujen määrittely ja suunnittelu sovelluskomponentit itse toimivat palvelujen tarjoajina ja hyödyntäjinä. Hyödyntäjä-sovellusten käyttäjien ja sovelluksia hankkivien organisaatioiden tarpeet ohjaavat sitä, millaisia ohjelmistopalveluita hankitaan ja kehitetään. Tässä yhteydessä hallinta tarkoittaa sovellusten ja sovelluspalvelujen ylläpitoa ja hallintaa. Tuotanto puolestaan viittaa sovelluskehityksessä ja -integraatiossa käytettäviin välineisiin, tekniikoihin ja menetelmiin. Sovellustasolla sovelluspalvelujen suunnittelussa korostuvat nimenomaan yksiselitteisten, toteutustekniikoista riippumattomien palvelurajapintojen määrittely sekä palvelujen keskinäiset löyhät kytkennät. Tämän tason suunnittelupäätöksillä on suora yhteys siihen, miten uudelleenkäytettäviä ja hallittavia palveluista tulee. Palvelupohjaisessa integroinnissa sovellukset jakavat yhteistä toimintalogiikkaa, metodeja tai sovelluspalveluita (Karvinen ym. 2004). Sovellusintegraation näkökulmasta yksi SOA:n merkittävistä eduista on se, että olemassa olevien sovellusten tietoja ja piirteitä voidaan hyödyntää arkkitehtuurin toteutuksessa. Sovellusten tarjoamaa toiminnallisuutta ja tietoja saadaan käyttöön määrittämällä, toteuttamalla ja julkaisemalla palvelurajapinnat olemassa oleviin sovelluksiin. Nykyään monet terveydenhuollon integrointitarpeet liittyvät tiedon vaihtoon eri järjestelmien välillä. Tietojen integrointi voi olla yksinkertaista tiedonvaihtoa viestien tai ohjelmointirajapintojen välityksellä, mutta siihen voi liittyä myös monimutkaisempaa tiedon prosessointia. Esimerkkinä suhteellisen yksinkertaisesta palvelusta on käyttäjätietojen hakuun määritelty ydinpalvelurajapinta. Sen sijaan esimerkiksi päätöksentuen toteuttamiseksi tarvitaan monimutkaisempaa tietojen siirtoa ja yhdistämistä. Paitsi sovelluspalvelujen määrittelyyn myös sovellusten koostamiseen ja kokonaisarkkitehtuurin määrittelyyn liittyy erilaisia suunnittelupäätöksiä, jotka on otettava huomioon niin, että käytettävyyteen, turvallisuuteen, testaukseen, ylläpitoon jne. liittyvät vaatimukset tulevat huomioitua. Esimerkiksi sovellusten käyttäjien näkökulmasta palvelutoteutukset on piilotettava siten, että järjestelmien käyttö muodostaa käyttäjän kannalta yhdenmukaisen kokonaisuuden. Käyttäjille näkyviä sovelluspalveluja ovat esimerkiksi kertakirjautuminen, yhtenäinen käyttöliittymä eri järjestelmien tarjoamiin palveluihin (esim. portaali), kontekstin tahdistus eri järjestelmien välillä sekä erilaiset prosessien osana käyttäjän suorittamat toiminnot Tekniikkataso Palveluarkkitehtuurille prosessi- ja sovellustasoilla määritellyt, sovelluspalvelujen tuotannon, hallinnan, tarjonnan ja hyödyntämisen vaatimukset edellyttävät sopivia tekniikoita ja välineitä. Erityisesti web-sovelluspalvelutekniikoiden kehittyminen on mahdollistanut palveluarkkitehtuurilähestymistavan yleistymisen. Web-sovelluspalvelutekniikoiden ansiosta palveluja voidaan tuottaa, tarjota ja hyödyntää standardilla tavalla riippumatta siitä, minkälaisilla tekniikoilla palvelut on toteutettu sisäisesti. Web-sovelluspalvelutekniikat tarjoavat eri sovelluksille ja sovelluspalveluille standardin tavan kommunikoida keskenään ja tukevat karkeajakoisuudeltaan korkeampien abstraktiotasojen ohjelmistokomponenttien toteuttamista paremmin kuin perinteiset komponenttimallit. Web-sovelluspalvelujen avulla saavutetaan myös alustariippumattomuus, koska palvelujen kuvaamiseen käytetty WSDL-kieli sekä viestien välittämiseen käytetyt SOAP- ja http-protokollat ovat alustariippumattomia. Merkittävä etu tuottamisen ja käyttöönoton kannalta on se, että palveluarkkitehtuurissa pystytään hyödyntämään olemassa olevaa sovellusinfrastruktuuria. Lisäksi avointen tekniikoiden ja standardien ansiosta eri tekniikoilla toteutettujen järjestelmien yhteensovittaminen helpottuu. 9

10 Palveluarkkitehtuurin soveltaminen terveydenhuollossa Teknisellä tasolla palvelun tarjoajan, hyödyntäjän, tuotannon ja hallinnan näkökulmat on kuvattu Nelialustamallissa (Four-Platform Framework) (Smith 2002). Viitekehys tarjoaa mallin websovelluspalvelujen arkkitehtuurille. Mallissa palvelujen tuotantoalusta (production platform) sisältää välineet ja toimintamallit web-sovelluspalvelurajapintojen toteuttamiseksi olemassa oleviin ja uusiin sovelluksiin. Sovelluskehittäjät siis tuottavat palvelurajapintoja, joista toiset kehittäjät myös koostavat toimintaa tukevia palveluja. Palvelujen tarjoaja vastaa palvelujen isännöinnistä ja saatavuudesta. Tarjoajan alusta (provider platform) voi sisältää muun muassa sovelluspalvelimet, integrointialustat sekä tietokantaohjelmiston ja tietokannan hallintajärjestelmät. Mallin mukaan palvelujen tarjoajan näkökulma edustaa suurta osaa web-sovelluspalvelujen käytössä tarvittavasta teknisestä infrastruktuurista. Palvelujen hallinnan näkökulmasta alusta (management platform) sisältää välineet ja ratkaisut, joiden avulla web-sovelluspalvelujen suorituksenaikaista käyttöä hallinnoidaan, ohjataan ja kontrolloidaan. Palvelun hyödyntäjien alustat (consumer platform) sisältävät tekniikat, joilla tuottajien ja tarjoajien sovelluspalveluja saadaan käyttöön. Hyödyntäjien alustat voivat olla hyvin erilaisia, esimerkiksi portaaliohjelmistoja, ohjelmistokehitysvälineitä tai sovellusadaptereja, ja niissä on voitu käyttää hyvin erilaisia toteutustekniikoita (.NET, Java, perinnejärjestelmien tekniikat jne.). (Smith 2002; Schmelzer & Bloomberg 2003). Smithin lähestymistapa ei kuitenkaan täysin vastaa tämän hetkistä tilannetta esimerkiksi siinä, miten yritykset toteuttavat ja ottavat käyttöön web-sovelluspalveluja. Todellisuudessa teknologiaalustoissa nämä eri näkökulmat nivoutuvat tiiviisti toisiinsa, vaikka eri näkökulmia painottavia välineitä voisikin hankkia erikseen. Toiseksi, vaikka luokittelu tarjoaa web-sovelluspalvelujen ja palveluarkkitehtuurinkin kannalta keskeiset näkökulmat, se ei kuitenkaan kata kaikkia toteutuksen kannalta tärkeitä piirteitä, kuten turvallisuus. Nykyisin teknologiatoimittajien infrastruktuuriratkaisut, kuten integrointialustat ja/tai sovelluspalvelimet, tukevat laajasti tällaisia piirteitä. Lisäksi integrointiratkaisut sisältävät mekanismeja prosessien yhdistämiseen ja hallintaan. Teknologiatoimittajat pyrkivätkin kokonaisvaltaisiin, palvelukeskeistä arkkitehtuuria tukeviin ratkaisuihin omissa tuotteissaan (ks. esim. luku 4). Myös palvelujen toteuttajat ja hyödyntäjät valitsevat mieluummin kokonaisratkaisuja kuin koostavat niitä osista. (Schmelzer & Bloomberg 2003) Vaikka web services -tekniikat mahdollistavat alustariippumattomuuden sovelluspalvelujen tarjoamisessa ja hyödyntämisessä, ei palveluarkkitehtuuria voida tai kannattaisi toteuttaa täysin teknologia- tai toimittajariippumattomasti. Tekninen infrastruktuuri tarjoaa valmiina paljon merkittäviä esimerkiksi turvallisuuteen ja palvelujen hallintaan liittyviä piirteitä, jotka voidaan menettää suunnittelemalla liian avoimia ratkaisuja. Lisäksi palvelujen yhdistäminen toimintaprosesseiksi vaatii sovitut standardit ja välineet. Välinetasolla kuitenkin eri teknologiat ja eri teknologiatoimittajien ratkaisut ja työkalut tukevat monipuolisesti palvelukeskeisen arkkitehtuurin perusratkaisuja. 1.2 Dokumentin eri osien sisältö Tämän dokumentin luvussa 2 käsitellään palvelupohjaisen kehitysprosessin käyttöä. Luvussa 3 esitellään käyttökelpoisen SOA-viitearkkitehtuurin eri tasot ja sovelluspalvelujen mallit. Luku 4 keskittyy prosessimallinnukseen esimerkkien kautta. Esimerkeissä on hyödynnetty luvun alussa kuvattua prosessienmallinnusprosessia ja prosessikuvausten tasoja. Luku 5 sisältää mallikeskeisten kehitysmenetelmien arvioinnin. Luvussa 6 käsitellään palveluarkkitehtuurin kehitystilannetta terveydenhuollossa, vedetään yhteen tämän dokumentin aihealueen osalta kehittämistyöhön liittyviä tuloksia, ja tunnistetaan palveluarkkitehtuurin kehittämiseen liittyviä jatkotyön tarpeita. 10

11 Osa 2: prosessien ja palvelujen määrittely ja suunnittelu 2 Palvelupohjainen kehittämisprosessi Palveluarkkitehtuurin, sovelluspalvelujen ja palvelupohjaisten sovellusten toteuttamisessa tarvitaan kehittämisprosesseja tehtävän työn ohjaamiseen. Viitearkkitehtuuri puolestaan tarjoaa jäsennetyn mallin kaikista kehittämistyössä huomioon otettavista asioista. Voidaan siis ajatella, että viitearkkitehtuuri toimii muistilistana kehittämistyössä huomioitavista näkökulmista ja yksityiskohdista, ja prosessi vaiheistaa sen, mitä näkökulmia milloinkin tarkastellaan. Viitearkkitehtuuria on kuvattu tarkemmin luvussa 3. Tässä luvussa käsitellään sovelluspalveluita ja palvelupohjaisia sovelluksia niiden kehittämisprosessien näkökulmasta. Esitetty kehittämisprosessi perustuu valmiiseen malliin (Papazoglou & van den Heuvel 2006), johon on yhdistetty näkökulmia seuraavista malleista: Service-oriented modeling and architecture (SOMA) -kehittämisprosessi (Arsanjani 2004) sovellusintegraatioratkaisujen vaiheittainen määrittelyprosessi (Mykkänen ym. 2004). Palveluarkkitehtuurin kehittämisessä hyödynnetään usein mallipohjaisia lähestymistapoja, kuten mallikeskeinen arkkitehtuuri (MDA) ja prosessimallinnus. SerAPI-hankkeessa tehdyn mallipohjaisten lähestymistapojen vertailun tulokset on vedetty yhteen tämän dokumentin luvussa 5.4. Tässä luvussa esitellään palvelupohjaisen kehittämisprosessin vaiheet. Prosessi käsittää kahdeksan varsinaiseen kehittämis- ja ylläpitotyöhön liittyvää vaihetta ja alustavan suunnitteluvaiheen (ks. kuva 2). Prosessien vaiheet voidaan organisoida eri tavoin siten, että vaiheisiin sisältyvät toiminnot sekä niiden esiintymisjärjestys ja painotus voivat vaihdella. Esimerkiksi laadunvarmistus kuuluu tavallisesti jokaiseen kehittämisprosessin vaiheeseen testauksen eri lajien ja tarkastuskäytäntöjen Kuva 2. Palvelupohjaisen kehittämisprosessin vaiheet (Papazoglou & van den Heuvel 2006) 11

12 Palveluarkkitehtuurin soveltaminen terveydenhuollossa myötä. Myös prosessin kokonaisia vaiheita voidaan suorittaa eri järjestyksessä, esimerkiksi peräkkäin, limittäin tai iteroiden. Alkuselvitysvaiheen (planning) tarkoitus on varsinaisen kehittämistyön projektointi eli tavoitteiden asettaminen tehtävälle työlle, vaatimusten kokoaminen sekä työn organisointi ja vaiheistaminen. Analysointivaiheessa (analysis) pääpaino on kohdealueen toiminnan jäsentämisessä liiketoimintaprosesseiksi niin, että tarvittava toiminnallisuus voidaan toteuttaa palveluina. Liiketoimintaprosessilla tarkoitetaan tässä yhteydessä sovelluksen suorittamaa loogista tehtäväkokonaisuutta. Palveluiden osalta tässä vaiheessa selvitetään erilaisia vaihtoehtoja siihen, miten tarvittavat palvelut kannattaa ottaa käyttöön uudessa sovelluksessa. Esimerkiksi käytössä olevia sovelluksia analysoidaan ja tutkitaan, löytyykö niistä toivottuja ominaisuuksia tai haluttua toiminnallisuutta, mikä voitaisiin palvelutekniikoiden avulla ottaa käyttöön palveluarkkitehtuurissa. Toisaalta tässä yhteydessä päätetään myös kokonaan uusien palveluiden hankinnasta. Suunnitteluvaiheessa (design) keskitytään varsinaisiin web-sovelluspalveluihin ja sovelluksen liiketoimintaprosesseihin tarkentamalla niiden määrittelyä asteittain. Palveluiden toteutusvaiheessa (construction) web-sovelluspalvelut koodataan ja ne yhdistetään liiketoimintaprosesseiksi suunnitteluvaiheen määrittelyiden mukaisesti. Testausvaiheessa (testing) varmistetaan, että palvelut ja niistä koostetut prosessit toimivat tarkoitetulla tavalla. Paketointivaiheessa (provisioning) palvelut tuotteistetaan valitun tuotteistusmallin mukaisesti. Tuotteistukseen kuuluu esimerkiksi tarjottavien palveluiden kuvaaminen, luokittelu ja mahdollinen hinnoittelu sekä laadunhallinnan määrittäminen. Tuotteistettu palvelu julkistetaan ja tarjotaan näin käyttöönotettavaksi (deployment). Palveluiden käyttö perustuu niiden suorituksen aikaiseen sitomiseen. Näin suoritusvaiheeseen (execution) liittyy keskeisesti palveluiden ja prosessien reaaliaikainen seuranta (monitoring), jolla varmistetaan se, että mahdollisiin poikkeustilanteisiin pystytään reagoimaan nopeasti. Toinen keskeinen seurannan tehtävä on tiedon tuottaminen analysointia varten. Palvelupohjaisessa kehittämisprosessissa avainasemassa ovat palvelun käyttäjän (hyödyntäjän) ja palvelun tarjoajan näkökulmat, joihin perinteisissä kehittämisprosesseissa ei niinkään ole kiinnitetty huomiota. Perinteiset sovelluskehittämisprosessit keskittyvät enemmän kokonaisratkaisun toimittajan ja tilaajan (asiakkaan) näkökulmiin, mutta palvelupohjaisessa kehittämisprosessissa palvelun käyttäjän ja tarjoajan näkökulmat tuodaan selkeämmin esiin. Palvelun käyttäjän vastuulla on määrittää tarvitsemansa palvelut, etsiä tai tilata tarkoituksenmukaiset sovelluspalvelut ja ottaa ne käyttöön varmistuttuaan siitä, että löydetyt tai tilatut palvelut vastaavat määrittelyjä. Tarjoaja puolestaan julkaisee toteuttamansa palvelun ja pitää huolen siitä, että se vastaa niin toiminnallisuudeltaan kuin muidenkin ominaisuuksien osalta käyttäjän/käyttäjien vaatimuksia. Erityisesti kokonaisratkaisun toimittajan kannalta näkökulmat ovat keskeisessä roolissa, koska ratkaisun kehittämisprojektissa voidaan hyödyntää joko omassa organisaatiossa tai muualla jo aiemmin toteutettuja palveluita ja toteuttaa itse uusia sovelluspalveluita. WS-oppaan osassa 1 tietojärjestelmien hankintatapoja ja -prosessia koskevassa luvussa 6 kuvataan toimittajaorganisaation hyödyntäjänäkökulmaa nimenomaan käsiteltäessä rajapintojen hankintaan liittyviä asioita. Palvelupohjainen lähestymistapa perustuu prosessien tunnistamiseen, määrittelyyn ja mallinnukseen. Palvelupohjaista sovelluskehitysprosessia tukemaan onkin kehitetty erilaisia mallikeskeisiä kehitysmenetelmiä, joista muutamaa arvioidaan tarkemmin luvussa

13 Osa 2: prosessien ja palvelujen määrittely ja suunnittelu 2.1 Alkuselvitys Alkuselvitysvaiheen aikana määritellään palveluratkaisun rooli kohdeympäristössä. Keskeinen vaatimus on ymmärtää tulevan ratkaisun käyttöympäristö toimintatapoineen riittävän kattavasti niin, että toteutettava ratkaisu pystytään rajaamaan jo tässä vaiheessa mahdollisimman tarkasti. Toteutukseen on järkevä valita palvelutekniikat, jotka sopivat organisaation käyttämiin toimintamalleihin ja tekniseen ympäristöön. Alkuselvitysvaiheen tehtäviä ovat muun muassa: liiketoiminnan jäsentäminen ja analysointi mitattavissa olevien tavoitteiden avulla nykyisen teknisen ympäristön kartoittaminen tuotettavan palveluratkaisun ominaisuuksien määrittäminen ja niiden sovittaminen alustavasti olemassa oleviin toteutuksiin. Toimittajan asiantuntijoiden tehtävä on pilkkoa kohdeympäristö toiminnallisuuden kannalta sopiviin osiin ja luokitella se tarkoituksenmukaisiin ryhmiin. Osiin jaon ja luokittelun tarkoitus on se, että toiminnallisuus ja muut vaatimukset voidaan esittää sekä yksittäisten palveluiden että niistä koostettujen liiketoimintaprosessien tarjoamina toimintoina ja ominaisuuksina. Palveluratkaisun tilaajalle oma toimintaympäristö jäsentyy korkean tason liiketoimintaprosesseina, jotka todellisuudessa koostuvat yksinkertaisimmista palveluista. Tuotettavan palveluratkaisun rajauksen ja alustavan jäsentämisen lisäksi alkuselvitysvaiheen toinen keskeinen tehtävä on kehittämisprojektin toteutuksen arviointi ja suunnittelu. Tähän kuuluu esimerkiksi kustannus-hyötyanalyysin laatiminen, budjetointi sekä varsinaisen kehittämistyön vaiheistus, tehtävien suunnittelu, tuloksien määritys ja aikataulun laadinta. Sovelluspalvelujen ja palvelupohjaisen arkkitehtuurin investointien kannattavuutta ja kannattavuusmittareita käsitellään WS-oppaan 1. osan luvussa Analysointivaihe Analysointivaiheessa tarkennetaan tulevan palveluratkaisun vaatimukset. Toiminnalliset vaatimukset on alkuselvitysvaiheessa johdettu toiminnan tavoitteista ja ne esitetään siis palveluina ja prosesseina. Alkuselvitysvaiheessa luotua, nykytilannetta kuvaavaa liiketoimintaprosessimallia täydennetään niin, että siihen tulevat mukaan kaikki tällä hetkellä käytettävissä olevat palvelut ja sovellukset. Näin organisaatiolla on käytössään koko olemassa olevien potentiaalisten palveluiden valikoima, jonka pohjalta voidaan tutkia ja arvioida erilaisia vaihtoehtoja uuden sovelluksen toteuttamiseksi. Lähtökohtana on se, että erilaisia vaihtoehtoja simuloitaessa ensisijaisesti määritellään palveluihin ja sovelluksiin tarvittavat muutokset ja arvioidaan niiden kustannusvaikutuksia suhteessa odotettuihin tuottoihin (ROI, return-on-investment) (ks. myös oppaan osa 1, luku 5). Mutta tarvittaessa myös liiketoimintaprosesseja voidaan muuttaa. Analysoinnin lopputuloksena saadaan tuotettavan sovelluksen määrittely, joka esitetään tavoitetilan mukaisena valikoimana toteutuksessa tarvittavista palveluista ja liiketoimintaprosesseista. Palveluratkaisun toimittajan näkökulmasta analysoinnin tarkoitus on selvittää mitkä osat sovelluksesta ovat olemassa jo valmiina ja mitä mahdollisesti on vielä toteutettava tai hankittava käyttöön muulla tavoin. 13

14 Palveluarkkitehtuurin soveltaminen terveydenhuollossa Analysointivaiheen keskeinen tavoite on olemassa olevien palveluluiden toiminnallisuuden ja muiden ominaisuuksien käyttö uusissa sovelluksissa. Vaiheen keskeiset tehtävät ovat: prosessien tunnistaminen prosessien rajaus palvelumäärittelyjen ja olemassa olevien toteutusten sovittaminen prosessien toteutuksen analysointi Sovellukseen toteutettavien liiketoimintaprosessien ja palveluiden tunnistamisen kannalta tärkeä on ymmärtää kohdealueen toimintaa, sen käytäntöjä ja sääntöjä. Ilman tätä ymmärrystä toimintaa on mahdoton rytmittää ja jäsentää järkevästi toteuttaviin sovelluspalveluihin ja niiden suorittamiin liiketoimintaprosesseihin. Usein jo alkuselvitysvaiheessa liiketoimintaprosessit ja palvelut on määritelty ainakin karkealla tasolla, mutta varsinaisesti analysointivaiheessa prosesseja ja niiden välistä työnjakoa arvioidaan tarkemmin palveluiden keskeisimpien suunnitteluperiaatteiden näkökulmista. Näitä suunnittelunäkökulmia ovat palveluiden väliset kytkennät (coupling) sekä palveluiden koossapysyvyys (cohesion) ja karkeajakoisuus (granularity). Prosessien rajauksen tavoitteena on estää prosessia muodostumasta yhdeksi monoliittiseksi monitoimipalveluksi. Rajaus tarkoittaa sitä, että prosessille määritetään omistaja, alku, loppu, syötteet, tuotokset ja rajapinnat muihin prosesseihin. Ensimmäinen rajaus koskee luonnollisesti koko sovellusta eli jo alkuselvitysvaiheessa määritetään karkealla tasolla se, mitä sovellus tekee, ketkä sitä käyttävät, millaisia syötteitä se vaatii, mitä saadaan tuloksena ja millaisia liittymiä vaaditaan muihin sovelluksiin ja palveluihin. Analysointivaiheessa puolestaan sovelluksen toiminnallisuus jaetaan aliprosesseiksi. Toiminnallisuuden jakaminen loogisiin kokonaisuuksiin tekee järjestelmästä helpommin ymmärrettävän, mikä puolestaan auttaa ylläpitoa tilanteissa, joissa palveluihin tarvitaan muutoksia tai vanha palvelu pitää korvata kokonaan uusilla palveluilla. Tunnistuksen ja rajauksen jälkeen näihin vielä suhteellisen abstrakteihin palvelu- ja prosessimäärittelyihin lisätään vähitellen toteutuksen kannalta merkityksellisiä yksityiskohtia. Määrittelyjen tarkentaminen aloitetaan vertaamalla haluttua toiminnallisuutta jo olemassa oleviin toteutuksiin ja niiden tarjoamiin mahdollisuuksiin uudelleenkäytön näkökulmasta. Tehtävän tuloksena saadaankin suositus tarvittavien palveluiden hankintatavoista. Palvelut luokitellaan sen perusteella voidaanko toteutuksessa hyödyntää olemassa olevia sovelluspalveluita sellaisenaan tai osittain vai hankitaanko tai kehitetäänkö kokonaan uusia sovelluspalveluita. Palvelujen luokittelua käsitellään tarkemmin luvussa Sovelluspalvelujen toteuttamisessa keskeiset lähestymistavat ovat alhaalta ylös (bottom-up) ja ylhäältä alas (top-down) -tekniikat. Alhaalta ylös -toteutustekniikka tarkoittaa sitä, että toteutuksen suunnittelussa lähdetään liikkeelle olemassa olevista sovelluksista, joihin suunnitellaan ja toteutetaan kokonaan uusia palvelurajapintoja. Tällä tavoin palveluarkkitehtuurissa voidaan hyödyntää alun perin suoritusympäristöönsä sidotuilla tekniikoilla toteutettujen järjestelmien toiminnallisuutta. Sovellettaessa ylhäältä alas suuntautuvaa tekniikkaa uusien palvelujen suunnittelussa tarkastellaan valmiita standardeja ja prosessimalleja. Näin palvelut toteutetaan yhdenmukaiseksi jo olemassa olevan rajapintamäärittelyn kanssa. Edellä kuvattujen puhtaiden lähestymistapojen lisäksi toteutuksessa voidaan soveltaa tekniikoita näiden väliltä esimerkiksi siten, että olemassa oleva rajapinta otetaan osittain käyttöön uudessa sovelluspalvelussa (meet-in-the-middle) tai että uuden sovelluspalvelun luonti perustuu jo toteutettuun sovelluspalveluun (green-field). Toteutusnäkökulmia käsitellään varsinaisesti WS-oppaan 1.osan luvussa 3.4. sekä tämän oppaan luvuissa 3.2.1, 3.3, 3.4 ja 3.5. Konkreettiset soveltamisesimerkit kuvataan luvussa 4. Sovelluspalveluiden hankintatavat ja - prosessi kuvataan puolestaan tarkemmin WS-oppaan 1. osan luvussa 6. 14

15 Osa 2: prosessien ja palvelujen määrittely ja suunnittelu Sovelluspalveluiden ja prosessien toteutusvaihtoehdoista luodaan erilaisia skenaarioita ja toteutussuunnitelmia, joita analysoitaessa arvioidaan muun muassa kustannuksia, riskejä, hyötyjä ja kannattavuutta suhteessa toiminnan asettamiin vaatimuksiin ja niiden merkittävyyteen eli keskinäiseen tärkeysjärjestykseen toiminnan kannalta. Toteutussuunnitelmien arvioinnin tuloksena syntyy prosesseista ja niiden toiminnoista koostuva liiketoiminta-arkkitehtuuri. 2.3 Suunnitteluvaihe Suunnitteluvaiheessa analysoinnin tuloksena saadut käsitteelliset prosessit ja palvelut muunnetaan konkreettisiksi mutta toteutustekniikoista riippumattomiksi sovellusrajapinnoiksi. Lähtökohtina ovat aikaisemmissa vaiheissa kuvatut vaatimukset ja tehdyt linjaukset esimerkiksi valmiiden sovellusten ja ratkaisujen hyödyntämisestä. Suunnitteluvaiheeseen kuuluu kaksi keskeistä tehtävää: yksittäisten palvelutoteutusten suunnittelu ja näiden yhdistäminen korkeamman tason palveluiksi ja sovellusratkaisuiksi. Suunnittelussa keskeisiä periaatteita ovat sovelluspalvelun tarkoituksenmukaisen rakenteen (granularity) säilyttäminen sekä uudelleenkäytön (reuse) ja koostettavuuden (composability) huomioonottaminen. Rajapintojen määrittelyt ovat riippumattomia toteutustekniikoista, ja joissakin lähestymistavoissa rajapintojen suunnittelu voidaan tehdä myös siten, että myös rajapintatekniikoiden suhteen on valinnanvaraa. Suunnitteluvaiheen tuotoksena saadaan riittävän tarkat määrittelyt sekä palvelujen että prosessien toteutusta ja käyttöönottoa varten. Sovelluspalvelujen suunnitteluun kuuluu rakenteen, käyttäytymisen ja toimintaperiaatteiden suunnittelu. Rakenteen suunnittelu sisältää rajapinnan kuvaamisen, operaatioiden ja niiden parametrien määrittelyn, viesti- ja siirtoprotokollien nimeämisen sekä käytettävien porttien määrittämisen. Käyttäytymisen suunnittelussa keskeistä ovat operaatioiden vaikutusten ymmärtäminen ja tältä pohjalta semantiikan ja sääntöjen määrittäminen palvelulle. Esimerkiksi tilauksenkäsittelyssä ei saa olla mahdollista päivittää jo peruttua tilausta. Rakenteen ja käyttäytymisen lisäksi suunnittelussa määrätään käytettävä ohjelmointityyli, joka voi olla joko tieto- tai prosessiorientoitunutta. Tietokeskeinen lähestymistapa soveltuu hyvin tilanteisiin, joissa välitetään paljon tietoa. Usein tiedot välitetään dokumenttina, esimerkiksi XML tai CDA. Tyypillistä viestinvälitykselle on myös se, että lähettäjä ei kaipaa välitöntä vastausta vastaanottajalta, jos kaipaa sitä ollenkaan. Tosin hyvän ohjelmointitavan mukaista on toimittaa lähettäjälle kuittaus siitä, että viesti on vastaanotettu. Sen sijaan prosessiorientoinut ohjelmointityyli sopii tapauksiin, joissa viestin lähettäjä tarvitsee välittömän vastauksen palvelupyyntöönsä. Esimerkkinä sähköinen tilaus, jossa tuotteet maksetaan saman tien luottokortilla. Tilausprosessi ei voi päättyä hyväksytysti ennen kuin maksuprosessi on onnistuneesti päättynyt. Toimintaperiaatteiden suunnittelu tarkoittaa palveluiden hallittavuuteen, turvallisuuteen ja rajoitteisiin liittyvien tekijöiden ja menettelytapojen määrittelyä. Toisin sanoen toimintaperiaatteiden suunnittelussa keskeisessä asemassa ovat kaikki muut kuin varsinaisesti palvelun suorittamaan toiminnallisuuteen liittyvät laatutekijät. Näitä tekijöitä ovat muun muassa suorituskyky, toiminta- ja käyttövarmuus, tekninen skaalautuvuus, transaktioiden käsittely ja muutosten hallinta. 15

16 Palveluarkkitehtuurin soveltaminen terveydenhuollossa Prosessien suunnittelu tarkoittaa loogisesti järkevien (toiminta)kokonaisuuksien koostamista palveluista ja siihen sisältyy rakenteen osallistujien roolien ja toimintaperiaatteiden suunnittelu. Rakenteen suunnittelussa valitaan prosessiin tarvittavat yksittäiset toiminnot ja palvelut, joista prosessi koostetaan. Prosessi kootaan liittämällä palvelut toisiinsa rajapintojensa kautta ja määräämällä niille suoritusjärjestys ja suoritukseen liittyvät ehdot. Tämän jälkeen kuvataan prosessin toteuttavan sovelluspalvelun rajapinta. Prosessien suunnittelussa toinen keskeinen tehtävä on suoritukseen osallistuvien toimintojen keskinäisten vastuiden määrittäminen niin yhden prosessin sisällä kuin prosessien välilläkin. Osallistujien rooleja voivat olla esimerkiksi käynnistäjä, lähettäjä ja vastaanottaja. Roolit määräävät muun muassa sen kuka ja missä tilanteessa voi käynnistää prosessin suorituksen sekä miten viestit kulkevat prosesseissa. Prosessien toimintaperiaatteiden toteutus ja roolipohjainen käyttövaltuuksien hallinta pohjautuvat usein roolien määrittelyyn. Prosessien kuvaamisessa ja roolien määrittelyssä, prosessien koostamisessa sekä niiden simuloinnissa ja analysoinnissa sovelluskehittäjät voivat hyödyntää esimerkiksi työkaluja, jotka tukevat BPMN:ää ja BPEL:iä. Samoin kuin yksittäisten palvelujen suunnittelussa myös prosessien suunnittelussa eitoiminnallisten periaatteiden suunnittelu on tärkeää. Prosessien suunnittelussa yksittäisten laatutekijöiden, kuten prosessien suorituskyky ja toimintavarmuus, lisäksi on otettava huomioon muun muassa palvelun käytön hinnoittelu- ja laskutustavat sekä laajemmin turvallisuuteen ja transaktiokäyttäytymiseen liittyvät näkökulmat. Esimerkiksi palvelun hyödyntäjän näkökulmasta ei riitä, että palvelun tarjoaja mainitsee turvallisuudesta ainoastaan sen, että palvelu on yhteensopiva esimerkiksi WS-Security -standardin kanssa. Sen sijaan palvelun tarjoajan on tarkennettava sitä, millä tavoin standardia edellytetään käytettävän tai on mahdollista käyttää. Nykyään korkeamman tason prosesseja toteuttaville sovelluspalveluille usein edellytetään palvelutasosopimuksia (Service Level Agreements, SLAs), joiden avulla paitsi kuvataan palvelun tai prosessin ei-toiminnalliset ominaisuudet, myös valvotaan ja kehitetään niitä. Palvelun tarjoajan ja hyödyntäjän palvelutasosopimukseen sisällytetään usein muun muassa kuvaus palvelun sisällöstä ja käyttömaksusta, mikä dokumentoidaan palvelutasosopimuksena. Sopimukseen on hyvä sisällyttää myös suunnitelmat poikkeustilanteita varten sekä mahdolliset rangaistus- ja korvauskäytännöt, jos jompikumpi osapuoli rikkoo sopimusta. 2.4 Toteutus- ja testausvaihe Huolellisen määrittelyn ja suunnittelun jälkeen sovelluspalvelut ja sovellukset toteutetaan ja luonnollisesti dokumentoidaan toteutuksen osalta. Sovelluspalveluita voidaan tuottaa kolmella tavalla: toteuttamalla kokonaan uusia web-sovelluspalveluita, muuntamalla käytössä olevien sovellusten toiminnallisuutta web-sovelluspalveluiksi ja koostamalla web-sovelluspalveluita toisista websovelluspalveluista ja -sovelluksista. Toteutustapojen arviointi ja valinta perustuu prosessien erilaisten toteutusskenaarioiden analysointiin, joka siis tehdään jo analysointivaiheessa ja jonka tuloksena saadaan suunnitelma liiketoimintaarkkitehtuurista (ks. luku 2.2). Toteutusvaiheessa korostuu palveluiden käyttäjän näkökulma, kun palveluita liitetään toisiinsa ja edelleen sovelluksiksi valitun liiketoiminta-arkkitehtuurin mukaisesti. Toteutusvaiheessa myös konkretisoituu palvelupohjaisen sovelluksen käyttöliittymäratkaisu, jon- 16

17 Osa 2: prosessien ja palvelujen määrittely ja suunnittelu ka suunnitelma tosin syntyy kehittämisprosessin analysointi- ja suunnitteluvaiheiden tuloksena. Palvelupohjaisen sovelluksen käyttöliittymiä selvitetään luvussa 3.6. ja sovelluspalveluiden liittämistä ja kokoamista sovelluksiksi luvuissa ja Vaikka sovelluspalvelujen toteutusta arvioidaan ja testataan paljon jo analysointi- ja suunnitteluvaiheessa esimerkiksi käyttämällä apuna simulointityökaluja, testauksen pääpaino on kuitenkin konkreettisten sovelluspalvelujen ja niistä kostetuttujen prosessien oikeellisuuden ja toimivuuden todentamisessa. Testausvaiheessa varmistetaan se, vastaako toteutus riittävän hyvin sille asetettuja vaatimuksia. Kun palvelut ja prosessit on saatu teknisesti toimimaan tarkoitetulla tavalla, dynaamisella testauksella tarkastellaan sovelluspalvelujen ja prosessien suorittamia toimintoja suhteessa siihen, miten niiden on odotettu toimivan. Toiminnallisuuden lisäksi dynaamisessa testauksessa arvioidaan palveluiden ja prosessien suorituskykyä, kuormituksensietoa, yleistä käytettävyyttä, käyttövaltuuksien oikeellissuutta jne. Yksittäisten sovelluspalvelujen ja niistä koostettujen sovellusten lisäksi testauksessa arvioidaan käyttöönotettavuutta erilaisissa suoritusympäristöissä, tietoliikenneyhteyksiä mm. käyttövolyymin ja turvallisuuden näkökulmista jne. 2.5 Paketointi-, käyttöönotto- ja suoritusvaihe Palvelupohjaisessa kehittämisprosessissa sovelluspalvelujen toteuttamiseen liittyvät tehtävät erotetaan palveluiden tuotteistamiseen, toimittamiseen ja käyttöönottoon liittyvistä toimenpiteistä. Tällä pyritään siihen, että palveluiden kehittäjät voivat todella keskittyä palveluiden ja prosessien määrittämiseen, suunnitteluun ja toteuttamiseen niin, että niitä voidaan käyttää uudelleen erilaisissa yhteyksissä. Sovelluspalvelujen paketointi eli tuotteistaminen käsittää suuren joukon sekä tekniikkaan että liiketoimintaan liittyviä näkökulmia, jotka pitää ratkaista sekä palvelun tuottajan että sen hyödyntäjän näkökulmasta. Molempien kannalta keskeisiä asioita ovat palvelujen hallintaan (governance) ja todentamiseen (certification) sekä palvelun käytön mittaamiseen (metering), hinnoitteluun (rating) ja laskuttamiseen (billing) liittyvät näkökohdat. Yksittäisten sovelluspalvelujen ja niistä koostettujen prosessien osalta tuotteistamisen lähtökohta on huolellinen dokumentointi: rajapintamäärittelyssä kuvataan palvelun toiminnallisuus ja palvelutason sopimuksilla (SLA) tarkennetaan palvelun laatu sekä kuvataan palvelun käyttö ja käyttöehdot. Sovelluspalvelujen hallinta on keskeisessä asemassa organisaatioissa siirryttäessä vähitellen palvelupohjaiseen arkkitehtuuriin ja palvelupohjaiseen järjestelmäkokonaisuuden hallintaan. Palvelupohjaisen arkkitehtuurin hallintaa käsitellään tarkemmin WS-oppaan 1. osan luvussa Niin sovelluspalvelujen hallintaan kuin hinnoitteluunkin voidaan soveltaa erilaisia malleja. Hallintamalleista tyypillisiä ovat keskitetty ja hajautettu hallinta. Keskitetty hallinta tarkoittaa sitä, että palveluita hallinnoidaan koko organisaation tasolla. Organisaation kaikki palvelut ovat yksissä käsissä ja näin uusien palveluiden hankinnasta, vanhojen poistamisesta tai muutoksista olemassa oleviin palveluihin päätetään keskitetysti ennen kuin mitään muutoksia palveluvalikoimaan toteutetaan. Hajautetussa mallissa organisaatiotasolla voi olla määritettynä yleiset toimintatavat ja sovellettavat standardit, mutta käytännössä toimintayksiköt päättävät itsenäisesti tarjoamistaan ja käyttämistään palveluista. Sovelluspalvelujen hinnoittelussa voidaan soveltaa tietojärjestelmien hinnoittelussa ja laskutuksessa perinteisesti käytettyä, lisensseihin ja ylläpitomaksuihin perustuvaa mallia, jossa käytön hinta ja 17

18 Palveluarkkitehtuurin soveltaminen terveydenhuollossa maksuväli pystytään määräämään etukäteen hyvinkin tarkasti. Mutta sovelluspalvelutarjonnan yleistyessä myös esimerkiksi sovelluspalvelun todelliseen käyttöön perustuva hinnoittelumalli saattaa yleistyä. Tämä tarkoittaa sitä, että niin tarjoajan kuin käyttäjänkin pitää pystyä seuraamaan esimerkiksi palveluun kirjautuneiden lukumäärää tai palvelun käyttökertoja ja -aikaa. Sovelluspalvelun hinnoittelun pohjana voi lisäksi olla palvelun laatu. Yksinkertaisia tai riisuttuja palveluita voidaan tarjota kokonaan veloituksetta kun taas monimutkaisempia liiketoimintoja tai niitä nopeammin suorittavat palvelut hinnoitellaan esimerkiksi porrastamalla. Palvelujen käyttöönotto tarjoajan näkökulmasta tarkoittaa sitä, että toteutetut, testatut ja dokumentoidut sovelluspalvelut ja -prosessit julkaistaan eli laitetaan saataville paikkaan, josta hyödyntäjät voivat käyttää niitä tai hakea ne käyttöönsä. Palvelun hyödyntäjän näkökulmasta käyttöönotto sisältää vaiheet toimituksen ohjauksesta käyttöönottoon (WS-opas 1. osa luvut ja 6.4.2). Sovelluspalvelun suoritusvaihe tarkoittaa sitä, että palvelu on toiminnassa ja toimii sovitulla tavalla. Palvelujen toimintaa ja käyttöä seurataan jatkuvasti valvontajärjestelmillä, joiden avulla muun muassa voidaan jäljittää palvelun tila ja saadaan tietoa palvelun suorituksesta, kuten suoritusajasta ja tuotosten määrästä. Valvonnan tavoitteena on paitsi raportoida palvelun käyttöä myös havaita pullonkaulat ja reagoida poikkeustilanteisiin. Näin seurantaan ja analysointiin perustuvaa tietoa hyödynnetään kokonaisvaltaisesti palvelun ja sen laadun kehittämisessä. Hallintanäkökulman lisäksi suorituksenaikaista seurantaa voidaan tarvita palvelun käytön laskutuksen perusteeksi. Usein palveluarkkitehtuurin ja palvelupohjaisten sovellusten toteutuksessa käytetyt ja hyödynnetyt palvelualustavat sisältävät välineitä seurantaan ja hallintaan (ks. luku 3.7.2). 18

19 Osa 2: prosessien ja palvelujen määrittely ja suunnittelu 3 Viitearkkitehtuuri ja sovelluspalvelujen mallit Tämä luku sisältää SerAPI-hankkeen prosessit ja palvelut (ProPa) -soveltamiskohteessa viitearkkitehtuurin hyödyntämiseen ja sovelluspalvelujen tunnistamiseen tarkoitettuja malleja ja ohjeita. Viitearkkitehtuuri täydentää palvelupohjaisia kehittämisprosesseja (luvussa 2), joita tarvitaan työskentelyn ohjaamiseen. Viitearkkitehtuuri ohjaa miettimään ja ratkaisemaan tietyn tyyppisiä seikkoja kerrallaan, jolloin kaikkia ratkaisuun vaikuttavia seikkoja ei tarvitse pohtia yhtä aikaa. Varsinaisten sovelluspalvelujen lisäksi viitearkkitehtuurin näkökulmien avulla voidaan huomioida myös muita ratkaisuihin vaikuttavia seikkoja pelkät "palvelut" ovat vain osa ratkaisuja. Viitearkkitehtuurin valinnassa on pyritty myös siihen, että se sisältää "riittävän vähäisen" määrän eri kerroksia ja näkökulmia, mutta kattaa tarpeelliset suunnittelussa huomioitavat seikat. Tämä luku liittyy yleisesti kehittämisprosessin vaiheisiin, joissa palveluja tunnistetaan, määritellään ja hankitaan. Palvelujen käyttöönotto, mukautus, konfigurointi sekä hallintaan liittyvät toimenpiteet ovat mukana pienemmällä painoarvolla. 3.1 Viitearkkitehtuuri Palveluarkkitehtuuri ei sinällään ole "tietojärjestelmäarkkitehtuuri" vaan lähestymistapa tietojärjestelmien suunnitteluun, hankintaan ja hallintaan. Järjestelmällinen lähestymistapa vaatii kuitenkin myös arkkitehtuurin määrittelyä. Tietojärjestelmäarkkitehtuuri kuvaa tietojärjestelmäkokonaisuuden osat, niiden väliset suhteet sekä kehittämisen periaatteet. Palvelupohjainen tietojärjestelmäkokonaisuus on monimutkainen yhdistelmä tietojärjestelmiä, sovelluspalveluita, prosesseja ja infrastruktuuria. Erilaisia palvelupohjaisia arkkitehtuureja ja viitearkkitehtuureja on esitelty runsaasti kirjallisuudessa (esimerkiksi Erl 2005, Microsoft 2005). 19

20 Palveluarkkitehtuurin soveltaminen terveydenhuollossa Kuva 3. Sähköisen hallinnon viitearkkitehtuurin luonnos (Akselin & Skwarek 2005). Kuva 4. Palveluarkkitehtuurin kerrokset (Papazoglou ym. 2006). 20

21 Osa 2: prosessien ja palvelujen määrittely ja suunnittelu SerAPI:n "Prosessit ja palvelut" -soveltamiskohteessa on tutkittu useita eri arkkitehtuurikuvauksia (ks. esim. kuvat 3 ja 4), mutta on havaittu, että tähän dokumenttiin valittu Arsanjanin viitearkkitehtuuri (kuva 5) sisältää muissakin kuvauksissa esitettyjä SOA-arkkitehtuurin kerroksia ja näkökulmia. Kuva 5. SOMA-viitearkkitehtuuri (Arsanjani 2004). Arsanjanin mukaan palveluarkkitehtuurin kolme keskeisintä elementtiä ovat toimintaympäristöstä tunnistettavat sovelluspalvelut, toimintaan liittyvät tapahtumaketjut ja työnkulut sekä komponentit, jotka ovat varsinaisia sovelluspalveluiden toteutuksia. Kuvan 5 viitearkkitehtuurissa elementit sijoittuvat omiin kerroksiinsa niin, että luonnollisesti komponentit sijaitsevat komponenttikerroksessa ja sovelluspalvelut sovelluspalvelukerroksessa. Prosessikerroksessa tarkastellaan tapahtumaketjuja ja työnkulkuja eli prosesseja. Viitearkkitehtuurin muut kerrokset ovat käyttäjälle näkyvä käyttöliittymäkerros ja olemassa oleviin järjestelmiin ja tekniseen infrastruktuuriin perustuva taustajärjestelmäkerros. Sovelluspalvelukerros on olennaisin palvelujen tarjoajan ja hyödyntäjän yhtymäpiste. Prosessi- ja käyttöliittymäkerrokset ovat ensisijaisesti palvelujen hyödyntäjän huolenaiheita, kun taas komponenttikerros ja taustajärjestelmäkerros ovat palvelujen tarjoajan vastuulla. Viitearkkitehtuurin kerrokset kuvaavat siis palvelukeskeisen arkkitehtuurin osat ja niiden yhteydet toisiinsa. Siksi kerrokset ovat keskeisiä näkökulmia palvelupohjaisten sovellusten toiminnallisuuden ja rakenteen suunnittelussa ja toteutuksessa. Mutta sovellusten toiminnallisuuden ja rakenteen määrittämisen lisäksi tarvitaan keinot siihen, miten määrityksistä todella saadaan toimivia sovelluksia. Tätä tarkoitusta varten viitearkkitehtuurin tulee sisältää palveluarkkitehtuurin teknisen toteutuksen ja hallinnan huomioon ottavat näkökulmat. Arsanjanin viitearkkitehtuurissa näkökulmia edustavat jokaisen kerroksen kattavat pystysuorat palkit integraatioarkkitehtuuri ja laatuun vaikuttavat tekijät. Seuraavaksi tarkastellaan lähemmin edellä mainittuja viitearkkitehtuurin osia ja niiden suhdetta toisiinsa. Taustajärjestelmäkerros. Viitearkkitehtuurissa taustajärjestelmäkerros käsittää organisaatiossa käytettävät sovellukset ja tietojärjestelmät. Erityisesti suomalaisessa terveydenhuollossa tämän kerroksen sovellukset ovat hyvin heterogeenisia. Toiminnassa hyödynnetään yhtä lailla niin viimeisimmillä web-tekniikoilla toteutettuja ratkaisuja kuin 1980-luvulla kehitettyjä ja edelleen toimivia 21

22 Palveluarkkitehtuurin soveltaminen terveydenhuollossa monoliittisia järjestelmiä. Oikein hyvin voidaan siis ymmärtää, että myös näiden sovellusten ja ratkaisujen vaatima infrastruktuuri on monenkirjava. Palveluarkkitehtuurin yksi keskeisistä eduista on se, että palvelutoteutuksissa voidaan hyödyntää olemassa olevien taustajärjestelmien toiminnallisuutta ja tietoja. Palvelujen tunnistamista käytössä olevista järjestelmistä käsitellään luvussa 3.4. Komponenttikerros. Tyypillisesti komponenteilla toteutetaan loogisia tehtäväkokonaisuuksia, kuten tilauksenkäsittely tai terveydenhuollossa ajanvaraus. Mutta yhtälailla tärkeitä ovat myös tukitoiminnot, kuten käyttäjän tunnistus, lokitietojen muodostaminen tai kontekstinhallinta. Perinnejärjestelmien kannalta komponenttien tarkoitus on paketoida ja abstrahoida niihin sisältyvää käyttökelpoista tietoa ja toiminnallisuutta muiden järjestelmien hyödynnettäväksi. Ja tietysti myös perinnejärjestelmissä voidaan hyödyntää toisten järjestelmien tietoja ja toiminnallisuutta komponenttijärjestelmien avulla. Sovelluspalveluiden näkökulmasta komponentit toteuttavat sovelluspalveluille määriteltyjä tehtäviä. Palveluarkkitehtuurissa komponentit voivat siis olla sekä olemassa olevien järjestelmien ominaisuuksia kokonaan tai osittain hyödyntäviä palvelutoteutuksia että täysin itsenäisiä palvelumäärittelyiden toteutuksia. Komponenttiarkkitehtuurissa komponentit voivat hyödyntää toistensa tarjoamia ominaisuuksia. Komponenttikerros myös muodostaa linkin tunnistettujen palveluiden ja nykyisten tietojärjestelmien välille mahdollistaen olemassa olevan sovellus- ja teknisen infrastruktuurin hyödyntämisen palveluarkkitehtuurissa. Ohjelmistokomponenttien toteuttaminen mahdollistui komponenttistandardien kehittymisen myötä. Tekniikkasidonnaisuuden näkökulmasta perinnejärjestelmät ovat tiukemmin sidottuja suoritusympäristöönsä kuin komponentit, mutta myös komponenteille on ominaista se, että toteutus on aina johonkin tekniikkaan sidottu. Tunnetuimmat komponenttitekniikoista ovat Javaan perustuva J2EEtekniikka ja Microsoftin.NET-tekniikka. Useimmiten komponenttien tekniikkasidonnaisuus tarkoittaa sitä, että yhdellä tekniikkastandardilla toteutettu komponentti ei toimi toisessa suoritusympäristössä, mikä toisaalta on ihan loogista. Mutta tekniikkasidonnaisuus komponenttien osalta voi tarkoittaa myös sitä, että yhden välinetoimittajan kehitystyökalulla toteutettu komponentti ei toimi periaatteessa samaan komponenttitekniikkaan perustuvan toisen välinetoimittajan suoritusympäristössä. Esimerkiksi välinetoimittajat ovat toteuttaneet kehitysympäristöön piirteitä, jotka toimivat ainoastaan heidän omassa suoritusympäristössään ja näin myös sitoneet piirteiden hyödyntäjät omaan infrastruktuuriinsa. Palveluarkkitehtuurissa komponentit nähdään kuitenkin tekniikkariippumattomien palveluiden toteutuksina. Siksi luvussa 3.3 keskitytään palveluiden toteutusvaihtoehtoihin niin tunnistamisen kuin hankinnankin näkökulmasta. Sovelluspalvelukerros. Sovelluspalvelut ovat palveluarkkitehtuurin keskeisimpiä rakennuspalikoita. Käytännössä ne tarkoittavat rajapintamäärittelyjä tehtäväkokonaisuuksille, jotka kuvataan ja julkistetaan standardilla tavalla ohjelmiston ymmärtämässä muodossa niin, että sovelluspalvelut voidaan paikantaa ja ottaa käyttöön erilaisissa suoritusympäristöissä. Tällä hetkellä ehkä suosituin tapa sovelluspalveluiden toteutuksessa on niiden toteuttaminen websovelluspalveluina. Web-sovelluspalvelu ymmärretään yleisesti XML-pohjaisena WSDLdokumenttina, joka kuvaa palvelun rajapinnat, SOAP-viestin tietosisältöä ja palvelun sijainnin. Lisäksi ne voivat sisältää dokumentaatiota rajapinnasta. (Sormunen 2005; Barry & Associates 2004) Sovelluspalveluille tunnusomaista on siis se, että palvelun rajapinta erotetaan sen toteutuksesta niin, 22

23 Osa 2: prosessien ja palvelujen määrittely ja suunnittelu että palvelun käyttöä ei sidota mihinkään tiettyyn tekniikkaan. Palvelukerroksen palvelu linkittyy komponenttikerroksen komponenttiin tai komponentteihin siten, että palvelu voidaan toteuttaa esimerkiksi EJB- eli Enterprise JavaBean komponenttina. Komponentin kääntäminen WSDLdokumentiksi kuitenkin mahdollistaa palvelun käyttöönoton ja käytön muissakin ympäristöissä kuin J2EE-alustoilla. Sovelluspalveluita sekä niiden luokittelua, tunnistamista ja dokumentointia käsitellään tarkemmin tämän dokumentin luvuissa 3.2. Prosessikerros. Prosessikerroksessa tarkastellaan liiketoimintaprosesseja ja sitä miten sovelluspalveluista koostetaan toimivia prosesseja. Toiminnan tavoitteet siis ohjaavat palveluiden yhdistämistä. Palveluiden koostamiseen liittyvät seuraavat osat: yksittäiset toiminnot (palvelut) yksittäisten toimintojen tilat säännöt, jotka yhdistävät toimintoja (esimerkiksi suoritusjärjestys, prosessiin sisältyvät toiminnot, prosessien tilat). Palveluarkkitehtuurissa palveluiden yhdistämisessä käytettyjä tekniikoita tai lähestymistapoja ovat orkestrointi ja koreografia. Orkestroinnissa yksi osapuoli tai prosessi tuntee kaikki kokonaisprosessin suoritukseen osallistuvat palvelut, koordinoi yhteyksiä palveluja välillä ja hallinnoi kokonaisprosessin suoritusta. Koordinaattorin tehtävä on huolehtia siitä, että suorituksessa ovat mukana kaikki tarvittavat osat, suoritus etenee oikeassa järjestyksessä ja että myös mahdolliset virhetilanteet tulevat hoidettua hallitusti. Web-sovelluspalvelujen orkestrointiin tarkoitetuista kuvauskielistä käytetyin tällä hetkellä on BPEL (ks. luku 5.2). Koreografiassa ei sen sijaan ole yhtä osapuolta tai prosessia, joka hallinnoisi kokonaisprosessin suoritusta, vaan jokainen prosessiin osallistuva palvelu tietää oman roolinsa kokonaisprosessissa. Näin ne itse sisältävät myös kaikki kokonaisprosessien suorittamiseen vaadittavat hallintatiedot, kuten kenen kanssa ja missä vaiheessa niiden täytyy keskustella. Koreografian kuvaamiseen tarkoitettu WS-CDL -kuvaus on globaali kuvaus prosessista, sen osa-puolista ja osapuolten vastuista prosessissa. WS-CDL -kuvausta ei ole sidottu tietylle suoritusalustalle tai toteutuskielelle, joten se on nimenomaan kuvaus prosessiin osallistuvien osapuolten yhteis-toiminnasta yleisellä tasolla. WS-CDL -kielen kehittäminen on kuitenkin hiipunut eikä kieltä voida enää pitää varteenotettavana vaihtoehtona prosessin kuvaamiseen. (Kavantzas ym. 2005) Edellä mainittujen notaatioiden lisäksi muun muassa prosessien suunnittelussa voidaan hyödyntää BPMN-mallinnusnotaatiota (Business Process Modeling Notation), joka tarjoaa standardin tavan prosessien graafiseen kuvaamiseen (OMG 2004) tai UML-mallinnuskieltä (Unified Modeling Language), jonka kaavioita voidaan käyttää siis myös liiketoimintaprosessien ja työnkulkujen kuvaamisessa (OMG 2007a). Prosessien suunnittelussa, koostamisessa ja toteutuksessa voidaan käyttää myös mallipohjaista arkkitehtuuria (model-driven architecture, MDA). Arkkitehtuuri käsittää joukon toisiinsa kytkettäviä malleja, joita käytetään ohjelmistokehityksessä järjestelmän toiminnallisuuden mallintamiseen (OMG 2007b). Aluksi järjestelmän toiminnallisuus kuvataan abstraktilla tasolla eli sitä ei sidota mihinkään suoritusalustaan tai tekniikkaan (platform-independent model, PIM). Seuraavaksi abstrakti malli muunnetaan tietylle alustalle sopivaksi, jolloin se myös tulee sidotuksi tekniikkaan (platform-specific model, PSM). Lopulta alustasidonnaisista malleista luodaan suoritusalustalla toimivia toteutuksia. Prosessien kuvaamiseen ja prosessikerroksen toteutusvaihtoehtoihin poraudutaan yksityiskohtaisemmin luvussa 3.5. Käyttöliittymäkerros. Tähän kerrokseen kuuluvat kaikki SOA-pohjaisen sovelluksen käyttöliittymää koskevat näkökulmat. Käyttöliittymän kautta sovelluksen toiminta näkyy käyttäjälle ja käyttö- 23

24 Palveluarkkitehtuurin soveltaminen terveydenhuollossa liittymän kautta käyttäjä myös itse osallistuu prosessien suoritukseen. Yleensä ottaen tähän asti SOA:n yhteydessä ei ole juurikaan käsitelty palvelupohjaisten sovellusten vuorovaikutusta ihmisen kanssa, mutta viime aikoina tähänkin osa-alueeseen on alettu kiinnittää enemmän huomioita mahdollisesti sen eteen tehdyn standardointityön ansiosta. Esimerkiksi standardointiyhteisö OASIS on julkaissut kesäkuussa 2006 alustavan määrittelyn WSRP-standardin (Web Services for Remote Portlets) versiosta 2.0 (OASIS 2006). Standardi määrittää liiketoimintalogiikkaa toteuttaville websovelluspalveluille tavan kommunikoida vuorovaikutuksesta ja esittämisestä vastaavien palveluiden kanssa. Vuorovaikutus näiden eri kerroksissa sijaitsevien web-sovelluspalveluiden välillä toteutuu standardissa määriteltyjen rajapintojen kautta. Portaalia ja muita palvelupohjaisiin sovelluksiin soveltuvia käyttöliittymävaihtoehtoja on käsitelty luvussa 3.6. Integraatioarkkitehtuuri. Integraatioarkkitehtuuri (enterprise service bus, ESB) määrittää tekniset perusratkaisut ja edellytykset hajautetun palvelupohjaisen arkkitehtuurin toteuttamiselle. Se tarjoaa mallin, jossa muun muassa yhdistyvät viestinvälitys, web-sovelluspalvelut, tietojen muuntaminen ja reititys niin, että eri järjestelmien välisen vuorovaikutuksen toteuttaminen ja koordinointi on mahdollista. Laajassa merkityksessä ESB:n avulla palvelujen käyttöä voidaan hallita ympäristössä, jossa toimipisteet ja kumppanit sijaitsevat hajallaan (Chappell 2004). Liitäntätavat ja palvelualustat esitetään luvussa 3.7 Palveluiden ja palvelupohjaisten sovellusten laatuun vaikuttavat tekijät. Tässä kerroksessa tarkastellaan valvontaan ja hallintaan kuuluvia mekanismeja, joilla selvitetään palveluiden ja sovellusten laatua. Laadun arvioinnissa keskeisiä tekijöitä ovat turvallisuus, suorituskyky ja saatavuus. Palveluarkkitehtuurin hallintaa koskevia laatuasioita käsitellään WS-oppaan 1-osassa. Nykyiset seuranta- ja valvontatyökalut perustuvat pääasiassa järjestelmien suorituksen aikana luomiin tapahtumalokeihin, joista saatava informaatio esitetään tavallisesti graafisessa ja helposti ymmärrettävässä muodossa. Esimerkiksi valvonta- ja hallintaprosessin tehtävä on ilmoittaa, jos jokin palvelupohjaisen sovelluksen tarvitsema palvelu ei ole käytettävissä. Valvonnan ja analysoinnin tavoitteena onkin havaita ja eliminoida viiveet, pullonkaulat ja tehoton resurssien käyttö. Tämän oppaan luku 3 siis perustuu edellä esitetyn viitearkkitehtuurin eri osien tarkempaan läpikäyntiin. Seuraavassa vielä kuvat kahdesta muusta viitearkkitehtuureista, joiden näkökulmat tulevat esiin valitussa viitearkkitehtuurissa. 3.2 Sovelluspalvelut (services) Palvelupohjaisen arkkitehtuurin keskeisimmät rakennusosat ovat uudelleenkäytettävät sovelluspalvelut, joista koostetaan toimintaprosesseja, sovelluksia tai korkeamman tason palveluita. Se, mitä seikkoja sovelluspalveluista kulloinkin käsitellään, riippuu palvelun elinkaaresta ja projektin vaiheesta. Palvelukeskeisen kehittämisen olennainen vaihe liittyy palvelujen tunnistamiseen, ja käytetyn lähestymistavan mukaisesti tunnistamisessa voidaan painottua tunnistamiseen prosessimäärittelyistä tai valmiista sovelluksista tai määrityksistä (luku 3.2.1). Palvelujen tunnistamisvaiheessa sekä suunnittelun, toteutuksen ja käytön yhteydessä on hyödyllistä tunnistaa erityyppisiä palveluita (luku 3.2.2), koska keskeisiä ominaisuuksia jakavien "palveluluokkien" avulla voidaan hyödyntää ja yhdenmukaistaa palvelujen kehittämistä ja hallintaa. Palvelujen tunnistamisessa ne on dokumentoitava siten, että tarkempi toteutusvaihtoehtojen arviointi tai suunnittelu on mahdollista (luku 3.2.3). Palveluista kuvattavia perusasioita hyödynnetään myös siinä vaiheessa, kun palvelun käyttötarkoitusta ja sopivuutta eri tilanteisiin arvioidaan myöhemmissä vaiheissa uudelleenkäyttöä varten. Palvelurajapintojen tarkkaa määrittelyä ei käsitellä tässä dokumentissa tarkemmin. Tähän tarkoitukseen löy- 24

25 Osa 2: prosessien ja palvelujen määrittely ja suunnittelu tyy valmiita malleja ja ohjeita (mm. Mykkänen ym. 2004) sekä malleja esimerkiksi SerAPIhankkeen soveltamiskohteiden rajapintamäärittelyistä. Tässä luvussa kuvataan erityyppisten palvelujen tunnistamista ja määrittelyä helpottavia malleja ja toimintatapoja. Palvelujen hankinta- ja toteutusvaihtoehtoja käsitellään tarkemmin luvussa Palvelujen tunnistaminen suunnat: olemassa olevat järjestelmät ja prosessimäärittelyt Palvelupohjaisen ohjelmistokehityksen pääasialliset kehitysstrategiat ovat prosessilähtöinen ylhäältä alas -menetelmä ja olemassa olevista sovelluksista lähtevä alhaalta ylös -menetelmä. Eri lähestymistapojen vertailua ja vaikutuksia ohjelmistokehityksen osatekijöihin on käsitelty tämän oppaan osassa 1 luvussa 3 (Ohjelmistokehityksen osatekijät ja kehitysstrategiat palvelupohjaisessa arkkitehtuurissa). Yleisesti suositeltu tapa tunnistaa ja määritellä sovelluspalveluja on yhdistää prosessien määrittely sekä olemassa olevien sovellusten tutkiminen tarvittavien ja käytettävissä olevien sovelluspalvelujen määrittelemiseksi. Varsinaista palvelujen valintaa ohjaavat kuitenkin aina ensisijaisesti käyttäjien, tietohallinnon ja asiakkaiden vaatimukset ja tarpeet. Alhaalta ylös -menetelmällä tapahtuvassa palvelujen tunnistamisessa käytetään pohjana esimerkiksi järjestelmäkarttoja ja järjestelmädokumentaatiota. Intuitiivinen tapa tunnistaa sovelluspalveluita on myös tarvittavaan prosessiin liittyvien toimintojen ja tietojen tunnistaminen sovelluksista. Jo toteutetut sovelluspalvelut ja sovelluksissa saatavilla olevat rajapinnat muodostavat keskeisen pohjan uudelleenkäytölle, mutta usein tunnistamisen yhteydessä saatetaan joutua määrittelemään myös tarvittavia muutoksia tai laajennuksia vanhoihin ratkaisuihin. Palvelujen toteutus- ja hankintavaihtoehtoja (alhaalta ylös) käsitellään tarkemmin luvuissa 3.3 ja 3.4. Ylhäältä alas -tyyppisessä palvelujen tunnistamisessa pohjana ovat riittävälle tasolle kuvatut tavoitetilan prosessit, ja palvelujen, rajapintojen ja operaatioiden määrittely pohjautuu prosessikuvauksiin. Prosessikuvausten hyödyntämistä palvelujen tunnistamisessa ja prosessikerroksen toteutusta käsitellään luvussa 3.5, ja luku 4 sisältää esimerkkejä sovelluspalvelujen prosessilähtöisestä tunnistamisesta Palvelujen luokittelu Palvelujen luokittelun tavoitteena on tunnistaa samantyyppisiä ratkaisuja samantyyppisiin tarpeisiin, auttaa kokonaisarkkitehtuurin hahmottamisessa palvelujen osalta sekä tarjota valmiita malleja erityyppisten sovelluspalvelujen tuottamiseen tai hankintaan. Koska kaikki palvelut eivät voi olla samantyyppisiä ja ratkaisuissa tarvitaan muutakin kuin palveluja, on järkevää tunnistaa perustyyppejä, joiden sisällä monet palvelujen ominaisuudet ovat samankaltaisia. Luokitteluun vaikuttaa lisäksi se, halutaanko "kaikki" käsittää palveluna: puhtaimmillaan SOA-lähestymistavassa on mahdollista käsittää esimerkiksi kirjoittimet, yhteistyökumppanit, työntekijät sekä käyttöliittymät palveluina, joilla on rajapinta (tähän ei kuitenkaan pyritä tässä dokumentissa). Luokitteluja voidaan käyttää olemassa olevien järjestelmien palveluiksi sopivien osien tunnistamisessa ja hyödyntämisessä sekä prosessien mallintamisessa tunnistettujen palvelutarpeiden luokittelussa, mikä ohjaa tietyntyyppistä toteutus- tai hankintatapaa kohti. 25

26 Palveluarkkitehtuurin soveltaminen terveydenhuollossa Palveluita voidaan luokitella mm. seuraavilla perusteilla: arkkitehtuurin kerrokset (esimerkiksi viitearkkitehtuurissa): järjestelmäpalvelut, liiketoimintapalvelut, prosessipalvelut (Arsanjani 2004), tai peruspalvelut, välittäjäpalvelut, prosessipalvelut, organisaatiotason palvelut (Dutta ym. 2006). teknisyys ja yleiskäyttöisyys: infrastruktuuri/ydinpalvelut/lisäpalvelut. palvelun kattamien integrointivaatimusten ensisijainen luonne: tietopalvelut, toiminnalliset palvelut, käyttäjäkeskeiset palvelut, prosessipalvelut (Linthicum 2003). toiminnallinen luokittelu: tekniset palvelut (viestinvälitys), yleispalvelut (ajanvaraus), toimintokohtaiset palvelut (radiologian sovelluspalvelut), rakenteisuuden (structure) ja "epävarmuuden" (uncertainty) aste (Stern & Davis 2003), jota on käytetty varsinkin erilaisten palvelulähtöisten lähestymistapojen luokitteluun ja vertailuun. Lisäksi on järkevää erottaa, onko palvelussa kyse loppukäyttäjälle (ihmiselle) suoraan näkyvästä vai vain sovelluksille näkyvästä palvelusta. Tässä dokumentissa kuitenkin käsitellään sovelluspalveluja toiminnallisina osina, joiden näkymä loppukäyttäjälle pitää määritellä erikseen. Arkkitehtuurissa on nimenomainen näkökulma tätä varten. Jotkut palvelujen tiedoista tai toiminnoista voivat olla melko suoraan käyttäjälle näkyvissä, mikä otetaan huomioon palveluiden suunnittelukysymyksissä. Palveluja voi luokitella myös niiden käsittelemien tieto- ja toimintokokonaisuuksien karkeajakoisuuden ja abstraktiotason mukaisesti, esim.: peruskäsitteet, perustoiminnot, suhteiden verkosto, toimialakäsitteet (Blobel 2006). Tämä kuvaustapa kuitenkin sekoittaa tieto-, käsite- ja toiminnallisuusnäkökulmat, jotka on syytä erottaa (Iivari 1994) Käytettävät luokittelut: integrointitapa ja yleiskäyttöisyys Tässä käytettävä luokittelu on tehty lähinnä viitearkkitehtuurin services-kerroksessa tunnistettavia sovelluspalveluja varten. Luokittelu on tehty hyödyntäjänäkökulmasta, eli huomiota kiinnitetään ensisijaisesti siihen, mitä palvelun hyödyntäjä tarvitsee (toteuttajanäkökulman sijaan). Tunnistettavat palvelut luokitellaan kahden erillisen näkökulman mukaisesti: integrointitapa ja yleiskäyttöisyys. Alla olevissa taulukoissa on myös kuvattu kriteerejä, joilla palveluja voidaan sijoitella eri luokkiin. Palvelun integrointitapa (ks. taulukko 1) on toinen käytettävä luokittelu, koska ratkaisuissa tarvitaan erilaisia palveluita, ja samaan luokkaan kuuluvilla palveluilla on paljon samantyyppisiä ominaisuuksia. Vastaavia luokitteluja on esitetty sovelluspalveluihin, hajautettujen tietojärjestelmien eri piirteisiin sekä sovellusintegraatioon liittyen (Erl 2005; ISO/IEC ; Linthicum 2003; Dutta ym. 2006). 26

27 Osa 2: prosessien ja palvelujen määrittely ja suunnittelu Taulukko 1. Palvelujen luokittelu integrointitavan mukaan Palvelun tyyppi Prosessipalvelu: toteuttaa suoraan prosessia tai osaprosessia Tietopalvelu: liittyy suoraan tietokokonaisuuteen, tietyn tyyppisiin dokumentteihin jne. Toiminnallinen palvelu: keskeistä tarjottava toiminnallisuus (business capability) Tukipalvelut Tyypillisiä piirteitä Prosessipalvelu ei yleensä itse sisällä muuta kuin prosessin etenemiseen liittyvää liiketoimintalogiikkaa. Se kokoaa tietoja ja toimintoja useista muun tyyppisistä palveluista. Viitearkkitehtuurissa se sijoitetaan ensisijaisesti prosessi-kerrokseen. Usein kutsuu muita (tieto-, toiminto- ja tuki-) palveluja, sisältää vaiheiden määrittelyä, toimintaohjeita "ihmisille", säilyttää tilaa prosessien vaiheesta (myös pitkäkestoiset prosessit). Voi olla yleiskäyttöinen, mutta yleensä sovitettu nimenomaisen organisaation tai työnkulun tukemiseen. Voi tarjota rajapinnan prosessin ohjaukseen ja seurantaan. Sijaitsee viitearkkitehtuurin prosessikerroksessa. Prosessipalvelu hoitaa yleensä useita saman prosessin esiintymiä, mutta voi liittyä joissain tapauksissa myös käyttäjäkohtaiseen työnkulkuun tai sen hallintaan. Tavoiteltuja hyötyjä: prosessin yksityiskohtien piilottaminen, kuormanhallinta, monikanavaisuus, prosessin toimintalogiikan erottaminen yksittäisten toimintojen ja käyttöliittymän logiikasta. Toiminnot: "hae, päivitä, kysele" jne. Voi sisältää samantyyppistä toiminnallisuutta kuin sovellusten tiedonsäilytyskerros, mutta yleensä huomattavasti kokonaista sovellusta pienemmältä sovellusalueelta. Kapseloi tiukasti hallitsemansa tiedon: tiedon hyödyntäjä saa sen käyttöönsä vain tietopalvelun raja-pinnasta. Tietopalvelu voi tarjota tietoja hienojakoisesti (monet parametrit) tai karkeajakoisesti (dokumentit, viestikokonaisuudet). Voi kutsua muita, varsinkin tietopalveluja, etenkin jos muodostaa koottuja tietokokonaisuuksia, mutta usein toimii vain tietoresurssien tarjoajana muille palveluille. Toiminnot: "tee, suorita, luokittele", jne. Toiminnalliset palvelut tarjoavat rajapinnan monimutkaisten algoritmien tai laskennan suorittamiseksi tai liike-toimintasääntöjen toteuttamiseksi. Voi usein käyttää esim. tietopalveluja. Toiminnot voivat liittyä sovellusten tarvitsemaan tai tarjoamaan toiminnallisuuteen tai toimialan keskeisiin tehtäviin tai toimintoihin. Palveluita, joilla ei ole suoraa toimialakohtaista kytkentää, tai joita tarvitaan muiden palvelujen tai teknisten ratkaisun piirteiden toteuttamiseksi tai muuntamiseksi. Yleensä tilattomia. Voivat käyttää muita palveluja esimerkiksi tarjoten eri teknisiä vaihtoehtoja palvelujen kutsumiseen. Esimerkkejä: technology gateway, joka muuntaa eri tiedon esitys- tai kommunikaatiotekniikoiden välisiä protokollia, esimerkiksi perinnejärjestelmän rajapinnasta web-sovelluspalvelurajapinnaksi; adapter (sovitin), joka muuntaa palvelun tarjoamat protokollat hyödyntäjän tarvitsemaan muotoon (tai päinvastoin); facade, joka tarjoaa useasta palvelusta koostetun näkymän hyödyntäjille (voi olla myös yhdistetty edellisiin); toiminnallisuutta lisäävä palvelu, joka laajentaa kutsumansa palvelun toiminnallisuutta tai sisältöä ilman, että alkuperäiseen palveluun tarvitsee tehdä muutoksia. Palvelun yleiskäyttöisyys (ks. taulukko 2) on toinen luokittelutapa, koska tavoitteena on erityisesti määritellä uudelleenkäytettäviä sovelluspalveluja. Mikäli tavoitteena on useisiin käyttötilanteisiin ja prosesseihin sopivat sovelluspalvelut, on yleistämiseen kiinnitettävä erityistä huomiota. Tämän 27

28 Palveluarkkitehtuurin soveltaminen terveydenhuollossa tyyppisiä luokitteluja on käytetty mm. komponenttipohjaisten järjestelmien sekä sovelluspalvelujen kehityksessä (Herzum & Sims 2000; CBDI 2005,; Dutta ym. 2006). Taulukko 2. Palvelujen luokittelu yleiskäyttöisyyden mukaan Palvelun tyyppi Yleispalvelut (utility) Ydinpalvelut Erikoispalvelut Tyypillisiä piirteitä Hyödynnettävissä hyvin monien erityyppisten palvelujen, sovellusten ja prosessien toteutuksissa (utility service). Usein tukipalveluja. Laajasti käsitettynä suuri osa teknisestä ohjelmisto- ja laitteistoinfrastruktuurista voidaan nähdä yleispalveluina. Monissa prosesseissa, yksiköissä ja sovelluksissa hyödynnettäviä toiminnallisia tai tietopalveluja (common service). Yleensä toimialakohtainen tai muuten merkityksellinen prosessin tai toimialasovelluksen toteuttamisessa. Kiinnitettävä huomiota yleistettävyyteen, mutta sovittava tai sovitettavissa erilaisiin tarkempiin käyttötilanteisiin. Ei yleensä säilytä kutsujakohtaista tilaa (tai sisällä tietyssä järjestyksessä kutsuttavia toimintoja), ellei ole prosessipalvelu (yleensä tieto- ja toiminnallisia palveluja). Oma ydinpalvelu-luokkansa ovat erittäin karkeajakoiset, erityisesti organisaatioiden välisiin ratkaisuihin tarkoitetut palvelut (public enterprise services). Nämä ovat erityisesti hyödynnettävissä ennalta tuntemattomien kumppaneiden kanssa ja hyödyntävät karkeajakoista ja löysästi kytkettyä dokumenttipohjaista viestinvälitystä, jolloin niiden toiminnot ja tiedot sisältävät koko tarvittavan kontekstin (esim. allekirjoitukset, tunnistus, salaus, muut turvallisuusratkaisut, ei pelkkiä viittauksia muiden palveluiden sisältämiin tietoihin vaan tarvittavat tiedot kokonaisuudessaan jne.). Löysä kytkentä palvelun tarjoajan ja käyttäjien välillä toteutetaan yleensä asynkronisella ja varmistetulla viestinvälityksellä. Palvelujen hyödyntämiseen voi liittyä laskutusta. SLA-sopimuksilla säännellään karkeajakoisten palveluiden toimintaa, mikä vaatii mm. palvelujen seurantaa. Tiettyihin erikoistilanteisiin vastaavia toimintoja, voi olla osasto-, sovellus- tai tehtäväkohtainen tarkoitus (specialized service). Yleensä tehty nimenomaiseen tehtävään ja käytössä vain erikoistuneissa sovelluksissa tai prosesseissa. Voi hyödyntää useita erilaisia palveluja tai olla riippumaton muista palveluista. SerAPI-hankkeen Prosessit ja palvelut -työssä on kiinnitetty erityistä huomiota ydinpalvelujen tunnistamiseen. Toisaalta olemassa olevia rajapintoja ja määrityksiä on suhteutettu eri palveluluokkiin. Yllä kuvattuja luokitteluja käyttäen on koottu esimerkkejä erityyppisten palvelujen luokittelusta: 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 yleispalvelu) alueellinen viitetietopalvelu (tieto- ja yleispalvelu) ajanvarauspalvelu (toiminnallinen ja ydinpalvelu) 28

29 Osa 2: prosessien ja palvelujen määrittely ja suunnittelu 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). Näistä esimerkiksi koodistojen CodeAPI-palvelu vastaa selkeään toiminnalliseen tarpeeseen (koodistohakujen ja selauksien tekeminen vuorovaikutteisesti käyttäjän toimesta: toiminnallinen palvelu), kun taas kansallinen koodistopalvelu tarjoaa useita eri koodistoja ladattavaksi eri organisaatioihin ja sovelluksiin (tietokeskeinen palvelu). Molemmat palvelut ovat yleiskäyttöisiä ja hyödynnettävissä monien eri koodistojen kanssa erittäin monissa eri prosesseissa, mutta eivät liity nimenomaisesti mihinkään tiettyyn toimintoketjuun (yleispalvelu). Edellä mainituista palveluista SerAPI-hankkeen työtä on tehty koodistojen DRG-ryhmittelijän, kontekstinhallinnan, CodeAPIpalvelun, ajanvarauspalvelun sekä käyttöoikeuksien kyselyn rajapintojen parissa Palvelujen dokumentointi ja kuvaaminen Tunnistettujen palvelujen dokumentoinnin, ymmärrettävyyden ja rajausten kannalta on olennaista kuvata keskeisimmät sovelluspalveluun liittyvät seikat. Kuvausta tarvitaan sekä tarkemman suunnittelun tai hankintavaihtoehtojen ohjaamisessa että jo hankittuja tai käytössä olevia palveluja arvioitaessa uusissa käyttötilanteissa. Palvelujen suunnitteluun liittyy olennaisesti myös palvelujen ja operaatioiden nimeämiskäytännöt, joiden avulla voidaan tehostaa viestintää ja ilmoittaa selvästi palvelujen tyyppi. Tässä kuvattujen mallien lisäksi palvelujen dokumentointia erityisesti rajapintojen osalta on kuvattu lähteessä (Mykkänen ym. 2004). Palvelunkuvaustaulukko (ks. taulukko 3) on tehty helpottamaan palvelujen tunnistamista ja luokittelua riippumatta siitä, tapahtuuko palvelun tunnistaminen prosessikuvausten ja -mallien tai olemassa olevien sovellusten, palvelujen ja määritysten pohjalta (Honey ym. 2006a; Mykkänen & Tuomainen 2007): Taulukko 3. Palvelunkuvaustaulukko Palvelun nimi Yksiselitteinen, hyvin palvelua kuvaava nimi. Ks. luku Tarkoituksen lyhyt kuvaus: Yhteenveto sovelluspalvelun keskeisistä toiminnallisista ominaisuuksista (tarjotuista palveluista ja operaatioista) ja sen hallitse- mitä toimintoja ja tietoja kattaa mista tiedoista Integrointitapa (ks ) Prosessi-, tieto-, toiminnallinen vai tukipalvelu Yleiskäyttöisyys (ks ) Mihin prosesseihin liittyy Mihin sovelluksiin/tuotteisiin liittyy Mihin määrityksiin liittyy Yhteydet ja riippuvuudet muihin palveluihin Arvio saatavuudesta/ toteutettavuudesta/ mukauttamistarpeista Muut kommentit Yleis-, ydin tai erikoispalvelu Lista prosesseista, joissa palvelua hyödynnetään tai voidaan hyödyntää. Olennainen tieto jäljitettävyyden ja yleistettävyyden kannalta + mm. kun pohditaan palvelun päivittämistä tai poistamista. Lista sovelluksista ja tuotteista, joihin palvelu liittyy. Olennainen tieto jäljitettävyyden kannalta + kun pohditaan palvelun päivittämistä/poistamista. Esim. paikalliset ja avoimet arkkitehtuuri- ja rajapintamäärittelyt Lista palveluista, joita palvelu hyödyntää omassa toiminnassaan. Mitä vähemmän yhteyksiä, sitä parempi. Hankinta- ja toteutusvaihtoehdot, mahdollisuudet rajapinnan ja toimintapolitiikkamääritysten (policy) muuttamiseen jne. Esim. viittaukset muihin tarkempiin määrittelyihin. 29

30 Palveluarkkitehtuurin soveltaminen terveydenhuollossa On runsaasti seikkoja, joita palvelusta voidaan dokumentoida edellä mainittujen lisäksi, mutta taulukon tavoitteena on muodostaa pikainen yleiskuva palvelun tarkoituksesta, luonteesta ja saatavuudesta. Seuraava vaihe palvelujen kuvaamisessa on tarkentaa palvelun tarjoamia tietoja ja toiminnallisuuksia. Tyypillisesti palvelun tarkentamisessa noudatetaan seuraavan tyyppistä hierarkiaa (mukaillen Honey ym. 2006b): o Palvelu, esim. Entity Identification Service o Rajapinta, esim. Query Operaatio, esim. Find Entities by Trait Operaatioon liittyvät viestit, esim. kutsu- (request) ja paluuviestit (response), poikkeukset. Palvelujen ja operaatioiden välissä oleva rajapintataso on järkevää kuvata usein lähinnä kuvaamalla kunkin rajapinnan perusvastuut ja listaamalla rajapintaan kuuluvat operaatiot. Sen sijaan tarkka, esim. taulukkomuotoinen kuvaus kustakin operaatiosta on erittäin hyödyllinen (ks. taulukko 4). SerAPI-hankkeen monet määritykset sisältävät esimerkkejä operaatiokuvauksista, ja kuvauspohjaa on hyödynnetty myös kansainvälisesti Healthcare Services Specification Project-hankkeessa. Taulukko 4. Operaatiokuvaustaulukko Operaatio Rajapinta Käyttötarkoitus Kutsu Vastaus Kuvaus Pakollisuus Lisätietoja Poikkeukset Operaation nimi, joka kuvaa lyhyesti kyseisen toiminnon tai palvelun tavoitteen Rajapinta (ja sitä kautta palvelu), johon operaatio kuuluu Lyhyt selite operaation tarkoituksesta Operaatiokutsun tietojen tai sanoman määrittely: rakenne, eri osien merkitykset, tarvittaessa käytetyt tietotyypit ja koodistot jne. Vastauksen tai paluuarvon tietojen tai sanoman määrittely: rakenne, eri osien merkitykset, tarvittaessa käytetyt tietotyypit ja koodistot jne. Tarkempi kuvaus operaation toiminnasta. Tieto, mitkä tiedot ovat pakollisia, tieto siitä miten operaatio liittyy määrityksen mahdollisiin tasoihin (conformance levels) Esimerkiksi lisätietoja toteutusmalleista tai perusteluja tehdyille ratkaisuille. Poikkeustilanteet Operaatiokuvaustaulukoissa voi lisäksi olla omat kohdat esimerkiksi esi- ja jälkiehdoille (kuvaus tilanteesta, joka on oltava voimassa ennen operaation kutsua, ja kuvaus operaation vaikutuksista ja lopputuloksesta). Lisäksi projektissa on hyödyllistä sisällyttää palvelu- ja operaatiokuvauksiin selkeät kohdat viittauksille vaatimuksiin tai kohdealueen kuvausten kohtiin, joihin ratkaisu perustuu. On huomioitava, että perinteisesti palvelukutsuissa käsitellyn kutsu/vastaus-periaatteen lisäksi voi olla mahdollista (tai määritelty noudatettaviin soveltamisperiaatteisiin), että käytetään myös muunlaisia vuorovaikutusmekanismeja ja viestinvaihtomalleja (Message Exchange Patterns), esimerkiksi asynkronisia ilmoituksia (notification), joihin ei tule vastausta lainkaan. 30

31 Osa 2: prosessien ja palvelujen määrittely ja suunnittelu Nimeämiskäytännöt Palveluiden ja operaatioiden nimeämiseen tulisi kiinnittää erityistä huomiota. Nimen tulisi olla erottuva, yksiselitteinen ja kuitenkin suhteellisen lyhyt. Hyvin määritelty palvelu tarjoaa tarkasti rajatun toiminnallisuuden ja käyttöalueen, jolloin palvelun nimeäminen on usein helppoa. Tämä pätee varsinkin uusiin palveluihin. Vanhojen perinnejärjestelmien toiminnoista luotuihin palveluihin ei aina saada tehtyä yhtä selväpiirteisiä toiminnallisuuden rajoja ja toiminta-alueiden jakoja; palvelu voi tarjota monenlaisia toimintoja, jolloin palvelun nimeäminen kuvaavasti mutta lyhyesti on haastavampaa. Nimeämisessä kiinnitetään huomiota mm. palvelun laajuuteen (scope) ja kontekstiin perustuva nimeämiskäytäntö on Thomas Erlin ajatus (Honey ym. 2006a, Erl 2006), ja alla olevassa kuvauksessa on hyödynnetty aiemmin esiteltyä palvelujen luokittelua. Yleispalveluja nimetään käyttötarkoituksen mukaisesti yleisellä tavalla. Yleiskäyttökonteksti (utility centric context) on tunnistettavissa sovelluspalveluista, jotka tarjoavat yleiskäyttöisiä toimintoja, kuten tapahtumalokin. Nämä uudelleenkäytettävät tai yleiskäyttöiset palvelut tulisi nimetä riippumatta mistään tietystä käyttötarkoituksesta, jossa palvelua käytetään. Yleiskäyttöisen käyttäjälle huomautuksia tuottavan palvelun nimenä voisi olla esimerkiksi Notification. Tietopalvelu (jokin kokonaisuus, esim. asiakas tai tilaus) kuvataan substantiivilla Customer, Order. Tiedon konteksti (entity-centric context) muodostuu liiketoimintapalvelussa (business service), joka edustaa tiettyä liiketoiminnan tietokokonaisuutta (entity), esim. laskua tai tilausta. Tällaisen palvelun nimeäminen määräytyy usein tietokokonaisuuden tai entiteetin nimen mukaan. Palvelun nimi voi siis olla yksinkertaisesti esim. Asiakas. Tietokeskeisillä palveluilla on usein suhteellisen samanlaisia käsittelyoperaatioita, mm. CRUD-suunnittelumallin (Create, Read, Update, Delete) mukaisesti sekä tietojen validointiin tai tarkastamiseen. Toiminnalliset palvelut nimetään usein substantiivilla ja verbillä (tee jotakin jollekin) - Member Registration. Tehtäväkeskeinen konteksti tulee tarpeeseen kun käsitellään liiketoimintalogiikkaa toteuttavia palveluita. Tässä tapauksessa yhteen liittävänä voimana on palvelun tarjoaman logiikan automatisoima tietty aktiviteetti, joka muodostuu joukosta toimintoja. Palvelu tai rajapinta nimetään usein "passiivisella verbillä" tai substantiivilla, esimerkiksi "Koodinhakupalvelu", "Koodistorajapinta", ja operaatiot aktiivisella verbillä, esimerkiksi "Listaa koodit" Rakennettaessa palveluita tyhjästä, niiden lajittelu arkkitehtuurin tarjoamiin lokeroihin auttaa nimeämisessä. Palveluiden nimeäminen vaikuttaa myös toimintojen nimeämiseen; kontekstin hyödyntäminen vähentää toistoa. Esimerkiksi jos palvelun nimi on Tilaus, tilaushistorian hakevan toiminnon nimen ei tarvitse olla haetilaushistoria, vaan se voi olla lyhyesti haehistoria, koska toiminnon kontekstina on Tilaus-palvelu (Erl 2006). Nimeämiseen vaikuttaa uudelleenkäytettävyys. Nimen tulee olla neutraali, jos samalla palvelulla voidaan tehdä moneen eri kontekstiin liittyviä toimintoja, mikä näkyy erityisesti yleispalvelujen nimeämisessä. Nimeämisen tarkka pohtiminen voi pienissä projekteissa vaikuttaa turhalta työltä, mutta suurissa hankkeissa ja ajan myötä hyvin suunniteltu nimeämiskäytäntö edesauttaa palveluiden uudelleenkäyttöä, kun palvelut ovat helposti löydettävissä ja tunnistettavissa pelkän nimen perusteella. Palvelukuvausten tarkentaminen Rajapintojen kuvaus on olennaisin osa palvelun dokumentaatiota. Palvelun käyttämiseksi tarvittavaan kuvaukseen kuuluu kuitenkin myös muita seikkoja. Rajapinnoissa kuvatun tieto- ja käyttäyty- 31

32 Palveluarkkitehtuurin soveltaminen terveydenhuollossa mismallin lisäksi palvelukuvauksen dokumentointiin kuuluu usein mm. palvelun saavutettavuuden ja näkyvyyden kuvaus (ml. osoitteet), palvelun toiminnan vaikutusten kuvaaminen ja palveluun liittyvien toimintapolitiikkojen (policy) kuvaukset. Lisäksi palvelukuvauksessa olevia tietoja, käyttäytymistä ja toimintoja kuvataan eri tavoin ja eri painotuksilla erityyppisissä palveluissa ja eri organisaatioissa. Toimintapolitiikkojen (policy) määritysten avulla mukautetaan palvelujen toimintaa, käyttöä tai kuvausta kunkin hetkisessä toimintaympäristössä rajoittamalla tai asettamalla ehtoja (MacKenzie ym. 2006). Toimintapolitiikkojen määrittelyt sisältävät usein tietoja laatuominaisuuksista, kuten sanomien käsittelyn nopeudesta, turvallisuusvarmenteista tai niiden laatimisesta. Toimintapolitiikkojen avulla voidaan myös toteuttaa toiminnan ohjausta tai hoitaa osin samoja seikkoja kuin rajapinta- tai prosessimäärittelyjen avulla. Periaatteena on, että toimintapolitiikkojen avulla voidaan rajoittaa sekä tiedollisia että toiminnallisia ominaisuuksia, ja toimintapolitiikat voivat liittyä sekä palvelujen tarjoajaan että hyödyntäjään. Tällöin on erityisesti huolehdittava siitä, että käytäntöjen määrittely ohjeistettua, ja eri palveluissa rajoitteita hyödynnetään yhdenmukaisilla periaatteilla. Lisäksi palvelukuvauksiin liittyy usein muita sopimuksia, joissa kuvataan esimerkiksi käytön ehtoja, palveluiden tarjoajan ja hyödyntäjän velvollisuuksia, sekä laskutus- ja ylläpitoperiaatteita. Palvelujen käyttökonteksti Rajapinta- ja toimintapolitiikkamäärittelyt korostuvat palveluiden määrittelyn ja suunnittelun aikana sekä silloin, kun palveluja käyttäviä sovelluksia ja prosesseja määritellään ja suunnitellaan. Sovellusten suorituksen ja käytön aikana palvelun toiminnan on noudatettava määrittelyjä, mutta varsinaiset määrittelydokumentit eivät yleensä ole niin olennaisia kuin suunnitteluvaiheessa. Palvelun rajapintakuvauksissa määriteltyjen viestien ja tietomallien sekä sijaintitietojen perusteella palveluja liitetään toisiinsa ja niitä käyttäviin sovelluksiin dynaamisesti sovelluksia käytettäessä. Toimintapolitiikat voivat ohjata palvelun ajonaikaista toimintaa, ja palvelujen suoritusympäristössä voidaan seurata palvelujen käyttöä, suorituskykyä ja tehokkuutta. Palvelujen käytön aikana palvelun tarjoajat ja käyttäjät liitetään toisiinsa suorituksen aikaisen infrastruktuurin avulla palvelujen kuvauksissa määritellyllä tavalla. On huomioitava, että samoista palveluista (ja samoista rajapintamäärittelyistä) voi usein olla useita instansseja suoritusympäristössä, ja tunnisteiden yhdenmukainen käsittely sekä viestien välitys oikeisiin osoitteisiin on erittäin tärkeää ratkaisujen toiminnan varmistamiseksi. Vaihdettujen tietojen tulkitsemisen käytön aikana tulisi nojautua riittävän tarkkoihin suunnittelun aikaisiin määrittelyihin, mutta osa tulkinnasta voi liittyä kulloiseenkin käyttökontekstiin (MacKenzie 2006). 3.3 Palvelujen toteutus- ja hankintavaihtoehdot (enterprise components) Viitearkkitehtuurin komponenttikerroksen avulla käsitellään ohjelmistokomponentteja, jotka toteuttavat palveluita tai niiden operaatioita (palvelukomponentit). Komponenttien on vastattava sekä palveluiden toiminnallisiin että ei-toiminnallisiin vaatimuksiin. Komponenttikerroksen toteutus on siis avainasemassa, kun palvelutasosopimuksen tai vaikkapa toimintapolitiikkamäärittelyjen suorituskyky-, ja muita laadullisia vaatimuksia toteutetaan. Lisäksi komponenttikerros tukee palvelujen koostamista ja kerrostamista ja piilottaa palvelujen käyttäjiltä komponentin toteutusyksityiskohdat. Komponenttikerroksen avulla varmistetaan, että tietotekninen toteutus vastaa loogista palvelukuvausta. Koska toteutus on piilossa, voi yhden loogisen palvelun toteutukseen käyttää useita eri sovelluksia tai kirjastoja. Palvelun hyödyntäjä on riippuvainen vain yhdestä palvelukuvauksesta, eikä sen 32

33 Osa 2: prosessien ja palvelujen määrittely ja suunnittelu tarvitse välittää siitä, miten palvelun tiedot ja toiminnallisuus on saatu aikaan. Rajapinta voi myös piilottaa osan muutoksista, joita palvelun toteutukseen tehdään. Komponentit (palvelutoteutukset) voivat myös kutsua muita sovelluspalveluja, mikä tekee viitearkkitehtuurin palvelu- ja komponenttitasoista kerroksittaisen. Se myös mahdollistaa erikokoisten atomisten ja koostettujen palvelujen käyttämisen, esimerkiksi yleiskäyttöisten palvelujen hyödyntämisen sekä tiettyihin prosesseihin vakioidulla tavalla että yksittäisissä käyttötilanteissa. Tässä luvussa käsitellään palvelutoteutusten tunnistamismahdollisuuksia (valmiiden sovellusten ja määritysten pohjalta) ja hankintavaihtoehtoja palvelujen tarjoamisen näkökulmasta Käytettävissä olevien palvelujen tunnistaminen Käytettävissä olevia palveluja kartoitettaessa on kyettävä määrittelemään, "millä tasolla" palvelu on käytettävissä. Tällä seikalla on huomattavasti vaikutusta siihen, kuinka palvelu hankitaan tai toteutetaan palvelun toteutuskomponenttikerroksessa, ja kuinka paljon työtä palvelun käyttöönotto vaatii. "Käytettävissä olevista palveluista" onkin määriteltävä, millä tasolla ne ovat käytettävissä. Alla on kuvattu tähän liittyviä vaihtoehtoja: Valmiit tuotteisiin toteutetut rajapinnat ja sovelluspalvelut tarjoavat nopeimman lähtökohdan palvelukomponenttien toteutukselle. Optimitilanteessa saatavilla on jopa web-sovelluspalvelurajapintoja, joita käytetään samantyyppisesti kuin organisaatiossa jo käytettyjä sovelluspalveluja. Nykyisellään kuitenkin myös web-sovelluspalvelutekniikoita (web services) voidaan soveltaa hyvin monin eri tavoin, vaikka hyödynnettäisiinkin soveltamistapoja rajoittavia profiilimäärityksiä, kuten WS-I -profiilit (ks. myös oppaan osa 3). Myös toisen tyyppiset rajapinnat kuin websovelluspalvelurajapinnat voidaan liittää SOA-arkkitehtuuriin esimerkiksi gateway-tukipalvelujen tai palvelualustan tarjoamien ominaisuuksien avulla. Rajapintoja hyödynnettäessä on kiinnitettävä huomiota sekä tekniseen että sisällölliseen yhteensopivuuteen. Käytössä olevia ja toteutettavia valmiita rajapintatyyppejä ovat mm.: valmiit web-sovelluspalvelurajapinnat (esim. SerAPI:ssa määritellyt DRG-, OID-, APRjne., tuotekohtaiset web-sovelluspalvelurajapinnat), http- ja XML-tekniikoilla toteutetut rajapinnat (esim. HL7 Finland Common Services), HL7 versio 2- ja versio 3 (joillakin sovellusalueilla) rajapinnat, CDA R1 ja R2 -rajapinnat, järjestelmien integroinnissa nykyisin käytetyt muut tietokanta- ja viestirajapinnat. Saatavilla olevia rajapintamäärittelyjä voidaan hyödyntää esimerkiksi tuotteita kartoitettaessa tai edelleen kehitettäessä, ja määrittelyjä voidaan verrata tilannekohtaisiin vaatimuksiin sekä teknisesti että sisällöllisesti: rajapintastandardit ovat läpikäyneet hyväksymismenettelyn ja ne on usein kehitetty yleiskäyttöisiksi. On kuitenkin syytä kiinnittää huomiota mm. siihen, kuinka laaja toteutusjoukko määritykseen liittyy, onko standardi määritelty tarkasti myös teknisellä tasolla, ja kuinka tarkasti standardien eri toteutukset toimivat yhdessä (Mykkänen & Tuomainen 2007). muut saatavilla olevat rajapintakuvaukset voivat liittyä mm. tuotekohtaisiin ratkaisuihin tai kehitteillä oleviin standardeihin. 33

34 Palveluarkkitehtuurin soveltaminen terveydenhuollossa Tuotteisiin ja järjestelmiin toteutetut piirteet ilman valmista rajapintaa tarjoavat toisinaan mahdollisuuksia sisällyttää tarvittavia ominaisuuksia SOA-arkkitehtuuriin. Näitä piirteitä voidaan "muuttaa sovelluspalveluiksi" eri tavoin: tuotetta muokkaamalla, rakentamalla adaptereita, tai käyttämällä integrointi- tai palvelualustojen ominaisuuksia (tietokantaliitännät, screen scraping jne.) tarvittavien tietojen tai toimintojen saantiin. Käyttöliittymien tarkastelu on myös käyttökelpoinen tapa tunnistaa käytettävissä olevia tietoja ja toiminnallisuuksia. Muualla tunnistetut sovelluspalvelujen tarpeet ja roadmap-dokumentit tarjoavat usein yleisellä tasolla tunnistettuja ja nimettyjä sovelluspalveluja. SerAPI-hankkeessa on käyty läpi suuri määrä tämän tyyppistä materiaalia avoimista ja tiettyyn infrastruktuuriin sitoutuneista ratkaisumalleista, joista osa on myös toteutettu esimerkiksi erilaisissa kansainvälisissä hankkeissa. Palvelukomponentin toteutuksen työmäärä Avoimet rajapintamäärittelyt, standardit Tuotteeseen toteutettu tuotekohtainen rajapinta Tilannekohtaiset, paikalliset rajapintamäärittelyt Yleisesti tunnistetut rajapintatarpeet, Tuotteiden ja roadmap-mallit järjestelmien piirteet ilman rajapintoja Tuotteeseen toteutettu standardirajapinta Käytettävissä olevien mallien lukumäärä Kuva 6. Palvelujen ja rajapintojen hankintavaihtoehtojen eroja. Valmiiksi toteutettuja palveluita ja rajapintoja on tyypillisesti vähemmän kuin potentiaalisesti käytettävissä olevia toiminnallisuuksia, tietoja ja määrityksiä. Toisaalta valmiiksi toteutetut palvelut tarjoavat huomattavasti nopeamman hyödyntämispolun kuin määritykset, järjestelmistä ilman rajapintaa tunnistetut ominaisuudet tai roadmap-dokumentit, ja standardien mukaisia rajapintoja tukevat välineet ja oppaat voivat helpottaa toteutusta entisestään (ks. kuva 6). Käytössä olevien järjestelmien pohjalta tapahtuvaa palvelujen tunnistamista käsitellään muuten kuin valmiiden rajapintojen osalta luvussa Sovelluspalvelujen hankinta ja kehittäminen Sovelluspalvelujen käyttöön saamiseksi on runsaasti eri vaihtoehtoja, jotka nojautuvat joko organisaation omien tai ulkoisten voimavarojen käyttöön (kuva 7). Perinteisten "osta tai rakenna" - vaihtoehtojen lisäksi on mahdollista teettää tai suunnitteluttaa komponentteja, ostaa sellaisenaan käytettäviä, räätälöitäviä tai paikallisesti mukautettavia komponentteja, käyttää valmiita sovelluskehyksiä komponenttien tuottamiseen, rakentaa sovittimia vanhoihin järjestelmiin tai kirjautua käyttämään sovelluspalveluja verkon kautta. Palveluarkkitehtuurin kehittämisessä kaikki vaihtoehdot 34

35 Osa 2: prosessien ja palvelujen määrittely ja suunnittelu ovat olemassa, mutta niistä on korostettu erityisesti vanhojen järjestelmien kapselointia palvelurajapinnoilla ja verkon yli muualta tarjottavien ohjelmistopalvelujen käyttöä. Olennaisia hankintaratkaisuja ovat mm.: tulevatko palvelut "itse hallittaviksi", ja millaista palvelin- tai muuta infrastruktuuria tällöin tarvitaan, kuinka syvälle ratkaisut vaikuttavat olemassa oleviin järjestelmiin (invasiveness), millaiset palvelutasosopimukset (SLA) palveluihin liitetään, erityisesti ulkopuolisten palvelujen hyödyntämisessä. Osta valmis tuote Toteuta itse Teetä uusi järjestelmä Suunnitteluta ulkopuolisella Osta ja räätälöi järjestelmä Vuokraa ulkopuoliselta (ASP) Osta ja integroi komponentit Toteuta vanhan järjestelmän sovittimena Kirjaudu käyttämään verkon kautta Laajenna sovelluskehyksestä Kuva 7. Tietojärjestelmäkomponenttien hankintavaihtoehtoja. Palvelukomponenttien toteuttamisessa on kaksi perusvaihtoehtoa: rajapinta edellä tai toteutus edellä (Erl 2005). Rajapintalähtöinen toteutus perustuu usein prosessimallinnukseen tai vaatimusten mallintamiseen, ja voi tuottaa usein karkeajakoisia rajapintoja. Toteutuslähtöinen palvelurajapintojen tekeminen perustuu usein rajapintamäärittelyjen generointiin esimerkiksi toteutusluokista ja johtaa helposti hienojakoisiin API-rajapintoihin. Kehitysstrategia yhdistääkin yleensä karkeajakoisemmasta hienojakoisempaan etenevän tarkentuvan määrittelyn ja olemassa olevista osista koostamalla ja mukauttamalla (Perepletchikov ym. 2005; Honey ym. 2006a) (ks. WS-opas osa 1, luku 3). Ylhäältä alas -lähestymistavan etuna on vapaus valita ja määritellä tilanteeseen sopivat tai yhdenmukaiset palvelujen karkeustasot ja vastuunjaot. Se kuitenkin vaatii enemmän analyysi- ja suunnittelutyötä kuin alhaalta ylös -strategia, ja uudelleenkäyttö sekä yhteensopivuus vanhojen sovellusten kanssa vaativat erityishuomiota. Alhaalta ylös -strategian etuina ovat nopeus, tarkkuus ja uudelleenkäyttö, mutta sen riskejä ovat "liian pienten palvelujen" lisäksi yleistämisen vaikeus, tarvittava olemassa olevien järjestelmien tai ratkaisujen tuntemus sekä mahdollinen lukkiutuminen vanhoihin toimintatapoihin tai prosesseihin. Web-sovelluspalvelujen osalta SerAPI-hankkeen eräänä tuloksena on saatavilla "Välineet ja web services" -selvitys, joka sisältää yksinkertaisia kokeiluja eri välineillä sekä "rajapinta edellä"- ja "toteutus edellä" -tyyppisistä web-sovelluspalvelujen toteuttamisesta ja rajapintamäärittelyjen sekä koodin generoinnista. 35

36 Palveluarkkitehtuurin soveltaminen terveydenhuollossa Hankintojen osalta oppaan osassa 1 (luku 6) käsitellään eri hankintatapoja ja hankintaprosessia, ja sovelletaan niitä suhteessa sovelluspalveluihin ja palveluarkkitehtuuriin. 3.4 Palvelujen tuottaminen taustajärjestelmistä (operational systems) Taustajärjestelmillä on moninainen merkitys palveluarkkitehtuurissa. Toisaalta ne muodostavat pohjan tarjoten mahdollisuuksia valmiiden palvelujen keräämiseen, toisaalta niiden kautta on saatava toteutettua rajapintojen ja sovelluspalvelujen takana olevat tiedot ja toiminnot. Itse taustajärjestelmien uusiminen tai piilottaminen voi olla yksi palveluarkkitehtuurin ajureista. Palvelujen tuottamisella olemassa olevien järjestelmien pohjalta pyritään suojaamaan niihin tehtyjä investointeja ja hyödyntämään niihin kertynyttä tietoa, toiminnallisuutta ja osaamista. Olemassa ja käytössä olevista sovelluksista voidaan parhaimmillaan muodostaa nopeastikin pohja, jonka päälle voidaan rakentaa koostettuja sovelluksia, prosesseja tai palveluja. Se, kuinka taustajärjestelmistä voidaan saada käyttöön sovelluspalveluja, riippuu kuitenkin suuresti taustajärjestelmän luonteesta. Mikäli kyseessä on valmisohjelmisto tai sovellus, jonka muuttaminen tai muokkaaminen ei onnistu, on vaihtoehtoja paljon vähemmän kuin tilanteissa, jossa sovellus on muokattavissa tai itse rakennettu (Arsanjani 2004). Lähtökohtana voi myös olla, että tiettyyn tarpeeseen vastaava sovelluspalvelu tai rajapinta on saatava sovitettua vanhaan järjestelmään. Tarkka menettelytapa, jolla vanhasta järjestelmästä hankitaan tai laajennetaan sovelluspalveluja, riippuu tehtävästä sovelluksesta, mutta sisältää karkeasti ottaen seuraavat vaiheet: palveluehdokkaan tai rajapintatarpeen tunnistaminen ja rajaus, ratkaisun sisällön tarkentaminen, sopivien integrointimekanismien valinta, rajapinnan suunnittelu ja toteutus. Prosessi muistuttaa suuresti tyypillistä, selvästi rajattua sovellusintegraatioratkaisun määrittelyä, ja siinä voidaan soveltaa pitkälti samantyyppisiä menetelmiä (esimerkiksi Mykkänen ym. 2004). Luonteva tapa lähteä tunnistamaan sovelluspalveluja olemassa olevista sovelluksista on tutkia käytössä olevien tietojärjestelmien niitä piirteitä, jotka voisivat muodostaa yleiskäyttöisiä tai tarkkoihin käyttötilanteisiin vastaavia sovelluspalveluja. Tätä varten voidaan: tunnistaa järjestelmän keskeisimmät toiminnot ja tiedot sekä erityisesti ne osat, joita olisi tarpeen käyttää muissa tai uusissa prosesseissa tai sovelluksissa, määritellä kunkin järjestelmän valmiit rajapinnat, joilla niiden tietoja ja toimintoja pystytään käyttämään, tunnistaa uudet tarvittavat rajapinnat, määritellä, mitkä eri järjestelmien keskeisimmät toiminnot ja tiedot, joista valitaan usein ydinjärjestelmään liittyviä), joista tarvitaan eniten (useissa yksiköissä, prosesseissa tai muissa järjestelmissä) tietoja ja toimintoja, tunnistaa, millaisia muutoksia tai liitäntöjä on mahdollista tuottaa kuhunkin järjestelmään, tunnistaa erityyppiset liitännät järjestelmien välillä, tunnistaa järjestelmät, joita halutaan kehittää, korvata, säilyttää jne. Näitä toimenpiteitä tukevia kuvauksia ovat mm. tietojärjestelmäkartat, sovellusten tietohakemistot ja muu järjestelmädokumentaatio, käyttöliittymät (kuvauksineen ja kaavioineen), käyttöohjeet ja kuvaukset sovellusten toiminnoista, sekä kuvaukset jo järjestelmässä saatavilla olevista rajapinnois- 36

37 Osa 2: prosessien ja palvelujen määrittely ja suunnittelu ta. Usein käyttäjä- tai hallintatarpeista tiedetään jo selvästi, mihin seikkoihin järjestelmästä tarvittaisiin yleiskäyttöinen liittymä tai sovelluspalvelu. Tietojärjestelmäkartoilla kuvataan mm. tietojärjestelmäkokonaisuuden osajärjestelmiä ja niiden välisiä suhteita (ks. kuva 8). SerAPI-hankkeessa on hyödynnetty eri sairaanhoitopiirien tietojärjestelmäkarttoja, integraatiodokumentaatiota ja materiaalia valmiista järjestelmistä mm. rajapintojen määrittelyissä, mutta myös prosessimallinnuksen esimerkeissä palvelujen tunnistamista varten vanhoista järjestelmistä. Organizational invoicing Data warehouse Financials Invoice handling, analysis Daily reporting Statistical reporting, QA Billing and administrative information grouping Patient billing Invoicing, monitoring, reporting Regional IS Orders, personnel Legacy systems, integration platform Patient registry Patient billing, Procedure statistics, Radiology, Case management Psychiatry and drug abuse, outpatient EPR Hospital infections reg. Anaesthesiology + ICU IS Neonatal & maternity IS Core HIS: Referrals, Bookings, Inpatient and outpatient management, orders, population registry Core EPR: electronic patient record, discharge summaries, medication management, digital dictation Surgery operations management Gastroenterology, other departmental systems Laboratory, Pathology, Blood orders Radiology IS PACS Pharmacy IS Patient group specific quality assurance Research statistics and reporting IS Duty, personnel and salary management Education, passage control Telephone network services Materials management Meal ordering Care and operations support systems Case and archive management Intranet and internet systems Forms repository Authority networks etc. Administrative systems Kuva 8. SerAPI-hankkeen erään osapuolen sairaalan tietojärjestelmät, yleistetty ja yksinkertaistettu kuva. (Mykkänen ym. 2007b). On myös mahdollista kuvata vanhojen järjestelmien toimintoja esim. käyttöliittymäkuvien tai kaavioiden (ks. kuva 9) avulla tai tutustumalla järjestelmädokumentaatioon. Valittujen toimintojen käyttämiseksi vanhoista järjestelmistä on usein erilaisia vaihtoehtoja, tietokantasovittimien, etäohjelmakutsujen tai järjestelmiin liitettävien sovelluspalvelinadapterien kehittämisestä ruutukaappausohjelmistojen käyttöön. Vaikka sovelluspalveluun saadaan helposti erittäin tarkka ja tiettyyn tilanteeseen sopiva malli vanhoista järjestelmistä, palvelun rajapinnasta on kuitenkin pyrittävä tekemään yleiskäyttöinen ja tarkoituksenmukainen. Vaikka komponentin sisäinen toteutus perustuisikin vanhaan sovellukseen tai tietokantaan, on sen uudelleenkäytettävyyteen kiinnitettävä huomiota yleistämällä. Sopivien integrointimekanismien ja integrointipisteiden valintaan taustajärjestelmistä vaikuttaa merkittävästi järjestelmien sisäinen arkkitehtuuri ja avoimuus: miten ja mihin kohtiin taustajärjestelmiä liittymien rakentaminen on mahdollista. Vakioiduissa sovelluksissa saattaa olla vakiorajapinnat, jotka ovat ainoa mahdollisuus päästä käsiksi sovellusten tietoihin, ja näiden yhdistäminen tavoitetilan paikallisiin prosessimäärittelyihin ei ole välttämättä mahdollista. Lisäksi on huomioitava valittu integroinnin peruslähestymistapa, jo sovelluksissa käytetyt rajapintatekniikat, sovelluksen sisäinen logiikka joka vaikuttaa rajapinnan seikkoihin ja tarvittavien välineiden saatavuus ja käyt- 37

38 Palveluarkkitehtuurin soveltaminen terveydenhuollossa tömahdollisuudet (Mykkänen ym. 2004). Toisaalta on muistettava, että järjestelmiin toteutetut integrointiratkaisut on mahdollista yhdistää tai mukauttaa osin arkkitehtuurin ylemmissä kerroksissa. UPO Henkilötietojen käsittely Lähetetietojen käsittely Ajanvaraus Työohjelmat Potilaan vallinta entisillä tiedoilla haku Uuden potilaan valinta Uuden potilaan tietojen kirjaami nen Potilaan tietojen katselu Entisten muutosten käsittely Potilaan tiedot Potilaan tietojen muuttaminen Lähetteen muut tiedot Ajanvaraus Vapaat ajat Vastaanottoaikojen siirto Ennakkoajanv araus potilaskohtain en kiinnittäminen Resurssit mm. huone laite henkilö Kalenteri mm. kuukausi, viikko, päivä, klo Lisäksi muita toimintoja yhteensä 13 kohtaa Ajan sitominen / vapauttaminen Kuva 9. Käyttöliittymäkaavio vanhasta Musti-järjestelmästä. 3.5 Prosessikerros Palvelukeskeisen arkkitehtuurin perusajatuksen kuvaamisessa viitearkkitehtuurin kerrokset ovat suureksi avuksi. Sama pätee järjestelmien suunnitteluun; viitearkkitehtuurin kerrosten välisten rajaaitojen huomiointi suunnitteluvaiheessa helpottaa myöhemmin kerrosten sisällä tapahtuvien muutosten toteuttamista ilman, että toisten kerrosten toteutuksiin tarvitsee puuttua. Kuitenkin ryhdyttäessä implementoimaan SOA-suunnitelmia käytäntöön on olennaisen tärkeää ymmärtää, että prosessit ovat vain yhdenlaisia palveluita. Loogisesti prosessit ovat arkkitehtuurissa palveluita ylemmällä tasolla, mutta käytännössä ne ovat usein hiukan monimutkaisempia ja erikoistuneempia palveluita. Tämän muistaminen helpottaa siirtymistä suunnittelusta toteutusvaiheeseen. (Foody 2005) Samaa ajatusta tukee myös huomio rajapinnan ja toteutuksen erottaminen toisistaan. Palvelun toteutus voi itsessään olla prosessi. On siis tarpeetonta yrittää tehdä keinotekoisia rajauksia palveluiden ja prosessien välille implementointivaiheessa, kun ero niiden välillä on lähinnä kiinni katsantokannasta. Prosessikerros palveluarkkitehtuurissa keskittyy tyypillisesti määriteltyjen työnkulkujen edistämiseen ohjaamalla eri sovelluspalvelujen kutsumista ja tehtävien välittämistä eri suorittajille. Prosessikerros eriyttää prosessien ohjauslogiikan siten, että muutokset prosessien etenemiseen voidaan tehdä puuttumatta alempien arkkitehtuurikerrosten ratkaisuihin. Toiminnan ohjauksen erottaminen toteutuksesta helpottaa myös prosessien seurantaa. Selkeästi määritelty prosessi mahdollistaa prosessien etenemisnopeuden seurannan ja siten mahdollisten pullokaulojen havaitseminen ja prosessien parantaminen helpottuu. Prosessien etenemisestä saatavia tietoja voidaan hyödyntää myös tilastollisiin tarkoituksiin. Prosessien etenemiseen vaikuttavien liiketoimintasääntöjen yhdistäminen kiinteästi prosessikuvauksiin ei prosessien muokattavuuden ja liiketoimintasääntöjen ylläpidettä- 38

39 Osa 2: prosessien ja palvelujen määrittely ja suunnittelu vyyden kannalta ole järkevää, joten liiketoimintasääntöjen tulisi olla löyhästi kytkettyinä prosesseihin ja sijaita omassa järjestelmässään (Business Rules Engine), josta niitä tarpeen mukaan hyödynnetään. Terveydenhuollossa on kuitenkin käynnissä runsaasti erisuuntaisia prosesseja, jotka vaikuttavat toisiinsa. Esimerkiksi yksittäisen potilaan ja työntekijän työnkulut poikkeavat huomattavasti toisistaan. Prosessin etenemistä kuvataan tyypillisesti tietyn tehtävän ja tuloksen edistämisen näkökulmasta läpi erilaisten toimintojen ja toimipisteiden. Toisaalta myös tietyn toimipisteen tai työntekijän tehtävistä pyritään muodostamaan järjestelmällinen ja selkeä kokonaisuus. Terveydenhuollon prosessien seuranta ja mittaukset mahdollistavat mm. hoitotakuun toteutumisen seurannan. Prosessien täydellinen automatisointi on terveydenhuollossa käytännöllisesti katsoen mahdotonta. Prosessien etenemisen arvaamattomuus ja siitä seuraava valtava eri variaatioiden lukumäärä tekee kaikkien mahdollisten prosessien kuvaamisesta mahdotonta. Kuitenkin kuvattaessa prosesseja tarpeeksi tarkalla tasolla tarkastelu siirtyy niin pieniin osiin, että muutokset niissä ovat pieniä, tai olemattomia. Esimerkiksi asiakirjojan lähettäminen osastolta toiselle on hyvin samankaltainen kerrasta toiseen, vaikka prosessi, johon asiakirjan lähettäminen liittyy, itsessään olisikin hyvin monimutkainen. Täydellisesti automatisoitujen ja täysin automatisoimattomien prosessien väliin kuitenkin mahtuu monia erilaisia tapoja, joita voidaan hyödyntää terveydenhuollon prosessien virtaviivaistamisessa ja toiminnan tehostamisessa. Esimerkiksi asiakirjojen toimittaminen oikeille osapuolille oikeaan aikaan on tehtävä, joka on toiminnaltaan helposti automatisoitavissa: päätös milloin ja kenelle mikäkin dokumentti lähetetään perustuu usein ennalta sovittuihin dokumenttikohtaisiin käytäntöihin ja on siten helposti määriteltävissä ja toteutettavissa ohjelmallisesti. Tehtävän automatisointi vapauttaisi ihmistyövoimaa vähemmän koneelliseen työhön ja parantaisi työn tehokkuutta Ihmistä tukeva järjestelmä ja ihmisen tukema prosessi Prosessiautomaatioajattelun eri näkökulmia edustavat human-assisting system ja human-assisted process; suomennettuna vapaasti ihmistä tukeva järjestelmä ja ihmisen tukema prosessi. Ihmistä tukeva järjestelmä on järjestelmä, joka auttaa käyttäjää suorittamaan tietyn tehtävän. Varsinaisesta prosessin etenemisestä vastaa käyttäjä. Prosessimoottorilla ei ole ymmärrystä prosessin etenemisestä, eikä prosessimoottori päätä mikä on seuraava prosessiaskel. Käyttäjä tietää, mitä prosessiaskelia seuraavaksi suoritetaan ja mitä ohjelmistoa (human-assisting system) siinä tarvitaan. Edelliseen verrattuna ihmisen tukema prosessi toimii juuri päinvastoin. Prosessi etenee automaattisesti järjestelmän ajamana. Ainoastaan tilanteissa joissa järjestelmä ei pysty etenemään sille annettujen toimintaohjeiden (liiketoimintasäännöt) avulla, ihmisen osallistuminen prosessin suoritukseen on tarpeen. Nämä kaksi eri näkemystä voidaan tulkita myös vanhan ja uuden ajattelun edustajina. Näin tulkittaessa ihmistä tukeva järjestelmä on vanhaa ajattelutapaa; se on periaatteessa kokoelma ohjelmia, joiden avulla käyttäjä saa suoritettua tarvittavat tehtävät prosessin edistämiseksi. Prosessinohjauksesta ei ehkä voida puhua sen kohdalla. Esimerkiksi toimisto-ohjelmapaketit voidaan käsittää ihmistä tukevina järjestelminä. Ihmisen tukema prosessi toimii kuin liukuhihna: käyttäjän eteen tuodaan sekä ongelma että työkalu sen ratkaisemiseksi. (Jenz 2003) Molemmat lähestymistavat ovat yhtä käyttökelpoisia. On vain kyse siitä, mihin ympäristöön ratkaisua yritetään sovittaa. Esimerkiksi terveydenhuollon asiakaslähtöisissä prosesseissa ihmistä tukeva lähestymistapa on mukautuvampi vaihtoehto. Prosessin kontrolloija (asiantuntija, hoitaja, lääkäri 39

40 Palveluarkkitehtuurin soveltaminen terveydenhuollossa tms.) on vastuussa siitä mitä seuraavaksi tehdään (prosessin eteneminen, päätökset), mitä välineitä (tietojärjestelmät) siihen tarvitaan sekä mitä tietoja tuotetaan. Toisaalta esimerkiksi tuotettujen potilasasiakirjojen käsittelyssä voidaan hyödyntää ihmisen tukema prosessi -lähestymistapaa. Asiakirjojen jakelu ja arkistointi on usein määrätty asetuksissa, laissa tai säännöissä, joten se voidaan sälyttää automaattisen järjestelmän vastuulle, jolloin asiakirjan tuottajan ei siis tarvitse pohtia asiakirjan lähettämiseen ja arkistointiin liittyviä asioita Vaihtoehtoja prosessikerroksen toteutukseen Prosessikerroksen voi toteuttaa usealla eri tavalla. Tässä käydään läpi lyhyesti neljä erityyppistä toteutustapaa. Prosessimoottori (Business Process Engine, BPE) on yleisesti SOA-arkkitehtuuriin liitetty tapa prosessien ulkoistamiseen palveluista ja niiden keskitettyyn hallintaan. Se perustuu workflow engine - ajatukselle: prosessit on kyetty määrittelemään riittävän tarkasti, ja prosessien etenemistä ohjaa keskitetty prosessin kontrolloija. Prosessimoottori ohjaa ennalta määritellyllä tavalla viestien ja vastausten liikkumista (sovelluspalvelujen kutsuja), säilyttää tiedon prosessin tilasta sekä mahdollistaa prosessien seurantaa, poikkeamien hallintaa ym. Se voi myös tuottaa teknistä tietoa prosessien etenemisestä, virhetilanteista sekä toiminnallista tietoa prosessien kulusta, läpimenoajoista, läpikäytyjen prosessien lukumääristä jne. Prosessimoottorin käyttö edellyttää prosessin askelten melko determinististä määrittelyä tai poikkeustilanteiden kattavaa hallintaa. Hyötyjen saavuttamiseksi on riittävän tarkasti tunnettava, kuinka prosessi etenee. Prosessimoottoria käytettäessä on yleensä otettava kantaa sekä tiedonkulun että työnkulun etenemiseen, ja prosessimäärittelyt on tehtävä melko hienojakoiselle karkeustasolle. Prosessimoottorin käyttö tarkoittaa sitä, että uuden prosessin lisäämiseksi tarvitaan vain prosessimoottorin tukemassa muodossa oleva prosessimäärittely, ja uusi prosessi on valmis käytettäväksi/suoritettavaksi. Uusissa järjestelmissä voidaan palveluiden suunnitteluvaiheessa ottaa huomioon prosessimoottoriin (tai oikeammin sen ajamiin prosessimäärittelyihin) sijoitetun prosessilogiikan, mutta vanhoissa järjestelmissä ja niistä johdetuissa palveluissa logiikka on sisäänrakennettuna. Jos järjestelmän tarjoama sovelluslogiikka huomioidaan prosessimoottorissa tai prosessimäärittelyissä, se tekee palvelun tai sen alla olevan järjestelmän korvaamisen myöhemmässä vaiheessa vaikeammaksi; palvelun tai järjestelmän tarjoama sovelluslogiikka tulee toteuttaa myös korvaavassa palvelussa tai järjestelmässä. Prosessin ohjausta ei ole välttämätöntä keskittää yhteen pisteeseen, vaan vastuu etenemisestä voidaan hajauttaa prosessin eri osapuolille. Ohjeet prosessin kulusta voi joko jakaa etukäteen osapuolille, tai sitten prosessimäärittelyjä voi myös kuljettaa dokumenttien mukana. Kullakin osapuolella olisi tieto miten missäkin tilanteessa tulisi toimia. Tällainen malli voisi toimia tilanteessa, jossa prosessit muuttuvat tapauskohtaisesti. Se mahdollistaisi myös prosessin muutokset suorituksen aikana, ts. osapuolet tekisivät tarvittavat muutokset prosessinohjausdokumenttiin. Ajatus on jonkin verran päällekkäinen liiketoimintasääntömoottorin käyttötarkoituksen kanssa. Kuitenkin liiketoimintasäännöt liittyvät pikemminkin solmupisteiden (prosessin haarautumispisteiden) sisältämään päätöslogiikkaan kuin itse prosessin sisältöön. Keskitetty prosessinohjaus ei vaadi prosessimoottoria tuekseen. Sama toiminnallisuus voidaan toteuttaa osana arkkitehtuuria erikseen rakennetuilla prosessinohjaukseen tarkoitetuilla palveluilla. 40

41 Osa 2: prosessien ja palvelujen määrittely ja suunnittelu Perusperiaate on sama kuin prosessimoottorissa, mutta valmista prosessialustaa ei ole; sama palvelualusta toimisi pohjana sekä palveluille että prosesseja käskyttäville prosessipalveluille.. Prosessin ohjaus voidaan nostaa arkkitehtuurin ylimmälle tasolle, käyttöliittymätasolle. Tällöin prosessi etenee käyttöliittymäkerrokseen (esim. portaali) tehdyn toimintalogiikan pohjalta. Prosessilogiikan siirtäminen tähän kerrokseen vaikeuttaa ylläpitoa ja heikentää arkkitehtuurin tarjoamaa joustavuutta, mutta toisaalta se mahdollistaa vanhojen sovellusten hyödyntämisen osana prosessia ilman, että niiden päälle tarvitsee rakentaa kovin monimutkaisia välikerroksia. Riippumatta prosessikerroksen toteutustavasta, prosessikuvauksen teko voidaan tehdä useimmiten saman kaavan mukaan. Prosessikuvausten tuottamisen vaiheista on kerrottu luvussa Käyttöliittymät Tässä luvussa kuvataan portaalien ja muiden palvelupohjaisten sovellusten kehittämiseen soveltuvia käyttöliittymävaihtoehtoja. SOA-pohjaisissa ratkaisuissa voidaan usein nojautua vanhojen sovellusten käyttöliittymiin siltä osin kuin niiden käyttöä jatketaan, mutta yleensä uusien sovellusten ja prosessien (jotka ovat SOA:n edistyessä yhä yleisempiä) esittämiseen myös käyttäjille tarvitaan joustavia ratkaisuja. Perusvaihtoehtoja SOA-ratkaisujen käyttöliittymien toteuttamiseen ovat: portaalit (usein integroituna ESB-infrastruktuuriin), jota on usein suositeltu etenkin uusissa sovelluksissa. Portletit ovat tarjolla oleva vaihtoehto "pikkukäyttöliittymiksi" palveluihin, ja mm. WSRP (web services for remote portals) on ko. käyttötapaan liittyvä avoin määrittely. vanhat järjestelmät: joko sellaisenaan (muutoksia ja hyötyjä vain muualle kuin sinne, missä järjestelmää käytetään), tai muokattuna. Valittava, mitä sijoitetaan ulkoiseen prosessilogiikkaan, mitä jää järjestelmään. On huomioitava, että integrointi on mahdollista myös käyttöliittymätasolla, jolloin tyypillisesti ohitetaan palvelinpohjaiset monen käyttäjän SOApalvelut. Tällainen vaihtoehto voi olla helppo käyttäjän tai käyttöönoton näkökulmasta, koska käyttäjä ei huomaa muutosta tai muutos on pieni. Tämä vähentää muutosvastarintaa ja helpottaa käyttöönottoa, mutta usein vanhojen järjestelmien liittämisessä uudella tavalla osaksi prosesseja tai kokonaisarkkitehtuuria myös käyttöliittymiin tarvitaan muutoksia, tai yksi keskeisistä tarpeista voi olla käyttöliittymien uusiminen. myös asiainhallintajärjestelmä yhdistettynä prosessin ohjaukseen voi tarjota käyttöliittymäratkaisuja, ja esimerkiksi käyttäjien työlistat voivat liittyä hyvin läheisesti palveluarkkitehtuurin palveluihin. On huomattava, että portaalin käytön ei tarvitse tapahtua pelkästään tietokoneen selaimella, vaan portaaleja voidaan yhdistää monikanavaisesti erilaisiin käyttöliittymäratkaisuihin. SOA-pohjaisten sovellusten käyttöliittymäratkaisuista yleisimmin käytetty malli nykyään on portaali. Erityisesti SOA:n yhteydessä käsitellään yritysportaaleja (enterprise portals), joissa on käyttäjän tarvitsemien tietojen, sivujen ja linkkien lisäksi pääsy keskeisiin käyttäjien tarvitsemiin sovelluksiin yhdenmukaisen käyttöliittymän kautta. Yleisiä portaaleihin liitettyjä piirteitä ovat lisäksi portaalin henkilökohtaistaminen ja muokattavuus (Hazra 2002). Sen mukaan, keskitytäänkö portaalissa tiedon saatavuuteen vai sovellusten käyttöön, kyseessä voi olla tietoportaali tai sovellusportaali. Erityisesti sovellusportaalit ovat palveluarkkitehtuurin kannalta keskeisiä. Sovellusportaalin kautta käyttäjä voi ottaa käyttöön tarvitsemiaan työkaluja ja palveluita. Hyviä esimerkkejä yhdenmukaisista asiakasportaalipalveluista ovat lentojen varauspalvelut, joista voi helposti paitsi löytää sopivan lentomatkan myös varata ja maksaa sen saman tien. Lisäsi saman palvelun kautta on tavallisesti 41

42 Palveluarkkitehtuurin soveltaminen terveydenhuollossa tarjolla esimerkiksi majoitus- ja muiden kulkuneuvojen varauspalveluita. Terveydenhuoltoorganisaatioiden portaaliratkaisuja ovat toistaiseksi olleet esimerkiksi (toisinaan myös käyttäjäkohtaisesti) web-sivulle kootut (linkki)kokoelmat käytössä olevista sovelluksista ja muista tarvittavista web-sivustoista ja -palveluista. Portaalin toteutuksissa on usein käytetty palveluarkkitehtuurin sijaan perinteisempiä sovellusten integrointitapoja, kuten kahdenkeskistä tiedonvaihtoa, sovellusten yhteisiä tietovarastoratkaisuja, perinnesovellusten avaamista portaalin kautta, kontekstinhallintaratkaisuja jne. Mikäli kokonaisarkkitehtuurissa pyritään portaalien käyttöön, on hyvin monet palveluarkkitehtuurin kehittämisessä huomioitavat seikat ratkaistava myös portaalien kannalta. Tällaisia ovat mm. portaalien hankintatai toteutusvaihtoehdot (portaalituote, liittymät vanhoihin järjestelmiin, portaalin kehityksessä käytettävät välineet), portaalien suhde prosessimallinnukseen tai käytettyihin sovelluskehyksiin (Hazra 2002). Suhteessa prosesseihin ja viitearkkitehtuurin prosessikerrokseen, portaalissa toimiva sovellus voidaan nähdä kokonaisprosessin koordinaattorina. Portaalien käyttöönotto liitetään usein myös uusien toimintatapojen ja prosessien käyttöönottoon: samalla kun yhdenmukaistetaan esimerkiksi toimintatapoja soveltuvin osin eri organisaation osissa, yhdenmukaistetaan myös käyttöliittymää, jolla organisaation järjestelmiin ollaan yhteydessä. Kehittämistyön tulosten hyväksynnän kannalta on ensiarvoisen tärkeää varmistaa, että uusien palvelujen ja prosessien hyödyntäminen on vaivatonta loppukäyttäjien näkökulmasta. Jos järjestelmä on toteutettu viitearkkitehtuurin mukaisesti, käyttöliittymä toteutustavasta riippumatta - on käyttäjän ainut näkymä liiketoimintaprosesseihin ja -palveluihin. Alempien kerroksien toimivuus tai toimimattomuus käyttäjän näkökulmasta tarkasteltuna rakentuu paljolti käyttöliittymäkerroksen varaan. Käyttöliittymien kannalta SOA antaa runsaasti erilaisia mahdollisuuksia. Pidemmän tähtäimen tavoitteena voidaan pitää esim. siirtymistä "yhteisestä työasemasta" henkilökohtaiseen käyttöliittymään (tilanteeseen sopivalla laitteella). Näkyvissä on kuitenkin selvästi, että työpöydän hallinnassa ollaan edelleen pitkään tilanteessa, jossa käyttäjillä voi olla useita sovelluksia yhtä aikaa käytössä. On huomioitava, että esimerkiksi portaaliratkaisut tarjoavat jossain määrin myös vaihtoehtoja ja "kilpailua" esimerkiksi sovelluspalvelujen käytölle organisaatiorajojen yli. Mikäli on helpompaa tarjota toisen organisaation käyttäjille portaalikäyttöliittymä joihinkin organisaation tarjoamiin palveluihin kuin rakentaa tarvittavat sovittimet toisessa organisaatiossa käytettyihin sovelluksiin, portaalin tai web-käyttöliittymän avulla voidaan ratkaista samoja tarpeita kuin sovelluspalveluilla. Mikäli portaalista halutaan rakentaa organisaation sovellusten, viestinnän ja tiedonsaannin kokonaisnäkymä käyttäjille, portaali voi tarjota ratkaisuja mm. seuraaviin seikkoihin käyttäjänäkökulmasta (Hazra 2002). Tässä näitä seikkoja käsitellään erityisesti palveluarkkitehtuurin näkökulmasta: Sisällönhallinta: ratkaisut tiedon lähettämiseen saataville, yhdistämiseen ja saantiin. Sisällönhallintaratkaisujen avulla voidaan löytää tarvittavia tietoja ja yhdistää uusia tietoja tarvittaviin prosesseihin tai muihin tietoihin. Dokumenttienhallinta on osa sisällönhallintaa. Palveluarkkitehtuurin näkökulmasta on päätettävä, mitkä sisällöt liittyvät sovelluspalveluihin, mitkä esimerkiksi dokumenttienhallintajärjestelmiin, ja kuinka tarvittavat sisällöt linkitetään esimerkiksi palveluista koostettujen prosessien eri vaiheisiin. Tietämyksen hallinta: portaaliin yhdistetyt tietämyksenhallintavälineet yhdistävät tietoelementtejä ja tuottavat saataville tietämystä esimerkiksi business intelligence-ratkaisujen kautta. Sovelluspalvelujen osalta on tärkeää määritellä sovelluslogiikan suhde tietämyksen hal- 42

43 Osa 2: prosessien ja palvelujen määrittely ja suunnittelu lintaan, esimerkiksi kuinka toimitaan paikallisten toimintapolitiikkojen muuttuessa. Palveluväylää tai palveluarkkitehtuurin prosessikerrosta voidaan käyttää pääasiallisena integrointipisteenä, jonka avulla saadaan tarvittavia tietoja prosessien seurantaan ja hallintaan sekä business intelligence-ratkaisuihin. Yhteistyöominaisuudet: on mahdollista yhdistää palvelupohjaisia sovelluksia osaksi sähköpostia, kalentereja ja tapaamis- tai kokousjärjestelmiä, jotka ovat usein yritysportaalituotteiden peruselementtejä. Yleisesti yhteistyöominaisuuksilla saadaan lähetettyä viestejä, ilmoitettua asioista tai avattua viestintäyhteyksiä. Palveluarkkitehtuurissa tämä voi tarkoittaa monikanavaista viestintää, sähköpostien, mobiiliviestien ja kalenterien integrointia osaksi määriteltyjä toimintaprosesseja tai vaikkapa tietyissä tilanteissa tarvittavien yhteydenottojen automaattista aloittamista. Organisaatioiden tai yksiköiden välisessä toiminnassa keskitytään usein prosessien koordinointiin ja transaktioiden hallintaan. Suoraan asiakkaille tai loppukäyttäjille suunnatuissa ratkaisuissa tarjotaan asiakkaille tapoja vuorovaikutukseen palvelujen tarjoajien kanssa. Käyttökokemusten ja suhteiden hallinta: käyttäjäkohtaisten käyttöliittymätarpeiden (ulkoasu, käytettävyys, käyttökanavat), hakuominaisuuksien, kertakirjautumisten, eri kielien ja tukipalvelujen saatavuuden kannalta portaaliratkaisuissa on usein monia piirteitä. Palveluarkkitehtuurin kannalta on huomioitava esimerkiksi portaaleihin suunnitellut joustavuus-, personointi- ja monikielisyysratkaisut siten, että toteutetut palvelut pystyvät tukemaan niitä. Joissakin seikoissa voikin olla vaikea valita, sijoitetaanko käyttäjävaatimuksiin liitettäviä ratkaisuja osaksi sovelluspalveluja, integrointiarkkitehtuuria vai portaaleja ja käyttöliittymiä. Peukalosääntönä voidaan pitää, että yleiskäyttöiset ja samalle käyttäjälle eri sovelluksissa samanlaisena säilyvät ominaisuudet kuuluvat läheisesti esim. portaalipalveluihin. Turvallisuus: turvallisuusratkaisujen avulla voidaan portaalitasolla hallita nähtäviä tai muutettavia tietoja, käytettäviä sovelluksia tai toimintapolitiikkojen määrittelyjä. Palveluarkkitehtuurin suhteen on valittava, sijoitetaanko turvallisuuspiirteitä juuri portaaleihin, käyttöliittymien yhteyteen, ja minkä verran niistä on huolehdittava myös sovelluspalvelujen tasolla. Monet palveluarkkitehtuurin infrastruktuuriin liittyvät turvallisuusratkaisut liittyvät läheisesti myös käyttöliittymiin, esimerkiksi sovelluspalvelujen ja portaalien käyttöä on mahdollista seurata yhtenäisten lokipalvelujen avulla. Käyttäjien tunnistaminen ja käyttöoikeuksien hallinta on erityisen haasteellista nopeasti muutettavissa palvelupohjaisissa sovelluksissa ja prosesseissa. Turvallisuusominaisuudet kuten kertakirjautuminen liittyvät läheisesti myös käyttökokemus-näkökulmaan. Eräs keskeinen kysymys on, kuinka syvälle käyttöliittymätason alapuolelle halutaan ulottaa tietoa esimerkiksi käyttäjistä ja käyttöoikeuksista. Yleisesti luotetussa organisaatioympäristössä on päädytty siihen, että käytönhallinta tapahtuu lähellä käyttöliittymiä, mutta luottamussuhteiden muodostaminen ja tarkastaminen on erityisen tarpeellista avoimissa ja hajautetuissa sovelluksissa, joissa on runsaasti eri osapuolia. Portaalien turvallisuusratkaisujen integroituminen muuhun palveluarkkitehtuurin hallintaan on tärkeää päällekkäisyyksien välttämiseksi. Portaaleissa on usein metatietoratkaisuja ja erillisiä hallintavälineitä portaaliympäristön hallintaan. Palvelupohjaisessa arkkitehtuurissa niiden tulisi integroitua osaksi muuta tarvittavaa hallintaa. Samoin portaali-infrastruktuurin sekä portaaliin tulevien sovellusten yhteydessä on huolehdittava ratkaisujen riittävästä testauksesta. Kehitysprosessin kannalta portaaliratkaisuja ja käyttöliittymiä on tarpeen käsitellä käyttäjien ja johdon kanssa ratkaisujen vaatimusten ja prosessien määrittelyn yhteydessä. Mallinnusta ja suunnittelua varten on kuvattava, mitkä seikat portaali- tai käyttöliittymäympäristö tarjoaa, ja mitkä on ratkaistava muilla tavoin. Portaaliratkaisujenkin kehittämisessä voidaan noudattaa esimerkiksi MDA:n mukaista mallipohjaista tarkentuvaa kehitysmenetelmää, jossa toimialan ja tarpeiden mallinnuksella 43

44 Palveluarkkitehtuurin soveltaminen terveydenhuollossa määritellään portaaliin tarvittavat piirteet ja ominaisuudet, teknisen ympäristön hankinnan tai pystytyksen yhteydessä tuotetaan portaalille alustakohtainen malli, ja varsinaisen toteutusvaiheen aikana toteutetaan tai otetaan käyttöön portaalin palvelut. Käyttöliittymäkerros voidaan nähdä käyttöliittymien lisäksi myös yleisemmin interaktiokerroksena, jonka kautta käyttäjille tai muille asianosaisille toimitetaan käyttäjäkohtaisten tarpeiden mukaisesti tietoja ja toimintoja. SOA:n joustavuustavoitteiden saavuttamisen kannalta on pystyttävä luomaan nopeasti käyttöliittymiä palveluista koostetuille sovelluksille ja prosesseille. Monikanavainen samojen tietojen ja palvelujen saanti on usein korostettu piirre palvelupohjaisten sovellusten kehittämisessä, ja useissa välineissä on jopa mahdollista generoida automaattisesti käyttöliittymiä rajapintakuvausten ja metatietojen pohjalta eri laitteille. Nopean tai automatisoidun käyttöliittymien toteutuksen riskinä on kuitenkin liian vähäinen käytettävyysvaatimusten huomiointi. Käyttöliittymien toteutuksiin avoimia menettelytapoja on ilmestynyt varsinkin web-pohjaisiin käyttöliittymiin liittyen. WSRP (Web services for remote portals) ja AJAX (Asynchronous Javascript and XML) ovat tämäntyyppisiä malleja, joita hyödynnetään usein palveluarkkitehtuurien käyttöliittymissä. WSRP on hyödynnettävissä erityisesti käyttöliittymäläheisten web-sovelluspalvelujen tai prosessikerroksen esittämiseen portaaleissa (Arsanjani 2004). Se mahdollistaa valmiiden sisältölähteiden tarjoamisen käyttöliittymäkerroksen ratkaisujen rakentamiseen, samantyyppisesti kuin viitearkkitehtuurin komponenttikerros piilottaa antaa kontrollin toteutuksesta palvelun tarjoajalle. AJAX:in avulla taas XML-tietoa voidaan siirtää http-yhteyden yli ilman, että selainohjelman tarvitsee tehdä http-päivityskutsua, mikä mahdollistaa vuorovaikutteisempien käyttöliittymien kehittämisen selainohjelmiin. SOA-ratkaisujen käyttöliittymissä voidaan hyödyntää myös portlet-ratkaisuja sekä monia esimerkiksi web 2.0-tekniikoita. 3.7 Integrointiarkkitehtuuri Integrointiarkkitehtuurissa määritellään palvelupohjaisessa arkkitehtuurissa tuetut liitäntätavat sekä integrointiin käytettävissä oleva infrastruktuuri. Olennaista on määritellä esimerkiksi viitearkkitehtuurin eri kerrosten väliset viestinvälitystavat ja väylät sekä näihin liittyvät tekniikat. Integrointiarkkitehtuurissa on otettava kantaa yleisesti mm. palvelujen, prosessien ja osallistujien tunnistamisen ja liittämisen pelisääntöihin. Tässä luvussa käsitellään integrointiarkkitehtuurissa tunnistettavia erilaisia liitäntä- ja integrointitapoja muutenkin kuin SOA-palvelujen osalta, ja erikseen palveluväylän (ESB) hyödyntämistä. Integrointiarkkitehtuuria ohjaavia perusperiaatteita ovat modulaarisuuden ja osien riippumattomuuden periaatteet (Honey ym. 2006a). Integrointiarkkitehtuurissa on myös otettava kantaa palveluiden ja ratkaisujen mukautusmekanismeihin ja tukeen eri karkeajakoisuudella toteutettuihin ratkaisuihin. Palvelujen välinen ja niiden sekä niiden hyödyntäjien välisen kytkennän tiukkuus on yksi peruslinjauksia integrointiarkkitehtuurissa viittausten käyttö, viestien koko ja "kokonaisuus", palveluinstanssien määrä ja rajapintojen laajennusmekanismien käyttö vaikuttavat merkittävästi kytkennän tiukkuuteen ja joustavuuteen. Lisäksi integrointiarkkitehtuurissa on tehtävä päätöksiä käytettävissä olevista tukipalveluista ja viestintämekanismeista sekä siitä, minkä tasoisia ovat esimerkiksi prosessien eri vaiheissa palveluiden välillä välitettävät viestit. Palveluarkkitehtuuria tukevassa integrointiarkkitehtuurissa on tunnistettava perusratkaisut riittävän monen tyyppisille integrointiratkaisuille, jotta erityyppisiin vaatimuksiin saadaan vastattua. Näille 44

45 Osa 2: prosessien ja palvelujen määrittely ja suunnittelu valituille integrointitavoille sen sijaan pyritään mahdollisimman vakioituihin ratkaisuihin ja liitäntätapoihin. Uudelleenkäytettävässä ohjelmistoinfrastruktuurissa voi olla tuki erilaisille yhteentoimivuustarpeille ja liittymätyypeille. Olemassa olevia verkkoja ja internet-infrastruktuuria voidaan hyödyntää palveluarkkitehtuureissa web-sovelluspalvelutekniikoilla tai niitä voidaan täydentää integraatioalustoilla tai palveluväylillä. Sovellusintegraation ratkaisumallit sisältävät tieto-, palvelu-, prosessi- ja käyttäjäpohjaiset integraatioratkaisuja (Linthicum 2003, Honey ym. 2006a). Yleensä yksi näistä on selvin ratkaisumalli yksittäisessä integraatioratkaisussa, mutta jokainen integraatio-ongelma voidaan usein ratkaista usean mallin avulla. Integrointiarkkitehtuurissa voidaan pyrkiä vakioimaan perusratkaisut esimerkiksi seuraavien integrointimallien suhteen: Tietopohjainen integraatio keskittyy tiedonvälityksen, -vaihdon ja tietokantojen sekä tietoa tuottavien rajapintojen hyödyntämiseen integraatiopisteinä. Tällä lähestymistavalla on useita hyötyjä: lähde- ja kohdejärjestelmät vaativat usein vain vähäisiä muutoksia, jolloin mm. tila- ja logiikkanäkökulmiin ei tarvitse ottaa kantaa. Lähestymistapa on yksinkertainen ja yleisesti käytetty. Esimerkkejä tietopohjaisesta integraatiosta ovat mm. HL7 ja HL7 CDA sekä DICOM. Kehittyneemmässä lähestymistavassa voidaan ottaa huomioon myös semantiikka, tietotyypit ja metatiedot. Prosessipohjainen integraatio keskittyy prosessien ja informaatiovirran hallintaan määrittäen prosessikerroksen. Tarkoituksena on yhdistää olennaiset prosessit niiden välisen tiedonvirran ja ohjauslogiikan tukemiseksi. Ratkaisut sisältävät usein joustavia väliohjelmistoja kuten integraatiopalvelimia tai hajautettuja olioita. Prosessipohjaiset ratkaisut vaativat taustalle organisaation prosessien määrittelyn ja ymmärtämisen. Esimerkki prosessipohjaisesta lähestymistavasta (ks. luku 3.5) ovat IHE integraatioprofiilit. Palvelupohjainen integraatio sallii sovellusten jakaa yleisen liiketoimintalogiikan tai metodit. Tällöin määritellään jaetut metodit ja tuotetaan infrastruktuuri tai väliohjelmisto jakamisen mahdollistamiseksi. Jaetut metodit vähentävät metodien ja tiedon toistuvuutta sekä tukevat uudelleenkäyttöä. Samalla mahdollistetaan sekä tieto- että prosessipohjainen integraatio. Palvelupohjaista integraatiota on määritellyt muun muassa Object Management Group (OMG). Käyttäjäkeskeinen integraatio mahdollistaa käyttäjälle useista järjestelmistä tuotetun näkymän. Esimerkkinä tästä ovat yhtenäiset käyttöliittymät tai työpöytäintegraatio. Käyttäjäkeskeinen integraatio ei välttämättä sisällä suoranaista järjestelmäintegraatiota, jolloin sovellukset voivat edelleen olla hyvin erillään tieto- tai palvelutasolla. Esimerkkejä käyttäjäpohjaisesta integraatiosta ovat portaalit ja HL7:n CCOW -kontekstinhallinta. Tarkemmin asiasta kerrotaan luvussa Palvelujen ja järjestelmien liitäntätavat Tässä luvussa käsitellään integrointiarkkitehtuuria ja liitäntätapoja, soveltaen sitä sairaalan tietojärjestelmäarkkitehtuurin kehittämiseen kohti palvelupohjaista suuntaa (Mykkänen ym. 2007b). Integrointiarkkitehtuurin eri osiin on määriteltävä yhdenmukaiset liitäntätavat, sekä käyttö- ja hallintamekanismit. Arkkitehtuurista voidaan tunnistaa useita osia (kuva 10), joista tietojärjestelmäkokonaisuus koostuu. Arkkitehtuurin elementit voidaan luokitella esimerkiksi seuraavalla tavalla: Ydinpalvelut, jotka tukevat potilashallintoa ja muita infrastruktuurin jaettuja osia. Esimerkkejä näistä ovat muun muassa keskeiset potilastiedot ja -tietovarastot, koodistot ja terminologiat sekä ajanvaraus. Ydinpalvelut ovat osia, joita monet kokonaisarkkitehtuurin muut osat hyödyntävät. Nykyisissä järjestelmissä hyödynnetään palvelurajapintoja, mutta monia osia ydinpalveluista joudutaan 45

46 Palveluarkkitehtuurin soveltaminen terveydenhuollossa hyödyntämään perinnejärjestelmien tai uusien ydinpalveluiden avulla. Ydinpalvelujen liittämiseen voidaan integrointiarkkitehtuurissa tehdä esimerkiksi valinta, että kaikki ydinpalvelut ovat käytettävissä web-sovelluspalveluina, antaa ohjeita palvelujen rajapintojen yhdenmukaistamiseen sekä palvelujen yhdenmukaisen löytämiseen ja hallintaan. Sähköisten potilaskertomusten tietovarasto (EHR repository), joka sisältää ja yhdistää muun muassa henkilötiedot, diagnoosit, lääkitykset ja testitulokset ym. On suositeltavaa, ettei sähköisten potilaskertomuksien tietovarastoon yhdistetä korkean tason prosessinhallintaa, vaan painotutaan ennemminkin henkilökohtaisiin hoitoketjuihin. Ydinsovellukset voivat syöttää ja hyödyntää tietoa tietovarastosta, jonka sisältöä voidaan hyödyntää myös yli organisaatiorajojen. Tietovarasto voidaan myös erottaa potilaskertomusjärjestelmistä. Organisaation sisällä sähköinen potilaskertomus voi olla ydinpalveluiden varassa, mutta tietovarastoja voidaan sijoittaa myös kansalliselle tai alueelliselle tasolle. Integrointiarkkitehtuurissa voidaan määritellä, että tietovarasto voi hyödyntää samoja viesti- ja dokumenttiformaatteja kuin erityisjärjestelmien välisessä kommunikaatiossa. Lisäksi on otettava kantaa päällekkäisten tietojen vähentämiseen tai välittämiseen eri järjestelmien tai tasojen (esim. paikallinen, alueellinen, kansallinen) välillä. Liitettävät erityispalvelut tai sovellukset, joita ovat esimerkiksi radiologia, farmasia, kuvantaminen ja keskushallinnolliset järjestelmät. Nämä järjestelmät voivat olla ydinpalveluiden varassa, jos sellaisia on saatavilla, jolloin vähennetään tiedon replikointia ja syöttämistä useisiin järjestelmiin. Ydinpalveluiden varassa olevat järjestelmät mahdollistavat modulaarisuuden, mutta myös vaativat ydinpalveluilta jatkuvaa saatavuutta. Tiedonvälitys erityisjärjestelmien välillä voi olla riippuvainen ydinpalveluista tai erityisjärjestelmien kyvystä keskinäiseen viestintään. Lisäarvopalvelut kuten potilasryhmittely- tai päätöksentukikomponentit ovat sovelluksia pienempiä erityispalveluita. Integrointiarkkitehtuurissa erityispalvelujen liittämiseen voidaan soveltaa monia samoja sääntöjä ja käytäntöjä kuin ydinpalveluihinkin. Hallinnolliset ja tukijärjestelmät sekä muut prosesseja tukevat sovellukset sisältävät toimintoja muun muassa laskutukseen, tilastointiin ja materiaalinhallintaan. Näitä järjestelmiä on mahdollista integroida ydinpalveluihin, mutta usein lähestymistapana on toteuttaa integraatio löyhästi kytketyllä viestinnällä tai kontekstinhallinnan avulla muista sovelluksista. Löyhää kytkentää suositaan usein myös erityyppisten terveydenhuollon laitosten välisessä viestinnässä ja transaktioissa. Käyttöliittymät voivat olla integroituna ydinpalveluihin ja kätkeä taakseen useita integroituja järjestelmiä. Käyttöliittymän tarkoituksena on tarjota ymmärrettävä näkymä, joka sisältää käyttäjälle olennaiset tiedot ja toiminnot. Käyttöliittymä voi liittyä prosessi-integraatioon ja työnkulkuun. Käyttöliittymät on kuvattu tarkemmin luvussa

47 Osa 2: prosessien ja palvelujen määrittely ja suunnittelu Insurance Statistical reporting Administration and management Financials Materials management Personnel management Property and infrastructure management Sales, CRM, marketing, PR Patient/citizen front-end Invoicing Resource / operations planning Materials & meal ordering Patient grouping, DRG Administrative core Admisstion, discharge, transfer Workstations Web Professional front-ends Mobile Ubiquitous Inpatient and outpatient management Reporting, Data warehousing, Management Workflow and process management Guidelines, protocols Patient / provider demographics Scheduling, Resouce Management Clinical core Orders / referrals, prescriptions, consultations Patient and provider id Medication EHR repository Results Problems Terminology Lab Radiology + PACS Pharmacy Decision support Etc Clinical subsystems Surgery Neonatal Gastroenterology Cardiology Anaesthesiology + ICU Pathology 1. Common, shared and centralized services 2. Context management, added value services 3. Loosely-coupled messages, documents, cross-facility invocations E q u i p m e n t Population / community health Disease management Research User management, security and access control Identification User role Care relationship Consent Integration, data access Kuva 10. Järjestelmien ja kytkentöjen tyyppejä ja tiukkuuksia (Mykkänen ym. 2007b) Palvelualustat Palveluarkkitehtuuriin (SOA) liittyy kiinteästi käsite palveluväylä (ESB, Enterprise Services Bus). Palveluväylä tukee palveluiden käyttäjien ja palveluiden tuottajien välistä vuorovaikutusta tietojen siirtoon ja hallintaan liittyvissä tehtävissä. Keskeiset tavoitteet palveluväylien hyödyntämiselle ovat: Palveluiden ja palveluiden käyttäjien keskeinen vuorovaikutus. Muutosten minimointi tietojärjestelmissä. Sovelluslogiikan erottaminen toimintaympäristön hallintaan kuuluvasta matalan tason ohjelmalogiikasta. Yhteentoimivuus eri teknologioiden ja teknisten ratkaisujen välillä, jolloin palveluväylä toimii teknologiariippumattomana yleisenä ja yhteiskäyttöisenä kerroksena. Vaihdettavuus, jolloin palveluväylän avulla hyödynnettäviä komponentteja tai kokonaisuuksia voidaan vaihtaa ilman sovelluksiin tehtäviä muutoksia. Löyhät kytkennät, joilla minimoidaan osapuolten välisiä riippuvuuksia. Palveluväylä sijaitsee tyypillisesti viestien lähettäjien ja vastaanottajien välissä (intermediary), hoitaen monia ohjelmistojen väliseen kommunikointiin liittyviä tehtäviä. Nykyiset palveluväylät tukevat aina SOAP/http-pohjaista liikennettä, mutta yleensä myös erilaisia viestipohjaisia middleware (MOM) -tekniikoita. Palveluväylän avulla voidaan toteuttaa eri viestinvälitysmalleja, esim. synkroninen, ei-synkroninen ja publish/subscribe-viestinvälitys. Web services -standardien (XML, WSDL, SOAP, http) tuki on yleinen palveluväylien vaatimus. Palveluväylien yleisesti hoitamia tehtäviä ovat myös reititys (mm. palveluntarjoajien löytäminen tai korvaaminen, ajonaikainen sidonta) sekä muunnokset (tietomuotojen + viestinvälitysprotokollien välillä). Lisäksi palveluväyliin liittyy usein palveluarkkitehtuurissa tarvittavien metatietojen (osoitteet, rajapinnat, skeemat, toimintapolitiikat) käyttö- ja hallintaominaisuuksia. Näiden ominaisuuksien lisäksi palveluväyliin on liitetty yleensä seurantaominaisuuksia (esim. Business Activity Monitoring, tekninen toimivuus, SLA-valvonta) sekä turvallisuusominaisuuksia. 47

48 Palveluarkkitehtuurin soveltaminen terveydenhuollossa Palveluväylätuotteisiin liittyy usein myös prosessimoottori. Erona perinteisiin integrointialustoihin (hub and spoke) voidaan pitää vaatimusta, että palveluväylissä myös integrointikomponentit on hajautettu palveluiksi, jotka ovat korvattavissa ja käytettävissä rajapintojen kautta. Palveluarkkitehtuurin suunnittelun, toteutuksen ja hallinnan kannalta on määriteltävä, mitä yllä kuvatuista seikoista hoidetaan palvelualustan avulla. Valinnat vaikuttavat mm. siihen, vaaditaanko hankittavilta sovelluspalveluilta suoraan yhdenmukaiset rajapintatekniikat, sisältävätkö palvelujen määrittelyt myös teknisesti lukkoon lyötyjä yksityiskohtia vai pelkästään sisällöllisiä ja semanttisia malleja jne. Palvelualustat ja -väylät voidaan karkeasti jaotella viestipohjaisiin ja palvelupohjaisiin ratkaisuihin (Cape Clear 2005). Viestipohjaisissa ratkaisuissa keskitytään tarjolla olevien palveluiden hyödyntämiseen viestinnän avulla, kun taas palvelupohjaisissa keskitytään palveluiden kehittämis- ja kokoamisnäkökulmiin. Palveluväylä voi tukea molempia toimintatapoja, mutta niiden erot on hyvä tunnistaa ratkaisujen ja integrointiarkkitehtuurin määrittelyssä. Viestipohjaisen palveluväylän periaate on sama kuin viestipohjaisissa väliohjelmistoissa yleensäkin (Message-Oriented Middleware, MOM). Sen avulla saavutetaan luotettava asynkroninen viestinvälitys, transaktiot ja tuki erilaisille interaktiotavoille. Viestipohjaiset väliohjelmistot voivat hyödyntää web services -tyyliä yhdistettynä viestinvälitykseen, jolloin saavutetaan viestipohjainen ESB. Tällöin pystytään hyödyntämään jo olemassa olevia erilliselle alustalle rakennettuja palveluita. Viestipohjainen ESB vaatii taakseen erityisen MOM-siirtotavan, jonka avulla tietoliikennettä reititetään ja hallinnoidaan. Samalla olemassa olevia sovelluksia joudutaan muuttamaan jotta ne tukevat palveluväylää tai kommunikaatio on hoidettava esimerkiksi siltojen avulla. Olisi kuitenkin hyödyllisintä, että palveluväylä pystyisi hyödyntämään jo olemassa olevaa viestintäinfrastruktuuria, jottei uusia viestintäväliohjelmistoja tarvitsisi rakentaa. Viestipohjaisen palveluväylän tarjoamat resurssit ja palvelut (esimerkiksi muunnokset, reititykset ja prosessit) ovat erillisiä SOAn tarjoamiin liiketoimintapalveluihin verrattuna. Nämä väylän toiminnot on tällöin järjestettävä osaksi viestinvälityskomponenttia tai erilliseksi palveluksi ja niitä on tällöin hallittava ja kehitettävä erikseen eivätkä ne ole SOAn uudelleenkäytettäviä palveluita (Cape Clear 2005). Viestipohjaisessa mallissa on otettava huomioon muun muassa jonot, palveluviestien lähettäjät ja vastaanottajat, sessiot ja yhteydet sekä niin edelleen, samoin kuin useat eri tavat lukea ja kirjoittaa viestejä väylän avulla. Väylässä voidaan hyödyntää erilaisia interaktiotyylejä viestien toimittamiseen, ja väylän kehittämisen olennaisin osa tässä lähestymistavassa onkin ottaa huomioon viestien sijoittaminen ja lukeminen. Useat toteutukset hyödyntävät Java Message Service (JMS) -määritystä, joka määrittelee kuinka tällainen malli toteutetaan teknisesti. Karkean ja korkeamman tason toiminnallisuus on integroitava erillisen palvelualustan avulla. Palvelukeskeisessä ratkaisussa palvelut ovat saatavilla suoraan väylästä, jolloin myös niiden kehittäminen ja hallinnointi tapahtuvat saman alustan kautta. Viestintä ei ole suoraan näkyvissä palveluille, vaan palveluiden välinen kommunikaatio reititetään palveluväylän kautta. Palvelukeskeiset väylät käyttävät olemassa olevaa viestintäinfrastruktuuria mikäli tarpeellista, jolloin infrastruktuuria ei tarvitse muuttaa tai kopioida. Palvelukeskeisen väylän tarjoamat palvelut ovat sijoitettu web service -tyyliin palvelualustalle ja niitä hallinnoidaan samaan tapaan kuin SOAliiketoimintapalveluita. Korkean tason prosesseissa on olennaista, että niiden luomisessa ja hallinnoinnissa käytetään yhteistä alustaa ja infrastruktuuria. Yleinen ja suositeltava lähtökohta palvelukeskeisyyteen on aloittaa 48

49 Adapter Adapter Osa 2: prosessien ja palvelujen määrittely ja suunnittelu Services Registry Look Up Publish Service Consumer Endpoint Application Service Provider Endpoint Application Logging / Audit Service Message Persistence Store / Service Security Manager / Service Transaction Manager / Service Kuva 11: Perus-SOA:n "palveluväylä". mallintaminen ylhäältä alas -periaatteella, jolloin korkean tason prosessirajapinnat mallinnetaan tarkemman tason teknisiksi rajapinnoiksi. Tätä kutsutaan meet-in-the-middle -palvelusuunnitteluksi, joka voidaan toteuttaa palvelukeskeisen ESB:n avulla. Viesti- ja palvelukeskeisyyden erot huomataan silloin, kun tarkastellaan kuinka nopeasti loppukäyttäjille valmiita tuotteita pystytään tuottamaan ja ylläpitämään. Vaikka viestintä onkin erittäin tärkeä osa ESB-toteutusta, viestikeskeinen ESB voi keskittyä liikaa viestintään unohtaen SOAn periaatteen: palvelut. ESB:n tulee ottaa ensisijaisesti huomioon palveluiden luominen, kokoaminen ja hallinta (Cape Clear 2005). Olemassa olevan viestintäinfrastruktuurin hyödyntäminen on toki keskeistä, jotta hallinta ja kehittäminen olisi helpompaa. Palvelukeskeinen lähestymistapa edesauttaa mm. olemassa olevan viestintäinfrastruktuurin ja rajapintojen uudelleenkäyttöä, vähentää monimutkaisuutta ja kehitystyön määrää sekä ennen kaikkea mahdollistaa saumattoman integraation yhden integraatioalustan avulla. Palvelu- ja viestikeskeisyyden lisäksi palveluväylän abstraktiotasot voivat vaihdella suuresti. Palveluväylän toteuttamisessa voidaan nähdä neljä erilaista näkymää tai tasoa (Honey 2006) : Perus-SOA ja infrastruktuurin avainominaisuudet Staattinen välitetty SOA, johon lukeutuvat myös muunnokset ja reititykset Dynaaminen välitetty SOA, johon lukeutuvat em. lisäksi myös julkaisu-, tilaus- ja toimintapolitiikkojen hallinta Orkestroitu SOA, johon kuuluvat myös orkestrointi ja prosessit Kuvassa 11 esitetään minimitason SOA-integrointialusta, joka jakautuu yksinkertaisimmillaan kolmeen osaan: palvelun tarjoaja, palvelun hyödyntäjä ja väylä. Yllä mainittuja voidaan pitää minimivaatimuksena SOA-palvelujen tarvitsemalle "väylälle". Palvelurekisteri ei ole välttämätön web services -teknologioiden hyödyntämiselle, mutta käytännössä se sisältyy aina minimitasoon. Staattisessa välitetyssä SOA:ssa näihin perusominaisuuksiin liitetään 49

50 Adapter Adapter Palveluarkkitehtuurin soveltaminen terveydenhuollossa viestien välitysominaisuuksia (usein myös hakemistoihin liittyen) ja tietotyyppien, tunnisteiden ja viestisyntaksien muunnokset, jotka ovat tyypillisiä viestipohjaisten väliohjelmistojen ominaisuuksia. Lisää dynaamisuutta saadaan aikaan tukemanna julkaisu (publish/subscribe)- ja paikallisten toimintapolitiikkojen määrittelyä ja noudattamista (policy) tukevia ominaisuuksia. Lisäksi palveluväylään voidaan liittää palvelujen käyttöä ja viestiliikennettä seuraavia lokipalveluita, esimerkiksi viestien tallennukseen sopivia tietokantoja sekä transaktioiden hallintaan tarvittavia palveluja, joiden merkitys kasvaa varsinkin koostettuja palveluja ja prosesseja kehitettäessä. Myös työnkulkumoottorit ja orkestrointi (ks. luku 3.1) ovat yleisiä palveluväylien tarjoamia palveluita. Kuvassa 12 näkyy edistynyt palveluväylä, johon kuuluu lukuisia palveluita ja tehtäviä. Services Registry Look Up Publish Service Consumer Endpoint Application Routing Intermediary Transformation Intermediary Service Provider Endpoint Application Subscription Manager Policy Manager / Service Logging / Audit Service Orchestration Engine / Service Message Persistence Store / Service Security Manager / Service Transaction Manager / Service Kuva 12. Orkestroidun SOA:n palveluväylän ominaisuudet. SOA:ssa käytettävät tilaus- ja julkaisuinteraktiot (publish/subscribe) luetaan usein osaksi tapahtumapohjaista arkkitehtuuria (Event-driven architecture, EDA). Näiden palveluiden mukaan liittäminen osaksi palveluväylää mahdollistaa tapahtumien julkaisemisen ja niistä kiinnostuneiden vastaanottajien määrittelyn. Tapahtumapohjainen toimintatapa johtaa erittäin löyhään kytkentään tiedon julkaisijan ja hyödyntäjien välillä, ja sopii myös tilanteisiin, joissa samoista tapahtumista ja niihin liittyvistä tiedoista on paljon kiinnostuneita tapahtumien hyödyntäjiä. On esitetty erilaisia näkemyksiä siitä, kuuluuko EDA osaksi palveluarkkitehtuuria vai onko se oma arkkitehtuurinsa. Jos palveluarkkitehtuuri ymmärretään suppeasti vain kutsu/vastaus-tyyppisiä interaktioita sisältäväksi arkkitehtuuriksi, tapahtumapohjainen toiminta voidaan rajata sen ulkopuolelle, mutta käytännön tarpeet tapahtumapohjaisen tiedonvälityksen käyttöön on järkevää tunnistaa integrointiarkkitehtuurin määrittelyn yhteydessä. Yhteenvetona palveluväylistä voidaan sanoa, että ESB toimii selkärankana integraatiolle ja tarjoaa konkreettisia integrointiin liittyviä palveluja, joilla voidaan saavuttaa huomattavia joustavuus- ja hallintaetuja. ESB:t ja sovelluspalvelut täydentävät toisiaan ja niiden väliseen interaktioon on olemassa useita eri toteutusvaihtoehtoja. Palveluväylän hankinta erillisenä tuotteena ei ole välttämätöntä, vaan ominaisuuksia voidaan rakentaa mukaan osaksi integraatiota tukevaa infrastruktuuria. Palveluväyläksi on kuitenkin olemassa useita erilaisia ratkaisumalleja ja tuotteita, jotka yleensä tarjoavat myös keskitetyn hallinnan, turvallisuuden sekä lisäpalvelujen ominaisuuksia. 50

51 Osa 2: prosessien ja palvelujen määrittely ja suunnittelu Erityisesti organisaatioiden välisessä toiminnassa ja yhä enemmän myös organisaatioiden sisällä on ratkaistava erillisten palveluväylien ja erillisesti kehitettyjen integrointiarkkitehtuurien pelisääntöjen välinen sovittaminen. Keskitetty ja yhdenmukainen palveluväylä on merkittävä yhteentoimivuuden ja joustavuuden mahdollistaja, mutta epäyhteensopimattomat oletukset palveluväylien tarjoamista ominaisuuksista voivat vaikeuttaa tietyillä oletuksilla tehtyjen sovelluspalvelujen uudelleenkäyttöä uusissa tilanteissa ja ympäristöissä Muita esimerkkejä terveydenhuollon palvelupohjaisesta integrointiarkkitehtuurista Oracle HTB on alusta terveydenhuollon sovellusten integraatioon, sovelluskehitykseen ja toimintaan käsittäen koko terveydenhuollon sektorin. Lisää aiheesta voi lukea erillisestä selvityksestä (Mäki 2005). Microsoftin Connected Health Framework (Microsoft 2006a) on suunniteltu terveydenhuollon tietojärjestelmäintegraatioon ja hyödyntää SOA-pohjaista lähestymistapaa toteuttajanäkökulmasta. Keskeisinä tekijöinä integraation mahdollistamisessa ovat liiketoimintakomponentit ja palveluiden orkestrointi. Tämän toteuttamiseksi on kehitetty näkökulma kolmeen osa-alueeseen: Liitetyt järjestelmät, jotka koostavat sovelluksia, laitteita, palveluita ja organisaatioita prosessien parantamiseksi, tiedon ja tietämyksen jakamiseksi sekä kustannusten vähentämiseksi. Liitetyt järjestelmät nojautuvat avoimiin standardeihin, jotka mahdollistavat perinnejärjestelmien ja kolmannen osapuolen sovelluksien yhteentoimivuuden. Tietopohjaiset ohjelmistot ja sovellukset, jotka helpottavat tiedonhakua, järjestämistä ja hyödyntämistä yhteistyön ja hoidon parantamiseksi. Yhteistyössä toimivat ympäristöt, jotka sisältävät monipuolisia rajapintoja yhteistyöhön ja konsultointiin hyödyntäen mm. audiovisuaalisia elementtejä. Integraation mahdollistamiseen käytännössä sovelletaan kahta "kehystä" (Microsoft 2006b, 2006c): Liiketoimintakehys (Connected Health Framework Business Framework), joka sisältää neljä arkkitehtuurillista käsitettä sovellusintegraation mahdollistamiseksi: o Palvelukeskeisyys, joka vähentää järjestelmien välisiä riippuvuuksia hyödyntäen avoimia standardeja ja protokollia. o Yhdistetty tieto, jota hallinnoidaan paikallisesti ja jolla mahdollistetaan eritasoiset palvelut järjestelmän eri tasoilla. o Yhdistetty turvallisuus korkealla tasolla, joka sisältää käyttäjähallinnan ja tunnistamisen sekä o Luotettavuus, joka kattaa vikasietoiset ja toimivat järjestelmät. Tekninen kehys (Connected Health Framework Technical Framework), joka kuvaa seikkoja ja työkaluja, jotka vaikuttavat yhteentoimivuuteen infrastruktuuritasolla, ottaen kantaa mm. seuraaviin: o Alustojen, sijaintien ja resurssien monimuotoisuus o Tunnistaminen o Joustavuus, turvallisuus ja skaalautuvuus o Suorituskyky o Integrointipisteet 51

52 Palveluarkkitehtuurin soveltaminen terveydenhuollossa Kuva 13. Microsoft Connected Health Services Hub (Microsoft 2006c) Toimintaprosessien suorittamiseen ja orkestrointiin Microsoftin lähestymistapa (Microsoft 2006c) sisältää käsitteen nimeltä Connected Health Services Hub (kuva 13), jota toimialalla yleisemmin kutsutaan nimellä e-health Services Hub. Hubeja voi olla myös useita ja ne voivat tarjota toiminnallisuutta myös yhdistetysti. Arkkitehtuurillisesta näkökulmasta kaikki hubin avulla palveluita käyttävät osapuolet ovat asiakkaita. Toisaalta, kun hub voi tarjota muille sitä käyttäville asiakassovelluksille palveluita, se voi myös itse toimia asiakassovelluksena ja hyödyntää muita tarjolla olevia palveluita. Myös topologiat voivat vaihdella ja hubit voivat sijoittua arkkitehtuuriin eri tavoin sekä vastata erilaisista palveluista ja toiminnallisista kokonaisuuksista. Esimerkkejä näistä palveluista ovat mm. ulkoiset autentikaatiopalvelut ja keskuspalvelut joihin hub voi myös tuottaa lisäarvoa tai -palveluita. Yleisimpiä hubin avulla hyödynnettäviä potilaskertomusja rekisteripalveluita ovat mm. haku- ja päivitystoiminnot, prosessien orkestrointi ja liiketoimintalogiikka. 52

53 Osa 2: prosessien ja palvelujen määrittely ja suunnittelu 4 Esimerkit prosessimallinnuksesta ja sovelluspalvelujen tunnistamisesta Tässä luvussa kuvataan esimerkkejä prosessimallinnuksesta, joka voidaan liittää sovelluspalvelujen määrittelyyn ja kehittämiseen. Erityisesti ylhäältä alas -tyyppisessä palveluarkkitehtuurin kehitysstrategiassa prosessien mallintaminen, määrittely, automatisointi ja seuranta ovat keskeisiä korostettuja toimintatapoja. SerAPI-hankkeen useimmat soveltamiskohteet ovat tuottaneet ratkaisuja selkeisiin rajapintatarpeisiin sovellusten ja palvelujen välillä. Tällaiset ratkaisut ovat usein pienenä osana useita eri prosesseja tai tukevat tiettyjä erityistarpeita. Näissä soveltamiskohteissa ei kuitenkaan ole yleensä kuvattu laajemmin kohdealueen prosesseja tai suunniteltu niiden toteuttamista toisiinsa liitettävien sovelluspalvelujen avulla. Vuonna 2006 käynnistetyssä Prosessit ja palvelut -soveltamiskohteessa, kuvattiin projektin osapuolten kanssa valituilla kohdealueilla esimerkkejä prosessien mallinnuksesta ja määrittelystä sekä sovelluspalvelujen tunnistamisesta ja määrittelyistä prosessikuvausten pohjalta. Luvussa 4.1 kuvataan esimerkeissä käytetty prosessimallinnuksen lähestymistapa. Luvuissa 4.2 ja 4.3 on esimerkkejä endoskopian ja äitiyshuollon alueen mallinnuksesta, jota on tehty SerAPIhankkeen "Prosessit ja palvelut" -soveltamiskohteessa. 4.1 Prosessien mallinnus Tämä luku sisältää SerAPI-hankkeen Prosessit ja palvelut (ProPa) -kohteessa prosessien mallintamiseen ja kuvaamiseen tarkoitettuja malleja ja ohjeita. Luvussa kuvataan järjestelmällinen lähestymistapa, jolla pyritään muodostamaan asteittain tarkentuva kuva prosesseista tietyllä kohdealueella. Prosessit ja palvelut -soveltamiskohteen tavoiteltuina tuotoksina on tunnistettu mm. prosessiesimerkkien, prosessimallien ja prosessikarttojen tuottaminen siten, että tuotokset palvelevat palveluarkkitehtuurin kehittämistä ja sovelluspalvelujen tunnistamista. Tämän dokumentin mallit on valittu ja kehitetty erityisesti näitä tavoitteita silmällä pitäen. Erityisesti dokumentin kehitystä ohjaavat ProPa-kohteen esimerkeissä ja osapuolilta esiin nousevat tarpeet. Prosessien mallinnuksella ja kuvaamisella pyritään esimerkiksi: lisäämään ymmärtämystä organisaation toiminnasta, työnkuluista tai tehtävien etenemisestä, tunnistamaan parannustarpeita sekä määrittelemään parannuksia ja tehostuksia toimintaan, yhdenmukaistamaan toimintaa, automatisoimaan prosessin vaiheita, parantamaan toiminnan seurantaa, simuloimaan toiminnan muutoksia ja niiden vaikutuksia. Prosesseja voidaan kuitenkin tunnistaa hyvin monilla eri tasoilla ja eri näkökulmista. Esimerkiksi asiakkaan, työntekijän, johdon ja tietojärjestelmien näkökulmasta samat toiminnot voivat näyttää hyvinkin erilaisilta. Lisäksi on eroja siinä, kuvataanko melko samanlaisina toistuvia rutiiniprosesseja, asiantuntijatyön prosesseja (joissa vain osa tehtävistä tai vaiheista on tarkasti tiedossa), vai kertaluonteisia prosesseja (kuten projektit tai kehittämistehtävät). 53

54 Palveluarkkitehtuurin soveltaminen terveydenhuollossa Mallintamisessa on alusta alkaen pidettävä mielessä käyttötarkoitus mihin prosessimalleja ollaan tekemässä. Halutaanko prosessi mallintaa niin tarkasti, että siitä saadaan tarkasti koordinoitu tai jopa automatisoitu? Onko terveydenhuollon prosessien epävarmuus ja suorituksen vaihtelu esteenä näin tarkalle mallinnukselle ja siten esteenä automatisoinnille? Onko prosessimäärittelyiden tehtävänä on vain kuvata tai automatisoida niitä prosesseja tai prosessien osia, joiden kuvaaminen tai automatisointi on niiden muuttumattomuuden johdosta järkevää? Prosessit ja palvelut -kohteessa lähtökohtana on toisaalta yleisten ja toistuvien prosessien kuvaaminen, määrittely ja automatisointimahdollisuuksien tunnistaminen, toisaalta terveydenhuollon prosessit ovat suurelta osin asiantuntijatyön prosesseja, joiden eteneminen ja vuorovaikutus on monimutkaista ja vain osin vakioitavissa. Terveydenhuollon prosessit ovat pitkäkestoisia, keskinäisessä vuorovaikutuksessa ja niissä on paljon poikkeuksia tai keskeytyksiä. Prosessimallinnuksessa edetään tyypillisesti toiminnan kokonaiskuvan ymmärtämisestä kohti tarkemmin ja tarkemmin kuvattuja prosesseja, tehtäviä ja toimintoja. Mallinnus voi kohdistua sekä nyky- että tavoitetilaan. Tässä luvussa esitellään yleisesti Prosessit ja palvelut -kohteessa käytettävät toiminnan ja prosessien kuvaustasot sekä vaiheittainen menetelmä, jota voidaan käyttää tarkentuvien kuvausten tuottamiseen Prosessikuvausten tasot Prosesseja mallinnettaessa on hyödyllistä tunnistaa kuvauksissa useita sisäkkäisiä tarkkuus- tai abstraktiotasoja. SerAPI-hankkeen prosessit ja palvelut -kohteessa eri kuvaustavat ja esimerkkeihin liittyvät kuvaukset on liitetty tässä kuvattuihin kuvaustasoihin. Tietty kuvaus tai kuvaustapa voi antaa tietoa monella eri tasolla; kuvaustapa voidaan katsoa tällöin olevan sillä tasolla, jossa tarkimmat kuvattavat asiat ovat. On huomattava, että kaikkia eri tasoilla kuvattavia seikkoja ei ole välttämätöntä kuvata: esimerkiksi voidaan valita, että prosessitasolla tunnistetaan vain joukko toimintoja ilman, että yritetään kattavasti määritellä toimintojen järjestys. I: YLEISKUVA: toimintaympäristö, kokonaiskuva toiminnasta: Yleiskuvan muodostaminen toiminnan kohdealueesta kuvattavat seikat esim.: toimintakokonaisuudet, organisaatiot, organisaatioyksiköt, tunnistetut prosessit, edellisten väliset yhteydet kuvaustavat: prosessikartta (ks. luku 4.1.3), jossa tunnistettuja prosesseja; yhteyskaaviot; toimintakokonaisuuden yleiskuva, organisaatiokartta II: PROSESSITASO: yhden valitun prosessin kuvaus: Usein tämän tason prosessikuvauksissa mennään organisaatio- tai toimijarajojen yli, kuvaten useiden osallistujien välisiä työnkulkuja. Prosessikuvaukset voivat joissain tapauksissa olla myös sisäkkäisiä, mutta osin samoja asioita on mahdollista kuvata myös seuraavalla (toiminto) tasolla. kuvattavat seikat: valitun prosessin tavoitteet, prosessin alun ja loppumisen sekä tuotosten määrittely, prosessin omistaja, prosessin vaiheet (toiminnot), prosessien väliset yhteydet, vaihtoehtoiset prosessin etenemispolut, prosessin eri vaiheiden välillä liikkuvat tiedot, 54

55 Osa 2: prosessien ja palvelujen määrittely ja suunnittelu kuvaustavat: prosessikaaviot, tarkennettu prosessikartta (jossa prosessin toimintoja ja aliprosesseja), aktiviteettikaaviot, prosessinkuvaustaulukko (ks. luku 4.1.3), työnkulun sanalliset kuvaukset, sovelluspalvelujen tunnistamisen kannalta tällä tasolla voidaan tunnistaa esimerkiksi toimintoja, jotka liittyvät moniin eri prosesseihin, tai prosesseja tai niiden osia, joita voitaisiin tukea tai toteuttaa prosessipalveluiden avulla III: TOIMINTOTASO: prosessin yhden vaiheen tai toiminnon tarkempi kuvaus: pääsääntöisesti tämän tason kuvaukset keskittyvät tietyn toimijan tai yksikön tehtävien kuvaukseen, jotka voivat sisältää useita peräkkäisiä toimenpiteitä tai vaiheita; toimintotasolla pyritään kuvaamaan suhteellisen samanlaisena säilyvää toimintaa (säilyy varsinkin toiminnon alkamisen, loppumisen ja tuotosten suhteen eri prosesseissa) kuvattavat seikat: toiminnon tavoitteet, mistä toiminto alkaa, mihin loppuu ja mitä tuottaa, toimijat (henkilöt tai roolit) ja organisaatioyksiköt, luettelo mihin eri prosesseihin liittyy, luettelo toimintoon liittyvistä tietojärjestelmistä, luettelo toiminnon yleisimmistä poikkeustilanteista, luettelo toimintoon liittyvistä (tuotettavista, käytettävistä) tietokokonaisuuksista, toimintoon kuuluvien tarkempien tehtävien tai käyttäjien ja osallistujien tekojen tunnistaminen kuvaustavat: toiminnonkuvaustaulukko (ks. luku 4.1.3), toiminnon sisällä kuvatut työnkulkukaaviot tai aktiviteettikaaviot tai tarkennetut prosessikaaviot, luettelot, toimintatarinat tai työnkulun sanalliset kuvaukset, sovelluspalvelujen tunnistamisen kannalta: voidaan erityisesti tunnistaa, mitkä toiminnot tai toimintojen osat liittyvät toimijoiden tai prosessin vaiheiden välisiin rajapintoihin, ja mitkä ovat näiden rajapintojen vaatimukset ja rajoitteet. IV: TEOT JA VÄLINEET: tarkat kuvaukset, rajapinnat tietojärjestelmiin: tarkan kuvaustason tarkoituksena on erityisesti tarkentaa tietojärjestelmiin ja sovelluspalveluihin kohdistuvia tarpeita ja ratkaisuja niin tarkalla tasolla, että kuvausta voidaan käyttää tarkan suunnittelun lähtökohtana. kuvattavat seikat: käyttäjien tekemät toimenpiteet, järjestelmien tarjoamat toiminnot, käyttäjien tarvitsemat tai tuottamat tiedot tarkalla tasolla, tapahtumat (events) jotka ovat rajapinta käyttäjän tai prosessin ja tietojärjestelmän välillä, tarkat poikkeustilanteet, tarkat kuvaukset käytettyjen tietojärjestelmien käytettävistä piirteistä, kuvaustavat: tarkat tieto- ja toimintomäärittelyt, palvelu- ja rajapintakuvaukset, käyttötapauskuvaukset, toimintatarinat, sovelluspalvelujen tunnistamisen kannalta tämän tason kuvauksista saadaan tarkkoja tarpeita ja ratkaisumalleja, joita voidaan käyttää esim. sovelluspalvelujen määrittelyssä, hankinnassa tai suunnittelussa Prosessikuvausten tuottamisen vaiheet Edellä kuvattujen tasojen mukaisia kuvauksia prosesseista voidaan tuottaa esimerkiksi seuraavanlaista määrittelyprosessia noudattaen. Esimerkit prosessi-, toiminto- sekä teot ja välineet -tasojen kuvauksista (ks. kuvat 14, 15 ja 16) seuraavat tasojen esittelyä. 55

56 Palveluarkkitehtuurin soveltaminen terveydenhuollossa Aluksi muodostetaan kokonaiskuva kohdealueesta. Tähän voi käyttää esimerkiksi toimintatarinaa, kohde-alueen toiminnan yleiskuvausta (keskeiset organisaatiot ja toiminnat), prosessikarttaa tai muita korkean tason kuvausmenetelmiä. YLEISKUVA-tason kuvaukset Valitaan tarkemmin kuvattava prosessi. 1. Kuvataan prosessin tavoitteet. 2. Nimetään prosessin omistaja (jos mahdollista). 3. Määritellään, mistä prosessi alkaa, mihin se loppuu ja mitä prosessi "tuottaa". 4. Tunnistetaan alustavasti prosessin päävaiheet (toiminnot), hyödyntäen esim. yleisiä hoito-, tutkimus- ja toimenpideprosesseja. 5. Toimintojen järjestys voidaan myös määritellä (tai jokin niiden tyypillinen järjestys). 6. Tunnistetaan prosessin osallistujat (organisaatiot, yksiköt, tarkemmissa kuvauksissa henkilöt tai heidän roolinsa). 7. Tuotetaan prosessikuvaus (esim. BPMN-notaatiolla, tarkennetulla prosessikartalla tai aktiviteettikaaviolla), kuvassa voi esittää keskeiset toimijat ja yksiköt (prosessikartta tai BPMN), prosessin vaiheet (BPMN) tai toiminnot (prosessikartta) ja prosessin eteneminen eri vaiheiden välillä (BPMN). PROSESSI-tason kuvaukset 8. Kuvataan toiminnoittain prosessin eri vaiheiden tai toimintojen yhteydet muihin prosesseihin ja toimintoihin ja ko. toiminnon osapuolet. 9. Tarkennetaan, mitä tietoa prosessin eri vaiheissa syntyy, siirtyy tai hyödynnetään. 10. Tarkennetaan, onko jokin prosessin osa (aliprosessi) kuvattava tarkemmin omana prosessinaan. Aliprosesseille kuvataan edeltävät askeleet siten kuin ne soveltuvat. 11. Nimetään ja luokitellaan toiminnon tärkeimmät poikkeukset. TOIMINTO-tason kuvaukset 56

57 Osa 2: prosessien ja palvelujen määrittely ja suunnittelu 12. Kuvataan vaihe vaiheelta valitussa toiminnossa tarvittavat tehtävät ja niissä tapahtuva tietotekniikan käyttö ja tehtävien tapahtumat, jotka ovat rajapinta käyttäjän tai prosessin ja tietotekniikan välillä. 13. Tunnistetaan ja nimetään yleiset tietojärjestelmä- ja sovelluspalvelut, jotka liittyvät vaiheen 10 tapahtumiin ja tehtäviin. 14. Tunnistetaan tietojärjestelmät ja sovellukset, joista sovelluspalveluja voidaan tarjota. 15. Tunnistetaan valmiit palvelumääritykset tai rajapinnat, joita voidaan hyödyntää tai soveltaa. 16. Siirrytään tarkempaan sovelluspalvelujen määrittelyyn tai soveltamiseen (ks. palvelumäärittelyn mallit, SOA) TEOT JA VÄLINEET -tason kuvaukset Kuva 14. Esimerkki prosessitason kuvauksesta: Alatiesynnytysprosessin prosessitason kuvaus 57

58 Palveluarkkitehtuurin soveltaminen terveydenhuollossa Kuva 15. Esimerkki toimintotason kuvauksesta: Alatiesynnytysprosessin kohta 1.1, haastattelu Kuva 16. Esimerkki teot ja välineet -tason kuvauksesta: Alatiesynnytysprosessin kohta 1.1.1, esitietojen täydennys 58

59 Osa 2: prosessien ja palvelujen määrittely ja suunnittelu Prosessien kuvaustavat Prosessien kuvaukseen on runsaasti graafisia, rakenteisia ja sanallisia kuvaustapoja. Prosessikuvauksien ei aina tarvitse olla graafisia, vaikka niiden voima onkin kiistaton korkean abstraktiotason kuvauksissa (esim. kuva 17). Sanalliset selitteet tukevat graafisia esitystapoja. Molemmat kuvaustavat yhdessä antavat kohdealueesta selkeämmän ja tarkemman kuvan kuin kummallakaan kuvaustavalla yksin pystyttäisiin antamaan. ProPa-työssä on käytetty taulukkomuotoisia kuvaustapoja prosessien ominaisuuksien esittämiseen. Näitä taulukkoja voi käyttää apuna prosessien ja niiden osien (toiminnot, tehtävät ja, käyttötapaukset) kuvaamisessa. Hyödynnettäessä taulukoita on syytä pohtia niiden soveltuvuutta kuvattavan kohteen esittämiseen ja muuttaa niitä vastamaan paremmin tarvetta. Prosessikartan (Karimaa ym. 2002) avulla voidaan muodostaa kokonaiskuva kohdealueesta. Kuvassa 17 on esitelty terveydenhuollon hoito-organisaation prosessikartta yleisellä tasolla. Yksiköt/yksikkötyypit (pystylaatikot) on esitelty tarkemmin kuvassa 18. Ydinprosesseja (tummemmat vaakanuolet) on vain yksi, hoito (mm. äitiyshuolto, diabeteshoito). Tukiprosesseja (vaaleammat vaakanuolet) ovat hoidollinen tukipalvelu (mm. laboratoriopalvelut, radiologiapalvelut), hallinto (mm. taloushallinto, henkilöstöhallinto), tieteellinen tutkimus, opetus ja yleinen tukipalvelu (mm. materiaalihuolto, ravintopalvelu). Yleisen tason prosessikartasta voidaan valita prosesseja tarkennettavaksi. Esimerkiksi kuvan 18 prosessikartasta voitaisiin valita tarkasteltavaksi esimerkiksi jokin hoitoprosessi. Valitusta prosessista ja sen tarvitsemista tukiprosesseista voi tehdä tarkemman tason prosessikartan. Luvussa 4.1 on esitelty valitun prosessin kuvaaminen vaiheittain. Luvuissa 4.2 ja 4.2 esitellään tässä kohteessa tarkasteltavat esimerkkiprosessit. TERVEYDENHUOLLON HOITO-ORGANISAATIO Toimenpideyksikkö Hoitoyksikkö Tutkimusyksikkö Hallintoyksikkö Tukipalveluyksikkö Hoito Hoidollinen tukipalvelu Hallinto Tieteellinen tutkimus Opetus Yleinen tukipalvelu Kuva 17. Terveydenhuollon hoito-organisaation yleisen tason prosessikartta Kuvassa 18 on esitelty terveydenhuollon hoito-organisaation yksiköt toiminnallisuuden mukaan luokiteltuna. 59

60 Palveluarkkitehtuurin soveltaminen terveydenhuollossa TERVEYDENHUOLLON HOITO-ORGANISAATIO Hoitoyksiköt Tukipalveluyksiköt Tutkimusyksiköt Toimenpideyksiköt Hallintoyksiköt Poliklinikka Laboratorio Leikkaussali Potilastoimisto Yleis- ja sairaanhoidon hallinto Apuvälinevarasto Keskusvarasto Vuodeosasto Radiologia Heräämö Kehittämis- ja suunnitteluosasto Tietohallinto Keittiö Apteekki Teho-osasto jne. Synnytyssali Henkilöstöosasto Kiinteistöosasto ATK-osasto Lääketieteellisen tekniikan osasto Päivystys Erikoisyksikkö Talousyksikkö jne. Huoltopalveluosasto Tekniikka jne. jne. Siivous Sairaankuljetus jne. Kuva 18. Terveydenhuollon hoito-organisaation yksiköt toiminnallisuuden mukaan luokiteltuna Prosessikaavio on graafinen kuvaus prosessista. Kuvassa 19 on korkean abstraktiotason esimerkkikuvaus prosessin vaiheista. Kuva voi vaikuttaa korostetun yksinkertaiselta, mutta sen tarkoituksena on selvittää lukijalle prosessin jakautuminen selkeisiin, hyvin eroteltaviin vaiheisiin. Tämän tason kuvauksessa ei useimmiten ole tarpeen kuvata toimijoita. Tarkempia prosessiesimerkkejä on kuvissa 14, 15, ja 16. Prosessi Päävaihe Päävaihe Päävaihe Kuva 19. Prosessin ylimmän tason prosessikaavio Prosessinkuvaustaulukko (taulukko 5) on sanallinen kuvaus prosessin ominaisuuksista. Sanallinen kuvaus ja graafinen esitystapa täydentävät toisiaan. Taulukkomuotoinen kuvaus antaa sellaista yksityiskohtaista tietoa, mitä graafinen esitystapa ei pysty tarjoamaan (tai jota ei ole järkevää yrittää liittää graafiseen esitykseen), ja toisaalta graafinen esitys prosessista antaa kertavilkaisulla lukijalle näkymän prosessin vaiheista ja etenemisestä. 60

61 Osa 2: prosessien ja palvelujen määrittely ja suunnittelu Taulukko 5. Prosessinkuvaustaulukko 1 Prosessi Tavoite Omistaja Alku Loppu Tuotokset Päävaiheet Syy, miksi prosessi on olemassa, voi kuvata prosessin lopputulosta. Kuka hallinnoi prosessia ja vastaa prosessin tuloksen tuottamisesta tai etenemisestä, joskus myös (ylläpito)vastuullinen tai prosessin kohteena oleva taho. Mistä prosessi alkaa. Selkeästi määritelty tapahtuma, jonka perusteella prosessi käynnistyy. Mihin prosessi päättyy. Prosessi voi päättyä usealla eri tavalla, ja ainakin tärkeimmät vaihtoehdot on selitettävä. Tieto, tapahtumat (event) tai vaikutukset (real world effects), joita prosessi suorituksen aikana tuottaa. Prosessin muodostavien päävaiheiden nimet numeroituina ja lyhyillä kuvauksilla, esimerkiksi 1.1 Vaiheen nimi Lyhyt kuvaus Osallistujat Tunnistetut poikkeukset, seuraukset, toimenpiteet Muuta Numerointi on tärkeää jäljitettävyyden kannalta. Prosessin eri vaiheisiin osallistuvat tahot (organisaatiot, yksiköt tai henkilöt). Tunnistetut poikkeustilanteet, joihin prosessin suorituksen aikana voidaan päätyä, poikkeusten seuraukset sekä tarvittaessa toimenpiteet, joihin ryhdytään poikkeuksen jälkeen. Muuta huomioitavaa prosessista. Prosessi koostuu toiminnoista, ja toiminnonkuvaustaulukko (taulukko 6) on sanallinen kuvaus toiminnosta. Toiminto voi itsessään olla prosessi, jolloin graafista esitystapaa voidaan käyttää toiminnon kuvaamiseen. 61

62 Palveluarkkitehtuurin soveltaminen terveydenhuollossa Taulukko 6. Toiminnonkuvaustaulukko 1.1 Toiminto Tavoite Osallistujat Esiehdot Tehtävät Tunnistetut poikkeukset Jälkitoimenpiteet Tarvittavat tiedot Tuotettavat tiedot Automatisoinnin tarve Muuta Syy, miksi toiminto on olemassa, kuvaus toiminnon lopputuloksesta. Toiminnon suorittamiseen liittyvät tahot. Mitä ehtoja tulee olla täytettyinä, että toiminto voidaan aloittaa (ks. tietovaatimukset erikseen alempana) Toiminnon muodostavien tehtävien lista numeroituna Tehtävän nimi Tehtävän kuvaus Tehtävän nimi Tehtävän kuvaus Mihin poikkeustilanteisiin toiminnon aikana voidaan päätyä. Mitä toiminnon ulkopuolella tapahtuvia jälkitoimenpiteitä toiminnon suorittaminen aiheuttaa. Mitä tietoja tarvitaan, jotta toiminto voidaan suorittaa Mitä tietoja toiminnon suorituksen aikana tuotetaan. Miten toiminnon osia voitaisiin automatisoida tai mitä automatisointia toiminnon aikana tarvitaan. Muuta huomioitavaa toiminnosta Toiminnonkuvaustaulukossa viitatut tehtävät voidaan niiden laajuuden mukaan joko kuvata suoraan toiminnonkuvaustaulukossa (triviaalit tehtävät) tai niistä voidaan muodostaa omia taulukkomuotoisia kuvauksia (monimutkaiset tehtävät). Taulukkokuvaukseen voi käyttää toiminnonkuvaustaulukon pohjaa. Tasokaavio kuvaa prosessin vaiheet eri tasoilla (ks. tasot luku 4.1.1). Kuvassa 20 on purettu abstraktia prosessia prosessitasolta teot ja välineet -tasolle asti auki (ks. myös endoskopian esimerkki, kuva 24). Tasokaavioon voidaan tehdä hyvin erityyppisiä kuvauksia. Koko prosessin kaikkien vaiheiden purkaminen auki samaan tasokaavioon voi tehdä kaaviosta raskaan luettavan, mutta toisaalta se tarjoaa ainutlaatuisen jäljitettävyyden seurannan aina korkean tason prosessikaaviosta käyttötapauksiin asti. Tasokaavion edut tulevat esiin varsinkin tarkasteltaessa prosessin vaiheita yksi kerrallaan. Käyttötapaustaulukkoa (taulukko 7) käytetään teot ja välineet -tasolla olevien käyttötapausten kuvaamiseen. Tältä tasolta voidaan helposti tunnistaa tarvittavia sovelluspalveluita. Yleensä käyttötapaus keskittyy nimetyn ohjelmiston ja käyttäjän väliseen vuorovaikutukseen, mutta tässä kuvaustavassa keskitytään käyttäjien ja osallistujien toimintaan ja tavoitteisiin. Sovelluspalveluiden kuvaamiseen voidaan käyttää palvelunkuvaustaulukkoa (taulukko 3), joka on esitelty jo aiemmin luvussa

63 Osa 2: prosessien ja palvelujen määrittely ja suunnittelu Prosessi Prosessi 1 Päävaihe 2 Päävaihe 3 Päävaihe Toiminto 1.1 Toiminto 1.2 Toiminto Tehtävä Tehtävä Tehtävä Tehtävä Tehtävä Teot ja välineet KT1 Käyttötapaus KT2 Käyttötapaus KT3 Käyttötapaus KT4 Käyttötapaus Taulukko 7. Käyttötapaustaulukko Kuva 20. Prosessin yhden päävaiheen tasokaavio KT1 Käyttötapauksen nimi Tarve Käyttötapauksen tavoitteen kuvaus. Lisäksi ilmoitetaan tehtävä, josta käyttötapausta hyödynnetään tai josta käyttötapaus saa alkunsa. Viittauksessa on jäljitettävyyden säilymisen takia syytä käyttää viitattavan tehtävän numeroa: Tehtävän nimi. Osallistujat Käyttötapaukseen osallistuvat tahot. Tuloehdot Missä tilanteessa ja millä ehdoilla käyttötapaus alkaa Kuvaus Lyhyt, selkeä kuvaus käyttötapauksen sisällöstä; vaiheet, teot, hyödynnettävät tietojärjestelmät Poikkeukset Mihin poikkeuksiin käyttötapauksessa voidaan päätyä. Lopputulos Mitä tietoja tai palveluita käyttötapauksen myötä syntyy, mihin käyttötapauksen Muut vaatimukset Esim. käyttötapauksen suorittajiin liittyviä vaatimuksia 4.2 Endoskopian mallinnusesimerkki Tässä luvussa esitetään yleistetty endoskopiaprosessin tavoitetilan mallinnusesimerkki. Yleistetyllä endoskopianprosessin mallinnuksella tarkoitetaan, sitä että mallinnettavaa prosessia ei ole sidottu mihinkään tiettyyn erikoissairaanhoidon organisaatioon eikä tiettyihin olemassa oleviin tietojärjestelmiin. Tavoitetilan kuvausta tehdään erityisesti palvelupohjaisen arkkitehtuurin (SOA) ja websovelluspalvelujen hyödyntämisen näkökulmasta. 63

64 Palveluarkkitehtuurin soveltaminen terveydenhuollossa Vaikka kyseessä on esimerkkimallinnus, pyritään prosessia kuitenkin kuvaamaan siten, että soveltuisi mahdollisimman monelta osin erikoissairaanhoidon endoskopiaprosessien kehittämiseen SOAlähestymistapaa soveltaen. Tavoitetilan kuvauksen lähtökohtana Satakunnan sairaanhoitopiirin endoskopian työkulun kuvaus ja Kuopion yliopistollisen sairaalan gastroskopiaprosessin nykytilan kuvaus. Endoskopian tavoitetilan mallinnuksessa on ollut ensisijaisina tavoitteina kehittää nykytilan prosessimalleja sekä tavoitetilan prosesseista ylhäältä alas -menetelmällä ja prosessikuvauksista määrittelemällä palveluja, rajapintoja ja operaatioita. Lisäksi kohteessa on pyritty tunnistamaan käytössä olevia palveluja alhaalta ylös -menetelmällä olemassa olevista järjestelmistä, toteutetuista palveluista ja rajapinnoista.. Tämän dokumentin pääasiallinen tavoite on esitellä menetelmää ja kuvausesimerkkejä eikä kuvata täydellisesti todellista endoskopian prosessia ja sen tavoitetilaa. Kuitenkin pohjana on käytetty todellisista ympäristöistä kerättyjä kuvauksia, ja tavoitteena on ollut kartoittaa minkälaisia integrointija kehitystarpeita endoskopiaprosessiin voisi liittyä ja kuinka niitä voitaisiin toteuttaa palvelupohjaisessa arkkitehtuurissa Endoskopian yleiskuva Endoskopiaprosessi on erikoissairaanhoidon hoito-organisaation hoidollinen tukipalveluprosessi. Kuvassa 21 on endoskopiaprosessin prosessikartta, jossa on kuvattu endoskopiaprosessiin liittyvät hoidolliset ja yleiset tukipalveluprosessit sekä prosessiin osallistuvat yksiköt. 64

65 Osa 2: prosessien ja palvelujen määrittely ja suunnittelu ERIKOISSAIRAANHOIDON HOITO-ORGANISAATIO Potilastoimisto Sisätautien poliklinikka Endoskopian osasto Laboratorio Apteekki Hoito-/tutkimus-/ toimenpideyksikkö Endoskopiatutkimus Patologiatutkimus Laboratoriotutkimus Kuvantaminen Lääkintä Lähetteiden ja palautteiden hallinta Potilastietojen hallinta Ajanvaraus Postitus Konsultaatio Hoidollinen tukipalvelu Yleinen tukipalvelu Kuva 21. Prosessikartta endoskopian hoidollisesta tukipalvelusta erikoissairaanhoidossa Endoskopian prosessitaso Tässä luvussa kuvataan endoskopian hoidollinen tukiprosessi tavoitetila sanallisesti ja kaavioina. Kuvauksessa esitetään endoskopiaprosessin toimintojen järjestys sekä tunnistetaan prosessin tarvitsemat hoidolliset ja yleiset tukipalveluprosessit. Kuvauksesta löytyvät myös hoitoprosessin tarvitsemat tukiprosessit (ks. esim. taulukko 8) (hoidolliset ja yleiset tukipalvelut) sekä prosessiin kuuluva toiminnot. Kuva 22 esittää endoskopiaprosessin päävaiheet ylimmän tason prosessikaaviossa. Endoskopiaprosessi muodostuu ylimmällä tasolla kolmesta päävaiheesta: endoskopiatutkimuksen esitoimenpiteistä, endoskopiatutkimuksesta sekä tutkimuksen jälkitoimenpiteistä. Kuvassa 23 on esitetty endoskopiaprosessin tarkennettu prosessikaavio, joka tarkentaa prosessin päävaiheiden toimintoja. Luvun taulukoissa annetaan kuvaukset tarkennetun prosessikaavion toiminnoista. 65

66 Palveluarkkitehtuurin soveltaminen terveydenhuollossa Taulukko 8: Endoskopian hoidollinen tukiprosessi Endoskopian hoidollinen tukiprosessi Tavoite Tavoitteena on suorittaa endoskopian tutkimus ja antaa tutkimuksen perusteella hoitopalaute tutkittavalle osapuolelle. Omistaja Lähetteen käsittelevä yksikkö (sisätautien poliklinikka). Alku Prosessi alkaa kun lähete saapuu sisäisesti sairaalan toiselta osastolta tai sairaalan ulkopuolelta perusterveyshuollosta. Loppu Prosessi loppuu hoitopalautteen lähettämiseen endoskopiatutkimuksen pyytäneelle osapuolelle. Tuotokset Hoitopalaute, hoitosuunnitelma sekä potilaskertomustietoja. Päävaiheet Endoskopiatutkimuksen esitoimenpiteet, endoskopiatutkimus ja endoskopiatutkimuksen jälkitoimenpiteet. Osallistujat Luvussa esitettyjen toimenpiteiden osallistujat. Tunnistetut poikkeukset, Prosessi keskeytyy, jolloin hoitopalautetta ei vastauksena lähetteeseen: seuraukset, toimenpiteet Lähetteen lähettäneelle osapuolelle ilmoitetaan endoskopianprosessin keskeytymisestä sekä syy miksi endoskopiaa ei voitu suorittaa. Muuta Endoskopiatutkimuksen aikana saatetaan tehdä toisinaan tehdä myös hoitotoimenpiteitä. Endoskopiaprosessin aikana tehdään myös muita tutkimuksia kuten verikokeita, patologian tutkimuksia ja röntgenkuvauksia. Endoskopia hoitoprosessi 1. Endoskopia tutkimuksen esitoimenpiteet 2. Endoskopiatutkimus 3. Endoskopia tutkimuksen jälkitoimenpiteet Kuva 22. Ylimmän tason prosessikaavio endoskopian hoidollisesta tukiprosessista Seuraavassa annetaan lyhyt sanallinen kuvaus kuvassa 23 esitetystä endoskopian prosessista. Prosessin toimintojen tarkemmat kuvaukset esitetään luvun taulukoissa ja tunnistettujen palvelujen tarkemmat kuvaukset esitetään luvun taulukoissa. Sulkeissa olevalla numerolla viitataan endoskopiaprosessin prosessikaavion toimintoihin. Endoskopian hoidollinen tukipalveluprosessi käynnistyy sairaalan ydinprosessia edustavan hoitoprosessin kutsusta. Endoskopiaprosessi alkaa endoskopiatutkimuksen esitoimenpiteillä (toiminnot ), kun lähete saapuu sisäisesti sairaalan toiselta osastolta tai sairaalan ulkopuolelta perusterveyshuollosta. Ensimmäisenä toimenpiteenä lähete tarkastetaan. Mikäli lähete on tullut kirjallisena, lähetteen tiedot kirjataan lähetejärjestelmään ja lähete kirjataan saapuneeksi (1.1). Sähköiset lähetteet tallentuvat automaattisesti lähetejärjestelmään, jolloin lähete tulee ainoastaan kirjata saapuneeksi. 66

67 Osa 2: prosessien ja palvelujen määrittely ja suunnittelu Hoitoprosessi Lähete endoskopiaan Hoitopalaute Endoskopian tutkimuspalvelu 1.1 Lähetteen käsittely 1.2 Hoidon suunnittelu 1.3 Ajanvaraus 1.4 Asiakkaan kutsuminen 2.1 Asiakkaan ilmoittautuminen 1.6 Lääkkeiden tilaus 1.5 Esitutkimukset 2.2 Asiakkaan valmistelu tutkimukseen 2.3 Asiakkaan lääkitys 2.4 Tähystys ja koepalojen otto 3.4 Jatkohoitosuunnitelma 3.1 Tähystyslausunnon kirjoitus ja kuvien valinta 3.3 Tulosten lisääminen potilaskertomukseen 3.2 Jälkitarkastus 3.4 Hoitopalaute tutkimuksen pyytäjälle Kuva 23. Endoskopian hoidollisen tukiprosessin prosessikaavio Kun lähete kirjataan saapuneeksi, lähetepalvelu avaa asiakkaalle samalla automaattisesti uuden hoitojakson potilaskertomukseen. Tämän jälkeen endoskopian osaston vastuulääkäri arvioi tilanteen ja tekee hoitosuunnitelman (1.2). Lääkäri hyödyntää tässä vaiheessa lähetteen ja potilaskertomuksen tietoja. Hoitosuunnitelman yhteydessä lääkäri määrää myös mahdolliset esitutkimukset kuten verikokeet ja röntgentutkimukset. Seuraavaksi tehdään ajanvaraukset tarvittaviin esitutkimuksiin, endoskopiatutkimukseen ja jälkitarkastukseen (1.3) sekä lähetetään potilaalle kutsu tutkimuksiin sekä tarvittavat tutkimusten valmistautumisohjeet (1.5). Prosessin seuraavassa vaiheessa suoritetaan edellä määrätyt esitutkimukset (1.3). Esitutkimuksia voidaan suorittaa myös perusterveyshuollon puolella. Esitutkimustoiminto käyttää laboratoriopalvelua, joka huolehtii ajanvarauksista. Esitoimenpiteiden viimeisenä toimintona tilataan tarvittavat lääkkeet asiakkaalle (1.6). Endoskopiatutkimustoiminto ( ) alkaa asiakkaan ilmoittautumisella potilastoimistossa (2.1), jonka jälkeen asiakas valmistetaan endoskopiatutkimukseen (2.2). Valmistelussa varmistetaan että asiakas on noudattanut ennakko-ohjeita ja asiakkaalle selvitetään tutkimuksen kulku. Tämän jälkeen potilas lääkitään (2.3) ja suoritetaan endoskopiatähystys (2.4). Tähystyksen yhteydessä videokuvasta otetaan still-kuvia, jotka tallentuvat kuvantamisjärjestelmään. Lisäksi otetaan usein myös koepaloja. Tähystyksen jälkeen suoritettavista jälkitoimenpiteistä ( ) ensimmäisenä lääkäri tekee lausunnon tähystyksestä ja valitsee mitkä kuvat liitetään lausuntoon (3.1). Jos tähystyksen aikana on otettu koepaloja, lääkäri laittaa lausuntoon merkinnän patologian tutkimuksesta, joka aiheuttaa automaattisesti patologian tutkimuspyynnön. Tällöin lausuntoon merkitään myös paikat, joista koepalat on otettu. Tämän jälkeen asiakas tulee kohdassa 1.4 varatulle poliklinikan vastaanotolle jälkitarkastukseen (3.2), jossa tarkastetaan potilaan vointi, kerrotaan jatkotoimenpiteistä. Tämän jälkeen täydennetään potilaskertomukseen endoskopian ja patologian tutkimustuloksissa ilmenneet asiat (3.3) ja tehdään asiakkaan jatkohoitosuunnitelma (3.4), jonka tarkoituksena on turvata asiakkaan hoidon jatkuvuus. Viimeisenä toimenpiteenä tehdään hoitopalaute (3.5), joka siirtyy palautteena endoskopiatutkimuksen pyytäneelle osapuolelle. 67

68 Palveluarkkitehtuurin soveltaminen terveydenhuollossa Prosessien toimintotaso Seuraavissa taulukoissa esitetään endoskopiaprosessin toimintojen kuvaukset. Toiminnoista kuvataan tavoite, prosessin osallistujat, esiehdot, tehtävät, tunnistetut poikkeukset ja poikkeuksista aiheutuvat seuraukset tai toimenpiteet, prosessin jälkitoimenpiteet, tarvittavat ja tuotettavat tiedot, mahdolliset automatisoinnin tarpeet sekä muut mahdolliset huomioitavat seikat Endoskopiatutkimuksen esitoimenpiteet 1 Endoskopiatutkimuksen esitoimenpiteet Tavoite Suorittaa endoskopiatutkimukseen valmistavat esitoimenpiteet. Osallistujat Toimenpiteiden henkilöt ja yksiköt. Esiehdot Lähete saapunut perusterveyshuollosta tai sisäinen lähete saapunut sairaalan toiselta osastolta. Tehtävät Toiminnot : Tunnistetut poikkeukset Jälkitoimenpiteet Tarvittavat tiedot Tuotettavat tiedot Automatisoinnin tarve Muuta 1.1 Lähetteen käsittely 1.2 Hoidon suunnittelu 1.3 Ajanvaraus 1.4 Asiakkaan kutsuminen 1.5 Esitutkimukset 1.6 Lääkkeiden tilaus Lähete häviää matkalla: prosessi keskeytyy. Endoskopiatutkimus. Asiakkaan henkilötiedot ja aiemmat sairaudet, lähettämisen syy. 68

69 Osa 2: prosessien ja palvelujen määrittely ja suunnittelu 1.1 Lähetteen käsittely Tavoite Osallistujat Esiehdot Tehtävät Lähete tarkastetaan ja kirjataan vastaanotetuksi sekä valitaan lähetteen käsittelevä lääkäri. Osastonsihteeri. Lähete tai pyyntö on saapunut Lähetteen vastaanotto Tarkastetaan lähete ja kirjataan se vastaanotetuksi Lähetteen ohjaaminen lääkärille Valitaan hoidon suunnitteleva lääkäri ja tehdään lisäys lääkärin työjonoon. Tunnistetut poikkeukset Lähete tullut väärään yksikköön: lähetteen siirto toiseen yksikköön. Lähettämisen peruste ei ole oikein: lähetteen palautus lähettäjälle. Jälkitoimenpiteet Tarvittavat tiedot Henkilötunnus (HeTu), lähetteen tietosisältö (luku 4.3.6). Tuotettavat tiedot Merkintä lähetteen vastaanottamisesta, lisäys lääkärin työjonoon Automatisoinnin tarve Lähete saapuu sähköisesti. Kun valitaan hoidon suunnitteleva lääkäri, tieto lähetteestä siirtyy automaattisesti lääkärin työjonoon. Sähköiseen potilaskertomukseen syntyy automaattisesti uusi hoitojakso, kun lähete kirjataan saapuneeksi. Muuta Hoitotakuun mukainen seuranta alkaa lähetteen kirjaamisesta, joka antaa potilaalle myös uuden hoitokokonaisuustunnuksen. Hoitotakuun mukaan aikaväli on lähetteen saapumisesta lähetteen lukemiseen saa olla korkeintaan kolme viikkoa. 1.2 Hoidon suunnittelu Tavoite Osallistujat Esiehdot Tehtävät Tunnistetut poikkeukset Jälkitoimenpiteet Tarvittavat tiedot Tuotettavat tiedot Automatisoinnin tarve Muuta Kiireellisyyden arviointi, asiakkaan hoidon suunniteltu ennakkoon, tutkimuksien määräys. Lääkäri. Lähete saapunut Lähetteen arviointi Lääkäri tutustuu lähetteeseen ja arvioi tutkimuksen tai hoidon kiireellisyyden ja kirjaa sen Hoitosuunnitelman teko Lääkäri suunnittelee, mikä tähystystutkimus asiakkaalle tehdään ja mitä esitutkimuksia asiakkaalle tarvitaan, ja tekee tarvittavat hoito- ja tutkimusmääräykset. Lähetteen tiedot eivät riitä suunnitelman tekemiseen. Lähetettä ei ole kirjattu vastaanotetuksi: Lääkäri kirjautuu lähetejärjestelmään ja kirjaa lähetteen vastaanotetuksi. Tutkimusten ajanvaraus. Lähetteen tietosisältö, potilaskertomus, hetu, aiemmat sairaudet, tulosyy. Hoito- ja tutkimusmääräykset Hoito- ja tutkimusmääräykset tehdään tietojärjestelmään. Tutkimusmääräykset siirtyvät suoraan myös laboratorio- ja röntgenjärjestelmiin. Hoitotakuun mukaisesti hoidon tarpeen arvioinnin jälkeen hoidon tulee alkaa kuuden kuukauden kuluessa. 69

70 Palveluarkkitehtuurin soveltaminen terveydenhuollossa 1.3 Ajanvaraus Tavoite Osallistujat Esiehdot Tehtävät Tunnistetut poikkeukset Jälkitoimenpiteet Tarvittavat tiedot Tuotettavat tiedot Automatisoinnin tarve Muuta Varataan asiakkaalle ajat endoskopiatutkimukseen, määrättyihin esitutkimuksiin sekä jälkitarkastukseen poliklinikalle. Osastonsihteeri tai hoitaja Lääkäri arvioinut kiireellisyyden ja määrännyt vastaanottavan poliklinikan tai osaston Esitutkimusajan varaaminen Varataan asiakkaalle ajat kohdassa määrättyihin esitutkimuksiin Endoskopiatutkimusajan varaaminen Varataan asiakkaalle aika endoskopiatutkimukseen Jälkitarkastusajan varaaminen Varataan asiakkaalle aika jälkitarkastukseen. Kutsun lähettäminen potilaalle. Asiakastiedot, varattavat vastaanotto- ja tutkimusajat. Ajanvaraustiedot. Ajanvarauksen tiedot siirtyvät potilaskertomukseen. Laboratorioajanvarauspyyntö aiheuttaa automaattisen laboratoriopalvelupyynnön, josta saadaan tutkimusaika. 1.4 Asiakkaan kutsuminen Tavoite Kutsun ja tarvittavien valmistautumisohjeiden lähettäminen asiakkaalle. Osallistujat Osastonsihteeri tai hoitaja. Esiehdot Ajanvaraukset on tehty. Tehtävät Kutsu asiakkaalle Osastonsihteeri tai sairaanhoitaja tulostaa asiakkaalle kutsukirjeen ja laittaa sen kirjekuoreen Potilasohjeiden liittäminen kutsuun Kirjeeseen tulostetaan mukaan tutkimuksiin valmistautumisohjeet. Tunnistetut poikkeukset Kirje ei tulostu: tulostetaan uusi kutsu. Tulostetaan väärät ohjeet. Kutsu tai ohjeet ei lähde. Jälkitoimenpiteet Asiakkaalle määrättyjen tutkimusten ja jälkitarkastuksen suorittaminen. Tarvittavat tiedot Asiakkaan henkilö- ja osoitetiedot, varattavat vastaanotto- ja tutkimusajat. Tuotettavat tiedot Kutsukirje, jossa mahdollisesti ohjeet ennalta määrättyihin tutkimuksiin. Automatisoinnin tarve Kutsukirjeen pohjan valinta, täyttö ja tulostus postituspalvelusta, potilasohjepalvelusta tarvittavat ohjeet kutsun mukaan. Muuta Kirje laitetaan lähtevään postiin. 70

71 Osa 2: prosessien ja palvelujen määrittely ja suunnittelu 1.5 Esitutkimukset Tavoite Osallistujat Esiehdot Tehtävät Tunnistetut poikkeukset Jälkitoimenpiteet Tarvittavat tiedot Tuotettavat tiedot Automatisoinnin tarve Muuta 1.6 Lääkkeiden tilaus Tavoite Osallistujat Esiehdot Tehtävät Tunnistetut poikkeukset Jälkitoimenpiteet Tarvittavat tiedot Tuotettavat tiedot Automatisoinnin tarve Muuta Endoskopiatutkimusta edeltävien esitutkimusten suorittaminen. Laboratoriohoitaja, röntgenhoitaja Asiakkaalle on määrätty esitutkimuksia Laboratoriotutkimus Asiakkaalle tehdään suunnitellut laboratoriotutkimukset Röntgentutkimus Asiakkaalle tehdään suunnitellut röntgentutkimukset. Endoskopiatutkimus. Potilaan nimi ja henkilötunnus, pyytävä yksikkö, lähettävän lääkärin nimi, tutkimuksen nimi, perustelut ja esitiedot sekä haluttu tutkimuspäivämäärä sekä tutkimuksen vaatimat lisätiedot. Esitutkimuksien tulokset. Laboratoriopalvelu käyttää lausuntopalvelua lausunnon luomiseen. Laboratorio- ja röntgentutkimus ovat hoidollisia tukipalveluprosesseja. Asiakkaan tullessa tarvittavat lääkkeet ovat saatavilla osastolla. Sairaanhoitaja. Tutkimukset ja lääkkeet on määrätty Lääkkeiden tilaaminen Apteekista tilataan tarvittavat lääkkeet. Tarvittavia lääkkeitä ei tiedossa: Suoritetaan kohta 1.3 uudestaan. Apteekki hoitaa tilauksen eteenpäin viemisestä ja lääkkeiden tuonnista osastolle. Lääkkeiden nimet vahvuudet ja annostus, asiakkaan riskitiedot (mm. lääkeaineyliherkkyydet). Lääketilaus. Lääkkeiden valinta ja tilaus tietojärjestelmästä Lääkkeiden tilauksen käsittely ja toimitus kuuluvat lääkintäpalveluprosessiin. 71

72 Palveluarkkitehtuurin soveltaminen terveydenhuollossa Endoskopiatutkimus 2 Endoskopiatutkimus Tavoite Suorittaa endoskopiatutkimus. Osallistujat Toimenpiteiden henkilöt ja yksiköt. Esiehdot Lähete, ajanvaraus hoidettu ja vaaditut esitutkimukset suoritettu. Tehtävät Toiminnot : Tunnistetut poikkeukset Jälkitoimenpiteet Tarvittavat tiedot Tuotettavat tiedot Automatisoinnin tarve Muuta 2.1 Asiakkaan ilmoittautuminen 2.2 Asiakkaan valmistelu tutkimukseen 2.3 Asiakkaan lääkitys 2.4 Tähystys ja koepalojen otto Potilas ei saavu tutkimukseen. Endoskopiatutkimuksen jälkitoimenpiteet. 2.1 Asiakkaan ilmoittautuminen Tavoite Asiakas ilmoittautuu potilastoimistossa ja osastolla, jossa endoskopian yksikkö sijaitsee. Osallistujat Asiakas, potilastoimiston henkilökunta, endoskopian osaston osastonsihteeri. Esiehdot Asiakas vastaanottanut tiedon ajanvarauksesta. Tehtävät Asiakas kirjataan saapuneeksi sairaalaan Tunnistetut poikkeukset Asiakas ei ilmoittautunut potilastoimistossa: ohjataan ilmoittautumaan potilastoimistoon. Asiakas tulee päivystyksestä ja hänelle ei ole ajanvarausta: potilaan tiedot syötetään ilmoittautumisen yhteydessä. Jälkitoimenpiteet Asiakkaan valmistelu tutkimukseen. Tarvittavat tiedot Asiakkaan henkilötunnus, ajanvaraustiedot. Tuotettavat tiedot Sisäänkirjaustiedot. Automatisoinnin tarve Muuta Asiakas ohjataan tarvittaessa laboratoriotutkimuksiin. Ilmoittautumisen yhteydessä kirjataan hoitotakuun mukainen käyntitapahtuma seurantatietoihin. 72

73 Osa 2: prosessien ja palvelujen määrittely ja suunnittelu 2.2 Asiakkaan valmistelu tutkimukseen Tavoite Varmistutaan, että asiakas on noudattanut ennakko-ohjeita, selvitetään tutkimuksen kulku asiakkaalle, valmistellaan asiakas tutkimukseen. Osallistujat Lääkäri, hoitaja. Esiehdot Asiakas saapunut ja ilmoittautunut sekä tarvittavat esitutkimukset suoritettu. Tehtävät Selvitetään tutkimuksen kulku asiakkaalle Kerrotaan mitä tutkimuksessa tapahtuu ja esim. missä asennossa tutkimuksen aikana pitää olla Valmistellaan asiakas tutkimukseen Ohjataan asiakas tutkimuspöydälle oikeaan asentoon. Tunnistetut poikkeukset Asiakas ei ymmärrä ohjeita: kerrotaan ohjeet uudestaan. Asiakas ei ole noudattanut ennakko-ohjeita: tarvittaessa perutaan tutkimus. Jälkitoimenpiteet Tarvittavat tiedot Asiakkaan aiemmat sairaudet, määrätty tutkimus tai hoito. Tuotettavat tiedot Kirjataan valmistelu ja ohjaus ja niiden arviointi hoitosuunnitelmaan. Automatisoinnin tarve Sähköiset ohjeet. Muuta 2.3 Asiakkaan lääkitys Tavoite Osallistujat Esiehdot Tehtävät Tunnistetut poikkeukset Jälkitoimenpiteet Tarvittavat tiedot Tuotettavat tiedot Automatisoinnin tarve Muuta Asiakas lääkitään tarpeenmukaisesti. Hoitaja tai lääkäri Lääke määrätty Lääke annetaan asiakkaalle Annostellaan lääke ja annetaan se asiakkaalle Lääkkeenanto kirjataan hoitosuunnitelmaan Lääkettä ei ole määrätty: määrätään lääkitys. Lääkettä ei ole osastolla: tehdään lääketilaus (kohta 1.6). Lääkkeen nimi, annos, annostelutapa, lääkeaineyliherkkyydet. Lääkkeen annon kirjaus potilaskertomukseen. Lääketietokanta potilaskertomuksessa. 73

74 Palveluarkkitehtuurin soveltaminen terveydenhuollossa 2.4 Tähystys ja koepalojen otto Tavoite Suorittaa tähystystutkimus. Osallistujat Lääkäri, hoitaja avustaa. Esiehdot Tutkimukseen tarvittavat välineet ja tiedot saatavilla. Tehtävät Tutkimus suoritetaan Tunnistetut poikkeukset Jälkitoimenpiteet Tarvittavat tiedot Tuotettavat tiedot Automatisoinnin tarve Muuta Lääkäri laittaa endoskoopin tutkittavaan kohteeseen esim. suun kautta mahalaukkuun tai suolistoon Otetaan tarvittavat kuvat Endoskoopin kautta otetaan kuvat Otetaan tarvittavat koepalat Endoskoopin kautta otetaan koepalat. Tehdään tähystyslausunto. Potilastiedot, lähetetiedot, määrätyt tutkimukset. Tutkimuksen kulku kirjataan hoitosuunnitelmaan Endoskopiatutkimuksen jälkitoimenpiteet 3 Endoskopiatutkimuksen jälkitoimenpiteet Tavoite Turvataan potilaan jatkohoito. Osallistujat Toimenpiteiden henkilöt ja yksiköt. Esiehdot Endoskopiatutkimus tehty. Tehtävät Toiminnot : Tunnistetut poikkeukset Jälkitoimenpiteet Tarvittavat tiedot Tuotettavat tiedot Automatisoinnin tarve Muuta 3.1 Tähystyslausunnon laatiminen 3.2 Jälkitarkastus 3.3 Tulosten lisäys potilaskertomukseen 3.4 Jatkohoitosuunnitelma 3.5 Hoitopalaute perusterveydenhuoltoon 74

75 Osa 2: prosessien ja palvelujen määrittely ja suunnittelu 3.1 Tähystyslausunnon laatiminen Tavoite Endoskopiasta saatu tieto tuotetaan lausunnoksi. Osallistujat Lääkäri tai osastonsihteeri. Esiehdot Endoskopia tehty. Tehtävät Tehdään lausunto (lausutaan tai kirjoitetaan) Tunnistetut poikkeukset Jälkitoimenpiteet Tarvittavat tiedot Tuotettavat tiedot Automatisoinnin tarve Muuta Lääkäri tekee lausunnon tutkimuksesta saadun tiedon perusteella Valitaan mitkä kuvat liitetään lausuntoon Lausuntoon valitaan kuvia, jotka otettiin skopian aikana Merkitään näytteenottopaikat Lausunnossa olevaan kaaviokuvaan merkitään kohdat mistä näytteet on otettu Lausunto liitetään potilaskertomukseen (lausunto tulostetaan mukaan) Lausunto jää tekemättä. Koepalat lähetetään patologian yksikköön (jos tuotetaan lähete patologiaan). Asiakkaan tiedot, skopian kulku, näytteidenottopaikat. Otettujen kuvien ja koepalojen paikat merkitään lausuntoon, näkymän lausunto, patologian tutkimuspyyntö. Endoskopia lausuntopohja, fraasien valinta pudotusvalikoista. Valittaessa kuvat kuvantamispalvelu tekee pyynnön lausuntopalveluun ja siirtää valitut kuvat lausuntoon. Merkintä patologian pyynnöstä aiheuttaa automaattisen patologian palvelupyynnön ja patologian tutkimuksen valmistuttua patologian lausunto talletetaan lausuntopalvelun kautta. 3.2 Jälkitarkastus Tavoite Osallistujat Esiehdot Tehtävät Tunnistetut poikkeukset Jälkitoimenpiteet Tarvittavat tiedot Tuotettavat tiedot Automatisoinnin tarve Muuta Asiakas käy jälkitarkastuksessa. Lääkäri, hoitaja, osastonsihteeri. Endoskopia tehty ja vastaukset tutkimuksista valmiina Asiakkaan vointi tarkastetaan Lääkäri ja hoitaja kyselevät asiakkaalta vointia. Asiakas ei saavu jälkitarkastukseen. Mahdollinen jatkohoitosuunnitelma. Tutkimustulokset (endoskopian ja patologin lausunnot). Havainnot asiakkaan tilasta kirjataan. 75

76 Palveluarkkitehtuurin soveltaminen terveydenhuollossa 3.3 Tulosten lisäys potilaskertomukseen Tavoite Täydentää potilaskertomukseen tutkimuksissa ilmenneet asiat. Osallistujat Lääkäri. Esiehdot Endoskopian ja patologian tutkimukset tehty ja vastaukset tutkimuksista valmiina. Tehtävät Lisätään tarpeelliset täydennykset potilaskertomukseen Tunnistetut poikkeukset Jälkitoimenpiteet Tarvittavat tiedot Tuotettavat tiedot Automatisoinnin tarve Muuta esimerkiksi tutkimustuloksien vastaukset Tutkimustulokset (endoskopian ja patologin lausunnot). Havainnot asiakkaan tilasta kirjataan potilaskertomukseen. 3.4 Jatkohoitosuunnitelma Tavoite Asiakkaan hoidon jatkuvuus turvataan. Osallistujat Lääkäri, hoitaja, osastonsihteeri. Esiehdot Kaikki vastaukset valmiina, jälkitarkastus tehty. Tehtävät Kerrotaan jatkotoimenpiteistä asiakkaalle Tunnistetut poikkeukset Jälkitoimenpiteet Tarvittavat tiedot Tuotettavat tiedot Automatisoinnin tarve Muuta Kirjataan jatkohoito Hoitopalaute perusterveydenhuoltoon, tarvittaessa muun erikoisalan konsultaatio. Tutkimustulokset. Jatkohoitosuunnitelma. 3.5 Hoitopalaute perusterveydenhuoltoon Tavoite Hoitopalaute, jatkohoito-ohjeet siirtyvät endoskopiatutkimuksen pyytäneelle osapuolelle. Osallistujat Sisätautien klinikka, lääkäri, hoitaja tai osastonsihteeri. Esiehdot Tutkimustulokset valmiit. Tehtävät Sanellaan tai kirjoitetaan hoitopalaute Tunnistetut poikkeukset Jälkitoimenpiteet Tarvittavat tiedot Tuotettavat tiedot Automatisoinnin tarve Muuta Hoitopalaute lähetetään lähettävälle lääkärille Hoitopalaute ei lähde. Laskutustietojen kirjaaminen. Tutkimustulokset. Loppulausunto ja hoito-ohjeet. Loppulausunnon siirto hoitopalautteeksi. Endoskopian ja patologian lausunnot saadaan lausuntopalvelun kautta. 76

77 Osa 2: prosessien ja palvelujen määrittely ja suunnittelu Tekojen ja välineiden taso Tässä luvussa esitetään käyttötapauskuvaukset endoskopiatutkimuksen esitoimenpiteistä. Sen sijaan endoskopiatutkimuksen ja endoskopiatutkimuksen jälkitoimenpiteiden käyttötapauskuvauksia ei esitetä tässä dokumentissa. Kuva 24 esittää endoskopiatutkimuksen esitoimenpiteiden toimintojen, tehtävien ja käyttötapausten hierarkian. Ylimmässä prosessiosassa on esitetty prosessin päätoiminnot ja keskimmäisessä toiminnot osassa on esitetty endoskopiatutkimuksen esitoimenpiteiden toiminnot ja tehtävät. Alimmaisessa tekojen ja välineiden osassa on esitetty endoskopiatutkimuksen esitoimenpiteisiin liittyvät käyttötapaukset. Seuraavien alalukujen taulukoissa esitetään endoskopiatutkimuksen esitoimenpiteiden toimintoihin liittyvät käyttötapaukset tekojen ja välineiden tasolla. Toiminnot sisältävät tehtäviä (esimerkiksi ja 1.1.2). Alimmaisessa tekojen ja välineiden osassa on esitetty käyttötapaukset ja niiden yhteydet tehtäviin. Kuva 24. Endoskopian esitoimenpiteiden toimintojen, tehtävien ja käyttötapausten hierarkia. 77

78 Palveluarkkitehtuurin soveltaminen terveydenhuollossa Lähetteen käsittely (1.1) Seuraavissa taulukoissa on esitetty kuvaukset lähetteen käsittelyn toimintoihin liittyvistä käyttötapauksista. KT1 Kirjautuminen lähetejärjestelmään Tarve Lähetteen vastaanotto Lähetteen ohjaaminen lääkärille Lähetteen arviointi Osallistujat Osastonsihteerit tai lääkäri. Tuloehdot Kirjautujalla tulee olla oikeudet kirjautua järjestelmään. Kuvaus Kirjaudutaan lähetetietojärjestelmään. Poikkeukset Käyttäjäoikeudet tai salasana vanhentunut. Lopputulos Käyttäjä on kirjautunut lähetejärjestelmään. Muut vaatimukset KT2 Saapuneiden lähetteiden haku Tarve Lähetteen vastaanotto Osallistujat Osastonsihteeri. Tuloehdot On kirjauduttu lähetejärjestelmään (KT1). Kuvaus Haetaan ne saapuneet lähetteet, joita ei ole kirjattu vastaanotetuksi (KT3). Poikkeukset Lopputulos Osastonsihteeri saa esille linkit lähetteisiin, joita ei ole vielä vastaanotettu. Muut vaatimukset KT3 Lähetteen avaaminen Tarve Lähetteen vastaanotto Lähetteen arviointi Osallistujat Osastonsihteeri tai lääkäri. Tuloehdot On kirjauduttu lähetejärjestelmään (KT1) ja saapuneet lähetteet haettu (KT2) Kuvaus Haetaan haluttu lähete lähetejärjestelmästä ja lähete avautuu. Poikkeukset Lähete ei aukea. Lopputulos Valittu lähete avautuu näytölle. Muut vaatimukset Lähete voidaan avata saapuneiden lähetteiden haun (KT2) linkistä tai suoraan hakuehdoilla lähetepalvelun kautta. KT4 Lähetteen kirjaaminen vastaanotetuksi Tarve Lähetteen vastaanotto Lähetteen arviointi (mikäli ei ole tehty lähetteen vastaanotossa) Osallistujat Osastonsihteeri tai lääkäri. Tuloehdot On kirjauduttu lähetejärjestelmään (KT1), saapuneet lähetteet haettu (KT2), lähete on avattu (KT3). Kuvaus Osastonsihteeri tarkistaa lähetteen ja merkitsee sen vastaanotetuksi. Poikkeukset Lähete on tullut väärään paikkaan: lähete toimitetaan oikeaan paikkaan. Lähettämisen syy ei ole oikein. Lopputulos Lähetejärjestelmään tulee merkintä lähetteen vastaanottamisesta. Muut vaatimukset Kun lähete kirjataan vastaanotetuksi, lähetepalvelu avaa asiakkaalle automaattisesti hoitojakson potilaskertomukseen. 78

79 Osa 2: prosessien ja palvelujen määrittely ja suunnittelu KT5 Hoidon suunnittelevan lääkärin valinta Tarve Lähetteen ohjaaminen lääkärille Osallistujat Osastonsihteeri. Tuloehdot On kirjauduttu lähetejärjestelmään (KT1), saapuneet lähetteet haettu (KT2), lähete on avattu (KT3), Lähete kirjattu vastaanotetuksi (KT4) Kuvaus Valitaan hoidon suunnitteleva lääkäri ja lisätään hoidon suunnittelu (toiminto 1.2) lääkärin työjonoon. Työjonon tehtäväkuvaukseen lisätään linkki asiakkaan lähetteeseen. Poikkeukset Lopputulos Muut vaatimukset Työjono tehtäväkuvauksessa linkki, josta saadaan avattua asiakkaan lähete. KT6 Työtehtävän haku työjonosta Tarve Lähetteen arviointi Osallistujat Lääkäri. Tuloehdot On kirjauduttu lähetejärjestelmään (KT1), saapuneet lähetteet haettu (KT2), lähete on avattu (KT3), Lähete kirjattu vastaanotetuksi (KT4), Hoitava lääkäri valittu (KT5). Kuvaus Lääkäri hakee työjonosta seuraavan tehtävänsä työjonosta. Tässä tapauksessa jonossa on hoidon suunnittelu toiminnon (1.2), joka käsittää asiakkaan lähetteen arvioinnin (1.2.1) ja hoitosuunnitelman teon (1.2.2) tehtävät. Poikkeukset Lopputulos Lääkäri saa seuraavan suoritettavan työtehtäväkuvauksen esille, joka käsittää tässä tapauksessa myös linkin asiakkaan lähetteeseen. Muut vaatimukset Hoidonsuunnittelun tehtäväkuvauksessa linkki asiakkaan lähetteeseen. KT7 Kirjautuminen potilaskertomusjärjestelmään Tarve Lähetteen arviointi Hoitosuunnitelman teko Osallistujat Lääkäri. Tuloehdot Kirjautujalla tulee olla oikeudet kirjautua järjestelmään. Kuvaus Kirjaudutaan potilaskertomusjärjestelmään. Poikkeukset Käyttäjäoikeudet tai salasana vanhentunut. Lopputulos Käyttäjä on kirjautunut potilaskertomusjärjestelmään. Muut vaatimukset KT8 Potilaskertomuksen haku Tarve Lähetteen arviointi Osallistujat Lääkäri. Tuloehdot Potilaskertomusjärjestelmään on kirjauduttu (KT7). Käyttäjäoikeudet potilaskertomuksen hakuun. Kuvaus Haetaan asiakkaan potilaskertomus potilaskertomusjärjestelmästä. Poikkeukset Potilaskertomus ei aukea. Potilaskertomusta ei ole: Luodaan potilaskertomus. Lopputulos Lääkärillä on asiakkaan lähete esillä. Muut vaatimukset 79

80 Palveluarkkitehtuurin soveltaminen terveydenhuollossa KT9 Kiireellisyyden arviointi Tarve Lähetteen arviointi Osallistujat Lääkäri. Tuloehdot Työtehtävä haettu työjonosta (KT6), potilaskertomusjärjestelmään kirjauduttu (KT7), potilaskertomus haettu (KT8). Lähete- ja sairaskertomustietojen tulee olla saatavilla. Kuvaus Lääkäri arvioi asiakkaan hoidon tarpeen kiireellisyyden lähetteen tietojen (ja aiempien sairauskertomustietojen perusteella) perusteella. Poikkeukset Lääkärillä ei ole riittäviä tietoja kiireellisyyden arvioimiseen. (esim. lähettä ei ole saatavilla) Lopputulos Asiakkaan hoidon tarpeen kiireellisyys arvioitu ja merkitty lähetejärjestelmään. Muut vaatimukset Lääkäri ottaa kantaa hoitotakuuseen ja tapahtuma kirjautuu hoitotakuun seurantaan. Käyttäjäoikeudet kiireellisyyden arviointiin Hoidon suunnittelu (1.2) Seuraavissa taulukoissa on esitetty kuvaukset hoidon suunnittelun toimintoihin liittyvistä käyttötapauksista. KT10 Hoitosuunnitelman kirjaaminen Tarve Hoitosuunnitelman teko Osallistujat Lääkäri. Tuloehdot Työtehtävä haettu työjonosta (KT6), potilaskertomusjärjestelmään kirjauduttu (KT7), potilaskertomus haettu (KT8), kiireellisyys arvioitu (KT9) Kuvaus Lääkäri tekee hoitojaksokohtaisen hoitosuunnitelman asiakkaalle ja kirjaa sen potilaskertomukseen. Käyttäjällä oikeudet hoitosuunnitelman tekoon. Poikkeukset Lähetteen tiedot puutteelliset: Selvitetään puutteelliset tiedot. Potilaalle ei ole avattu hoitojaksoa, jolloin hoitosuunnitelmaa ei voida kirjata: Avataan hoitojakso. Lopputulos Asiakkaalle on kirjattu hoitojaksokohtainen hoitosuunnitelma. Muut vaatimukset Lääkärillä tulee olla lähete- ja potilaskertomustiedot käytettävissä. KT11 Hoitomääräyksen teko Tarve Hoitosuunnitelman teko Osallistujat Lääkäri. Tuloehdot Työtehtävä haettu työjonosta (KT6), potilaskertomusjärjestelmään kirjauduttu (KT7), potilaskertomus haettu (KT8), kiireellisyys arvioitu (KT9), hoitosuunnitelma kirjattu (KT10) Käyttäjällä oikeudet hoitomääräyksen tekoon. Kuvaus Lääkäri määrää asiakkaalle tehtävän hoitotoimenpiteen ja kirjaa sen. Poikkeukset Lähetteen tiedot puutteelliset: selvitetään puutteelliset tiedot. Potilaalle ei ole avattu hoitojaksoa, jolloin hoitomääräystä ei voida kirjata. Lopputulos Asiakkaalle on määrätty suoritettava hoitotoimenpide. Muut vaatimukset 80

81 Osa 2: prosessien ja palvelujen määrittely ja suunnittelu KT12 Tutkimusmääräyksen teko Tarve Hoitosuunnitelman teko Osallistujat Lääkäri. Tuloehdot Työtehtävä haettu työjonosta (KT6), potilaskertomusjärjestelmään kirjauduttu (KT7), potilaskertomus haettu (KT8), kiireellisyys arvioitu (KT9), hoitosuunnitelma kirjattu (KT10) Käyttäjällä oikeudet tutkimusmääräyksen tekoon. Kuvaus Lääkäri määrää asiakkaalle tehtävän tutkimuksen ja kirjaa määräyksen. Poikkeukset Lähetteen tiedot puutteelliset: selvitetään puutteelliset tiedot. Potilaalle ei ole avattu hoitojaksoa, jolloin tutkimusmääräystä ei voida kirjata. Lopputulos Asiakkaalle on määrätty tutkimus. Muut vaatimukset KT13 Lääkityksen määrääminen Tarve Hoitosuunnitelman teko Osallistujat Lääkäri. Tuloehdot Työtehtävä haettu työjonosta (KT6), potilaskertomusjärjestelmään kirjauduttu (KT7), potilaskertomus haettu (KT8), kiireellisyys arvioitu (KT9), hoitosuunnitelma kirjattu (KT10) Lääkärillä tulee olla potilaan riskitiedot käytettävissä. Oikeudet määrätä lääkitys asiakkaalle. Kuvaus Lääkäri määrää asiakkaalle endoskopiatutkimuksessa tarvittavat lääkkeet ja kirjaa hoitosuunnitelmaan. Poikkeukset Lähetteen tiedot puutteelliset: selvitetään puutteelliset tiedot. Lopputulos Asiakkaalle määrätty lääkitys endoskopiatutkimukseen ja tarvittava lääkitys kirjattu hoitosuunnitelmaan. Muut vaatimukset KT14 Kuittaus työtehtävän valmistumisesta Tarve Hoitosuunnitelman teko Osallistujat Lääkäri. Tuloehdot Työtehtävä haettu työjonosta (KT6), potilaskertomusjärjestelmään kirjauduttu (KT7), potilaskertomus haettu (KT8), kiireellisyys arvioitu (KT9), hoitosuunnitelma kirjattu (KT10), hoitomääräys tehty (KT11), tutkimusmääräys tehty (KT12), Lääkitys määrätty (KT13). Kuvaus Lääkäri kuittaa työjonossa olleen työtehtävän tehdyksi, sen jälkeen kun on suorittanut tehtävän. Poikkeukset Lopputulos Työtehtävä kuitattu suoritetuksi, jolloin tehtävä poistuu työjonosta. Muut vaatimukset 81

82 Palveluarkkitehtuurin soveltaminen terveydenhuollossa Ajanvaraus (1.3) Seuraavissa taulukoissa on esitetty kuvaukset ajanvarauksen toimintoihin liittyvistä käyttötapauksista. KT15 Kirjautuminen ajanvarausjärjestelmään Tarve Esitutkimusajan varaaminen Endoskopiatutkimusajan varaaminen Jälkitarkastusajan varaaminen Kutsu asiakkaalle Osallistujat Osastonsihteeri Tuloehdot Kirjautujalla tulee olla oikeudet kirjautua järjestelmään. Kuvaus Käyttäjä kirjautuu ajanvarausjärjestelmään. Poikkeukset Käyttöoikeudet tai salasana vanhentunut. Lopputulos Käyttäjä on kirjautunut ajanvarausjärjestelmään. Muut vaatimukset KT16 Vapaiden aikojen haku Tarve Esitutkimusajan varaaminen Endoskopiatutkimusajan varaaminen Jälkitarkastusajan varaaminen Osallistujat Osastonsihteeri Tuloehdot On kirjauduttu ajanvarausjärjestelmään (KT15) Kuvaus Haetaan ajanvarauskohteen vapaat ajat annettujen hakuehtojen perusteella. Poikkeukset Lopputulos Käyttäjälle tulostuu näytöllä kohteen vapaat ajat ajanvarausjärjestelmästä. Muut vaatimukset KT17 Varattujen aikojen haku Tarve Esitutkimusajan varaaminen Endoskopiatutkimusajan varaaminen Jälkitarkastusajan varaaminen Osallistujat Osastonsihteeri Tuloehdot On kirjauduttu ajanvarausjärjestelmään (KT15). Varattujen aikojen katseluun on asiakkaan suostumus. Kuvaus Haetaan ajanvarauskohteen varatut ajat ajanvarausjärjestelmästä halutulta aikaväliltä. Poikkeukset Lopputulos Käyttäjälle tulostuu näytöllä kohteen varatut ajat. Muut vaatimukset 82

83 Osa 2: prosessien ja palvelujen määrittely ja suunnittelu KT18 Ajan varaaminen Tarve Esitutkimusajan varaaminen Endoskopiatutkimusajan varaaminen Jälkitarkastusajan varaaminen Osallistujat Osastonsihteeri Tuloehdot On kirjauduttu ajanvarausjärjestelmään (KT15). On haettu vapaat ajat (KT16)ja varatut ajat (KT17). Käyttäjällä ajanvarausoikeudet. Kuvaus Käyttäjä varaa haluttuun kohteeseen (esim. tutkimukseen) vapaan ajan. Valitaan vapaista ajoista haluttu aika, kirjataan asiakkaan tiedot ja muut ajanvarauksen tarvitsemat tiedot Poikkeukset Varattava aika ei ole vapaa. (Esim. vapaa aika ehditään varata sillä aikaa kun täytetään ajanvarauksen tietoja.) Lopputulos Asiakkaalle on varattu aika ajanvarausjärjestelmästä haluttuun kohteeseen (tutkimukseen). Muut vaatimukset Asiakkaan kutsuminen (1.4) Seuraavissa taulukoissa on esitetty kuvaukset potilaan kutsun toimintoihin liittyvistä käyttötapauksista. KT19 Kutsupohjan haku Tarve Kutsu asiakkaalle Osallistujat Osastonsihteeri. Tuloehdot Aika varattu (KT18) Kuvaus Haetaan näytölle kutsulle sopiva kutsupohja. Poikkeukset Ei löydy tilanteeseen sopivaa kutsupohjaa. Lopputulos Saadaan valittu tyhjä tai osittain esitäytetty kutsupohja näytölle. Muut vaatimukset KT20 Kutsun teko Tarve Osallistujat Tuloehdot Kuvaus Poikkeukset Lopputulos Muut vaatimukset Kutsu asiakkaalle Osastonsihteeri tai sairaanhoitaja. Tutkimukset määrätty (KT10-12), aika varattu (KT18) ja haettu kutsupohja (KT19), jolle kutsu tehdään. Täydennetään valittuun kutsupohjaan (KT19) potilaan yhteystiedot ja hänelle varatut tutkimusajat sekä lisätään liitteeksi tarvittavat tutkimuksiin liittyvät ennakkovalmistelujen potilasohjeet. Valmis kutsu, joka sisältää kutsut määrättyihin tutkimuksiin sekä potilasohjeet tutkimuksiin. Lähetepalvelu vastaa kutsukirjeen ja ohjeistukset asiakkaalle Esitutkimukset (1.5) Esitutkimusten käyttötapauksia ei kuvata tässä dokumentissa, koska esitutkimukset tehdään tukipalveluprosessipyyntöinä ja niiden käyttötapaukset tulee kuvata kyseisten tutkimusprosessien kuvauksissa. 83

84 Palveluarkkitehtuurin soveltaminen terveydenhuollossa Lääkkeiden tilaus (1.6) Seuraavissa taulukoissa on esitetty kuvaukset lääkkeiden tilauksen toimintoihin liittyvistä käyttötapauksista. KT21 Kirjautuminen potilastietojärjestelmään Tarve Hoitosuunnitelman teko Lääkkeiden tilaus Osallistujat Sairaanhoitaja. Tuloehdot Kirjautujalla tulee olla oikeudet kirjautua järjestelmään. Kuvaus Sairaanhoitaja kirjautuu potilastietojärjestelmään. Poikkeukset Käyttäjäoikeudet tai salasana vanhentunut. Lopputulos Käyttäjä on kirjautunut potilastietojärjestelmään. Muut vaatimukset KT22 Asiakkaan riskitietojen haku Tarve Hoitosuunnitelman teko Lääkkeiden tilaus Osallistujat Sairaanhoitaja tai lääkäri. Tuloehdot On kirjauduttu potilastietojärjestelmään (KT21). Oikeudet hakea riskitietoja. Kuvaus Haetaan asiakkaan allergiatiedot ja muut riskitiedot. Poikkeukset Lopputulos Saadaan halutun asiakkaan allergia- ja riskitiedot näkyville. Muut vaatimukset KT23 Kirjautuminen lääketietojärjestelmään Tarve Lääkkeiden tilaus Osallistujat Sairaanhoitaja. Tuloehdot Kirjautujalla tulee olla oikeudet kirjautua järjestelmään. Kuvaus Sairaanhoitaja kirjautuu lääketietojärjestelmään. Poikkeukset Käyttäjäoikeudet tai salasana puuttuu. Lopputulos Käyttäjä on kirjautunut lääketietojärjestelmään. Muut vaatimukset KT24 Lääkkeen haku Tarve Lääkkeiden tilaus Osallistujat Sairaanhoitaja. Tuloehdot On kirjauduttu lääketietojärjestelmään (KT22). Kuvaus Haetaan halutuilla hakuehdoilla haluttu lääke tai lääkkeet. Poikkeukset Lopputulos Listaus hakuehdon täyttävistä lääkkeistä. Muut vaatimukset 84

85 Osa 2: prosessien ja palvelujen määrittely ja suunnittelu KT25 Lääkkeen tilaus Tarve Lääkkeiden tilaus Osallistujat Sairaanhoitaja. Tuloehdot Asiakkaan riskitiedot haettu (KT22), lääketietojärjestelmään kirjauduttu (KT23), lääke haettu (KT24). Lääkettä on saatavilla tilattava määrä. Käyttäjäoikeudet lääketilauksen tekemiseen. Kuvaus Tilataan asiakkaalle määrätyt tai muut tarvittavat lääkkeet. Poikkeukset Lopputulos Lääkkeet tilattu ja lääketilaus tallentunut lääketilausjärjestelmään. Muut vaatimukset Apteekki toimittaa lääketilauksen mukaiset lääkkeet yksikköön. Lääkkeiden nimet, vahvuudet ja annostus, asiakkaan lääkeaineyliherkkyydet Palvelukuvaukset Endoskopiaprosessin kuvausta prosessitasolla, ja erityisesti esitoimenpiteiden kuvausta tarkemmalla tekojen ja välineiden tasolla on käytetty prosessissa tarvittavien sovelluspalvelujen tunnistamiseen. Endoskopiaprosessi hyödyntää seuraavia sovelluspalveluja: Lähetepalvelu Työjonopalvelu Ajanvarauspalvelu Laboratoriopalvelu Kuvantamispalvelu Lausuntopalvelu Patologian tutkimuspalvelu Hoitosuunnitelmapalvelu Postituspalvelu Potilasohjepalvelu Lääketilauspalvelu Potilaskertomuspalvelu Kuvassa 25 on tarkennettu endoskopian hoidollinen tukiprosessi ja siitä tunnistetut edellä mainitut palvelut. Eri palveluiden liittyminen endoskopiaprosessin esitoimenpiteiden eri käyttötapauksiin kuvataan tarkemmissa palveluiden kuvauksissa kohdassa "Mihin käyttötapauksiin liittyy". 85

86 Palveluarkkitehtuurin soveltaminen terveydenhuollossa Kuva 25. Endoskopian hoidollisen tukiprosessin tarkennettu prosessikaavio. 86

87 Osa 2: prosessien ja palvelujen määrittely ja suunnittelu Seuraavissa taulukoissa esitetään endoskopian palveluprosessin käyttämien potentiaalisten sovelluspalveluiden peruskuvaukset käyttäen palvelukuvauksiin tarkoitettuja taulukoita: Lähetepalvelu Tarkoituksen lyhyt kuvaus: mitä toimintoja ja tietoja kattaa Integrointitapa Yleiskäyttöisyys Mihin käyttötapauksiin liittyy Mihin sovelluksiin tai tuotteisiin liittyy Mihin määrityksiin liittyy Yhteydet ja riippuvuudet muihin palveluihin Arvio saatavuudesta, toteutettavuudesta, mukauttamistarpeista Muut kommentit Työjonopalvelu Tarkoituksen lyhyt kuvaus: mitä toimintoja ja tietoja kattaa Integrointitapa Yleiskäyttöisyys Mihin käyttötapauksiin liittyy Mihin sovelluksiin tai tuotteisiin liittyy Mihin määrityksiin liittyy Yhteydet ja riippuvuudet muihin palveluihin Arvio saatavuudesta, toteutettavuudesta, mukauttamistarpeista Muut kommentit Toiminnot: Hae saapuneet lähetteet, valitse lähete, avaa lähete, merkitse lähete saapuneeksi Tiedot: Lähetteen tiedot (katso luku 4.3.6) Tietopalvelu Ydinpalvelu KT1 Kirjautuminen lähetejärjestelmään KT2 Saapuneiden lähetteiden haku KT3 Lähetteen avaaminen KT4 Lähetteen kirjaaminen vastaanotetuksi Potilashallintojärjestelmä, potilaskertomusjärjestelmä Open CDA Lähetteen ja hoitopalautteen CDA R2-rakenne (ks. luku 4.2.6) Potilaskertomuspalvelu: lähetteen vastaanotosta ilmoitus potilaskertomuspalveluun -> hoitojakson avaus. Potilashallintojärjestelmä Toiminnot: Lisää tehtävä työjonoon, hae työtehtävä, poista työtehtävä Tiedot: työjonon omistaja, työjonon työtehtävät Tietopalvelu. Yleispalvelu. KT5 Hoidon suunnittelevan lääkärin valinta Jonojenhallintajärjestelmä, potilashallintojärjestelmät, osastojen ja poliklinikoiden järjestelmät Potilashallintojärjestelmä 87

88 Palveluarkkitehtuurin soveltaminen terveydenhuollossa Hoitosuunnitelmapalvelu Tarkoituksen lyhyt kuvaus: mitä toimintoja ja tietoja kattaa Integrointitapa Yleiskäyttöisyys Mihin käyttötapauksiin liittyy Mihin sovelluksiin tai tuotgteisiin liittyy Mihin määrityksiin liittyy Yhteydet ja riippuvuudet muihin palveluihin Arvio saatavuudesta, toteutettavuudesta, mukauttamistarpeista Muut kommentit Laboratoriopalvelu Tarkoituksen lyhyt kuvaus: mitä toimintoja ja tietoja kattaa Integrointitapa Yleiskäyttöisyys Mihin käyttötapauksiin liittyy Mihin sovelluksiin tai tuotteisiin liittyy Mihin määrityksiin liittyy Yhteydet ja riippuvuudet muihin palveluihin Arvio saatavuudesta, toteutettavuudesta, mukauttamistarpeista Muut kommentit Toiminnot: hae hoitosuunnitelma, tallenna hoitosuunnitelma, päivitä hoitosuunnitelma. Tiedot: HeTu, Hoitosuunnitelmaan kirjatut tiedot Tietopalvelu. Ydinpalvelu. KT1 Kirjautuminen lähetejärjestelmään KT3 Lähetteen avaaminen KT4 Lähetteen kirjaaminen vastaanotetuksi KT 6 Työtehtävän haku työjonosta KT 7 Kirjautuminen potilaskertomusjärjestelmään KT 8 Potilaskertomuksen haku KT 9 Kiireellisyyden arviointi KT 10 Hoitosuunnitelman kirjaaminen KT 11 Hoitomääräyksen teko KT 12 Tutkimusmääräyksen teko KT 13 Lääkityksen määrääminen KT 14 Kuittaus työtehtävän valmistumisesta Potilaskertomusjärjestelmä Potilaskertomuspalvelu: Hoitosuunnitelma tallennetaan potilaskertomukseen. ajan- ja hoidonvarausjärjestelmä Toiminnot: Hae henkilö, hae tutkimus, valitse tutkimus, tallenna tutkimuspyyntö, välitä tutkimuspyyntö Tiedot: HeTu, tutkimus, tilaava yksikkö, tilaava lääkäri Prosessipalvelu. Erikoispalvelu. Laboratoriotietojärjestelmä, potilaskertomusjärjestelmät Ajanvarauspalvelu. Kaksisuuntainen yhteys potilastietojärjestelmästä laboratoriojärjestelmään 88

89 Osa 2: prosessien ja palvelujen määrittely ja suunnittelu Ajanvarauspalvelu Tarkoituksen lyhyt kuvaus: mitä toimintoja ja tietoja kattaa Integrointitapa Yleiskäyttöisyys Mihin käyttötapauksiin liittyy Toiminnot: kysele vapaat ajat, kysele varatut ajat, varaa aika, siirrä ajanvaraus, peru ajanvaraus Tiedot: HeTu, vapaat ajat, varatut ajat Tietopalvelu. Yleispalvelu. KT 10 Hoitosuunnitelman kirjaaminen KT 11 Hoitomääräyksen teko KT 12 Tutkimusmääräyksen teko KT 13 Lääkityksen määrääminen KT 14 Kuittaus työtehtävän valmistumisesta KT 15 Kirjautuminen ajanvarausjärjestelmään KT 16 Vapaiden aikojen haku KT 17 Varattujen aikojen haku KT 18 Ajan varaaminen Mihin sovelluksiin tai tuotteisiin liittyy Potilashallintojärjestelmä, potilaskertomusjärjestelmä, osastojen ja poliklinikoiden järjestelmät Mihin määrityksiin liittyy Open CDA 2006 Yhteydet ja riippuvuudet Potilaskertomuspalvelu: ajanvarauksista tiedot potilaskertomukseen. muihin palveluihin Arvio saatavuudesta, SerAPI:n HL7v3 ajanvaraus rajapinnat. toteutettavuudesta, mukauttamistarpeista Muut kommentit Postituspalvelu Tarkoituksen lyhyt kuvaus: mitä toimintoja ja tietoja kattaa Integrointitapa Yleiskäyttöisyys Mihin käyttötapauksiin liittyy Mihin sovelluksiin tai tuotteisiin liittyy Mihin määrityksiin liittyy Yhteydet ja riippuvuudet muihin palveluihin Arvio saatavuudesta, toteutettavuudesta, mukauttamistarpeista Muut kommentit Toiminnot: valitse kutsupohja, liitä aika kutsuun, tulosta kutsu ja ohjeet, tulosta osoitetarra. Tiedot: asiakkaan osoitetiedot, varatut ajat, potilasohjeet. Prosessipalvelu. Erikoispalvelu. KT 15 Kirjautuminen ajanvarausjärjestelmään KT 16 Vapaiden aikojen haku KT17 Varattujen aikojen haku KT 18 Ajan varaaminen KT19 Kutsupohjan haku KT20 Kutsun teko Potilaskertomusjärjestelmä Ajanvarauspalvelu: määrätyt tutkimukset ja niiden ajankohdat. Potilasohjepalvelu: kutsuun liitettävät potilasohjeet. Potilastietopalvelu: asiakkaiden osoite- ja muut tarvittavat tiedot. 89

90 Palveluarkkitehtuurin soveltaminen terveydenhuollossa Lääketilauspalvelu Tarkoituksen lyhyt kuvaus: mitä toimintoja ja tietoja kattaa Integrointitapa Yleiskäyttöisyys Mihin käyttötapauksiin liittyy Mihin sovelluksiin tai tuotteisiin liittyy Mihin määrityksiin liittyy Yhteydet ja riippuvuudet muihin palveluihin Arvio saatavuudesta, toteutettavuudesta, mukauttamistarpeista Muut kommentit Kuvantamispalvelu Tarkoituksen lyhyt kuvaus: mitä toimintoja ja tietoja kattaa Integrointitapa Yleiskäyttöisyys Mihin käyttötapauksiin liittyy Mihin sovelluksiin tai tuotteisiin liittyy Mihin määrityksiin liittyy Yhteydet ja riippuvuudet muihin palveluihin Arvio saatavuudesta, toteutettavuudesta, mukauttamistarpeista Muut kommentit Toiminnot: hae lääke lääketietokannasta, tallenna tilaus, hyväksy tilaus, välitä tilaus apteekkiin Tiedot: lääkkeen nimi, vahvuus ja antotapa, tilaava yksikkö, toimitusaika Prosessi- tai tietopalvelu. Erikoispalvelu. KT21 Kirjautuminen potilastietojärjestelmään KT22 Asiakkaan riskitietojen haku KT23 Kirjautuminen lääketietojärjestelmään KT24 Lääkkeen haku KT25 Lääkkeen tilaus Lääketilausjärjestelmä, potilaskertomusjärjestelmä, apteekin tietojärjestelmät, (lääketietokannat) Potilastietopalvelu: asiakastiedot, asiakkaan riskitiedot. Toiminnot: Hae henkilö, hae tutkimus, valitse tutkimus, tallenna tutkimuspyyntö, välitä tutkimuspyyntö Tiedot: HeTu, tutkimus, tilaava yksikkö, tilaava lääkäri, kuvauspäivä (päivystys/ajanvaraus) Tietopalvelu. Erikoispalvelu. Kuvantamisjärjestelmät Lausuntopalvelu: kuvia siirretään lausuntoon. Röntgenjärjestelmät 90

91 Osa 2: prosessien ja palvelujen määrittely ja suunnittelu Lausuntopalvelu Tarkoituksen lyhyt kuvaus: mitä toimintoja ja tietoja kattaa Integrointitapa Yleiskäyttöisyys Mihin käyttötapauksiin liittyy Mihin sovelluksiin tai tuotteisiin liittyy Mihin määrityksiin liittyy Yhteydet ja riippuvuudet muihin palveluihin Arvio saatavuudesta, toteutettavuudesta, mukauttamistarpeista Muut kommentit Patologian tutkimuspalvelu Tarkoituksen lyhyt kuvaus: mitä toimintoja ja tietoja kattaa Integrointitapa Yleiskäyttöisyys Mihin käyttötapauksiin liittyy Mihin sovelluksiin tai tuotteisiin liittyy Mihin määrityksiin liittyy Yhteydet ja riippuvuudet muihin palveluihin Arvio saatavuudesta, toteutettavuudesta, mukauttamistarpeista Muut kommentit Toiminnot: hae henkilö, tee lausunto, tallenna lausunto Tiedot: HeTu, tutkimustiedot ja tulokset Prosessipalvelu. Yleispalvelu. Potilaskertomusjärjestelmä, esimerkkiprosessissa patologian ja laboratorion järjestelmät Patologian tutkimuspalvelu: merkintä lausunnossa patologian tutkimuksesta aiheuttaa patologian pyynnön patologian tutkimuspalveluun. Endoskopiaan liitetty järjestelmä Toiminnot: hae asiakas, hae tutkimus, valitse tutkimus, tee pyyntö, tallenna pyyntö, välitä pyyntö Tiedot: HeTu, tutkimus, tilaava yksikkö, tilaava lääkäri, Prosessipalvelu. Erikoispalvelu. Patologian järjestelmät Lausuntopalvelu: käytetään lausunnon kirjoittamiseen. 91

92 Palveluarkkitehtuurin soveltaminen terveydenhuollossa Potilaskertomuspalvelu Tarkoituksen lyhyt kuvaus: mitä toimintoja ja tietoja kattaa Integrointitapa Yleiskäyttöisyys Mihin käyttötapauksiin liittyy Toiminnot: hae asiakkaan potilaskertomus, täydennä kertomusta tallenna kertomus Tiedot: HeTu, asiakkaan kertomustiedot Tietopalvelu. Ydinpalvelu. KT1 Kirjautuminen lähetejärjestelmään KT3 Lähetteen avaaminen KT4 Lähetteen kirjaaminen vastaanotetuksi KT 6 Työtehtävän haku työjonosta KT 7 Kirjautuminen potilaskertomusjärjestelmään KT 8 Potilaskertomuksen haku KT 9 Kiireellisyyden arviointi KT 10 Hoitosuunnitelman kirjaaminen KT 11 Hoitomääräyksen teko KT 12 Tutkimusmääräyksen teko KT 13 Lääkityksen määrääminen KT 14 Kuittaus työtehtävän valmistumisesta KT 15 Kirjautuminen ajanvarausjärjestelmään KT 16 Vapaiden aikojen haku KT17 Varattujen aikojen haku KT 18 Ajan varaaminen Mihin sovelluksiin tai tuotteisiin liittyy Potilaskertomusjärjestelmä Mihin määrityksiin liittyy Open CDA 2007 Yhteydet ja riippuvuudet muihin palveluihin Arvio saatavuudesta, toteutettavuudesta, mukauttamistarpeista Muut kommentit Lähetepalvelu: hoitojakson avaus lähetteen saapumisesta. Ajanvarauspalvelu: ajanvarauksista tiedot potilaskertomukseen. Kaikki hoidolliset palvelut, joiden tulee tuottaa tietoa potilaskertomukseen. Potilaskertomusjärjestelmä Potilaskertomustiedot (sekä kuvat että tekstit) pystyttävä siirtämään tulevaisuudessa kansalliseen kertomusarkistoon. 92

93 Osa 2: prosessien ja palvelujen määrittely ja suunnittelu Potilasohjepalvelu Tarkoituksen lyhyt kuvaus: mitä toimintoja ja tietoja kattaa Integrointitapa Yleiskäyttöisyys Mihin käyttötapauksiin liittyy Mihin sovelluksiin tai tuotteisiin liittyy Mihin määrityksiin liittyy Yhteydet ja riippuvuudet muihin palveluihin Arvio saatavuudesta, toteutettavuudesta, mukauttamistarpeista Muut kommentit Toiminnot: hae tutkimuksen ohje, liitä ohje ajanvarauskirjeeseen, tulosta kirje Tiedot: tutkimus, tutkimukseen valmistautumisohjeet Tietopalvelu. Ydinpalvelu. KT19 Kutsupohjan haku KT20 Kutsun teko Potilashallintojärjestelmä, potilasohjejärjestelmä, ohjepankit Postituspalvelu: potilasohjeet lisätään asiakkaalle postitettavaan kutsuun. Potilasohjejärjestelmä, ohjepankit Lähetteen tietomäärittely Seuraavassa on esitetty lähetteessä tarvittavat tiedot. Lähetetiedot on otettu tähän esimerkiksi prosessin ja palvelujen tyypillisestä tietokokonaisuudesta, ja muita vastaavan tarkkuustason tietomäärittelyjä ei esitetä endoskopian esimerkkiin liittyen. Sisältö liittyy edellä tunnistetuista palveluista luonnollisesti varsinkin lähetepalveluun, mutta myös esimerkiksi ajanvarauspalvelun ja sen taustajärjestelmien välillä on tunnistettu tarve lähetetietojen käyttämiselle (Tuomainen ym. 2005). Lähetteen rakenne noudattaa yleistä CDA-sairauskertomusrakennetta (Tarhonen ym. 2007). Lähete sisältää seuraavia tietoja: Lähetteen tekniset ja osapuolitiedot o Sanoman tyyppi ja alityyppi o Alkuperäisen lähetteen tunnus, antopäivämäärä, lähettävä lääkäri ja laitos o Lähetteen tunnus, käsittelypäivämäärä, lähettävä lääkäri ja laitos o Vastaanottajan lähetteen tunnus, käsittelypäivämäärä, laitos, vastaanottava ja käsitellyt lääkäri o Palvelutapahtuman tai palvelukokonaisuuden tunnukset, luontiaika, omistava laitos ja vastuulääkäri o Lähetteen tallennusaika ja tallentaja o Alkuperäisen lähettävän järjestelmän tunnus ja lähetysaika o Lähettävän järjestelmän tunnus ja lähetysaika o Vastaanottoaika ja järjestelmätunnus o Kenelle saa lähettää hoitopalautteen Hoidon priorisointi o Lähettäjän kiireellisyysluokitus o Vastaanottajan kiireellisyysluokitus o Tavoitehoitoaika o Erityistason sairaanhoito ja tasoryhmät 93

94 Palveluarkkitehtuurin soveltaminen terveydenhuollossa Esitiedot o Diagnoosit o Toimenpiteet ja leikkaukset o Tutkimukset ja tulokset o Tulosyydiagnoosi o Nykyinen sairaus o Annettu hoito o Lääkkeet ja sairauslomat o Lähettämisen syy o Lääkinnällinen kuntoutus ja apuvälineet o Asiakkaan näkemys omasta tilastaan Lähetteen tyyppi ja yleisteksti Lähetteen palauttamisen syy Informointi o Ajanvarauksesta ilmoittaminen o Sairaalassaolosta ilmoittaminen o Lähetetäänkö vastaanotosta kuittaus o Onko potilaalla turvakielto o Saako lähettäjälle lähettää hoitopalautetta o Saako vastaanottavan laitoksen potilaan tietoja selata ATK-järjestelmän kautta o Onko tarpeen vaatiessa konsultoijalla lupa kutsua potilas hoitoon Asiakirjat Etuudet ja eläkejärjestelyt Lähetteen muut tiedot o Onko kyseessä työtapaturma o Lähettävä lääkäri tarvitsee loppulausunnon o Voiko lähettäjä huolehtia jatkohoidosta o Onko vastaanottavalla lääkärillä EML-oikeus o Ulkokuntalaisen hoitoon oton syy o Ulkokuntalaisen hoitoon oton hyväksymistapa Aikaisempi hoito o Onko hoidettu aiemmin o Hoitojaksot Maksutiedot Kuljetuksen järjestäminen Potilaan toivomat jatkohoitopaikat ja ajat Lisäksi liitteenä tulee olla seuraavat tiedot: Allekirjoitus Henkilötietolomake Lääkityslista Suostumuslomake 94

95 Osa 2: prosessien ja palvelujen määrittely ja suunnittelu Käytössä olevat tietojärjestelmät Tässä luvussa on kuvauksia ja esimerkkejä olemassa olevista tietojärjestelmistä, joista palveluja ja rajapintoja voitaisiin käyttää ja hyödyntää. Esimerkeissä on lueteltu lähinnä Satakunnan ja KYS:n pohjamateriaaleissa sekä keskusteluissa esiin nousseita järjestelmiä. Järjestelmät on ryhmitelty luvun palvelukuvaustaulukoissa käytetyillä yleisnimillä taulukkoon 9. Luvussa 3.4 on lueteltu tässä kuvattujen seikkojen lisäksi järjestelmistä selvitettäviä seikkoja, kuten valmiit liitännät ja rajapinnat, elinkaari ja muutettavuusmahdollisuudet. Taulukko 9. Esimerkkejä olemassa olevista tietojärjestelmistä Järjestelmä Kuvaus Esimerkkejä potilashallintojärjestelmä Sisältää lähetteet, ajanvarauksen, MD-Oberon, MUSTI (UPO, hoidonvarauksen, jonojenhallinnan UJO), AHO-potilashallinto, Effica, Pegasos potilaskertomusjärjestelmä Potilasasiakirjojen lainaustoiminnot MD-MIRANDA, YKERT, osastojen ja poliklinikoiden käyttöön WebKert, Effica, Pegasos laboratoriotietojärjestelmä Laboratoriopyyntöjen tekoon ja MULTILAB II, Effica, vastausten katseluun sekä laboratorion Pegasos sisäisiin toimintoihin kuten pyyntöjen kuittaamiset, työjonojen tekemiset. lääketilausjärjestelmä Osastojen kulutustavara- ja lääketilausjärjestelmä ORDER apteekin tietojärjestelmä Järjestelmä, jolla ylläpidetään lääkerekisteriä MARELA ja sinne päivitetään talon oma lääkevalikoima röntgen- ja radiologiajär- PACS arkistojärjestelmä, C-RIS PACS, C -RIS, RADU, Effica, jestelmät muut kuvantamisjärjestelmät tuotannon ohjausjärjestelmä Digitaalisen lääketieteellisen kuvainformaation tuottamiseen, käsittelyyn ja arkistointiin suunniteltu ohjelmisto. patologian järjestelmät Patologian laboratoriotietojärjestelmä, johon tallennetaan kliinisen patologian tutkimusten tiedot. potilasohjejärjestelmä, ohjepankit Järjestelmästä saadaan poimittua yksilölliset ohjeet asiakkaalle Pegasos MediMaker, ENDOBASE (kuvantaminen ja lausunto) QPATI Physiotools, paikalliset ohjesivustot Näiden tietojärjestelmien lisäksi ja välillä lähete-, epikriisi- ja ajanvaraustietoja välitetään myös OVT/EDI-rajapintojen avulla. Lisäksi SerAPI-hankkeen osapuolten ympäristöissä kuvattuihin prosesseihin liittyy myös hoitoilmoitusjärjestelmä HILMO, käyttöoikeuksien hallintajärjestelmä MD- UMBRIEL sekä aluetietojärjestelmiä (FIALE, Navitas). Myös näillä järjestelmillä on liittymiä kuvattuihin prosesseihin. Sekä endoskopian että äitiyshuollon osalta yhteenvetoa ja kokemuksia tehdystä mallinnuksesta ja prosessien kuvaamisesta on koottu lukuun

96 Palveluarkkitehtuurin soveltaminen terveydenhuollossa 4.3 Äitiyshuollon mallinnusesimerkki Tässä luvussa käsitellään äitiyshuollon palvelukokonaisuutta, joka on toinen SerAPI-hankkeen Prosessit ja palvelut -kohteen esimerkkiprosesseista. Äitiyshuolto on endoskopiaa laajempi kokonaisuus. Toiseksi mallinnusesimerkiksi valittiin tarkoituksella laaja kokonaisuus, jotta kuvaustapoja ja menetelmiä voitaisiin kokeilla erityyppisissä tilanteissa. Myös äitiyshuollon osalta kuvausesimerkkien tuottamisessa on nojauduttu ensisijaisesti valmiiseen materiaaliin. Monet käytetyistä kuvauksista ovat SerAPI-hankkeen Prosessit ja palvelut -työpajoissa käytettyjä. Tämän lisäksi äitiyshuollon esimerkkien tuottamisessa on hyödynnetty luonnosta dokumentista "Äitiyshuollon sähköisen potilaskertomuksen rakenteiset tiedot (Äitiyshuollon sähköisen potilaskertomuksen rakenteiset tiedot - hanke), jonka keskeneräisyyden vuoksi siitä ei ole poimittu tietoja tähän dokumenttiin. Äitiyshuollon koko palvelukokonaisuuden yleiskuva kuvataan yleisellä tasolla luvussa Erikoissairaanhoidon osuutta kuvataan tarkemmin äitiyspoliklinikan osalta luvussa ja synnytystoiminnan osalta luvussa Äitiyspoliklinikan ja synnytys-hoitokokonaisuuden toiminnasta on tuotettu esimerkkikuvauksia eri kuvaustapoja käyttäen toimintotasolle asti. Synnytyshoitokokonaisuudesta on lisäksi mukana esimerkki tekojen ja välineiden tasolla tapahtuvasta tarkemmasta kuvauksesta. Kuvauksissa ei ole tunnistettu tarvittavia sovelluspalveluja ja tietojärjestelmiä, vaan ne keskittyvät prosessien ja toiminnan kuvaamiseen tuettavan toiminnan näkökulmasta ja ylemmillä kuvaustasoilla Äitiyshuollon yleiskuva Äitiyshuollon palvelukokonaisuuden yleiskuvan tavoitteena on muodostaa kokonaiskuva äitiyshuollon toimintaympäristöstä ja sen tyypillisistä prosesseista. Eri yksiköt ja niiden perustoiminnot äitiyshuoltoon liittyen sekä sanalliset kuvaukset eri yksiköiden toiminnasta muodostavat pohjaa, jonka avulla voidaan tunnistaa kehitettävien ratkaisujen toimintaympäristö ja tunnistaa lukuisia prosesseja, tietojoukkoja, samoin kuin valmiita toimintatapoja ja järjestelmiä äitiyshuoltoon liittyen. Useimmat kuvaukset koskevat sekä nyky- että tavoitetilaa. Luku sisältää kuvauksia äitiyshuollon palveluihin liittyvistä organisaatioista ja niiden toimintokokonaisuuksista. Luvussa kuvataan äitiysneuvolan osalta perusterveydenhuollossa tehtäviä käyntejä ja tutkimuksia. Luvussa on erikoissairaanhoidon osalta kuvaus raskauden aikaisista mahdollisista toimenpiteistä ja prosessikarttaan kuvattuna äitiyshuoltoon liittyvät ydin- ja tukiprosessit. Erikoissairaanhoidon osalta äitiyspoliklinikkatoimintaa kuvataan tarkemmin luvussa ja synnytystoimintaa luvussa Luku sisältää toimintatarinan, joka kuvaa etenkin asiakkaan ja perheen näkökulmasta tyypillisen ketjun raskauden alusta synnytyksen jälkeiseen aikaan Äitiyshuollon palvelukokonaisuus Äitiyshuollon palvelukokonaisuus koostuu perusterveydenhuollon ja erikoissairaanhoidon hoitokokonaisuuksista sekä sosiaalihuollon palvelu- ja hoitokokonaisuuksista. Kuvassa 26 näkyvät perusterveydenhuollon ja erikoissairaanhoidon tärkeimmät yksiköt ja toimintakokonaisuudet äitiyshuoltoon liittyen sekä äidin tai perheen liikkuminen näiden palvelujen välillä yleisesti. 96

97 Osa 2: prosessien ja palvelujen määrittely ja suunnittelu Kuva 26. Äitiyshuollon palvelukokonaisuuden yleiskuva. Kokonaiskuvan hahmottamisessa myös esimerkkityyppinen kuvaus, jossa kuvataan asiakkaan tavoitteita tai tilanteita ja yhdistetään niitä palvelutarjoajien palveluihin, on hyödyllinen (ks. kuva 27). Kuva havainnollistaa selkeästi useita yhtäaikaisia prosesseja, jotka liittyvät yhdenkin tilanteen tai asiakkaan tarpeen hoitamiseen sosiaali- ja terveydenhuollossa. Molemmat kuvaustavat ovat yleiskuva-tason kuvauksia. Molemmista niistä on kuitenkin myös mahdollista tunnistaa ja valita tarkemmin mallinnettavia toimintakokonaisuuksia, prosesseja tai toimintoja, jotka voidaan näiden ylemmän tason kuvausten kautta jäljittää palvelukokonaisuuksiin. Seuraavassa aliluvussa kuvataan perusterveydenhuollon osalta tarkemmin äitiyshuollon käynnit. Erikoissairaanhoidon osalta tunnistetaan luvussa yleisellä tasolla hoitoprosessit sekä niiden tarvitsemat tukiprosessit (hoidolliset ja yleiset tukipalvelut) ja prosesseihin osallistuvat yksiköt. Lukujen ja tarkemmat kuvaukset äitiyspoliklinikka- ja synnytystoiminnasta ovat myös esimerkkejä tarkennetuista kuvauksista. 97

98 Palveluarkkitehtuurin soveltaminen terveydenhuollossa KANSALAISEN KOKONAISUUDET (case raskaus) = PALVELUTAPAHTUMA POTILAS ONGELMA TAI ELÄMÄN- TILANNE Nainen, jolla on jo pari lasta, toteaa olevansa raskaana. Puoliso on matkatöissä ja käy kotona vain viikonloppuisin. UUSI TERVEYS- TAI SAIRAUS- ONGELMA Soittaa terveyskeskukseen ja pyyntää yhdistää oman postipiirinsä neuvolaan 3. raskaus SAMAN YLEISTILAN- TEEN UUSI TERVEYS- TAI SAIRAUS- ONGELMA Virtsa kirvelee SAMAN YLEISTILAN- TEEN UUSI TERVEYS- TAI SAIRAUS- ONGELMA Tilaa ambulanssin ja viedään synnytyspäivystykseen Mahakipua ja kuumetta SAMAN YLEISTILAN- TEEN UUSI TERVEYS- TAI Synnytys SAIRAUS- ONGELMA PALVELUKOKONAISUUS 3.RASKAUS ESH TERVEYS-KESKUS YHTEYDENOTTO Saa puhelinajan neuvolaan Puhelimessa antaa esitietoja ja sovitaan 1. käynti 8-10 vk Tehdään lab lähete ja uä lähete ja sovitaan lääkäriaika Uä:n ja lääkärin tutkimuksen perusteella tehdään lähete äitiyspkl:lle lisätutkimuksiin vk vk LÄHETE Luetaan lähete ja tehdään suunnitelma: kiireellinen aika pkl:lle, jossa yhteydessä tehdään uä. Suunnitelma: neuvolakontrollit, mutta vielä toinen tarkastus äitiyspkl:lla. Kotona ollessa iskee virtasatulehdus ja hakeutuu tk:hon ja saa lääkityksen joka ei tehoa heti, vaan vaatii 2 kontorllinäytettä ja yhden puhelun lääkärille HOITOKOKONAISUUS alkuraskauden ongelmaepäily vk HOITOKOKONAISUUS VTI ILMOITUS HOIDON PÄÄTTYMISESTÄ ESITIEDOT HOITOKOKONAISUUS 3. raskaus Esitietojen vastaanotto voi olla pelkkä tekninen prosessitapahtuma, mutta jos ne luetaan, kyse on palvelutapahtumasta (hoidon tarpeen arvio) aiheuttavat pal vk vk äitiysvalmennus EI LÄHETETTÄ hoitojakso ILMOITUS HOIDON PÄÄTTYMISESTÄ HOITO- KOKONAISUUS keskenmeno epäily hoitojakso HOITO-KOKONAISUUS umpilisäkkeen tulehdus Tikkien poisto ja Hb tarkastus Otetaan synnytysvastaanoton kautta osastolle seurantaan. Kaikki hyvin raskauden suhteen, mutta onkin umplisäkkeen tulehdus, jonka takia leikataan kirurgian puolella. Synnytys äitiyspkl - synnytyssali-osasto ILMOITUS HOIDON PÄÄTTYMISESTÄ Hoitajan ja lääkärin jälkikontrollit HOITOKOKONAISUUS SYNNYTYS SOSIAALI- ALA Neuvola teki ilmoituksen äidin pynnöstä sosiaalitoimeen, että tarvetta lastenhoidon tukeen on odotettavissa Hoivapalveluita, kun puoliso on työmatkalla Hoivapalvelulita, kun puoliso on matkalla ja isovanhemmat muualla käymässä V Kuva 27. Esimerkki asiakkaan tilanteen ja palvelujen kuvaamisesta palvelukokonaisuuksina ja tapahtumina (Pirkko Kortekangas 2007, käytetty tekijän luvalla) Perusterveydenhuolto - äitiysneuvola Tässä luvussa kuvataan äitiysneuvolakäynnit perusterveydenhuollon osalta. Normaalitilanteessa on terveydenhoitajan ja lääkärin tarkastuksia sekä ennen synnytystä että sen jälkeen (ks. taulukko 10). Eri käynneillä suoritetaan vaihtelevasti tutkimuksia ja mittauksia raskauden seuraamiseksi ja mahdollisten ongelmien havaitsemiseksi (ks. taulukko 11). Ennen synnytystä äitiysneuvolakäynneillä annetaan terveysneuvontaa ja keskustellaan erilaisista raskauteen ja synnytykseen liittyvistä asioista. Synnytyksen jälkeen keskustellaan terveysneuvonnan lisäksi vanhemmuuteen, vauvan hoitoon ja ehkäisyyn liittyvistä asioista. (Tekay 2007) Raskauden seurantaan liittyy myös seulontatutkimuksia, joita ovat varhaisraskauden yleinen ultraäänitutkimus raskausviikolla 10 14, kromosomipoikkeavuuksien selvittäminen ensisijaisesti varhaisraskauden yhdistelmäseulonnan avulla (veriseula raskausviikolla 8 11 ja niskaturvotuksen mittaus yleisen ultraäänitutkimuksen yhteydessä raskausviikolla 10 12) tai vaihtoehtoisesti kolmoisveriseulonta raskausviikolla ja ultraäänitutkimus vaikeiden rakennepoikkeavuuksien selvittämiseksi raskausviikolla tai raskausviikon 24 jälkeen. Näistä varhaisraskauden ja raskausviikkojen ultraäänitutkimuksia suositellaan tehtäväksi kaikille äideille, joten kuntien tulisi järjestää nämä tutkimukset, muut seulontatutkimukset vapaaehtoisia. (VN 2006) 98

99 Osa 2: prosessien ja palvelujen määrittely ja suunnittelu Taulukko 10. Äitiysneuvolakäynnit (Tekay 2007) No: Ajankohta Kohderyhmät Vastaanotto rvk kaikki synnyttäjät terveydenhoitaja / kätilö rvk kaikki synnyttäjät lääkäri rvk kaikki synnyttäjät terveydenhoitaja / kätilö rvk kaikki synnyttäjät terveydenhoitaja / kätilö rvk kaikki synnyttäjät terveydenhoitaja / kätilö 6 28 rvk kaikki synnyttäjät lääkäri 7 30 rvk ensisynnyttäjä terveydenhoitaja / kätilö 8 32 rvk kaikki synnyttäjät terveydenhoitaja / kätilö 9 34 rvk ensisynnyttäjä terveydenhoitaja / kätilö rvk kaikki synnyttäjät terveydenhoitaja / kätilö rvk ensisynnyttäjä terveydenhoitaja / kätilö ja lääkäri rvk kaikki synnyttäjät terveydenhoitaja / kätilö rvk ensisynnyttäjä terveydenhoitaja / kätilö rvk kaikki synnyttäjät terveydenhoitaja / kätilö rvk kaikki synnyttäjät terveydenhoitaja / kätilö 16 Heti synn. jälk. kaikki synnyttäjät terveydenhoitaja / kätilö (kotikäynti) kk synn. jälk. kaikki synnyttäjät terveydenhoitaja / kätilö ja lääkäri (jälkitarkastus) Äitiysneuvolassa tunnistetuista poikkeuksista käynnistyy erikoissairaanhoidon prosesseja (raskaudenaikaisten ongelmien seuranta). Tällaisia raskauksia kutsutaan riskiraskauksiksi. Riskiraskauden syitä voivat olla esimerkiksi äidin korkea ikä, äidin perussairaus kuten insuliinihoitoinen diabetes, epilepsia tai astma, monisikiöinen raskaus, sikiön poikkeava koko tai lasketun ajan ylitys. Hänellä voi olla raskauteen liittyviä ongelmia esimerkiksi kohonnut verenpaine, raskausmyrkytys, ennenaikaisia supistuksia, lapsiveden meno tai sokeritasapainon häiriö. Riskiraskauksia ovat myös päihdeongelmaisten tai tarttuvaa tautia sairastavien äitien raskaudet ja ne kuuluvat erikoissairaanhoidon seurantaan. Myös synnytyspelkoa hoidetaan erikoissairaanhoidossa äitiyspoliklinikalla (KYS 2007). 99

100 Palveluarkkitehtuurin soveltaminen terveydenhuollossa Taulukko 11. Äitiysneuvolakäynneillä tehtävät tutkimukset (Tekay 2007) Käynti nro Tutkimus Verenpaine x x x x x x x x x x x x x x Paino x x x x x x x x x x x x x x Hb (hemoglobiini) x x x x Veriryhmä x Vasta-aineseula verestä x Kardiolipiini x HBsAg (hepatiitti) x HIV x U-gluk (virtsan glukoosi) x x x x x x x x x x x x x x x U-prot (virtsan proteiini) x x x x x x x x x x x x x x x U-bakt x x Gynekologinen tutkimus x x Sydänäänten kuuntelu x x x x x x x x Lasketun ajan tarkistus x Sikiön liikkeet x Kohdunpohjan mittaus x x x x x x x x x x Veriryhmävastaaineseulonta Rh- äideiltä x x Kohdunsuun tutkiminen x x x Sikiön tarjonta x x x x x x x Synnytystapa x x Liikelaskennan aloittaminen x Lapsiveden määrän arviointi x Lähete synnytyssairaalaan yliaikaisuuden vuoksi viimeistään x 42+0 rvk:lla Kliininen tutkimus (rinnat, kohtu, mahd. välilihanleikkaus- tai leikkaushaava, ompeleet x jne.) Erikoissairaanhoito Tässä luvussa kuvataan erikoissairaanhoidon osalta yleiskuva prosesseista ja hoitokokonaisuuksista, jotka liittyvät äitiyshuoltoon (ks. kuva 28). Tarkempia kuvauksia valituista toimintokokonaisuuksista on myöhemmissä luvuissa. Äitiysneuvolassa tunnistetuista poikkeuksista (esim. äidillä kohonnut verensokeri) käynnistyy neuvolassa tunnistettujen raskaudenaikaisten ongelmien seuranta- tai hoitoprosesseja. Äidin tullessa ensiapuun tai päivystykseen raskauteen liittyvän ongelman vuoksi (esim. keskenmenoepäily) käynnistyy päivystysluonteisten raskaudenaikaisten ongelmien hoito -prosessi. 100

101 Osa 2: prosessien ja palvelujen määrittely ja suunnittelu Tilanteita joissa raskaus ei suju normaalisti voi olla jo ennen raskautta tai sen aikana. Esimerkkejä: Jo raskauden suunnitteluvaiheessa (tai heti kun suunnittelematon raskaus on todettu) erikoissairaanhoitoa tarvitaan esimerkiksi, kun äidillä on jokin lääkehoitoa ja seurantaa vaativa perussairaus kuten insuliinihoitoinen diabetes, verenpainetauti tai jos äidiltä on vasta hoidettu jokin pahanlaatuinen sairaus tai sikiöllä on epämuodostuman tai perinnöllisen sairauden riski. Alkuraskauden aikana seurantaa tarvitaan esimerkiksi, jos äidillä on jatkuvaa lääkehoitoa vaativa sairaus kuten astma tai krooninen suolistosairaus, monisikiöinen raskaus tai aikaisempi komplisoitunut raskaus tai perheessä on päihdeongelmia. Neuvolaseurannan perusteella äiti lähetetään erikoissairaanhoitoon mm., jos kohtu kasvaa poikkeavasti tai äidillä todetaan poikkeava glukoosin sietokyky tai seulontatulos on poikkeava sikiötutkimuksissa tai todetaan jokin muu raskauden kulkuun tai synnytykseen vaikuttava riskitekijä. Lisäksi päivystyslähetteen aiheita synnytysvastaanotolle ja äitiyspoliklinikalle ovat esimerkiksi epäily sikiön voinnin huononemisesta, säännölliset ennenaikaiset supistukset ennen 35. raskausviikkoa ja raskauden aikainen infektio, jota ei hoideta avohoidossa.(kys 2005) ERIKOISSAIRAANHOIDON HOITO-ORGANISAATIO Äitiyspoliklinikka Potilastoimisto Leikkaussali Synnyttämättömien vuodeosasto Heräämö Synnytysvastaanotto Synnytyssali Tehoosasto Laboratorio Ensiapu Vastasyntyneiden teho-osasto Lapsivuodeosasto (synnyttäneiden vuodeosasto) Apteekki Hoito-/tutkimus-/toimenpideyksikkö Synnytys Seulonnat Neuvolassa tunnistettujen raskaudenaikaisten ongelmien seuranta / hoito Päivystysluonteisten raskaudenaikaisten ongelmien hoito Laboratoriopalvelut Kuvantamispalvelut Ravitsemuspalvelut Lääkintäpalvelut Konsultaatio Kuva 28. Prosessikartta äitiyshuolto-palvelukokonaisuudesta erikoissairaanhoidon osalta Toimintatarina Tässä luvussa kuvataan äitiyshuollon toimintatarina, joka ei sisällä perusraskaudenkulusta poikkeavia tilanteita. Toimintatarina kattaa koko äitiyshuollon palvelukokonaisuuden. Lähteinä toimintatarinassa on käytetty Kuopion kaupungin äitiysneuvolan tarkastusohjelmaa (Kuopio 2005), Helistimen kotisivua (Päkkilä 2005) ja Äitiyshuollon sähköisen potilaskertomuksen rakenteiset tiedot - oppaan luonnosta. Synnytysosuus on kirjoitettu Pohjois-Karjalan sairaanhoito- ja sosiaalipalvelujen kuntayhtymän "Synnytys tutuksi" -sivuilla (PKSHP 2007b) sekä Kuopion yliopistollisen sairaalan "Tutuks-palvelu, virtuaalinen tutustumiskäynti synnytyssairaalaan" -sivuilla (KYS 2007) olevien tietojen pohjalta. 101

102 Palveluarkkitehtuurin soveltaminen terveydenhuollossa Toimintatarinan tavoitteena on kuvata suhteellisen tarkasti yksi tyypillinen raskausprosessin eteneminen. Yleiskuva-tasolla se auttaa hahmottamaan äitiyshuollon palvelukokonaisuutta, mutta siitä on tunnistettavissa myös monia palvelutuotannon prosesseja, toimintoja ja yksittäisiä toimenpiteitä, joita (ja joiden välisiä rajapintoja) on pystyttävä tukemaan määriteltävissä ratkaisuissa. Samoin tietojen osalta voidaan tunnistaa tärkeitä tietokokonaisuuksia sekä yksittäisiä tietoja, joita prosessien etenemiseen liittyy. Tietojärjestelmäratkaisujen kehittämisessä näistä yksityiskohdista valitaan kuhunkin prosessin vaiheeseen ja niissä käytettyihin tietojärjestelmiin ja palveluihin liittyvät. Raskausaika Anna 23 v. huomaa kuukautistensa olevan viikon myöhässä ja tekee raskaustestin, jonka tulos on positiivinen. Hän kertoo puolisolleen Onnille odottavansa lasta. Hän sopii ensimmäisen tapaamisen Jynkän äitiysneuvolan vastaanotolle muutaman viikon päähän, jolloin raskaus on kestänyt arviolta 10 viikkoa. Ensimmäisellä neuvolakäynnillä terveydenhoitaja kyselee Annalta raskauteen liittyviä tietoja kuten henkilötiedot, viimeiset kuukautiset ja kuukautiskierron pituus, ehkäisyn käyttö, paino ennen raskautta, sairaudet, lääkitys, allergiat, elintavat, perhe, ammatti tai työ. Hän tutkii Annan mittaamalla painon, verenpaineen, hemoglobiinin, virtsan valkuaisen ja sokerin, kyselee voinnista yleensä ja kuuntelee sikiön sydänäänet doppler-laitteella. Terveydenhoitaja antaa lähetteet terveyskeskuksen laboratorioon alkuraskauden laboratorionäytteisiin, joilla tutkitaan mm. veriryhmä ja Rh-tekijä, vasta-aineet, kardiolipiini, hepatiitti, HIV-vasta-aineet ja virtsan valkuainen, sokeri ja bakteerit. Hän antaa äitiyskortin ja informaatiota sekä lähetteen alkuraskauden ultraäänitutkimuksiin, jotka ovat vapaaehtoisia, mutta tarjotaan kaikille. Anna varaa tutkimusajan 11 raskausviikolle, jolloin UÄ tutkimuksessa tarkistetaan mm. sikiöiden lukumäärä ja arvioitu laskettu aika. Tutkimukseen pääsee myös Onni isä mukaan. Anna käy alkuraskauden terveydenhoitajan tarkastuksissa neljän viikon välein, 30. raskausviikosta alkaen hän käy kahden viikon välein ja 36. raskausviikosta alkaen viikoittain. Neuvolakäynneillä seurataan Annan painoa tavallisella puntarimittauksella, hemoglobiini katsotaan kerran jokaisessa raskauskolmanneksessa ja sikiön sydänäänet kuunnellaan doppler-ultraäänilaitteella. Raskauden puolivälin (19 22 rvk) jälkeen sikiön kasvua seurataan välillisesti symfyysi-fundus -mitalla (kohdunpohjan korkeus häpyluusta). Lääkärin tarkastuksia on neuvolassa kolme, jotka ajoittuvat alku-, keski- ja loppuraskauteen. Lääkäri tekee sisätutkimuksen arvioidakseen kohdunkaulan pituuden ja kiinteyden sekä kohdun asennon. Sikiön sydänäänet kuunnellaan doppler-laitteella. Lääkäri keskustelee Annan voinnista ja mahdollisista muista sairauksista sekä niiden vaikutuksesta raskauteen ja lapseen. Kun raskaus on kestänyt n. 2/3 eli n. 6 kk, neuvolasta laitetaan esitietolomake äitiyspoliklinikalle Annan raskaudesta ja perheen tiedoista. Anna ja Onni osallistuvat neuvolan järjestämille synnytysvalmennuskursseille, joissa käydään synnytystä läpi ja opastetaan vastasyntyneen hoitoon. Synnytys Annan raskautta on kestänyt melkein pari päivää yli lasketun ajan ja vatsa tuntuu olevan kaikkialla tiellä. Liikkuminenkin hengästyttää helposti ja päiväkävelyllä täytyy ottaa välillä puunkyljestä tukea, kun kummasti kovistaa vatsassa. Anna miettii, jokohan pitäisi lähteä synnytyssalille. Yöllä Anna herää kesken unien märästä lammikosta ja oivaltaa hetken kuluttua lapsiveden menneen (synnytyksen avautumisvaihe on alkanut). Hän herättää Onnin ja sanoo, että heidän täytyy lähteä synnytyssairaalaan. Anna ottaa mukaan sairaalaan äitiyskortin, kameran, lukemista, musiikkia, tossut, aamutakin ja eväät Onnille. Vauvalle varatut varusteet Onni tuo sairaalaan myöhemmin, kun Anna ja vauva pääsevät kotiin. 102

103 Osa 2: prosessien ja palvelujen määrittely ja suunnittelu Synnytysvastaanoton toiminta Anna ja Onni saapuvat sairaalan synnytysvastaanotolle. Siellä kätilö hakee Annan ennakkotiedot, jotka on neuvolasta lähetetty äitiyspoliklinikalle ja tallennettu siellä tietojärjestelmään. (Ennakkotietoja ovat: sekä äidin että isän henkilötiedot, sairaudet sekä tupakan, alkoholin ja lääkkeiden tai huumeiden käyttö, äidin aikaisemmat raskaudet ja niiden kulku, tämän raskauden kulku sekä nimiehdotus lapselle.) Kätilö tarkistaa ennakkotiedot ja kysyy tulosyyn (vedenmeno/supistukset/vuoto/kipu/liikehälytys) sekä aloittaa synnytyskertomuksen. Tulovaiheessa tehdään samanlainen terveystarkastus kuin neuvolassa, eli katsotaan verenpaine ja lämpö sekä virtsan valkuaiset ja sokeri. Lisäksi kätilö ajaa KTG-käyrän (sikiön sydänäänikäyrän) sekä tekee ulkotutkimuksen ja sisätutkimuksen, jossa hän tutkii kohdunsuun tilanteen, eli arvioi synnytyksen vaiheen. Lisäksi kätilö kysyy Annalta mahdollisia toiveita synnytykseen liittyen. Sitten Anna saa käydä suihkussa, minkä jälkeen hänelle tehdään loput esivalmistelut synnytystä varten. Lopuksi Anna ja Onni opastetaan synnytyssalin käytäntöihin ja ohjataan synnytyssaliin. Synnytyssalin toiminta Kätilö seuraa Annan synnytyksen kulkua havaitakseen mahdolliset ongelmat, lapsen vointia (ajaa KTG-käyrää) juttelee vanhempien kanssa, hoitaa itsenäisesti synnytyksen siis avustaa Anna äitiä. I AV:n (ajan vaiheen) aikana seurataan Anna äidin kohdunsuun avautumista aina ponnistusvaiheeseen asti. Kätilö tekee sisätutkimuksia säännöllisin väliajoin (yleensä vähintään kahden tunnin välein tai tiheämmin, jos supistukset ovat napakoita). Tarkoitus on saada käsitys Annan synnytyksen etenemisestä. Tutkimustiedot kirjataan partogrammiin ja synnytyskertomukseen. Annan mielestä synnytys muuttuu kivuliaaksi. Kätilö arvioi kivun voimakkuutta yhdessä Annan kanssa äidin oman arvion mukaan. Aluksi kipua helpotetaan hoidollisilla kivunlievitysmenetelmillä rentoutumisella supistusten välillä, liikkumisella huoneessa ja asennon vaihdoilla, lämpötyynyllä sekä hieromalla kipualuetta ristiselästä. Kun Annasta tuntuu etteivät nämä keinot enää riitä, Anna hengittää ilokaasua. Anna hengittää itse lääkkeen ja hapen seosta maskin kautta supistuksen aikana. Myöhemmin Annalle laitetaan parakervikaalipuudutus (=kohdunkaulan puudutus), jonka laittaa gynekologi sisätutkimuksen yhteydessä. Ennen vauvan syntymää Anna vielä haluaisi tehokkaampaa kivunhoitoa, jolloin harkitaan epiduraalipuudutusta, jota käytetään useammin ensisynnyttäjillä. Annan ja Onnin vauva on kuitenkin jo tulossa maailmaan. Annalle tulee voimakas tarve ponnistaa lapsen painaessa peräsuolta supistuksen aikana. Anna äiti työntää omien tuntemuksiensa mukaan aina supistuksen aikana n. 2-4 kertaa ja kun supistus loppuu Anna lepää. II AV:n aikana autetaan syntyvä lapsi ulos. Pään synnyttyä kätilö auttaa vauvan hartioista syntymään, jolloin vartalo seuraa helposti kainaloista vetäen. Samalla kätilö huomioi Anna äidin voinnin, arvioi mahdollisen episiotomian (välilihan leikkaus) tarpeen ja vuodon määrää alustavasti. III AV:n aikana syntyy istukka. Avustava kätilö antaa Annalle synnytyksessä kohtua supistavat lääkkeet, jonka jälkeen kohtu supistuu voimakkaasti ja istukka irtoaa. Istukka poistetaan vatsan päältä painaen ja samanaikaisesti napanuorasta kevyesti vetäen. Tämän jälkeen tarkistetaan Anna äidin limakalvovauriot ja väliliha, tarvittaessa ommellaan sekä seurataan kohdun supistumista ja jälkivuodon määrää. Ulosauton jälkeen Annan ja Onnin lapsi kuivataan ja nostetaan äidin vatsalle lepäämään lämpimästi peiteltynä. Kätilö ohjaa Anna äitiä ja vauvaa ensi-imetykseen. Lapselle annetaan Apgar-kuntoisuuspisteet 1min. / 5 min. / 15 min. iässä, joista 5 min pisteet ovat tärkeimmät. 103

104 Palveluarkkitehtuurin soveltaminen terveydenhuollossa Annan verenpaine ja lämpö mitataan. Vauvasta otetaan synnytyssalissa ns. napaverinäytteet, jonka jälkeen napanuora suljetaan. Kun vauva on imenyt haluamansa määrän, hänet punnitaan ja mitataan, otetaan lämpö sekä annetaan K-vitamiinipistos lihakseen suojaamaan sisäisiltä verenvuodoilta. Avustava kätilö auttaa Onni isää vauvan mittaamisessa ja kylvettämisessä. Anna käy suihkussa ja hänelle tuodaan syötävää (mahdollisesti myös Onni isälle). Tiedot Annan synnytyksen kulusta kirjataan synnytyskertomukseen ennen osastolle siirtymistä ja vauvan tiedot myös lapsen hoitokertomukseen. Synnytyksestä vanhemmille jää kirjallinen synnytys- ja hoitokertomus. Anna siirtyy lapsivuodeosastolle noin kaksi tuntia synnytyksen jälkeen ja samalla siirtyvät hänen esitietonsa ja synnytyksen kulun tiedot lyhyesti. Annan synnytys sujui hyvin, vaikka hän tunsikin loppuvaiheessa vointinsa jo melko väsyneeksi. Synnytyssalissa tapahtuneen seurannan ja lapsen ensimmäisen kylvetyksen jälkeen Anna ja vauva siirtyvät synnyttäneiden vuodeosastolle, jossa Annan ja Onnin hyväkuntoinen vauva on vierihoidossa koko hoitojakson ajan. Synnytyksen jälkeinen seuranta ja hoito Anna toipui synnytyksestä hyvin ja vauva voi hyvin. Anna ja Onni opettelivat hoitajan opastuksella oman vauvan hoitoa, kuten kylvettämistä, imetystä. Ennen kotiutumista Annan vointi ja palautuminen synnytyksestä tarkastetaan. Myös vauvan vointi tarkastetaan. Tiedot synnytyksestä siirtyvät neuvolaan Anna äidin neuvolakortin mukana, kun hän tapaa terveydenhoitajan ensimmäisen kerran. Neuvolaan menee myös epikriisi Annan synnytyksestä. Synnytyssairaalasta kotiutumisen jälkeinen aika Päästyään kotiin sairaalasta Anna-äiti ottaa yhteyttä Jynkän äitiysneuvolaan ja sopii kotikäyntiajan terveydenhoitajan kanssa neljän päivän päähän kotiutumisesta. Kätilö tarkastaa Anna-äidin palautumisen synnytyksestä, kuten kohdun palautumisen, rinnat ja mahdolliset haavat. Lisäksi hän tarkastaa lapsen voinnin, painon, navan jne. sekä vanhempien selviytymisen uuden tulokkaan kanssa. Lapsi siirtyy 2 viikon kuluttua lastenneuvolan seurantaan. Terveydenhoitaja tekee neuvolassa Annalle jälkitarkastuksen sekä sopii lääkärintarkastuksen n. 2 kk:n päähän synnytyksestä ja perhesuunnittelun tai muun neuvolassa käynnin tarpeen mukaan Äitiyspoliklinikan mallinnusesimerkki Tämä luku sisältää tarkemman mallinnusesimerkin äitiyspoliklinikan toiminnasta. Toiminnasta kuvataan yleiskuva-tasolla tärkeimmät toiminnot ja liittyminen perusterveydenhuoltoon sekä synnytystoimintaan yleisimmät tutkimukset ja käynnit sekä syitä äitiyspoliklinikkaseurantaan. Prosessitason kuvausesimerkki on tuotettu riskiraskauden seurantakäynnistä sekä ultraääniseulontatutkimuksen prosessista. Näiden asiakasnäkökulmaan keskittyvien mallien lisäksi luvussa on työntekijän näkökulmasta tehty toimintotason kuvausesimerkki ultraäänikätilön työskentelystä. Esimerkit havainnollistavat yhdessä yksikössä tehtävää toiminnan mallinnusta suhteellisen yleisellä tasolla. Kuvauksista selviävät yleiset yksikön toimintakokonaisuudet ja valittujen prosessien eteneminen osallistuvien toimijoiden näkökulmasta. Tätä "prosessin suuntaan" etenevää kuvaustapaa täydentää yhden toimijan näkökulmasta tehty työnkulkujen kuvaus. Käytännössä monet prosessit näkyvät useille toimijoille vain tiettyjen tehtävien toistumisena siltä osin, kuin toimija itse osallistuu prosessiin. Tämä on huomioitava erityisesti käyttöliittymien suunnittelussa: prosessilähtöiseen rajapintojen ja prosessivaiheiden suunnitteluun on yhdistettävä yksittäisen käyttäjän useita (mahdollisesti yhtäaikaisiakin) prosessi-instansseja ja muita tehtäviä palvelevien käyttöliittymien suunnittelu. 104

105 Osa 2: prosessien ja palvelujen määrittely ja suunnittelu Äitiyspoliklinikkatoiminnan yleiskuva Lähteinä yleiskuvauksessa on käytetty Pohjois-Karjalan sairaanhoito- ja sosiaalipalvelujen kuntayhtymän "Synnytys tutuksi" -sivuilla (PKSHP 2007b) sekä Kuopion yliopistollisen sairaalan "Tutukspalvelu, virtuaalinen tutustumiskäynti synnytyssairaalaan" -sivuilla (KYS 2007) olevia tietoja. Äitiyspoliklinikkatoiminnan yleiskuva ja tärkeimmät toiminnot näkyvät kuvassa 29. Äitiyspoliklinikalle tullaan neuvolan lähettämänä raskauden ajan seulonta- ja erikoistutkimuksia varten. Poliklinikalla hoidetaan ja tutkitaan myös erityisseurantaa tarvitsevia ja riskiraskausäitejä. Riskiraskauden syitä voivat olla esimerkiksi äidin korkea ikä, äidin perussairaus, monisikiöinen raskaus, sikiön poikkeava koko tai lasketun ajan ylitys. Synnyttäjät tulevat poliklinikalle äitiysneuvolan terveydenhoitajan tai lääkärin lähettämänä. Isä tai muu tukihenkilö voi tulla vastaanotolle mukaan. Äitiyspoliklinikalla lääkärinä toimii synnytys- ja naistentautien erikoislääkäri tai alalle erikoistuva lääkäri. Tarvittaessa konsultoidaan sairaalan muiden erikoisalojen asiantuntijoita. Kätilön vastaanotolla tehdään raskauden ajan normaaliseurantoja. Kätilö tekee myös ultraäänitutkimuksia ja avustaa lääkäriä näytteenotossa. Kaikille äitiyspoliklinikan seurannassa oleville tehdään ultra-äänitutkimus. 32. raskausviikosta lähtien poliklinikalla otetaan sikiön sydämen sykekäyrä. Lääkäri tekee ensisynnyttäjille loppuraskauden aikana synnytystapa-arvion. Äitiyspoliklinikalla voidaan myös tutkia istukka- ja lapsivesinäytteitä. Kuva 29. Äitiyspoliklinikan toiminnot ja liittyminen perusterveydenhuoltoon ja synnytystoimintaan. 105

106 Palveluarkkitehtuurin soveltaminen terveydenhuollossa Seuraavassa kuvataan tärkeimpiä äitiyspoliklinikan vakiotutkimuksia ja käyntejä: raskausviikon ultraäänitutkimus: Tutkimuksessa selvitetään sikiöiden lukumäärä, sydämen syke ja raskauden kesto. Lisäksi tutkitaan sikiön rakenteet sillä tarkkuudella, joka tässä raskauden vaiheessa on mahdollista. Sikiön niskapoimu mitataan. Ultraäänitutkimuksen tekee joko lääkäri tai kätilö raskausviikon ultraäänitutkimus: Ultraäänitutkimuksessa tutkitaan sikiön rakenteet sekä istukan paikka ja lapsiveden määrä. Tutkimuksessa käydään systemaattisesti läpi sikiön pään, vartalon ja raajojen alueet. Tutkimuksen tekee lääkäri tai kätilö 37. raskausviikon poliklinikkakäynti: Käynnin aluksi kätilö haastattelee odottajan. Synnytyskertomukseen kirjataan odottajan henkilötiedot sekä raskauden kulku (ellei äiti ole ollut jo aiemmin äitiyspoliklinikan asiakkaana): käytetyt lääkkeet ja mahdolliset ongelmat. Keskustelun jälkeen tehdään ultraäänitutkimus, jossa tarkastetaan sikiön kasvu, lapsiveden määrä ja istukan kunto. Lisäksi otetaan sikiön sydänäänikäyrä. Käynnin lopuksi lääkäri tutkii kohdunsuun tilanteen ja lantion mitat. Seurantakäynti: Odottajalla voi olla perussairauksia tai raskauden aikana voi ilmetä ongelmia, jolloin äitiyspoliklinikkakäyntejä tulee useammin, jotta sikiön ja äidin hyvinvointi varmistettaisiin. Tällöin puhutaan riskiraskausseurannasta. Äitiyspoliklinikalle voidaan ohjata jo raskauden suunnitteluvaiheessa, jolloin esim. lääkitys voidaan vaihtaa sopivaksi raskautta ajatellen. Ensimmäisellä käynnillä kätilön vastaanotolla otetaan verenpaine ja tarkistetaan esitiedot, pyydetään suostumukset ja annetaan seulontainfo sekä kysytään halukkuus seulontatutkimuksiin. Tämän jälkeen ultraäänitutkimuksen tekee joko lääkäri tai kätilö. Lääkäri selvittää myös muut raskauteen vaikuttavat tekijät kuten äidin mahdollisen perussairauden vaikutukset. Jos odottavan äidin BMI (body mass index) on yli 32, voi käyntiin liittyä keskustelu ravitsemusterapeutin kanssa tai myöhemmillä käynneillä. Seuraavilla käynneillä kätilön tapaamisella käydään läpi yleinen vointi, neuvolassa tehdyt mittaukset ja seulonnan tulokset sekä tehdään muita tutkimuksia - esim. verensokerin mittaus. Ultraäänitutkimuksen jälkeen vielä lääkäri keskustelee äidin voinnista, tutkimustuloksista, lääkityksistä tai muista esille tulevista asioista. Yleisimpiä syitä äitiyspoliklinikkaseurantaan ovat mm.: kohonnut verenpaine, (kuvattu tarkemmin alla) gestaatiodiabetes (White-A, raskauden aikana esiintyvä sokeriaineenvaihdunnan häiriö), hepatogestoosi, raskauden aikainen maksan toimintahäiriö, kaksoisraskaus, perätila, kasvuseuranta (esim. sikiön kasvun hidastuminen), synnytystapa-arvio (esim. sikiön suuri koko ja synnyttäjän lantionmitat), synnytyspelko, muut pitkäaikaissairaudet, yliaikainen raskaus ja ennenaikaiset supistukset. Kuhunkin seurannan syyhyn liittyy joukko toimenpiteitä, ehtoja ja toimintasääntöjä, joista esitetään esimerkkejä seuraavassa alaluvussa. 106

107 Osa 2: prosessien ja palvelujen määrittely ja suunnittelu Prosessitason esimerkki: riskiraskauden seurantakäynti ja ultraäänitutkimus Edellä kuvattuihin riskiraskauden seurantoihin liittyvän seurantakäynnin prosessi on kuvattu yleisesti kuvassa 30. Se kuvaa tarkentaa luvun alussa kuvatuista prosessikartan prosesseista tarkemmin "neuvolassa tunnistettujen raskaudenaikaisten ongelmien seuranta/hoito" -prosessia äitiyspoliklinikan osalta. Prosessin eteneminen äitiyspoliklinikalla lähtee liikkeelle lähetteestä, jonka kiireellisyyden arvioinnin jälkeen tehdään ajanvaraus. Ilmoittautumisen jälkeen tehdään tarvittavat tutkimukset ja hoitopäätökset, jotka kirjataan tietojärjestelmiin sekä äitiyskorttiin. Jatkohoito voi vaatia ajanvarauksia lisätoimenpiteisiin tai -tutkimuksiin, ja hoitoa muissa yksiköissä. Prosessin eri vaiheissa (mm. kiireellisyysluokitus, hoitosuunnitelmien laatiminen jne.) käytetään runsaasti erilaisia tietoja ja tietämystä riippuen edellä kuvatuista seurantojen syistä, ja voidaan suorittaa erilaisia tutkimuksia. Prosessin eri vaiheissa äitiyspoliklinikalta voidaan myös lähettää tietoja neuvolaan. Kuva 30. Riskiraskauden seurantaprosessin eteneminen äitiyspoliklinikalla. Esimerkiksi kohonneen verenpaineen hoitamiseen äitiyspoliklinikalla liittyy seuraavaa hoitoon ja tutkimuksiin liittyvää tietämystä ja toimintaa: Kohonnut verenpaine: Verenpaine voi olla koholla jo ennen raskautta tai se voi nousta raskauden aikana. Verenpaine on koholla, jos arvo on 140/90 tai yli tai arvot kohoavat selkeästi alkuraskauden verenpainearvoista. Koholla olevan verenpaineen seurantaan liittyy virtsan valkuaisen seuraaminen. Tarvittaessa kerätään virtsaa vuorokauden ajan ja siitä määritetään valkuaisen määrä. Tärkeää on myös muiden oireiden seuranta (päänsärky, näköhäiriöt, ylävatsakipu, turvotukset). Kohonnut verenpaine ja valkuainen virtsassa voivat viitata pre-eclampsian (=raskausmyrkytys, 107

108 Palveluarkkitehtuurin soveltaminen terveydenhuollossa toxemia) kehittymiseen, joka vaatii äidin seurantaa osastolla. Jos verenpaine on koholla jo alkuraskaudessa, selvitetään istukan ja kohdun virtaukset jo alkuraskauden ultraäänitutkimuksen yhteydessä. Myös loppuraskauden kohonneessa verenpaineessa tarkistetaan em. virtaukset. Toinen esimerkki äitiyspoliklinikan prosessikuvauksesta on kuvassa 31 näkyvä ultraääniseulontatutkimus. Kuten näkyy, prosessi ei tässä tapauksessa lähde (välttämättä) liikkeelle lähetteestä, jolloin se ei myöskään tuota samalla tavoin hoitopalautetta perusterveydenhuoltoon. Prosessissa on kuitenkin useita samoja osia ja työvälineitä kuin riskiraskauden seurantaprosessissa. Kuva 31. Ultraääniseulontatutkimuksen prosessin eteneminen äitiyspoliklinikalla Toimintotaso: ultraäänikätilön toiminta Edellinen kuva on esimerkki vaakasuuntaisesta prosessista, johon osallistuu useita toimijoita (vaakasuuntainen prosessi). Toiminnan kuvaamisessa prosessikaavioita ja -kuvauksia voidaan tehdä kuitenkin myös "pystysuuntaan", yhden toimijan näkökulmasta. Yhdellä toimijalla voi olla omalla "työlistallaan" useita samojen tai eri prosessien instansseja, joiden jotkin vaiheet toistuvat toimijan työskentelyssä. Näiden toimintojen tarkempi tutkiminen ja toimijan näkökulmasta kuvattujen työnkulkujen kuvaaminen voi auttaa tunnistamaan prosessien pullonkauloja ja parantamaan ratkaisujen käytettävyyttä, koska "vaakasuuntaisten" prosessien kuvaus voi jättää yksittäisen toimijan näkökulmassa selvinä näkyviä ongelmia kuvaamatta. Kuvassa 32 on esitetty edellisen kuvan Kätilö-toimijan toimintaa ultraäänikuvausprosessissa toimijan henkilökohtaisen päivän työnkulun kannalta. Vaikka kuvaus on pelkistetty ja kuvaa vain pienen osan kaikista työtehtävistä, se havainnollistaa työnkulkujen yksityiskohtia ja etenemistä toimijakohtaisesti. 108

109 Osa 2: prosessien ja palvelujen määrittely ja suunnittelu Kuva 32. Prosessikaavio ultraäänikätilön tyypillisestä toiminnasta. Kuten äitiyspoliklinikan mallinnusesimerkeistä nähdään, prosessikuvauksia on mahdollista tuottaa monilla eri tasoilla ja monien eri toimijoiden näkökulmasta. Samoja kaaviotyyppejä voidaan käyttää eri tasoilla ja eri toimijoiden työn kuvaukseen. Monia muita prosessien mallinnuksessa tarvittavia kuvauksia esimerkiksi käytettävistä tiedoista ja tietojärjestelmistä tarvitaan ratkaisujen määrittelyssä prosessikuvausten lisäksi. Myös voidaan havaita, että esimerkiksi kohonneen verenpaineen tai muiden seurannan syiden erityispiirteet vaativat erityyppistä toimintaa ja erilaisia tietoja sekä tutkimuksia prosessin eri vaiheissa, mutta prosessin yleisellä tasolla voidaan tunnistaa prosessien päävaiheet yleisesti kaikkia niitä läpikäymättä. Toisaalta yksittäisten tilanteiden (esimerkiksi erityinen ongelmaepäily) selvittäminen voi vaatia prosessin peruskulusta poikkeavia toimenpiteitä. Vaikka mikään kuvauksista ei mennytkään tarkalle tekojen ja välineiden tasolle, on esimerkiksi tutkimusten ja seurannan syiden kuvauksissa monia tarkkoja tietoja kerättävistä tiedoista ja tehtävistä toimenpiteistä. 109

110 Palveluarkkitehtuurin soveltaminen terveydenhuollossa Synnytys-hoitokokonaisuus (erikoissairaanhoito) Toinen esimerkki tarkemmasta hoitokokonaisuuden kuvauksesta äitiyshuollossa on synnytyshoitokokonaisuus, joka kuvataan tässä luvussa. Luku täydentää luvun yleiskuvaa, prosessikarttaa ja toimintatarinaa synnytystoiminnan osalta. Synnytys-hoitokokonaisuudesta kuvataan yleiskuva-tasolla tyypillinen hoitopolku, prosessin päävaiheet sekä päätoiminnot luvussa Luvussa kuvataan tarkemmin tyypillistä alatiesynnytysprosessia tarkennetun prosessikartan sekä synnytyssalin toiminnan osalta varsinaisesta synnytyksestä tehdyn toimintatarinan (osien) avulla. Seuraavissa aliluvuissa kuvataan toimintotason kuvaustaulukoiden avulla tehtäviä, jotka liittyvät synnytysvastaanoton toimintaan, ( ) synnytyssalin toimintaan ( ) ja synnytyksen jälkeiseen seurantaan ja hoitoon osastolla ( ). Lopuksi luvussa käsitellään esimerkki tarkemmasta tekojen ja välineiden tasolla tehtävästä kuvauksesta. Esimerkit havainnollistavat tarkentuvaa prosessien ja tehtävien mallinnusta, jossa on sovellettu luvussa 4.1 kuvattuja prosessien ja toimintojen kuvaustasoja ja -menetelmiä. Yleiskuvassa on käytetty lähteinä "Synnytys tutuksi" -sivuja (PKSHP 2007b), "Tutuks-palvelu, virtuaalinen tutustumiskäynti synnytyssairaalaan" -materiaalia (KYS 2007) sekä olevia tietoja ja Vauvan syntymä -kirjasta (San06). Kuva 33. Synnytyksen hoitopolut, vahvennettuna normaali hoitopolku (KYS 2007) 110

111 Osa 2: prosessien ja palvelujen määrittely ja suunnittelu Synnytys - yleiskuva Synnytystoiminnan tyypilliset hoitopolut (joiden kautta äiti ja perhe kulkevat) näkyvät kuvassa 33. Normaali hoitopolku kulkee synnytyssalin vastaanoton ja synnytyssalin kautta osastolle, mutta osaston, leikkaussalin, heräämön, lasten teho-osaston ja vauvanhoitohuoneen kautta kulkevat hoitopolut ovat myös yleisiä. Synnytykseen liittyvät prosessit on kuvattu erikoissairaanhoidon hoito-organisaation tarkennetussa prosessikartassa kuvassa 34. Synnytystoiminnan kannalta alatiesynnytysprosessi ja ennalta suunniteltu keisarinleikkaus on tunnistettu keskeisiksi tarkemmin kuvattaviksi prosesseiksi synnytykseen liittyen. Kuvassa näkyvät myös muut synnytystoimintaan liittyvät yksiköt. ERIKOISSAIRAANHOIDON HOITO-ORGANISAATIO Synnyttämättömien vuodeosasto Vastasyntyneiden tehoosasto Synnytysvastaanotto Synnytyssali Leikkaussali Heräämö Tehoosasto Lapsivuodeosasto (synnyttäneiden vuodeosasto) Laboratorio Apteekki Hoito-/tutkimus-/ toimenpideyksikkö Alatiesynnytys Ennalta suunniteltu keisarinleikkaus Laboratoriopalvelut Kuvantamispalvelut Ravitsemuspalvelut Lääkintäpalvelut Konsultaatio Kuva 34. Prosessikartta synnytys-hoitokokonaisuudesta erikoissairaanhoidossa Alatiesynnytys - prosessitaso Prosessikarttaa voidaan tarkentaa edelleen valittuun prosessiin liittyen, kuvaamalla eri yksiköiden ja prosessien toimintoja tai toimintakokonaisuuksia. Kuvassa 35 alatiesynnytyksen, laboratoriopalvelujen, lääkintäpalvelujen sekä ravitsemuspalvelujen yleisimmät toiminnot on kuvattu yksiköittäin. Normaalin alatiesynnytysprosessin vaiheet kulkevat synnytysvastaanoton, synnytyssalin ja vuodeosaston kautta, mikä on kuvattavissa myös ylimmän tason prosessikaavion avulla (kuva 36). 111

112 Palveluarkkitehtuurin soveltaminen terveydenhuollossa ERIKOISSAIRAANHOIDON HOITO-ORGANISAATIO Synnytysvastaanotto Synnytyssali Lapsivuodeosasto (synnyttäneiden vuodeosasto) Laboratorio Apteekki Keittiö Alatiesynnytys Haastattelu Tutkimus Avautumisvaiheen toiminta Ponnistusvaiheen toiminta Äidin palautumisen seuranta ja hoito Opastus lapsen hoitoon Synnytyksen valmistelu Jälkeisvaiheen toiminta Synnytyksen jälkeinen toiminta Lapsen seuranta ja hoito Verikokeen tutkiminen ja tulokset Lääkkeiden toimitus Laboratoriopalvelut Lääkintäpalvelut Ravitsemuspalvelut Ruoan valmistus ja toimitus Kuva 35. Prosessikartta alatiesynnytys-prosessista erikoissairaanhoidossa Alatiesynnytys Synnytysvastaanoton toiminta Synnytyssalin toiminta Synnytyksen jälk. seuranta ja hoito Kuva 36. Alatiesynnytys-prosessin päävaiheet Prosessikuvausten kerroksittaisuus auttaa prosessien hahmottamisessa. Kuvassa 37 on tarkempi prosessikuvaus, jossa näkyvät alatiesynnytysprosessin prosessikartassa näkyvien vaiheiden välinen eteneminen ja prosessien toiminnot eri yksiköissä. Käytetty notaatio on hyvä esimerkki mallinnusvälineiden tukemista notaatiotavoista. Siinä näkyy havainnollisesti esimerkiksi kuvaustapoja toiminnoille, jotka voidaan käydä läpi missä tahansa järjestyksessä. 112

113 Osa 2: prosessien ja palvelujen määrittely ja suunnittelu Kuva 37. Synnytysprosessin toiminnot eri yksiköissä. Synnytys-hoitokokonaisuudesta on koostettu myös sanallinen yleiskuvaus toiminnasta. Alla esitetään lyhennelmä tästä kuvauksesta. Lyhennelmästä on poistettu puhtaasti hoitoon tai lääketieteeseen liittyvät kuvaukset, koska tässä tavoitteena on ollut tunnistaa tietojärjestelmiin ja niiden avulla tuettuihin prosesseihin liittyviä seikkoja. Toimintojen kuvaus esimerkiksi lääkärien ja muiden terveydenhuollon ammattilaisten kannalta keskittyy helposti juuri hoidollisiin seikkoihin. Tämä antaa toisaalta mahdollisuuden tunnistaa uusia tapoja hoidon tukemiseen (esimerkiksi sääntöjen tai tarkistusten kirjoittaminen sovelluksiin) ja antaa hyvän kuvan järjestelmiin kirjattavasta toiminnasta ja tiedoista, mutta usein sovelluspalvelujen ja rajapintojen kuvauksessa riittää huomattavasti yleisempi kuvaustaso. Nimenomaisesta toimintaa tarkasti palvelevissa erityissovelluksissa tarkat kuvaukset ovat erityisen hyödyllisiä. Synnytyksen kulkuun ei yleensä puututa, jos äiti ja vauva voivat hyvin ja synnytys edistyy normaalisti. Jos syntyy ongelmia synnytyksen aikana, muuttuu normaali synnytys riskisynnytykseksi.... Synnytys voidaan määritellä normaaliksi vasta jälkikäteen.... Kätilön tehtävä on synnytyksessä tarkkailla äidin ja lapsen vointia ja havaita mahdolliset ongelmat. Tarkkailun apuna käytetään erilaisia menetelmiä kuten: sikiön sydänäänten ja supistusten seuranta KTG:llä sikiön, EKG:n seuranta STAN:illa (kohdun sisäinen EKG mittaus lapselta) ja muita kliinisiä oireita.... Synnytys jaetaan 113

114 Palveluarkkitehtuurin soveltaminen terveydenhuollossa kolmeen vaiheeseen, joista avautumisvaihe on ensimmäinen ja ajallisesti yleensä pisin.... Ensisynnyttäjän synnytys kestää keskimäärin n h ja uudelleensynnyttäjällä n h. Suurin osa synnyttäjistä kokee synnytyksen eriasteisesti kivuliaana.... Synnytyskipua on hoidettava aktiivisesti ja äidin toivomuksia kivunlievityksen suhteen on kuunneltava. Synnytyskipua mitataan kipumittarin avulla. Hoidollisia kivunlievitysmenetelmiä käytetään erityisesti synnytyksen alkuvaiheessa.... Lihakseen pistettävät kipulääkkeet ovat tarkoitettu synnytyksen alkuvaiheen kivunlievitykseen.... Koska nämä lääkkeet vaikuttavat myös lapseen, tulee sikiön sydänäänikäyrän olla hyvä.... Ilokaasu on vanha ja turvallinen kivunlievitysmenetelmä.... Parakervikaalipuudutuksen (=kohdunkaulan puudutus) laittaa gynekologi sisätutkimuksen yhteydessä.... Ennen puudutuksen laittoa sikiökalvot puhkaistaan ja sikiölle laitetaan kohdunsisäinen sydänäänten seuranta.... Epiduraalia käytetään useammin ensisynnyttäjillä, joilla on pidemmät synnytyksenkestot, mutta tilanteen ja toivomusten mukaan myös uudelleen synnyttäjillä.... Ennen puudutuksen laittoa tehdään muutamia turvallisuutta lisääviä toimenpiteitä... Puudutus vaatii jatkuvan verenpaine seurannan ja usein supistuksia parantavan tiputuksen tuekseen... Joskus epiduraalipuudutuksen sijasta käytetään niin sanottua matalaa spinaalipuudutusta... Ponnistusvaihe alkaa, kun kohdunsuu on täysin auki (10 cm) ja lapsen pää on laskeutunut lantionpohjalle sekä lapsen pään lakisauma on kääntynyt suoraan mittaan.... Episiotomiaan johtavia syitä voivat olla; lasta uhkaava hapenpuute, imukuppisynnytys, lapsen koko tai äidin repeytymisvaara... Lapsen pään synnyttyä kätilö auttaa vauvan hartioita syntymään, vartalo seuraa yleensä helposti kainaloista vetäen. Lapsen synnyttyä äidille annetaan välittömästi kohtua supistavia lääkkeitä... Istukka poistetaan... Tavallisesti istukka painaa g, riippuen lapsen koosta... liittyy usein jonkin verran verenvuotoa, tavallisesti alle 500 ml... haavat puudutetaan hyvin ja ommellaan... Kätilö ohjaa äitiä ja vauvaa ensi-imetyksessä... vauva punnitaan ja mitataan, otetaan lämpö ja annetaan K- vitamiinipistos lihakseen... Äidin ja lapsen vointia ja toipumista synnytyksestä seurataan synnytyssalissa n. 2 tuntia... Verenpaine ja lämpö mitataan... Synnytyksestä vanhemmille jää kirjallinen synnytys- ja vastasyntyneen hoitokertomus. Synnytyssalissa tapahtuneen seurannan ja lapsen ensimmäisen kylvetyksen jälkeen äiti ja vauva siirtyivät synnyttäneiden vuodeosastolle... Osastolla seurataan äidin yleisvointia ja toipumista synnytyksestä. Osaston kätilö tarkistaa äidiltä kohdun supistumisen, jälkivuodon ja mahdollisen välilihan haavan synnytyksen jälkeen ja kotiin lähtiessä sekä tekee tarvittavat merkinnät hoitokertomukseen. Tarvittaessa tarkistetaan veren hemoglobiini ja virtsa valkuainen ja sokeri. Äidin erityistarpeensa otetaan myös huomioon kuten mieliala ja väsymys tai mahdollisen perussairauden vaatima seuranta ja hoito... Ennen kotiutumista äidin vointi ja palautuminen synnytyksestä tarkastetaan. Myös vauvan vointi tarkastetaan. Tiedot synnytyksestä siirtyvät neuvolaan äidin neuvolakortin mukana, kun hän tapaa terveydenhoitajan ensimmäisen kerran. Neuvolaan menee myös epikriisi synnytyksestä Synnytysvastaanoton toiminta - toimintotaso Prosessikartan ja prosessikuvausten sekä toimintatarinoiden tai toimintakokonaisuuden kuvausten pohjalta voidaan sanallisen kuvauksen lisäksi tuottaa tarkempia kuvauksia toiminnasta. Tässä ja seuraavissa aliluvuissa on kuvattu toiminnonkuvaustaulukoita soveltamalla keskeisiä tehtäviä, tietoja ja esiehtoja edellisissä luvuissa (prosessikartta, prosessikaaviot) kuvatusta synnytysprosessista. Kuvaustaulukoiden avulla voidaan pyrkiä kiinnittämään huomiota nimenomaisesti tietojärjestelmä- 114

115 Osa 2: prosessien ja palvelujen määrittely ja suunnittelu ratkaisujen suunnittelussa tarvittaviin seikkoihin, jotka jäävät helposti sivurooliin etenkin toiminnan muihin yksityiskohtiin keskittyvissä sanallisissa kuvauksissa. Taulukoissa olisi mahdollista kuvata tarkemmin myös käytettäviä tietojärjestelmiä, mutta toisaalta toiminnan kehittämiseksi voidaan lähinnä keskittyä tietotarpeisiin ja automatisointitarpeiden tunnistamiseen ilman olemassa olevien järjestelmien asettamia rajoitteita. Synnytysvastaanoton toiminnan toimintotason kuvaustaulukoissa kuvataan haastattelun, tutkimuksen ja synnytyksen esivalmistelujen keskeiset toimenpiteet. 1 Synnytysvastaanoton toiminta Osallistujat Kätilö Esiehdot Äiti on saapunut synnytysvastaanotolle supistusten, lapsiveden menon tai muun syyn vuoksi. Tehtävät 1.1 Haastattelu Tunnistetut poikkeukset 1.2 Tutkimus 1.3 Synnytyksen esivalmistelu Synnytys ei ole käynnistynyt 1.1 Haastattelu Osallistujat Esiehdot Tehtävät Tunnistetut poikkeukset Tarvittavat tiedot Tuotettavat tiedot Automatisoinnin tarve Kätilö Äiti on saapunut synnytysvastaanotolle supistusten, lapsiveden menon tai muun syyn vuoksi Ennakkotietojen tarkastus ja täydennys Haetaan neuvolasta lähetetyt esitiedot. Tarkastetaan ja täydennetään niitä tarvittaessa kyselemällä tietoja äidiltä Tulosyyn selvitys Kysytään äidiltä tulosyy (vedenmeno/supistukset/vuoto/kipu/ liikehälytys) ja kirjataan se (raskaus-/)synnytyskertomukseen Raskauden aikaisen voinnin selvitys Kysellään äidiltä raskauden aikaista vointia ja kirjataan huomioita (raskaus-/)synnytyskertomukseen Synnytykseen liittyvien toiveiden selvitys Kysellään äidiltä synnytykseen liittyviä toiveita ja kirjataan ne (raskaus-/)synnytyskertomukseen. Synnytys ei ole käynnistynyt Ennakkotiedot Synnytyskertomuksen alku Esitietojen pitäisi olla haettavissa tietojärjestelmästä (KT1) ja niitä pitäisi voida muokata ja täydentää (KT2). Synnytyskertomuksen pitäisi olla sähköinen. Uusi synnytyskertomus pitää voida luoda ja tallentaa tietojärjestelmään ja sitä pitää pystyä täydentämään ja muokkaamaan myöhemmin. Synnytyskertomukseen pitää voida tallentaa tulosyy, synnytykseen liittyvät toiveet sekä muita tietoja. (KT3) 115

116 Palveluarkkitehtuurin soveltaminen terveydenhuollossa 1.2 Tutkimus Osallistujat Esiehdot Tehtävät Tunnistetut poikkeukset Kätilö Äiti on saapunut synnytysvastaanotolle supistusten, lapsiveden menon tai muun syyn vuoksi Äidin terveystarkastus Mitataan äidin paino, verenpaine ja lämpö sekä pyydetään äitiä antamaan virtsanäyte ja testataan siitä valkuainen ja sokeri. Tulokset kirjataan (raskaus-/)synnytyskertomukseen Sikiön sydänäänten kuuntelu Kuunnellaan sikiön sydänäänet esim. doppler-laitteella ja kirjataan huomio (raskaus-/)synnytyskertomukseen Ulkotutkimus Tutkitaan sikiön asento ja tarjoutuva osa tunnustelemalla vatsanpeitteiden päältä ja kirjataan huomio (raskaus- /)synnytyskertomukseen Sisätutkimus Tutkitaan kohdunsuun tilanne, eli synnytyksen vaihe, gynekologisella tutkimuksella ja kirjataan tulos (raskaus- /)synnytyskertomukseen KTG-käyrän ajaminen Ajetaan KTG-käyrä, eli sikiön sydänäänet, kesto noin min. ja kirjataan huomio (raskaus-/)synnytyskertomukseen. Synnytys ei ole käynnistynyt, sikiö on perätarjonnassa, sikiön sydänääniä ei kuulu Automatisoinnin tarve Tutkimusten tulokset kirjataan sähköiseen (raskaus- /)synnytyskertomukseen. Huomiot KTG käyrästä kertomukseen suoraan (laitteesta) mittauksen aikana? 1.3 Synnytyksen esivalmistelu Osallistujat Kätilö Tehtävät Äidin valmistelu Poistetaan äidiltä ihokarvoja, annetaan äidille peräruiske ja opastetaan äiti peseytymään. Tunnistetut poikkeukset Tuotettavat tiedot Sairaalan vaatteiden antaminen Annetaan äidille sairaalan vaatteet ja tukihenkilölle suojavaatteet Opastus synnytyssalin käytäntöihin Opastetaan sekä äiti että tukihenkilö synnytyssalin käytäntöihin. Apuna voidaan käyttää potilasohjeita Synnytyssaliin ohjaaminen Opastetaan äiti ja tukihenkilö synnytyssaliin ja näytetään tarvittavat tilat (peseytymistilat, tukihenkilön lepotilat, tms.). Valmisteluja ei ehditä suorittaa (synnytys miltei loppuvaiheessa.) Kirjaus ohjauksen ja valmistelujen suorittamisesta (vähintään +/- tasolla mikäli osastolla ennalta sovitut käytännöt) synnytyskertomukseen. 116

117 Osa 2: prosessien ja palvelujen määrittely ja suunnittelu Synnytyssalin toiminta - toimintotaso Synnytyssalin toiminnan toimintotason kuvaustaulukoissa kuvataan synnytyksen etenemisen seuraamiseen, kivunlievitykseen, syntyvän lapsen ulos auttamiseen, jälkeisten ulosauttamiseen, synnytyksen jälkeiseen seurantaan ja hoitoon, lapsen tutkimiseen ja hoitoon sekä vanhempien opastukseen liittyviä osallistujia, tehtäviä, tietoja, poikkeuksia ja ehtoja. 2 Synnytyssalin toiminta Osallistujat Kätilö, tarvittaessa lääkäri Esiehdot Synnytys käynnissä Tehtävät 2.1 Synnytyksen etenemisen seuraaminen Tunnistetut poikkeukset Tarvittavat tiedot Tuotettavat tiedot Automatisoinnin tarve 2.2 Kivunlievitys 2.3 Syntyvän lapsen ulos auttaminen 2.4 Jälkeisten ulos auttaminen 2.5 Synnytyksen jälkeinen äidin seuranta ja hoito 2.6 Lapsen tutkiminen ja hoito 2.7 Vanhempien opastus Synnytyksen eteneminen pysähtyy Esitiedot ja vastaanotolla aloitettu synnytyskertomus Synnytyskertomus (äidin hoito ja huomiot lapsen syntymästä) sekä lapsen oma hoitokertomus (alkaa syntymästä). Lapsen tietojen siirtyminen äidin synnytyskertomuksesta lapsen hoitokertomukseen. Tietojen siirtäminen lapsen hoitokertomuksesta synnytyskertomukseen. 117

118 Palveluarkkitehtuurin soveltaminen terveydenhuollossa 2.1 Synnytyksen etenemisen seuraaminen Tavoite Synnytyksen etenemisen seuraaminen synnytyksen avautumisvaiheessa Osallistujat Kätilö, (joskus lääkäri) Tehtävät Sisätutkimus (toistuva) Tutkitaan säännöllisin väliajoin kohdunsuun avautuminen, eli synnytyksen vaihe, gynekologisella tutkimuksella ja kirjataan tulos synnytyskertomukseen. Vrt Tunnistetut poikkeukset Automatisoinnin tarve Sikiön sydänäänten ja supistusten seuranta KTG:llä (jatkuva) Ajetaan KTG-käyrää, eli sikiön sydänäänet, ja kirjataan huomio synnytyskertomukseen. Vrt Sikiön EKG:n kohdun sisäinen seuranta esim.stan:lla (jatkuva) Käytetään yhdessä KTG seurannan kanssa. Mittaus tapahtuu sikiön päänahkaan kiinnitetyn spiraalielektrodin avulla Kirjataan huomio synnytyskertomukseen Muiden kliinisten oireiden seuranta (jatkuva) Äidin vointi: virkeys, kivuliaisuus - äidin oma kokemus tai ammattilaisen näkemys äidin käyttäytymisen perusteella arvioituna. Kipulääkityksen vaikutusten seuranta, mielialan seuranta, jaksaminen (henkinen, fyysinen). Huomiot kirjataan synnytyskertomukseen. Sikiön sydänäänten heikkeneminen, äidin voimakas väsyminen, supistusten heikkeneminen tai loppuminen. Esim. STAN -järjestelmästä suoraan tietoja synnytyskertomukseen. 118

119 Osa 2: prosessien ja palvelujen määrittely ja suunnittelu 2.2 Kivunlievitys Tavoite Osallistujat Tehtävät Kivunlievitys synnytyksen eri vaiheissa Kätilö, äiti itse tai tukihenkilö, tarvittaessa synnytyslääkäri, anestesialääkäri Hoidollinen kivunlievitys Kätilö opastaa äitiä ja tukihenkilöä hoidollisessa kivunlievityksessä Hoidollisia kivunlievitysmenetelmiä ovat mm. rentoutuminen, lämpöpakkaus, sähköstimulaatio, hieronta, liikkuminen, lämmin kylpy tai suihku, musiikki, aquarakkulat, akupunktio. Huomiot kirjataan synnytyskertomukseen Lihakseen pistettävät kipulääkkeet Yleiskipulääkkeitä (yleensä Petidin), joilla vaikutus myös lapseen, joten lapsen sydänäänikäyrää seurataan (oltava hyvä). Synnytyksen kulun seuranta - lääkkeen rentouttava, unettava vaikutus, vaikutus itse synnytykseen. Lääkkeen nimi, annos, annostelutapa ja kelloaika sekä vaikutukset kirjataan synnytyskertomukseen, kuten myös vaikutukset sikiön vointiin Ilokaasu Happi-ilokaasuseoksen oikea hengittäminen (ajoitus ja tekniikka) - rytmitetty supistusten mukaan. Ilokaasun vaikutusten seuranta - kuinka hyvin lievittää kipuja, muuttuuko äidin vointi (esim. tokkuraisemmaksi). Ilokaasuseoksen hengittelyn alkamisaika ja tiheys sekä vaikutukset kirjataan synnytyskertomukseen Parakervikaalipuudutus Parakervikaalipuudutuksen (=kohdunkaulan puudutus) laittaa gynekologi sisätutkimuksen yhteydessä. Se on eräänlainen kohdunsuun paikallispuudutus. Edellyttää hyviä sikiön sydänääniä ja kohdunsuu vähintään 4 cm auki (synnytys aktiivivaiheessa). Ennen puudutusta puhkaistaan sikiökalvot ja laitetaan kohdun sisäinen sydänäänten seuranta sikiölle. Kipulääkityksen vaikutusten seuranta. Lääkkeen nimi, annos, annostelutapa ja kelloaika sekä vaikutukset kirjataan synnytyskertomukseen, kuten myös vaikutukset sikiön vointiin Epiduraalipuudutus Puudutuksen laittaa gynekologin luvalla anestesialääkäri. Ennen puudutusta puhkaistaan sikiökalvot ja laitetaan kohdun sisäinen sydänäänten seuranta sikiölle. Äidille suonensisäinen nestetiputus, verenpaineen seuranta (verenpaineen lasku mahdollista). Puudutus laitetaan selkäytimen epiduraalitilaan katetrin avulla, joka on yhdistetty kipupumppuun. Kipupumppu annostelee lääkkeen tasaisesti. Jatkuva verenpaineen seuranta ja usein tarvitaan supistuksia parantava tiputus. Äidin voinnin ja vireystilan seuranta; äiti useimmiten sängyssä. Lääkkeen nimi, annos, annostelutapa ja kelloaika sekä vaikutukset kirjataan synnytyskertomukseen. Samoin vaikutukset sikiön vointiin Spinalipuudutus Käytetään vaihtoehtona epiduraalipuudutukselle ns. matalaa spinaalipuudutusta - anestesialääkäri laittaa katetrin, jonka kautta kipulääke annetaan, selkäydintilaan. Arvioidaan kuinka korkealle puudutus vaikuttaa. Samanlainen menettely kipulääkkeen annostelussa ja äidin voinnin seurannassa, kuin epiduraalipuudutuksessa. Puudutuksen poistumisen seuranta synnytyksen jälkeen. Lääkkeen nimi, annos, annostelutapa ja kelloaika sekä vaikutukset kirjataan synnytyskertomukseen, kuten myös vaikutukset sikiön vointiin Tunnistetut poikkeukset Tuotettavat tiedot Paikallispuudutus Paikallispuudutusta käytetään synnytyksen jälkeen välilihan leikkaushaavan tai repeämien paikkaamisessa. Lääkkeen nimi, annos, annostelutapa ja kelloaika sekä vaikutukset kirjataan synnytyskertomukseen. Äiti ei ole niin kipeä, että kaipaa erityisesti kivunlievitystä. Synnytyskertomukseen käytetyt menetelmät, lääkkeet, annokset, antotapa ja vaikutukset. Lapsen hoitokertomukseen myös maininta kivunlievityksestä, mikäli annetuilla lääkkeillä on vaikutusta syntyvän tai syntyneen lapsen vointiin. 119

120 Palveluarkkitehtuurin soveltaminen terveydenhuollossa 2.3 Syntyvän lapsen ulos auttaminen Tavoite Syntyvän lapsen ulos auttaminen synnytyksen ponnistusvaiheessa Osallistujat Kätilö, lääkäri tarvittaessa Esiehdot Synnytys edennyt ponnistusvaiheeseen Tehtävät Ponnistamisen opastus Voimakas tarve ponnistaa, kun lapsi laskeutunut kanavassa. Työntö supistusten aikana 2-4 kertaa - kätilö ohjaa tai oman tuntemuksen mukaan. Lepo supistuksen loputtua. Ponnistusvaiheen kulku kirjataan synnytyskertomukseen. Tunnistetut poikkeukset Tuotettavat tiedot Episiotomia (=välilihan leikkaus) Tehdään tarvittaessa, kun lapsen pää kiristää välilihaa - aika loppuvaiheessa ponnistusvaihetta. Kirjataan synnytyskertomukseen, mikäli tehty. Kirjataan myös mikäli välilihaan tullut repeämä synnytyskertomukseen Lapsen hartioista vetäminen II AV: pää syntyy ensin, autetaan hartioista syntymistä ja kainaloista vetämällä loppu vartalosta. Mahdollisen haavan (episiotomia tai repeämä) huomiointi, vuodon määrän arvio, voinnin seuranta. Kirjataan synnytyskertomukseen Imukuppisynnytys Käytetään synnytyksen pysähtyessä tai äkillisessä hätätilassa kohdunsuun ollessa täysin auki. Vedetään joko kovalla kupilla, joka edellyttää pahkan kehittämistä ennen vetoa, tai pehmeällä kupilla veto, joka voidaan aloittaa heti. Episiotomia tehdään yleensä aina. Kirjataan synnytyskertomukseen miksi imukuppisynnytys tarpeen, imukuppisynnytyksen tapa ja kuinka sujui. Supistusten loppuminen Synnytyskertomus, jossa kuvattu tehdyt toimenpiteet 2.4 Jälkeisten ulos auttaminen Tavoite Jälkeisten ulos auttaminen jälkeisvaiheessa Osallistujat Kätilö Tehtävät Kohtua supistavien lääkkeiden antaminen Äidille annetaan lapsen synnyttyä kohtua supistavat lääkkeet, jolloin istukka irtoaa kohdun seinämästä. Tuotettavat tiedot Istukan poistaminen Istukka poistetaan äidin vatsan päältä painaen ja samanaikaisesti napanuorasta kevyesti vetäen Istukan arviointi Arvioidaan istukan eheys, punnitaan paino ja mitataan koko. Kirjataan huomiot synnytyskertomukseen Vuodon määrän arviointi Arvioidaan synnytyksen aikana tullut vuodon määrä punnitsemalla käytetyt liinavaatteet ja muu nestettä imevä materiaali sekä silmämääräinen arvio lisäksi. Merkintä synnytyskertomukseen. Synnytyskertomus - tiedot istukan irrottamisesta ja millainen se on ollut; myös arvio synnytyksen aikaisesta vuodosta. 120

121 Osa 2: prosessien ja palvelujen määrittely ja suunnittelu 2.5 Synnytyksen jälkeinen äidin seuranta ja hoito Tavoite Äidin voinnin seuranta ja hoito synnytyksen jälkeen Osallistujat Kätilö, tarvittaessa lääkäri Tehtävät Limakalvovaurioiden ja välilihan tarkistus Tarkistetaan äidin limakalvovauriot ja väliliha. Kirjataan huomiot synnytyskertomukseen. Tuotettavat tiedot Välilihan tai repeämien ompelu Tarvittaessa ommellaan väliliha tai repeämät. Ennen ompelua laitetaan paikallispuudutus, ks Kohdun supistumisen ja jälkivuodon määrän seuranta Seurataan kohdun supistumista ja jälkivuodon määrää. Huomiot kirjataan synnytyskertomukseen Äidin verenpaineen mittaaminen Mitataan äidin verenpaine ja kirjataan tulos synnytyskertomukseen Äidin lämmön mittaaminen Mitataan äidin lämpö ja kirjataan tulos synnytyskertomukseen. Synnytyskertomus, jossa huomiot kirjattuna. 2.6 Lapsen tutkiminen ja hoito Tavoite Lapsen tutkiminen ja hoito syntymisen jälkeen Osallistujat Kätilö, lastenhoitaja, isä tai tukihenkilö, tarvittaessa lasten lääkäri Tehtävät Napanuoran verinäytteiden ottaminen ja sulkeminen Vauvan napanuorasta otetaan verinäytteitä: astrup, TSH, tarvittaessa veriryhmä. Näytteiden ottamisen jälkeen napanuora suljetaan. Merkintä synnytyskertomukseen ja lapsen hoitokertomukseen näytteistä. Tunnistetut poikkeukset Tuotettavat tiedot Apgar-kuntoisuuspisteiden antaminen Vauvalle annetaan Apgar-kuntoisuuspisteet 1 min, 5 min ja 15 min iässä. Näistä 5 min pisteet ovat tärkeimmät. Kirjataan synnytyskertomukseen ja lapsen hoitokertomukseen Mittaaminen Vauva punnitaan ja mitataan (pituus, päänympärys, vatsan ympärys) sekä otetaan lämpö. Tarvittaessa opastetaan isää tekemään mittaus, ks Tiedot kirjataan sekä synnytyskertomukseen että lapsen hoitokertomukseen K-vitamiinipistos Vauvalle annetaan K- vitamiinipistos lihakseen suojaamaan sisäisiltä verenvuodoilta. Merkintä hoitokertomukseen Ensi-imetyksen ohjaaminen Ohjataan vauvan suu äidin rinnalle ja tarkkaillaan kuinka vauva osaa imeä. Kirjataan lapsen hoitokertomukseen. Lapsi syntyessä veltto, ei hapetu, muuten vointi huono. Lapsi ei osaa imeä tai lapsella suun rakenne poikkeava. Synnytyskertomus ja lapsen hoitokertomus - huomiot vastasyntyneestä ja toimenpiteiden kirjaus. 121

122 Palveluarkkitehtuurin soveltaminen terveydenhuollossa 2.7 Vanhempien opastus Tavoite Osallistujat Tehtävät Tarvittavat tiedot Tuotettavat tiedot Vanhemmille annetaan opastusta lapsen imettämiseen ja kylvetykseen Kätilö, lastenhoitaja Imetyksen opastus Opastetaan äitiä vauvan imetyksessä. Oikean imetysasennon ja sopivan vauvan tukemisen opastaminen. Kirjataan synnytyskertomukseen Kylvettämisen ja mittaamisen opastus Opastetaan tukihenkilöä lapsen kylvettämisessä ja mittaamisessa. Kirjataan synnytyskertomukseen tai lapsen hoitokertomukseen Opastus turvallisiin hoito-otteisiin ja käsittelyyn Opastetaan tukihenkilöä tai isää vauvan pukemisessa ja kapaloinnissa. Opastetaan vauvan käsittelyssä turvallisiin otteisiin, oikea pään ja vartalon tukeminen hoitotoimissa. Kirjataan synnytyskertomukseen tai lapsen hoitokertomukseen Esitiedot Kirjaus annetusta ohjauksesta ja kuinka lapsen hoito onnistunut ohjattuna Synnytyksen jälkeinen seuranta ja hoito osastolla - toimintotaso Synnytyksen jälkeiseen seurantaan ja hoitoon liittyen toimintotason kuvaustaulukoissa kuvataan äidin palautumisen seurantaa ja hoitoa, opastusta lapsen hoitoon, sekä lapsen seurantaa ja hoitoa koskevia tehtäviä ja niihin liittyviä tietoja. 3 Synnytyksen jälkeinen seuranta ja hoito osastolla Osallistujat Kätilö, sairaanhoitaja, lastenhoitaja, lääkäri Tehtävät 3.1 Äidin palautumisen seuranta ja hoito 3.2 Opastus lapsen hoitoon 3.3 Lapsen seuranta ja hoito 122

123 Osa 2: prosessien ja palvelujen määrittely ja suunnittelu 3.1 Äidin palautumisen seuranta ja hoito Tavoite Osastolla seurataan Anna äidin yleisvointia ja toipumista synnytyksestä Osallistujat Kätilö, sairaanhoitaja, tarvittaessa lääkäri Tehtävät Kohdun supistumisen seuranta Kohdun supistumista seurataan vatsan päältä kokeilemalla päivittäin. Huomiot kirjataan hoitokertomukseen. Tarvittavat tiedot Tuotettavat tiedot Jälkivuodon määrän seuranta Jälkivuodon määrää tarkkaillaan päivittäin. Huomiot kirjataan hoitokertomukseen Välilihan haavan parantumisen seuranta Välilihan paraneminen tarkistetaan päivittäin. Kirjataan hoitokertomukseen Veren hemoglobiinin mittaaminen Tarvittaessa tarkistetaan hemoglobiini, jos synnytyksen aikainen vuoto tai jälkivuoto runsasta. Kirjataan hoitokertomukseen Virtsan valkuaisen ja sokerin tarkastus Tarvittaessa (esim. kohonneet sokeriarvot raskausaikana tai verenpainearvot koholla) tarkistetaan virtsanäytteestä sokeri ja valkuaiset. Kirjataan hoitokertomukseen Äidin mielialan ja väsymyksen seuranta Seurataan äidin mielialaa ja jaksamista keskustelemalla ja tarkkailemalla äitiä. Kannustetaan ja tuetaan vuorovaikutusta lapsen kanssa, puolison ja mahdollisten sisarusten kanssa, jos tarpeen. Huomiot kirjataan hoitokertomukseen Verenpaineen seuranta Tarvittaessa verenpaineen seuranta, jos raskausaikana kohonneet verenpainearvot tai äidillä on perussairaus, jossa verenpaineen nousu mahdollista. Kirjataan hoitokertomukseen. Esitiedot, synnytyskertomus Hoitokertomukseen kliinisten muutosten ja arvojen kirjaus sekä ohjauksen ja tuen tarve ja määrä. 3.2 Opastus lapsen hoitoon Osallistujat Tehtävät Tuotettavat tiedot Kätilö, sairaanhoitaja, lastenhoitaja Lapsen imettämisen opastus äidille Opastetaan erilaisia syöttöasentoja, vauvan oikea asento, imuote rinnasta, vauvan ohjailu imemään, rintojen hoito, maidon lypsämien. Kirjataan ohjaus ja huomiot äidin hoitokertomukseen Lapsen hoidon (mm. kylvettämisen) opastus äidille ja isälle Opastetaan äitiä ja isää vauvan kylvetyksessä, vaipan vaihdossa, ihon ja navan hoidossa pukemisessa ja kapaloinnissa. Opastetaan vauvan käsittelyssä turvallisiin otteisiin, oikea pään ja vartalon tukeminen hoitotoimissa. Vauvan ruokkimisen opastus myös isälle (esim. mikäli äidin oma maito ei riitä - imetys ensisijainen ruokinta). Opastetaan sylihoito tai ns. kenguruhoito ja läheisyyden merkitystä. Kirjataan hoitokertomukseen. Hoitokertomukseen tiedot ohjauksesta, neuvonnasta ja kuinka vanhemmat ovat oppineet. 123

124 Palveluarkkitehtuurin soveltaminen terveydenhuollossa 3.3 Lapsen seuranta ja hoito Osallistujat Kätilö, sairaanhoitaja, lastenhoitaja Tehtävät Lapsen kasvun seuranta Painon ja pituuden seuranta sekä päänympärysmitan tarkistus. Kirjaus lapsen hoitokertomukseen. Tuotettavat tiedot Tekojen ja välineiden taso Lapsen imetyksen seuranta Seurataan kuinka lapsi osaa imeä ja millaisia "apukeinoja" tarvitaan. Kirjaus hoitokertomukseen Lapsen voinnin seuranta Lapsen ihon kunto ja väri, navan kuivumisen seuranta, lapsen reagointi käsittelyyn, kylpyyn ja pukemiseen, itkun seuranta, motoriikka, jäntevyys, päälakiaukile. Kirjataan lapsen hoitokertomukseen Rokotus alkaen rokotetaan vain ne vastasyntyneet, joilla on lisääntynyt riski sairastua tuberkuloosiin. Riski arvioidaan äitiysneuvolassa, jossa terveydenhoitaja haastattelee äitiä raskausaikana. Edelleen on tärkeää rokottaa ne lapset, joilla on suurentunut riski saada tartunta.(ktl:n ohje) Lapsen hoitokertomus lapsen kasvusta, hoidosta ja voinnista. Tämän tason tarkastelun esimerkkikohteena on synnytysprosessin vastaanotto-päävaiheen (kohta 1 prosessissa) haastattelu-toiminnon (kohta 1.1 prosessissa) ennakkotietojen tarkastus ja täydennys - tehtävä (kohta 1.1.1). Kyseisestä tehtävästä on tunnistettu viisi käyttötapausta: Ennakkotietojen haku Ennakkotietojen muokkaaminen Synnytyskertomuksen aloitus Tulosyyn kirjaaminen Synnytykseen liittyvien toiveiden kirjaaminen Näistä on kuvattu esimerkin vuoksi kohta , Ennakkotietojen haku: Ennakkotietojen haku Tarve Ennakkotietojen tarkastus ja täydennys Osallistujat Kätilö Tuloehdot Äiti on saapunut vastaanottoon. Kuvaus Kätilö kysyy tai selvittää äidin henkilötunnuksen. Henkilötunnuksen perusteella kätilö hakee tietojärjestelmästä äidin neuvolassa antamat ennakkotiedot käsiteltäväksi (tietojen tarkastus, raskauteen liittyvien riskitietojen varmistaminen tarvittaessa, ennakkotietojen täydennys). Poikkeukset Ennakkotietoja ei löydy. Lopputulos Ennakkotiedot ovat luettavassa ja muokattavassa muodossa kätilön käytössä. Muut vaatimukset - 124

125 Osa 2: prosessien ja palvelujen määrittely ja suunnittelu Jäljitettävyys säilyy siis aina yleiskuvatason prosessikuvauksista käyttötapauksiin asti otsikkonumerointien avulla. Käyttötapaustasolta voidaan jäljitysketjua jatkaa järjestelmien tunnistamiseen asti, jolloin voidaan osoittaa tietyn järjestelmän tarve takaisinpäin mille tahansa prosessin tasolle. Ennakkotietojen haku -esimerkistä voidaan tunnistaa sellaisen järjestelmän tarve, josta saadaan äidin neuvolassa syöttämät ennakkotiedot. Ko. järjestelmä voi olla sairaalan oma järjestelmä, johon tiedot on siirretty esim. eräajona neuvolan järjestelmistä, tai tarvittava järjestelmä voi yhtä hyvin olla neuvolan järjestelmä, joka tarjoaa vastaanoton tietojärjestelmän käytettäväksi tietojenhakupalvelun web services -rajapinnan kautta Äitiyshuollon prosesseihin liittyvät tietojärjestelmät Äitiyshuollon toimintaympäristössä käytetään runsaasti sekä erityis- että yleisohjelmistoja. Näiden sovellusten linkityksiä edellisissä luvuissa kuvattuihin malleihin ja kuvauksiin ei ole eritelty mallinnuksen yhteydessä. Ne kuitenkin tarjoavat pääosan kuvauksissa käsitellystä toiminnallisuudesta ja tallentavat suurimman osan kuvatuista tiedoista äitiyshuollon toiminnassa. Erityisesti erikoissairaanhoidon osuuteen äitiyshuollon palveluketjuista on koottu tietoa käytössä olevista ja kehitettävistä ohjelmista. Eri organisaatioissa on useita erikoistuneita sovelluksia esimerkiksi äitiyspoliklinikan ja synnytystoimintaa varten (esim. Haikara, i-pana, Mama). Lisäksi osin samoja tietoja kuin äitiys- ja synnytyskertomuksissa talletetaan yleisiin potilaskertomusohjelmistoihin (esim. MD-Miranda, Effica). Yleinen potilashallinto liittyy myös neuvola-, äitiyspoliklinikka- ja synnytystoimintaan, kuten myös niissä käytetyt ohjelmistot, esimerkiksi ajanvaraus- ja potilashallinto-ohjelmistot (Musti, MD-Oberon, Effica, Pegasos). Äitiyshuoltoon liittyy joukko erillisohjelmistoja esimerkiksi hoitajakutsuihin (Miratel), synnytyssalien keskusvalvomo-ohjelmisto, ultraääniohjelmisto (Nyytti), kuvantamisen ohjelmistoja (RADU, CRIS), laboratorioiden ohjelmistoja (esim. Multilab 2), ohjelmistoja erilaisten tilausten tekemiseen, hoito-ohjeiden sekä potilasohjeiden ja viestinnän tukemiseen sekä toimenpiteiden tilastointiin. Osaa näistä ohjelmistoista käytetään äitiyshuoltoa laajemminkin. Äitiyshuollon mallinnusesimerkeissä ei yhdistetty toimintoja tai tietojoukkoja erikseen mihinkään järjestelmään. Käytännössä etenkin äitiyshuollon prosessin rajapinnat esimerkiksi perusterveydenhuollon ja erikoissairaanhoidon välillä, prosessissa laboratorioista tai muista tutkimusyksiköistä tarvittavat tutkimukset, äitiys- ja synnytyskertomuksen suhde potilaskertomukseen ja niihin liittyvät ohjelmistot sekä yleisesti tarvittavat palvelut kuten ajanvaraus ovat selkeitä ehdokkaita sovelluspalveluille. Niihin liittyen on myös havaittavissa päällekkäisyyksiä sekä muita tiedonvälityksen kehittämistarpeita (esimerkiksi esitietojen saatavuus). Runsaasti mallinnetusta aihealueesta huolimatta kehitystarpeita ja erillisten sovellusten integrointityötä näyttää vielä olevan runsaasti jäljellä. 4.4 Yhteenvetoa endoskopia- ja äitiyshuolto -esimerkeistä Endoskopian ja mallinnusesimerkkiä on tehty huolellisesti. Mallintaminen on ollut työlästä, mutta on myös tuottanut tarkkaa tietoa, joka on hyödynnettävissä, mikäli ratkaisujen suunnittelua ja toteuttamista varten halutaan kuvata tarkasti tuettavaa toimintaa. Tältä kannalta katsoen etenkin endoskopian osalta on ollut vaikea nähdä mitään, mitä olisi voinut jättää pois. Tarkan mallintamisen johdosta jäljitettävyys tasolta toiselle säilyy hyvin. Endoskopia-prosessista vain yksi osa (esitiedot) on esimerkinomaisesti mallinnettu pikkutarkasti. Mallinnustyö vaatii alussa opettelua, mutta nopeutuu, kun mallinnusprosessin ja annettujen työvälineiden (esim. taulukot, prosessin vaiheet, välineet) käyttö rutinoituu. 125

126 Palveluarkkitehtuurin soveltaminen terveydenhuollossa Endoskopian prosessikuvaukset on tehty melko tarkalla tasolla, eikä yleistämistä ole suoritettu niin laajasti kuin mahdollista. Lisäyleistäminen ja samojen palvelujen ja osaprosessien käyttö muissa prosesseissa helpottaisi uudelleenkäyttöä ja ydinpalvelujen ja -prosessien tunnistamista. Erityisesti kannattaa kuitenkin huomioida, että tekojen ja välineiden tarkkuustasolla useimmat käyttötapauskuvaukset ovat yleiskäyttöisiä ja voisivat olla osana monissa eri prosesseissa. Voidaan myös havaita, että ylemmällä toimintojen tasolla käsitellään jo hyvinkin endoskopia-spesifejä seikkoja. Tästä huolimatta sieltäkin on selvästi tunnistettavissa yleistettäviä prosessien osia. On selvää, että esimerkiksi endoskopian kaikkien teot ja välineet -tason käyttötapausten tekeminen yhteen kaavioon tekee siitä jo liian yksityiskohtaisen. Käytännössä on järkevää ja ymmärtämistä helpottavaa tehdä mallinnusta tasoittain ja käyttää tarkimmilla tasoilla useita kaavioita. Valmiiden taulukkopohjien käyttö eri mallinnustasoilla antaa mallintamiseen rakennetta, jolloin tarvittavat asiat tulevat järjestelmällisesti kuvattua ja selvitettyä. Yhteenvetona endoskopiamallinnuksen esimerkistä voidaan todeta, että käytetyillä kuvaustavoilla on saatu aikaan tarkkoja kuvauksia ja hyvä jäljitettävyys eri kuvaustasojen välillä, mutta mallinnus on ollut työlästä. Äitiyshuolto on mallinnettavana kohteena vielä laajempi kuin endoskopia. Jotta kuvaaminen olisi mahdollista ilman kohtuutonta työmäärää, on rajaukset mietittävä tarkoin; mitä kuvataan tarkasti, mitä yleisemmällä tasolla ja mitä ei lainkaan. Kaikkea ei voi kuvata täydellisesti. Osa yksityiskohdista on kuvattava vain esimerkkien kautta. Äitiyshuollon mallinnusesimerkissä saatiin kuvattua yleiskuva ja valittujen prosessien vaiheita ja tehtäviä melko tarkalla tasolla, mutta mallinnukseen ja sovelluspalvelujen tunnistamiseen ei ehditty pureutua riittävästi. Vaikka äitiyshuollosta on saatavilla paljon pohjamateriaalia äitiyshuolto on yksi parhaiten mallinnettuja terveydenhuollon osa-alueita on prosessikuvausten teossa ehdottomasti oltava mukana kohdealuetta tuntevia ihmisiä, jotka tuntevat hyvin mallinnettavan kohteen ja esimerkiksi ovat siihen liittyvissä tehtävissä (esimerkiksi yleinen terveydenhuollon organisaatioiden tuntemus ei riitä). Sama pätee yleisesti mallinnuksessa sekä prosessien että tietojen ja toimintojen osalta. Mallinnusesimerkeissä prosessienmallinnusmenetelmä on korostunut: itse prosessimallin lisäksi kehittämisen kohteena on ollut mallinnusmenetelmä. SerAPI-hankkeen esimerkeissä mallinnuksen oikeellisuuden tarkastamista ei voitu tehdä niin paljon kuin olisi ollut suotavaa. Ongelmana mallinnuksessa on ollut myös nyky- ja tavoitetilan erottaminen toisistaan. Osaltaan myös tähän vaikutti asiantuntijoiden puute mallinnusprosessissa. Endoskopian esimerkissä on päästy sovelluspalvelujen tunnistamiseen asti, mutta ei vielä tarkempiin määrittelyihin. Äitiyshuollon osalta yleiskuva ja useita tarkempia tasoja on mallinnettu suhteellisen tarkasti toiminnalliselle tasolle, mutta palvelumäärittelyjä ei ole tehty. On huomioitava, että osin vastaavia mallinnusmenetelmiä ja kuvaustapoja on käytetty myös SerAPI-hankkeen rajapintakohteiden määrittelyn alkuvaiheessa. Esimerkiksi ajanvarausrajapintojen vaatimukset ja rajaukset -vaiheessa (Tuomainen ym. 2005) on tehty toimintatarinoita ajanvarauksesta perusterveydenhuollon ja erikoissairaanhoidon välillä, moniajanvarauksesta, call center:in kautta tehtävästä ajanvarauksesta sekä asiakkaan oma-ajanvarauksesta. Määrittelyissä käytettiin myös käyttötapaus- ja toimintokuvauksia. Tarkemmissa ratkaisumäärittelyissä kuvattiin UML:n aktiviteettikaavioilla käyttäjän ja ajanvarauspalvelun vuorovaikutusta. Tämä kuvaustapa on lähellä teot ja välineet -tason kuvauksia tässä dokumentissa. Nämä vaatimuslähtöiset ylhäältä alas -mallit oli yhdistettävä standardeissa esitettyihin (osin samantyyppisiin) malleihin, kun hyödynnettäväksi standardiksi valittiin HL7 versio 3, jonka mallipohjaisessa lähestymistavassa myös käytetään toimintatarinoita ja vuorovaikutusten mallintamista (ks. myös luku 5). Prosessien kuvaukseen on lähes 126

127 Osa 2: prosessien ja palvelujen määrittely ja suunnittelu yhtä monta tapaa kuin on tekijääkin - tai työkalua. Tärkeintä on valita käyttötarkoitukseen soveltuva tapa. Yksiselitteistä, joka tilanteeseen sopivaa ratkaisua ei voida tarjota. Tarkat kuvaukset prosessien ja toimintojen sisäisestä toiminnasta eivät intuitiivisesti ajatellen anna "juurikin tarvittavaa" tietoja prosessien eri vaiheiden välisiin ja tietojärjestelmien rajapintoihin: toiminnan yksityiskohtainen kuvaaminen tuottaa "turhaa" tietoa, jolla ei ole merkitystä yleistetyissä toimintaprosesseissa, joita palveluarkkitehtuurissa tavoitellaan. Totuus ei kuitenkaan ole aivan näin mustavalkoinen. Toiminnan tarkan kuvauksen avulla saadaan selville varsinkin tarvittavien tietojen määrittelyyn ja ratkaisujen käytettävyyteen liittyviä vaatimuksia, joiden kuvaaminen on tarpeellista ratkaisujen toimivuuden ja hyväksynnän varmistamiseksi. Pelkkä prosessin vaiheiden ja sovelluspalvelujen sekä niiden toimintojen tunnistaminen ei riitä tarkkoihin ratkaisuihin. Lisäksi tarkat kuvaukset ja "vertikaaliset", yhden toimijan toimintaan keskittyvät kuvaukset (horisontaalisen prosessin etenemisen lisäksi) voivat paljastaa merkittäviä pullonkauloja tai kehittämiskohteita. Myös jotkin kokemukset SerAPI-hankkeen selkeistä rajapintakohteista (esimerkiksi Ajanvaraus) tukevat tätä havaintoa: toiminnan kehittämiseksi on tarpeen paljastaa tiettyjä palvelun tarjoajan "sisäisiin vastuisiin" ensi näkemältä kuuluvia seikkoja, esimerkiksi ajanvarausrajapintoihin liitettävät "ohjaustiedot" helpottavat merkittävästi tarkempien palvelujen tarjoamista käyttäjälle ajanvarausrajapintojen kautta. On siis välttämättä valittava tarkkuustaso, jolle mallinnusta viedään. Yleistäminen ja abstraktiotason nosto on välttämätöntä SOA-hyötyjen (mm. uudelleenkäyttö) saavuttamiseksi. SerAPI-hankkeen mallinnuskokemusten perusteella yleiskäyttöisiä ratkaisuja voidaan mallintaa selvästi ainakin prosessin päävaiheiden ja toimijoiden rajapinnoissa sekä toiminnan kuvauksen kohtuullisen tarkalla kuvaustasolla, jossa suoritettavat "prosessinpätkät" toistuvat samanlaisina monissa erityyppisissä työnkuluissa. Molemmissa tilanteissa erityisvaatimusten huomiointi voi kuitenkin helposti kasvattaa joko määriteltäviä tietojen massaa tai luoda tarpeita palvelujen tapauskohtaiseen "profilointiin" monien seikkojen suhteen. 127

128 Palveluarkkitehtuurin soveltaminen terveydenhuollossa 5 Mallikeskeisten kehitysmenetelmien arviointi Palveluarkkitehtuurin kehittämisessä hyödynnetään laajalti mallipohjaisia lähestymistapoja, kuten prosessimallinnusta ja UML-mallinnusta. SerAPI-hankkeessa vertailtiin mallipohjaisia lähestymistapoja terveydenhuollon tietojärjestelmien kehitykseen projektissa tehtyjen selvitysten ja SerAPI- ja PlugIT-hankkeissa mallipohjaisista määrittelystä saatujen kokemusten pohjalta. Vertailussa käytettiin lisäksi pohjana ZipIT-hankkeen kanssa yhteistyössä tuotettuja suosituksia ja lähestymistapaa (Mykkänen ym. 2006; kuva 38), joilla pyritään parantamaan vaatimusten jäljitettävyyttä tietojärjestelmien kehityksen eri vaiheissa ja vähentämään välimatkaa ohjelmistokehityksen ja toiminnallisten käyttäjävaatimusten välillä. Kuva 38. Esimerkki jäljitettävyyttä tukevasta mallinnusketjusta (Mykkänen ym. 2006). Osana jäljitettävyyteen ja vaatimusten kuvaukseen liittyvää tutkimusta havaittiin, että eri mallinnusmenetelmien ja -notaatioiden tarkempi arviointi ja toisiaan täydentävien kuvaustapojen valinta ketjun eri vaiheisiin etenkin käsiteltävän tiedon osalta oli tarpeen. Lisäksi tarvittiin vaatimusten entistä tarkempaa dokumentointia sekä esimerkiksi käyttöliittymäkuvien hyödyntämistä yhteisen ymmärryksen luomisessa jäljitettävyyden parantamiseen. Mallipohjaisten kehitysmenetelmien vertailuun koottiin arviointikehikko, jossa otettiin huomioon (edellä mainitut jäljitettävyyteen liittyvät seikat mukana): lähestymistavan pääasialliset käyttökohteet, se, mitä malleja voidaan käyttää tietojärjestelmäkehityksen eri vaiheissa (kohdealueen kuvaus, vaatimusmäärittelyt, ratkaisun suunnittelu, ratkaisun kehittäminen, ohjelmisto käytössä), se, kuinka kattavasti menetelmä ottaa huomioon tietojärjestelmien eri osa-alueet (Iivari 1994) kehityksen eri vaiheissa: rakenne (mitä käsitteitä, tietokokonaisuuksia ja entiteettejä tietojärjestelmä sisältää), toiminnot (mitä tehtäviä suoritetaan) ja käyttäytyminen (koska ja millaisia vuorovaikutuksia käyttäen tehtävät suoritetaan). erityishuomiointi sille, kuinka semanttiset elementit ja terveydenhuollon tieto ja tietämys kuvataan, kuinka lähestymistavassa huomioidaan ratkaisujen havainnollistaminen käyttäjille jo suunnitteluprosessin alkuvaiheessa, 128

129 Osa 2: prosessien ja palvelujen määrittely ja suunnittelu kuinka lähestymistapa tukee tarkkojen, yhdenmukaisten, atomisten ja yksiselitteisten vaatimusten esittämistä ja dokumentointia, jolla saavutetaan yhdenmukainen käsitys tavoitteista ja saadaan nostettua esiin piilotettua tietämystä, kuinka tarkasti lähestymistapa määrittelee käytettävät menetelmät, lähestymistavat ja notaatiot (definitiivisyys), ja kuinka paljon tarvitaan projektikohtaisia menetelmien ja osaratkaisujen tarkennuksia, miten lähestymistapa ohjaa eri abstraktiotasojen esittämiseen, kuinka loppukäyttäjät tai prosessien osapuolet näkyvät tuotettavissa malleissa, kuinka mallien, vaiheiden ja abstraktiotasojen välisiä muunnoksia tehdään ja onko muunnosten automatisointiin välineitä, (jäljitettävyys ja tuottavuus), kuinka laajasti lähestymistapaa on käytetty ja millaisissa yhteyksissä. Mallipohjaisten lähestymistapojen vertailuun otettiin mukaan kolme hyvin erilaista mallikeskeistä ohjelmistokehityksen ja -integraation lähestymistapaa: OMG:n Model-Driven Artchitecture, prosessimallinnus käyttäen BPMN- ja BPEL-mallinnuskieliä sekä HL7 Development Framework. Kustakin lähestymistavasta tuotettiin selvitys (MDA- ja HDF-malleista on kuvauksia myös lähteessä Mykkänen ym. 2004), vertailua tuotettiin useissa työkokouksissa ja tarkennettiin myös konferenssijulkaisua varten. Vertailua varten käytiin varsinaisten lähestymistavan määrittelydokumenttien lisäksi useita esimerkkejä lähestymistavan käytöstä mm. konferenssien ja kirjallisuuden pohjalta. Kutakin menetelmään on välinekokeilujen lisäksi käytetty eri tavoin projekteissa: MDA on muodostanut pohjan yleisen integrointimenetelmän kehittämiselle (mm. Mykkänen 2007a) ja Healthcare Services Specification Project-hankkeen kehitysmenetelmälle. HDF-menetelmää on hyödynnetty mm. SerAPI:n ajanvarausrajapintojen kehittämisessä, ja BPMN-kuvauksia luvun 4 prosessikuvausesimerkeissä. On huomioitava, että tarkastelu keskittyi mallinnusketjun alkuvaiheisiin, ja että vaatimusvaiheen jälkeen ei aina edetä toteutukseen vaan kyseeseen voi tulla myös valmiin järjestelmän tai komponentin hankinta. Seuraavissa aliluvuissa esitetään lyhyt kuvaus vertailtujen mallipohjaisten lähestymistapojen pääseikoista ja arvioinnin tuloksista. 5.1 Model-Driven Architecture (MDA) Model-Driven Architecture (MDA) on OMG:n kehittämä mallikeskeinen lähestymistapa ohjelmistojen suunnitteluun ja kuvaamiseen. MDA:ta käytetään yleensä UML-kaavioiden kanssa. MDA:n abstraktiotasot erottavat toisistaan järjestelmien loogiset ja tekniset ratkaisut kolmeen mallinnustasoon: laskentariippumaton malli (computation independent, CIM), alustariippumaton malli (platform independent, PIM) ja alustakohtainen malli (platform specific, PSM). MDA pyrkii ratkaisujen siirrettävyyteen eri alustoille alustakohtaisen mallin erottamisella alustariippumattomista ratkaisuista. Muita MDA:n päätavoitteita ovat yhteentoimivuus ja uudelleenkäyttö arkkitehtuurissa tapahtuvan ratkaisun eri aspektien erottamisen avulla. Mallien välistä jäljitettävyyttä ja kehitystyön tuottavuutta pyritään parantamaan mallien välisiä muunnoksia automatisoimalla (ks. kuva 39), mukaan lukien suoritettavan koodin tuottaminen alustakohtaisista malleista. 129

130 Palveluarkkitehtuurin soveltaminen terveydenhuollossa PSM Koodi CIM PIM PSM Koodi PSM Koodi Kuva 39. MDA:n mallien väliset muunnokset ja koodin generointi. MDA:n laskentariippumattomien mallien (CIM) avulla mallinnetaan toimintaprosessit ilman tietoteknisiä ominaisuuksia, järjestelmien pääkäsitteet ja toimintaympäristö (Miller & Mukerji 2003). Järjestelmän rakennetta ei määritellä CIM-tason malleissa. CIM-tason UML-mallien avulla kuvataan sovellusaluetta ja järjestelmän vaatimuksia. Laskentariippumattomia malleja pyritään erityisesti käyttämään järjestelmän kohdealueen asiantuntijoiden ja käyttäjien tarpeiden ja vaatimusten kuvaamisessa. CIM-tason malleilla kuvataan ratkaistavia ongelmia ja tarpeita, mutta ne muodostavat myös yhteisen sanaston, jota voidaan käyttää tarkemmissa ratkaisumalleissa. Alustariippumaton malli (PIM) kuvaa järjestelmän siten, että siinä ei ole mukana järjestelmän alustasta tai toteutustekniikasta riippuvia yksityiskohtia. Alustariippumattoman tason mallit kuvaavat yleisesti organisaation toimintaa ja järjestelmän tietoja ja toimintoja. Alustariippumaton malli voi kuvata yhden tai useamman arkkitehtuurityylin ratkaisuja. Alustakohtainen malli (PSM) tuotetaan muuntamalla alustariippumatonta mallia. Tällöin yhdistetään alustariippumattomaan PIM-malliin toteutusalustan tai -tekniikoiden ominaisuuksia (Miller & Mukerji 2003). Alustakohtaisissa malleissa kuvataan, kuinka alustariippumattoman mallin toteutus tarkennetaan tietylle alustalle. PIM- ja PSM-mallien välisiä muunnoksia voidaan myös toistaa: kukin uusi alusta tuottaa uusia ominaisuuksia toteutuksiin. Näin voidaan siis itse asiassa toteuttaa useita tasoja PIM- ja PSM-kuvauksia, ja yhdessä järjestelmässä voi olla useita erilaisia "alustoja" (platform). MDA-määrittelyissä laskentariippumattoman mallin vaatimusten tulisi olla kaksisuuntaisesti jäljitettävissä alustariippumattoman ja alustakohtaisen mallin ratkaisuihin. MDA-välineet voivat myös muuntaa alustariippumattoman mallin suoraan suoritettavaksi koodiksi, näyttämällä alustakohtaista mallia käyttäjälle. Tämä vaatii kuitenkin tarkalla tasolla tiettyyn arkkitehtuurityyliin kuvattuja PIMmalleja tai monia välinekohtaisia oletuksia. Käytännössä MDA:n käyttö vaatii tarkkoja tulkintoja, joita ei ole valmiina MDA-määrityksissä. Tässä arvioinnissa on käytetty MDA toolkit-lähestymistapaa (Fado 2004), joka tarkentaa tapaa, jolla eri UML-malleja käytetään CIM-, PIM- ja PSM-tasoilla sekä ohjelmistokehitysprosessin eri vaiheissa. 130

131 Osa 2: prosessien ja palvelujen määrittely ja suunnittelu 5.2 Prosessien mallinnus BPMN- ja BPEL-kielten avulla Business Process Modeling Notation (BPMN) (BPMN 2006; Paakkanen 2007) graafinen notaatio prosessien kuvaamiseen. Sen tavoitteena on olla erilaisten käyttäjien ymmärrettävissä, aina liiketoiminnan suunnittelijoista ohjelmistokehittäjiin ja ihmisiin, jotka hallinnoivat ja tarkkailevat liiketoimintaprosesseja. On kolmentyyppisiä BPMN-prosessikaavioita. Private process eli yksityinen prosessi kuvaa yhden organisaation sisällä tapahtuvan tarkan työnkulun. Tämäntyyppinen kuvaus voidaan mäpätä BPEL4WS-kieleen, suoritettavaksi prosessikuvaukseksi. Public process eli julkinen prosessi kuvaa interaktiot ja viestit yksityisten prosessien välillä ja toisten osapuolien kanssa. Prosessi esittää viestinvaihtoon liittyvät aktiviteetit ja prosessin etenemisen ohjaukseen liittyvän toiminnallisuuden. Collaboration process eli yhteistoimintaprosessi kuvaa kahden tai useamman julkisen prosessin (liiketoimintakokonaisuuden) väliset interaktiot. Tämäntyyppinen kuvaus voidaan mahdollisesti mäpätä sähköisen liiketoiminnan tarpeisiin tehtyihin yhteistoimintaprotokolliin kuten ebxml tai RosettaNet. BPMN-kaavioiden kuvausvoimaa voidaan laajentaa käyttämällä BPMN-artifakteja, jotka tarjoavat lisätietoa kuvattavaa prosessia koskien. Artifakteilla voidaan kuvata esim. erityisalakohtaisia erityispiirteitä, jos BPMN-kielen perusrakennuspalikat eivät tarjoa riittäviä ominaisuuksia. Vaikka graafinen puoli on BPMN:n näkyvin ja merkittävin osa, sen ei-graafiset osat ovat yhtä tärkeitä, kun ryhdytään mäppäämään BPMN-kuvauksia tarkempiin, suoritettaviin kieliin, kuten BPEL4WS (ks. alla). Business Process Execution Language for Web Services (BPEL4WS) (Thatte 2006, Andrews ym. 2003) on XML-pohjainen liiketoimintaprosessien ja yhteistoimintaprotokollien kuvaamiseen tarkoitettu kieli. Kielellä voidaan määritellä joko suorituskelpoisia, yksityiskohtaisia prosessikuvauksia tai abstrakteja, tarkkoja yksityiskohtia pois jättäviä yleisempiä kuvauksia. Kielellä ei ole määriteltyä graafista notaatiota, joten kukin välinetoimittaja on tehnyt oman näkemyksensä mukaisen graafisen esitystavan XML-muotoisen kielen ominaisuuksista. BPEL4WS on nimitys BPEL-standardin epävirallisesta versiosta 1.1. OASIS-järjestön ajamana standardista on julkaistu versio 2.0, joka on virallisen standardin asemassa. Versio 2.0 kantaa virallista lyhennettä WS-BPEL (Web Services Business Process Execution Language). BPMN-määrittelyssä on kuvattu mäppäys BPEL4WSkieleen. Tämä mahdollistaa asteittaisen etenemisen prosessikuvauksissa BPMN-tasolta (korkeampi abstraktiotaso) BPEL4WS-tasolle (matalampi abstraktiotaso, prosessien automatisointi ja suorittaminen työnkulkumoottoreissa). Mäppäystä BPMN:stä WS-BPELiin ei ole määritelty vielä. BPEL-mallinnuksella pyritään tukemaan prosessien automatisoitua suoritusta. BPEL-muotoinen prosessikuvaus esittää prosessin yhden osapuolen näkökulmasta. Prosessin hyödyntämät ulkopuoliset sovelluspalvelut (tai partnerit, kuten BPELissä niitä kutsutaan) kuvataan WSDLrajapintakuvauksena. BPEL-prosessi itsessäänkin näkyy ulkopuolisille tarkastelijoille WSDLrajapinnan kautta kutsuttavana sovelluspalveluna. BPMN sinällään on yleiskäyttöinen prosessien kuvausnotaatio, mutta yhdistettynä BPEL:in käyttöön niitä on yhteisesti erityisesti nostettu esiin web-sovelluspalveluista koostettujen prosessien kuvaamisessa ja määrittelyssä. 131

132 Palveluarkkitehtuurin soveltaminen terveydenhuollossa 5.3 HL7 Development Framework HL7 Development Framework Methodology Specification (HDF) on lähestymistapa HL7 versio 3 -standardien kehittämiseen (HL7 2006, Mykkänen ym. 2004). Sen avulla analysoidaan, suunnitellaan ja dokumentoidaan HL7 versio 3 -ratkaisuihin liittyviä prosesseja, toimijoita, tietoja ja sääntöjä. Lähestymistapa pohjautuu mallien käyttöön ja määritysten tarkentamiseen yhteisten viitemallien pohjalta. HDF on aiemman MDF-menetelmän (Message Development Framework) seuraaja. Tärkeä perusta HL7 versiolle 3 ja HDF-menetelmälle on Reference Information Model (RIM). Kaikki HL7 version 3 tietomallit perustuvat RIM-malliin. Lisäksi tietomäärittelyjä tuetaan rakenteisten sanastojen (vocabulary) ja käytettävien termien määrittelyn (glossary) avulla. RIM-malli on kuvattu UML-luokkakaaviona. Lisäksi HDF:n useissa muissa malleissa hyödynnetään suoraan joitakin UML-kaaviotyyppejä. HDF:ään liittyen on määritelty UML:n metamalliin laajennuksia, joiden avulla tuotetaan mm. tarkempien tietomallien kuvauksia. HDF:n avulla on tuotettu runsaasti eri määrittelyalueiden (domains) määrittelyjä HL7 versio 3 -paketissa. HDF:ää on kuitenkin kehitetty jatkuvasti eteenpäin, joten esim. eritasoisten mallien nimissä on eroja äänestyspaketin eri osissa. HDF (toisin kuin MDA ja BPMN) sisältää myös kehitysmenetelmän, jossa on seitsemän vaihetta: projektin aloitus, vaatimusten analysointi ja dokumentointi, määrityksen mallinnus, määrityksen dokumentointi, määrityksen julkaisu, määrityksen hyväksyminen ja standardin profilointi. Tähän arviointiin liittyvät läheisimmin vaatimus-, määrityksen dokumentointi- ja standardin profilointi -vaiheet. Useita erilaisia kaaviotyyppejä ja suunnittelu- ja dokumentointivälineitä hyödynnetään eri vaiheissa. Vaatimusvaihe tuottaa kuvauksia terveydenhuollon jostain osa-alueesta pyrkien käyttämään terveydenhuollon terminologiaa. Tässä vaiheessa toimintaprosesseja kuvataan mm. käyttötarinoiden (storyboards), käyttötapausten ja aktiviteettikaavioiden avulla. Lisäksi käytetään mm. taulukkolaskentaohjelmistoja ja UML:n luokkakaavioita. Toimintasääntöjä kuvataan mm. suhteiden, liipaisintapahtumien (triggers), tietojen vaihdon rajoitteiden, sekä tilakaavioiden avulla. Sovellusalueen kuvauksia kootaan DAM-malleiksi (Domain Analysis Model). Sovellusalueiden DAM-malleja ja sanastoja kehittävät toiminnan ja toimialan asiantuntijat, ja niitä käyttävät tekniset asiantuntijat HL7 versio 3 -viestien määrittelyyn. Määrittelyvaiheessa (specification modeling) viitemalleja tarkennetaan asettamalla niihin rajoitteita ja tuottaen suunnittelutason malleja. Tällä tasolla tuotettuja malleja voidaan viedä standardiäänestyksiin. Keskeiset suunnittelun tietomallit ovat toimialueen tietomalli (Domain Information Model DIM, aiemmin Domain Message Information Model DMIM), rajoitettu tietomalli (Constrained Information Model CIM, aiemmin Refined Message Information Model RMIM), ja serialisoitu rajoitettu tietomalli (aiemmin Hierarchical Message Description HMD). Lisäksi käytetään mm. UML:n sekvenssi- ja yhteistoimintakaavioita eri interaktioiden ja sovellusroolien kuvaamiseen ja liittämiseen sanomamäärittelyihin. Suunnittelussa kiinnitetään myös huomiota mallien uudelleenkäyttöön (mm. CMET, Common Message Element Types) ja harmonisointiin RIM-mallin kanssa. Standardien profilointivaiheessa julkaistua standardia profiloidaan eli tarkennetaan paikallisten vaatimusten pohjalta. Standardin elementtejä voidaan edelleen kuvata tarkemmin, rajoittaa tai laajentaa tässä vaiheessa. Tarkat ratkaisut siirrettäville tiedoille, vuorovaikutuksille ja esim. viestien vastaanotto- ja kuittauskäytäntöihin määritellään tässä vaiheessa. Profilointivaiheessa standardin sisältämiin malleihin myös sovelletaan toteutustekniikoiden määrityksiä (ITS, Implementation Technology Specification), joilla tuotetaan esimerkiksi XML-skeemamäärittelyjä, joita voidaan hyödyntää sanomien rakentamisessa. Tämä määrittely johtaa soveltamisoppaisiin tai määritysprofiileihin sekä määritysten mukaisuuden määrittelyihin (conformance statements). Lisäksi tässä vaiheessa tuotetaan yleensä ratkaisun käyttäjille suunnattua dokumentaatiota. 132

133 Osa 2: prosessien ja palvelujen määrittely ja suunnittelu 5.4 Arvioinnin tulokset Kuvassa 40 ja taulukossa 12 esitetään päätulokset mallikeskeisten lähestymistapojen arvioinnista (Tuomainen ym. 2007). Kuvassa 40 eri lähestymistapojen mallit ja kuvaukset esitetään suhteessa yleisiin tietojärjestelmien kehittämisprosessin vaiheisiin. Taulukossa 12 käsitellään muita luvun 5 alussa esitetyn arviointikehikon (Mykkänen & Tuomainen 2007) seikkoja. Muita arvioinnissa esiin nousseita asioita käsitellään taulukon jälkeen. Kuva 40. Mallikeskeisten lähestymistapojen mallit ja tuotokset (Tuomainen ym. 2007) MDA on yleiskäyttöinen lähestymistapa mallipohjaiseen ohjelmistojen ja järjestelmien kehittämiseen. Se pyrkii tukemaan kaikkia sovelluskehityksen näkökulmia siirrettävällä tavalla, joka erottaa tekniikan muutokset loogisista ratkaisuista. Arvioinnin muut lähestymistavat voisivat olla, ja osin ovatkin, määriteltävissä MDA:n tarkennuksina. MDA:ta on sovellettu hyvin monilla eri tavoilla, ja MDA:n metatason perustekniikat kuten XMI (XML Metadata Interchange) mallien siirrettävyyteen ja MOF (Meta Object Facility) mallien ja metamallien määrittelyyn, eivät ole pakollisia tai yhdenmukaisesti sovellettuja eri välineissä. Näin ollen ei ole "yhtä oikeaa" MDA-lähestymistapaa, vaan MDA-lähestymistavan soveltaminen riippuu tilanne- ja välinekohtaisista käytännöistä ja tarpeista. MDA:n abstraktiotasoja voidaan hyödyntää monissa tietojärjestelmien kehitysvaiheissa. Prosessimallinnuksessa BPMN:n avulla ei ole mukana kaikkia tietojärjestelmien kehittämisen näkökulmia. BPMN:stä on tarkoituksellisesti jätetty pois mm. organisaatioiden rakenne, toiminnallisuuden tarkempi kuvaus, tietomallit ja strategiset tai toimintasäännöt (BPMN 2006). Käyttäjiin liittyviä seikkoja "käyttäjätehtävien" lisäksi ei BPMN:ssä käsitellä. Toisaalta jos prosessimäärittelyt saadaan esimerkiksi BPEL-työnkulkumoottorien edellyttämälle tarkkuustasolle, voidaan niiden avulla seurata tarkallakin tasolla prosessien etenemistä ja niihin liittyviä toimintoja. Koska käyttäjien toimenpiteitä tarvitaan yleensä osana prosesseja, voidaan prosessimallinnusta täydentää tarvittaessa esimerkiksi käyttöliittymien tai käyttötapausten kuvauksilla. BPMN ja BPEL eivät määrittele prosessia tai menetelmää, jolla malleja tuotetaan. Menetelmällisesti tuottaminen on kuitenkin yksinkertaisempaa kuin esim. MDA:ssa, koska voidaan keskittyä pelkästään prosessien kuvaamiseen. 133