Jani Hyytiäinen
Simuloinnin hyödyntäminen terveyskeskuksen toiminnan kehittämisessä
Diplomityö, joka on jätetty opinnäytteenä tarkastettavaksi diplomi-insinöörin tutkintoa varten
Espoo 31.1.2007
Professori Paul Lillrank Valvoja:
Ohjaaja: Diplomi-insinööri Janne Keskinarkaus
Työn nimi: Simuloinnin hyödyntäminen terveyskeskuksen toiminnan kehittämisessä
Päivämäärä: 31.1.2007 Sivumäärä: 119 + 3 Osasto: Konetekniikan osasto
Professuuri: TU-22 Teollisuustalous Työn valvoja: Professori Paul Lillrank
Työn ohjaaja: Diplomi-insinööri Janne Keskinarkaus
Terveydenhuollon kehittämisprojektit ovat perinteisesti keskittyneet lääketieteelliseen tutkimukseen. Viime vuosina kustannuspaineet ovat johtaneet terveyskeskuspalvelujen kehitysprojekteihin, joiden tavoitteena on palvelujen saatavuuden ja kustannustehokkuuden parantaminen.
Terveydenhuollon potilasvirtaa ohjaavat prosessit eivät teknisesti eroa huomattavasti kappaletavaratuotannon tuotantoprosesseista, joten tuotantotaloudesta tutut menetelmät voivat tietyin rajoituksin toimia myös terveydenhuollossa.
Yksi teollisuudessa käytettävistä tuotannonsuunnittelun työkaluista on tapahtumapohjainen simulointi. Simulointi pyrkii kuvaamaan kokonaista järjestelmää tietokonemallilla, joka ohjelmoidaan toimimaan esikuvansa mukaan.
Simulointi mahdollistaa pienten tekijöiden kokonaisseurausten ja vaikuttavuuden tutkimisen, sekä uusien toimintamallien tai kokonaan uusien järjestelmien toiminnan tutkimisen ilman todelliseen järjestelmään puuttumista.
Tässä diplomityössä tutkitaan miten tapahtumapohjainen simulointi soveltuu suomalaisen terveyskeskuksen toiminnan mallintamiseen, ja miten mallia voidaan käyttää toiminnan kehittämiseen.
Terveyskeskustoiminnan ominaispiirteitä ovat lakisääteiset vaatimukset hoidon järjestämisestä, henkilöresurssipainotteisuus, resurssien korkea koulutustaso sekä kysynnän erilaisuus suhteessa teollisuuteen. Monet näistä tekijöistä asettavat erityisiä vaatimuksia simulointimallien käyttämiseen kehitysprojekteissa.
Esimerkkinä tässä työssä esitellään Hyvinkään terveyskeskuksen simulointiprojekti, jossa mallinnettiin terveyskeskuksen ajanvaraus- sekä päivystysvastaanotot.
Projektissa tutkittiin simuloinnin avulla erilaisten potilasohjausmenetelmien vaikutusta jonotusaikoihin sekä henkilöstön kuormitusvaihteluihin. Lisäksi tutkittiin lääkärien poissaolojen vaikutusta koko järjestelmän toimintaan.
Edellä mainitut erityispiirteet aiheuttivat projektille haasteita, mutta tulosten perusteella voidaan sanoa, että simulointi soveltuu myös terveydenhuollon prosessien mallintamiseen. Projektien läpivienti, lähtötietojen analysointi sekä tulosten perusteella vedettävien johtopäätösten laatiminen vaativat kuitenkin projektiin osallistuvilta perinteisiä projekteja suurempaa tarkkuutta ja osaamista.
Avainsanat: tapahtumapohjainen simulointi,
terveyskeskus, prosessikehitys, potilasvirta Julkaisukieli: suomi
Author: Jani Kristian Hyytiäinen
Title of the thesis: The use of simulation in developing health centre operations
Date: 31 January 2007 Number of pages: 119 + 3 Department: Department of Mechanical Engineering
Professorship: TU-22 Industrial Management Supervisor: Professor Paul Lillrank
Instructor: Janne Keskinarkaus, M.Sc. (Technology)
Development projects in health care industry have traditionally focused on medical issues. In recent years, pressure has been put on patient queuing times, costs, patient flow and process development.
Health care processes are somewhat similar to the processes in the traditional manufacturing industry and production. Thus, it can be assumed, that traditional tools of industrial engineering can be used in health centre process development.
One of these tools is discrete-event simulation. Simulation model depicts a true system as a whole, and is programmed to operate in the same way as the real system. Simulation can be used to model complex systems and the implications of small or sudden changes to the whole system and its outputs. Simulation also allows modelling changes to existing systems or testing systems that do not exist yet, and can therefore help development projects cost-efficiently.
This master’s thesis researches the use of simulation in health centre operational development. The aim is to point out concerns that have to be borne in mind when doing simulation studies in a health centre and to find out how the model can be used to develop its operations.
The Finnish health centre system is characterized by juridical requirements on care availability, the importance of human resources, high professionalism of the resources and the structure and formation of demand different from the one in manufacturing industry. These characteristics pose a great deal of challenge in the simulation projects.
As a case study we discuss a project conducted in the health centre of Hyvinkää, Finland. The scheduling, reception, appointments and the care of urgent patients were modelled. The model was used to examine different patterns of patient care and resource utilization.
The characteristics mentioned above issued some extra work and special care had to be taken to validate the model. The conclusion is that simulation is a capable method to model health centre systems, but these projects demand skilful and thorough professionals to yield valid results.
Keywords: discrete-event simulation, health centre, Publishing language:
process development, patient flow, Finnish
syksyllä 2001 odotin tutustuvan! seuraavien vuosien aikana mekaniikan saloihin. Laivanrakennus-, auto- ja koneenrakennustekniikka olivat alat, jotka tunsin parhaiten osaston tarjonnasta. Jo ensimmäisen vuoden aikana huomasin kuitenkin, että järjestelmien tutkiminen, prosessien virtaviivaistaminen ja tehokkuuden parantaminen olivat puhdasta mekaniikkaa kiinnostavampia aloja. Päällimmäisenä kysymyksenä ei ollutkaan enää ”miten se toimii?” vaan pikemminkin ”miten se valmistetaan, ja miten niitä voitaisiin valmistaa mahdollisimman tehokkaasti?”
Tämä uusi kiinnostuksenala yhdistettynä kauppatieteiden opintoihin johti tuotantotekniikan opiskeluun, ja lopulta simuloinnin kiehtovaan maailmaan.
Lopputuloksena syntyi tämä teos, jolla ei ole mekaniikan kanssa enää juurikaan tekemistä. Poikkitieteellisyys avaa kuitenkin aina uusia ovia tieteen
maailmassa.
Haluan kiittää koko Delfoi Oy: n henkilöstöä työni tukemisesta, mielenkiintoisista keskusteluista sekä kirjallisuusvinkeistä. Suurimmat kiitokset ansaitsevat vanhempani ja isovanhempani antamastaan taloudellisesta sekä henkisestä tuesta koko opiskeluaikanani, sekä LT Eija- Riitta Salomaa, LT Juhani Elo sekä äitini LT Kristiina Arimaa-Elo ammatillisista keskusteluista ja avoimesta asenteesta insinöörien tunkeutuessa heidän Hippokrateen suojelemalle ammattialueelleen.
Espoossa, tammikuussa 2007
Jani Hyytiäinen
SISÄLLYSLUETTELO
1 Johdanto...1
1.1 Työn tavoitteet...2
1.2 Työn rajaus... 3
2 Tapahtumapohjainen simulointi...5
2.1 Mitä simulointi on?... 5
2.2 Miksi simulointia käytetään?... 11
2.3 Tapahtumapohjaisen simuloinnin ohjelmistot...17
2.4 Simuloinnin ongelmakohtia ja rajoitteita... 27
2.5 Simuloinnin käyttö terveydenhuollossa... 30
3 Simulointiprojektin läpivienti...36
3.1 Projektirakenne... 36
3.2 Projektin määrittely... 39
3.3 Mallin rakentaminen ja testaus... 43
3.4 Mallilla suoritettavat kokeet... 44
3.5 Projektin päättäminen ja implementointi... 45
4 Terveyskeskuksen toiminta ja sen erityispiirteet...47
4.1 Terveydenhuollon toiminnanohjaus...47
4.2 Kysyntä... 49
4.3 Tarjonta... 54
4.4 Hoidon kiireellisyyden määrittely...58
4.5 Hoitotyypin määrittely... 59
4.6 Toimintavuokaavio... 60
4.7 Väestövastuu- eli omalääkärijärjestelmä... 61
5 Terveyskeskuksen toiminnan kehittäminen...65
5.1 Terveyskeskusten hoitoonpääsyn nykytila... 66
5.2 Terveyskeskuksen tuottavuuden mittaaminen...67
5.3 Työkaluja hoitoprosessin parantamiseen... 72
5.4 ”Keskeneräinen potilas” -ajattelutapa...75
5.5 Terveyskeskuksen toimintojen valinta ja jako...78
6 Case: Hyvinkään terveyskeskus...82
6.1 Projektin haasteet... 82
6.2 Lähtötietojen keruu ja muokkaaminen simulointimallia varten...83
6.3 Ohjausmallien kehittäminen ja vertailu... 89
6.4 Mallin tekninen kuvaus... 90
6.5 Mallin visualisointi, verifiointi ja validointi... 92
6.6 Mallissa käytetyt parametrit... 95
6.7 Tulokset... 95
6.8 Johtopäätökset ja suositukset...103
7 Johtopäätökset...104
7.1 Simuloinnin tuomat hyödyt terveyskeskusten kehittämishankkeissa... 104
7.2 Simuloinnin puutteet ja rajoitteet terveyskeskusten kehittämishankkeissa 108 8 Yhteenveto...111
9 Lähdeluettelo...113
10 Liitteet...120
1 Johdanto
”Terveyskeskusjärjestelmä on romahtamassa, ellei jotakin tehdä.” - Lääkäriliiton neuvottelupäällikkö Mikko Hirvikangas 9.10.2006 (Hannus 2006)
Terveydenhuollon kehittämisprojektit ovat perinteisesti keskittyneet hoitomenetelmien kehittämiseen ja lääketieteelliseen tutkimukseen.
Tutkimukset ja kehityshankkeet, joissa oltaisi keskitytty teollisuuden tapaan tuotantoprosessien kehittämiseen, virtaviivaistamiseen ja materiaalihallinnon kustannusten hallintaan, olivat vielä kymmenen vuotta sitten harvinaisia.
Viime vuosina julkisen terveydenhuollon kustannuspaineet sekä julkisen hallinnon lisääntynyt huoli palvelutason ylläpitämisestä ovat johtaneet terveyskeskuspalvelujen kehitysprojekteihin, joiden tavoitteena on palvelujen saatavuuden ja kustannustehokkuuden parantaminen. (Alho 2004)
Syinä projekteihin ovat olleet jokaiselta terveydenhuollon osapuolelta kuuluneet huudot, joissa potilaat vaativat nopeampaa hoitoonpääsyä, julkinen hallinto matalampia kustannuksia ja henkilökunta parempia työoloja sekä kuormituksen tasaamista. Vaatimukset eivät siis kuulosta kovinkaan erilaiselta kuin perinteisesti teollisuudessa kuultavat vaatimukset asiakkaan, konsernijohdon ja työntekijöiden suunnalta.
Tavoitteena kehitysprojekteissa on ollut parantaa julkisen terveydenhuollon laatua ja kykyä vastata väestön ikääntymisen vuoksi yhä kasvavaan kysyntään. Julkinen terveydenhuolto on kärsinyt viime vuosina jatkuvasta resurssipulasta. Suurimmat syyt resurssipulaan ovat olleet henkilökunnan katoaminen yksityiselle sektorille ja ulkomaille parempien palkkojen ja työolojen perässä, sekä julkisen hallinnon budjettiraamien aiheuttama kyvyttömyys vastata yksityisen sektorin palkkakilpailuun. Työn tehokkuuden ja työympäristön parantaminen ovat siis ensiarvoisen tärkeitä haasteita joihin
suomalaisen julkisen terveydenhuollon tulee kyetä vastaamaan.
Prosessikehitykseen tähtäävissä projekteissa on käytetty myös perinteisen teollisuuden tuotanto- ja prosessikehityksen menetelmiä ja asiantuntemusta.
Tämä on mahdollista, koska terveydenhuollon prosesseissa on merkittäviä yhtäläisyyksiä esimerkiksi kappaletavaratuotannon prosesseihin. Monet teollisuuden työkaluista ovat löytäneet tiensä palvelualojen prosessien mallintamiseen. Yksi tällainen menetelmä on tapahtumapohjainen simulointi (discrete-event simulation, DES, diskreetti simulointi). Simulointi on tietotekniikan kehityksen ja käyttäjälähtöisen rajapinnan avulla kehittynyt alkeellisesta simulointikielellä laadittavasta ”salakielestä” parhaimmillaan jopa helposti käytettäväksi visuaaliseksi tutkimusmenetelmäksi, joka ei ole enää vain tuotantoinsinöörien, vaan yhtä lailla liiketoiminta- ja palveluprosesseista vastaavien henkilöiden työkalu (Greasley 2004).
1.1 Työn tavoitteet
Tämän työn tavoitteena on tutkia tapahtumapohjaisen simuloinnin käyttömahdollisuuksia suomalaisen julkisen sektorin ylläpitämän terveyskeskuksen toiminnan mallintamisessa, sekä simulointimallin käyttöä terveyskeskuksen ohjausmenetelmien kehittämisprojektissa. Esimerkkinä tässä työssä käytetään mallia, joka luotiin yhteistyössä Delfoi Oy:n, Lillrank Consulting Oy:n sekä Hyvinkään terveyskeskuksen kanssa. Mallinnuksesta ja projekteista saadut kokemukset ovat omiaan kertomaan simuloinnin
mahdollisuuksista ja rajoitteista terveyskeskuksen kehittämisprojektissa.
Terveydenhuollon hoitoprosessit vaativat erilaista näkökantaa kuin teollisuuden tarkkaan määritellyt prosessit, joita varten simulointiohjelmistot useimmiten on myös suunniteltu. Terveyskeskuksessa jokainen potilas on uniikki ja siten jokainen yksittäisprosessi ainutlaatuinen. Tämä johtaa ensisijaisesti prosessiajan satunnaisuuteen. Terveyskeskustoiminnassa henkilöstö - lääkärit ja hoitajat - ovat pääasiallinen tuotantoresurssi, joten työprosessi on periaatteessa lähempänä käsityötä kuin sarjatuotantoa, johon simulointi yleensä soveltuu parhaiten. Silti potilasvirran kulkua voidaan pitää
suhteellisen säännöllisenä, koska hoitoajat varataan standardikestoille, jotka on määritelty ohjausmenetelmissä.
Toinen terveydenhuoltoa leimaava erityispiirre on lakisääteiset vaatimukset hoidon toteuttamisesta. Kansanterveyslain mukaan kunnan tulee mm.
huolehtia kuntalaisten terveystarkastuksista, sairaankuljetuksesta sekä järjestää kunnan asukkaiden sairaanhoito sisältäen lääkärin tekemät tutkimukset, hoito ja kuntoutus (Kansanterveyslaki). Terveyskeskuksissa ei siis voi loputtomiin myydä ”eioota”, vaan palvelu on verorahoin rahoitettua peruspalvelua. Kolmas tekijä on markkinaohjautuvuuden puute kysynnän rakentumisessa. Ihmiset sairastuvat ja tarvitsevat lääkäriä, vaikka sen hinta olisikin äärimmäisen korkea, toisaalta palvelujen saatavuuden parantaminen ja hinnan minimointi saattavat johtaa potilasmäärän hallitsemattomaan
kasvuun. (Alho 2004)
Työssä tutkitaan edellä mainittujen perusongelmien kuvaamista realistisesti simulointimallilla, sekä mainittujen erityispiirteiden huomioonottamista simulointiin pohjautuvissa kehitysprojekteissa. Työ on tehty simulointiratkaisuja ja tuotantoprosessien konsultointia tarjoavalle Delfoi Oy:lle. Delfoi Oy:n henkilöstöllä on satojen simulointiprojektien kokemus, ja näistä projekteista kymmenet ovat olleet teollisuuden ulkopuolelta, lähinnä terveydenhuollosta.
1.2 Työn rajaus
Tässä työssä keskitytään ainoastaan suomalaisen julkisen sektorin terveyskeskuksen toiminnanohjauksen parantamiseen. Tarkoitus ei ole puuttua lääketieteellisiin tai poliittisiin näkökulmiin, lainsäädännön luomiin velvollisuuksiin tai erilaisiin julkisen terveydenhuollon rahoitusmalleihin eikä nykyisen lainsäädännön mielekkyyteen. Työ ei käsittele terveyskeskuksen hallinnon ja organisaation kehittämistä, vaan keskittyy nimenomaan operatiivisen toiminnan kehitysprojekteihin. Tarkoitus ei ole myöskään tutkia
sairaalatoimintaa, erikoissairaanhoitoa tai muuta terveydenhuoltoon kuuluvia alueita kuin terveyskeskuksia.
Työssä ei myöskään käsitellä mediassa keskustelua herättänyttä kysymystä hoidon etiikasta ja inhimillisen rajapinnan aiheuttamasta terveydenhuollon erityislaatuisuudesta (ks. esim. Kauma 2005). Nämä tekijät otetaan huomioon vain siinä laajuudessa, jossa ne lakien, asetusten ja muiden säännösten kautta vaikuttavat prosesseihin, ei subjektiivisena mielipiteenä siitä, millaisella prosessilla ihmistä voi eettisesti hoitaa. Työtä ei siis tule käsitellä kannanottona inhimillisten olosuhteiden merkityksellisyyteen tai ihmisten alistamiseen kappaletavaraksi.
Työssä käytetyllä simulointimallilla on tarkoitus mallintaa nykymuotoisen terveyskeskuksen toimintaa ja toiminnanohjausta. Avainsanoja terveyskeskusten toiminnanohjauksessa ovat aikataulutus, resurssimäärät (henkilöstö, tilat, määrärahat), työajat, vastaanottojen kesto, potilaan ohjaaminen lääkärille tai hoitajalle sekä ohjaaminen omalääkärille tai toiselle lääkärille. Työssä saatetaan ottaa kantaa lainsäädännön tai julkisen hallinnon muuten terveyskeskuksiin kohdistamiin palveluvaatimuksiin, mutta kannanotto on tällöin ainoastaan prosessikehityksen näkökulmasta, eikä sisällä lääketieteellistä, poliittista, eettistä eikä ideologista näkökulmaa.
2 Tapahtumapohjainen simulointi
Tässä kappaleessa tutustutetaan lukija simulointiin ja sen käyttöön. Ensin esitellään simulointi käsitteenä, perehdytään simuloinnin etuihin, hyötyihin ja sen tuomiin mahdollisuuksiin, ja selvitetään, miksi simulointia yleensä käytetään. Seuraavaksi esitellään muutamia laajassa käytössä olevia tapahtumapohjaisen simuloinnin ohjelmistoja ja niiden erityispiirteitä. Lopuksi perehdytään simulointimallien käytön ongelmakohtiin ja mahdollisiin erityisongelmiin, joita voidaan kohdata terveydenhuollon projekteissa.
2.1 Mitä simulointi on?
Simuloinnin määritteleminen ei ole kovin helppo tehtävä.
Yksinkertaisimmillaan simulointi voidaan määritellä malliksi, joka matkii todellisuutta (Robinson 1994). Keiton, Sadowski ja Sturrock (2004) määrittelevät simuloinnin laajaksi metodien ja sovellusten kokoelmaksi, jolla pyritään imitoimaan todellisten järjestelmien toimintaa, yleensä soveltuvalla tietokoneohjelmistolla". Simulointi voidaan kuitenkin mieltää myös fyysiseksi (ei tietokoneella tehdyksi) malliksi, joka pyrkii olemaan mahdollisimman todenmukainen (Greasley 2004).
Simulointi käsitteenä on tuttu lukuisilta aloilta. Yleisesti tunnettuja simulointityökaluja ovat esimerkiksi erilaiset liikennevälineisiin liittyvät simulaattorit, kuten lentohenkilöstön koulutuksessa käytettävät lentosimulaattorit. Simulointia käytetään myös viihdeteollisuudessa, ja nykyiset video- ja tietokonepelit pohjautuvatkin kokemuksellisesti yhä enemmän simulointiin.
2.1.1 Jatkuva ja tapahtumapohjainen simulointi
Simulointimallit voidaan jakaa kahteen eri tyyppiin: jatkuvaan (continuous) simulointiin ja tapahtumapohjaiseen (discrete-event) simulointiin (Keiton ym.
2004; Autti, Eloranta & Hameri. 1989). Jatkuvassa simuloinnissa mallin
muutokset tapahtuvat jatkuvasti ajan suhteen. Tyypillisesti näillä malleilla kuvataan esimerkiksi kemianteollisuuden tuotantoprosesseja, joissa neste tai muu bulkkitavara virtaa tai reagoi ajan suhteen tietyllä nopeudella. Jatkuva simulointi ei sovellu terveyskeskuksen mallintamiseen, koska terveyskeskustoiminnassa käsitellään yksilöitä eikä edellä mainitun kaltaisia jatkuvia prosessivirtoja.
Tapahtumapohjainen simulointi perustuu yksiköihin ja tiettyinä aikoina tapahtuviin muutoksiin (tapahtumiin), jotka muuttavat järjestelmän tilaa portaittain. Esimerkkinä konepaja, jossa osat saapuvat koneille tai työvaihe valmistuu tiettynä ajan hetkinä. Tällä ajan hetkellä syntyy siis tapahtuma, joita mallissa kuvataan. Jos järjestelmässä tapahtuu jatkuvia prosesseja (esimerkiksi poran uppoaminen syvemmälle aineeseen tai mallissa olevan potilaan paraneminen ajan myötä), ne kuvataan mallissa vain alku- ja päätöshetken yksittäisinä tapahtumina. Tämän tyyppiset simulointimallit soveltuvat kappaletavaratuotantoon ja jonomalleihin, joissa yhden kappaleen etenemistä seurataan läpi järjestelmän, ja reititykset, vaiheajat ja syntyneet jonot aiheuttavat mallin dynamiikan. Tällainen malli on myös terveyskeskus, jossa potilaita ohjataan eri vastaanotoille tiettyinä aikoina ja käytössä on kokonaisluvun verran resursseja, jotka hoitavat kokonaisluvun verran potilaita. (Keiton ym. 2004)
Kuva 1 esittää tapahtumapohjaisen simuloinnin tuloksia graafisesti. Potilaan saapuminen jonoon on tapahtuma, joka muuttaa jonon pituutta. Lääkärin vapautuminen toisella ajan hetkellä on toinen tapahtuma, jonka seurauksena seuraava potilas pääsee vastaanotolle ja jono lyhenee yhdellä potilaalla.
Potilasjonon pituus ajan suhteen
10 T"
9 -
8 -
7 -
3 - --- --- ---
2 - ---
1---
0 *1 I I--- 1--- 1---F---1---1---1--- 1--- 1--- 1---
0 10 20 30 40 50 60 70 80 90 100 110 120
Aika (min)
Kuva 1: Esimerkkikuvaaja tapahtumapohjaisen simuloinnin tuloksista. Kuvaajassa on esitetty terveyskeskuksen potilasjonon kehitys ajan suhteen.
Kuva 2 havainnollistaa tuloksia jatkuvasta simuloinnista. Vesitankkiin virtaa vettä ja toisaalta siitä otetaan aika-ajoin vettä eri virtausnopeuksilla.
Vesitankissa olevan veden määrä on siis jatkuvassa muutoksessa, ja sen muutosta jokaisella ajan hetkellä kuvaa kuvaajan kulmakerroin.
Vesitankin sisältö ajan suhteen
Aika (min)
Kuva 2: Esimerkkikuvaaja jatkuvan simuloinnin tuloksista. Kuvaaja esittää vesitankissa olevaa vesimäärää ajan suhteen.
Simulointia voidaan tehdä tietokonemallilla tai tapahtumia voidaan simuloida fyysisissä koeolosuhteissa. Autojen törmäystesti on esimerkki kolaritilanteen simuloinnista, jossa käytetään todellista koekappaletta, mutta jossa ympäristö ja tapahtuma ovat keinotekoisia. Törmäystestien kalaisissakin malleissa tuloksia tutkitaan tietokoneilla, mutta erotuksena tietokonemalleihin on se, että simuloinnista jää fyysisiä jälkiä, jotka ovat ihmisaistein tutkittavissa. Fyysisessä ympäristössä tapahtuva simulointi ei yleensä sovellu hyvin logististen järjestelmien kehitysprojekteihin, koska yksi simuloinnin näihin projekteihin tuomista suurimmista hyödyistä - ajan säästö - on vaikea
toteuttaa. Simulointipelejä voidaan kuitenkin käyttää esimerkiksi henkilöstön kouluttamiseen.
Tässä työssä keskitytään tietokonemallilla tapahtuvaan tapahtumapohjaiseen simulointiin, koska se soveltuu terveydenhuollon prosessien mallintamiseen, kun taas jatkuva simulointi on käyttökelpoinen epidemia- ja biologisten mallien simulointiin (Lowery 1998). Useat tapahtumapohjaiseen simulointiin pätevät teoriat ja havainnot pätevät kuitenkin myös jatkuvaan simulointiin.
2.1.2 Deterministiset ja stokastiset simulointimallit
Deterministiset mallit kuvaavat järjestelmiä, joissa ei esiinny satunnaisuutta.
Tosielämässä satunnaisuutta esiintyy lähes aina, mutta esimerkiksi täysin automatisoidun tuotantosolun simulointimalli saattaa olla deterministinen.
Kone suorittaa jokaista toimintoa sekunnilleen saman ajan, ja jokainen tuote valmistuu tarkalleen määritellyssä ajassa. Näissä malleissa tavoitteena on yleensä kokeilla erityyppisten tuotantoaikataulutusten vaikutusta.
Esimerkkinä parhaan eräkoon määrittäminen, kun tarkat asetus- ja vaiheajat ovat tiedossa. Näiden mallien analysoinnissa riittää lähtötiedoilla yksi simulointiajo, koska jokaisesta samoilla lähtötiedoilla ajetusta ajosta syntyy samat tulokset.
Stokastisten mallien lähtötiedot sisältävät satunnaisuutta. Esimerkiksi terveysasemalla lääkärien vastaanottojen kestot vaihtelevat tietyn jakauman ja tiettyjen raja-arvojen mukaan. Tulokset vaihtelevat ajokohtaisesti, ja siksi analysoinnissa tulee käyttää useaa simulointiajoa ja niiden tiedoista laskettuja tilastollisia luotettavuuksia. Yleensä tosielämän järjestelmissä on aina mukana stokastisuutta, ja usein laajassa tehdasmallissa on sekä stokastisia että deterministisiä komponentteja.
Tässä työssä keskitytään suurimmaksi osaksi stokastisiin malleihin, koska terveydenhuollon järjestelmät sisältävät aina stokastisia ja inhimillisiä
komponentteja (Lowery 1998). Lähtötietojen ja tulosten satunnaisuudesta ja analysoinnista kerrotaan lisää kappaleessa 3.2.3.
2.1.3 Päättyvät ja ei-päättyvät simulointimallit
Tietyt järjestelmät käynnistävät toimintansa tiettynä aikana, toimivat määrätyn ajan ja ajavat sen jälkeen toimintansa alas. Esimerkki tällaisesta järjestelmästä on talon rakentaminen, joka alkaa tyhjältä tontilta ja päättyy, kun talo on kokonaan valmis. Tällaisen järjestelmän mallintamisessa on selkeä alku ja loppu, ja käynnistys- ja sammutusvaiheet kuuluvat mallinnukseen. Näitä malleja kutsutaan päättyviksi (terminating) simulointimalleiksi (Centeno, Reyes & Florencia 1998; Keiton ym. 2004).
Useat järjestelmät, kuten terveyskeskukset, eivät varsinaisesti aloita ja lopeta toimintaansa. Tietenkin terveyskeskus, tehdas tai muu laitos on joskus perustettu, mutta toiminta on tämän jälkeen jatkuvaa, eikä toiminnan päättymiselle ole annettu aikaa. Näiden järjestelmien simulointimalleja kutsutaan ei-päättyviksi (non-terminating tai steady-state) malleiksi (Centeno ym. 1998; Keiton ym. 2004). Niiden jatkuva luonne, historia ennen simulointiajon alkua sekä tulevaisuus ajon päättymisen jälkeen, tulee ottaa huomioon mallia rakennettaessa. Esimerkiksi tehtaassa tulee olla jokaisessa välivarastossa ja työpisteessä oikeat materiaalit, kun simulointimallista aletaan tallentaa dataa. Terveyskeskus ei voi simulointimallin alussa olla vailla yhtään varausta, jos varauskirjat ovat jatkuvasti täynnä seuraaville päiville. Tällaiset virheet simulointimallissa aiheuttaisivat mallista saatavan loppudatan vääristymää.
Tämä vääristymä voidaan eliminoida kahdella tavalla. Ensimmäinen tapa on syöttää malliin heti alussa tietty määrä osia, varauksia ja varastoja siten, että alkuhetki pyritään saamaan muistuttamaan järjestelmän todellista tilaa historioineen. Toinen tapa on käyttää mallin lämmitysaikaa (warm-up-time), jonka aikana malli täyttyy komponenteista, ja asettuu oikeaan tilaan (Keiton ym. 2004). Lämmitysajan aikana ei rekisteröidä mitään tietoja mallista. Usein
nämä kaksi tapaa yhdistetään. Esimerkiksi terveyskeskuksen varauskirja voidaan asettaa määrätylle tasolle, mutta jonon pituuden annetaan lisäksi asettua oikealle tasolle lämmitysajan aikana, jotta toimintamallin aiheuttama jonojen purku tai kasvu ehtii tapahtua. Näin voidaan lyhentää lämmitysaikaa ja varmistaa, että datan tallennuksen alkaessa järjestelmä on oikeanlaisessa tilassa.
Usein jako päättyviin ja ei-päättyviin järjestelmiin ei ole aivan selvä.
Terveyskeskuksen simulointikin voidaan tehdä päättyväksi malliksi, mutta tällöin ei oteta huomioon varauskirjoja, vaan mallinnetaan ainoastaan päiväkohtaista toimintaa, ja kaikki potilaat hoidetaan saman päivän aikana tai jäävät hoitamatta kokonaan.
2.2 Miksi simulointia käytetään?
Simuloinnin eduista ja käytön syistä löytyy runsaasti kirjallisuutta. Eri kirjoittajat painottavat eri syitä simulointimallien käytölle, ja perusteluja löytyykin tarvittaessa jopa kymmeniä. Simulointi on käytössä niin monen tyyppisissä sovelluksissa, että jokaisella simulointia käyttäneellä on omankaltaisensa perustelut omien järjestelmiensä simulointiin. Yleispätevin selitys simuloinnin käytölle lienee sen kyky auttaa päätöksenteossa (Greasley 2004). Simulointimalli itsessään ei tuota mitään, vaan toimii pelkkänä kokeiluna. Sen avulla pyritään saamaan informaatiota, jonka perusteella päätöksentekijä voi tehdä mahdollisimman hyvän päätöksen.
2.2.1 Simuloinnilla tutkittavat järjestelmät
Piddin (1996) mukaan lähes jokainen järjestelmä on simuloitavissa, kunhan projektiin kohdennetaan tarpeeksi asiantuntemusta, tietokoneresursseja, aikaa ja rahaa. Kuitenkaan minkä tahansa järjestelmän simuloiminen ei ole järkevää, koska muitakin työkaluja järjestelmän analysointiin on olemassa.
Pidd listaa simuloitaville mallille kolme ominaisuutta:
1. Dynaamisuus. Järjestelmissä toiminta muuttuu ajan suhteen.
Dynaamisuus voi aiheuttaa järjestelmään monimutkaisuutta, ja ilmiöitä, joiden tapahtumista ei osata kunnolla selittää, mutta niiden tapahtuminen voidaan mallintaa tai analysoida tilastollisesti
2. Interaktiivisuus. Järjestelmässä on komponentteja, jotka reagoivat toisten komponenttien toimiin. Kaikkien vaikuttavien komponenttien vaikuttavat toimet luovat järjestelmän tilan, jonka mukaan vaikutuksen alaisena olevat komponentit toimivat.
3. Monimutkaisuus. Komponenttien määrä on suuri, joten järjestelmän kokonaistoiminta muuttuu interaktioiden ja dynaamisten muutosten vuoksi monimutkaiseksi ja siten vaikeaksi hahmottaa ilman mallinnusta.
Nämä järjestelmäkriteerit toteutuvat hyvin erilaisissa järjestelmissä. Simulointi onkin todettu toimivaksi kehitystyökaluksi niin valmistavassa teollisuudessa, kuljetuspalveluteollisuudessa, puolustusteollisuudessa niin logistisia kuin taistelustrategisia malleja hyödyntäen, liiketoimintaprosessien
uudelleensuunnittelussa (business process re-engineering) kuin terveydenhuollossa. (Pidd 1996)
Teollisuuden ja palvelualojen logististen simulointiprojektien perustelut voidaan jakaa kahteen kategoriaan (Law 1998):
1. Uuden järjestelmän suunnittelu. Näissä projekteissa tutkitaan tarvittavien resurssien (työkoneet, tilat, henkilöstö, varastot) määrää, järjestelmän layoutia, vuorojärjestelmiä, materiaalihallinnon prosesseja, tuotannonohjauksen menetelmiä, järjestelmän tyyppiä (linjavalmistus vs. soluvalmistus) yms.
2. Olemassa olevan järjestelmän optimointi tai hienosäätö. Tutkittavia aiheita ovat yleensä tuotannon ohjauslogiikoiden muutokset, mahdollisen lisäresurssin hankinta, varastojen optimimäärät jne.
Vastaava jako pätee myös terveydenhuollon simulointiprojekteihin.
Kappaleessa 5 esiteltävä Hyvinkään terveyskeskuksen projekti keskittyi olemassa olevan terveyskeskuksen ohjausmenetelmien kehittämiseen.
Tärkein syy toiminnan kokeilemiseen simuloinnilla oli ajan säästö sekä olemassa olevalla järjestelmällä tehtävän testaamisen mahdottomuus, johtuen terveyskeskuksen velvoitteesta hoitaa potilaat hoitotakuun edellyttämällä tavalla.
2.2.2 Teknilliset ja taloudelliset perustelut
Simulointi- ja kehitysprojektien syyt ovat yleensä kustannustehokkuuteen liittyviä. Kirjallisuudessa ja artikkeleissa on esitelty lukuisia tapauksia, joissa simuloinnin käytöllä tuotantoresurssien optimoinnissa ja järjestelmän kehityksessä on saavutettu jopa miljoonien dollareiden kustannussäästöt (ks.
esim. Law 1998).
Joskus projektien tarkoituksena on myös etsiä järjestelmän maksimikapasiteettia tai lyhentää läpimenoaikoja kysyntään vastaamisen tai markkinoilletuloajan (time-to-market) parantamiseksi. Tällöinkin taustalla on halu tehdä muutoksia, jotka parantavat yrityksen taloudellista kannattavuutta.
Suorat kustannussäästöt saavutetaan yleensä resurssitarpeen optimoinnilla ja varastojen minimoimisella. Epäsuoria etuja saadaan asiakastyytyväisyyden parantamisella, uusien tuotteiden markkinoille saamisen nopeuttamisella ja laadun paranemisella.
Nykyinen valmistavan teollisuuden kilpailuympäristö asettaa lisäksi yhä suurempia vaatimuksia materiaalinhallinnon kykyyn ylläpitää mahdollisimman pieniä varastoja, vastata tarpeeseen mahdollisimman nopeasti, tilauksen penetraatiopisteen (Order Penetration Point) siirtämiseen tuotantoprosessin alkupäähän ja läpimenoaikojen minimointiin. Ympäristö muuttuu nopeasti, eikä näiden tavoitteiden saavuttamiseksi ole aikaa pitkiin pohdintoihin tai kokeiluihin olemassa olevilla järjestelmillä.
Simulointiohjelmistojen sekä tietotekniikan kehitys ovat myös johtaneet huomattavaan simulointimallien tehokkuuden lisääntymiseen.
Tuotantojärjestelmien automatisointi on johtanut monimutkaisempiin järjestelmiin, joiden analysointi ilman simulointia voi olla vaikeaa (Law 1998).
Kehittyneemmät ohjelmistot mahdollistavat lyhyemmät simulointimallien rakennusajat ja tehokkaammat tietokoneet nopeuttavat simulointiajoja sekä mahdollistavat yhä monimutkaisempien ja yksityiskohtaisempien mallien toteuttamisen (Law 1998).
Seuraavassa on listattu yleisimpiä syitä simuloinnin käyttöön päätöksenteon apuvälineenä:
1. Oikean järjestelmän tai laitteen kanssa kokeileminen tuhoaisi koekappaleen (Law 1998; Greasley 2004). Yksinkertaisena esimerkkinä tästä ovat autojen törmäyssuojajärjestelmien tietokonesimuloinnit.
2. Oikean järjestelmän tai laitteen kanssa kokeileminen ei ole kustannustehokasta (Robinson 1994; Law 1998; Keiton ym. 2004).
Jos tuotantojärjestelmä toimii nykymuodossaan täydellä kapasiteetilla, ja tämä kapasiteetti myös tarvitaan kysynnän tyydyttämiseen, ei järjestelmää kannata ottaa testi käyttöön. Erillisen järjestelmän rakentaminen testauskäyttöön ei myöskään yleensä ole kannattavaa.
Terveyskeskuksen toiminnanohjauksen muutosten kokeilu saattaisi sotkea terveyskeskuksen palvelujen tuotettavuuden viikkokausiksi ja johtaisi täten terveyskeskuksen hoitovelvoitteen laiminlyöntiin ja
asiakastyytymättömyyteen.
3. Oikean järjestelmän tai laitteen kanssa kokeileminen on mahdotonta (Law 1998; Keiton ym. 2004). Kyseistä järjestelmää, laitetta tai tuotetta ei ole vielä rakennettu, vaan simuloinnilla testataan ominaisuuksia ennen ensimmäisenkään prototyypin valmistamista.
4. Oikean järjestelmän tai laitteen kanssa kokeileminen olisi vaarallista ympäristölle ja ihmisille, tai jopa laitonta (Robinson 1994).
Ydinvoimalan koetoiminta voidaan simuloida ennen varsinaisen oikealla reaktorilla tehtävän toiminnan aloittamista.
5. Simuloinnilla voidaan saada tuloksia nopeammin kuin todellisella järjestelmällä (Robinson 1994). Tietokonemallilla kelloa pystytään kääntämään moninkertaisella nopeudella eteenpäin, jolloin useiden päivien toiminta saadaan mallinnettua mahdollisesti sekunneissa.
6. Toistettavuus (Robinson 1994). Todellisessa elämässä olosuhteet muuttuvat aina ympäristön muutosten vuoksi. Eri toimintamallien testaaminen täysin samanlaisella otoksella ja lähtödatalla on täten mahdotonta. Esimerkiksi lentoaseman check-in-tiskin toiminnan kokeileminen eri päivinä voi johtaa täysin erilaisen matkustajamäärän aiheuttamiin eroihin lopputuloksessa, koska eri viikonpäivinä lähtee eri määrä lentoja eri kohteisiin. Simulointimallissa kokeilu voidaan tehdä täysin samanlaisella lähtödatalla, ja toistaa lukuisia kertoja eri toimintatavoilla.
Suurimmat syyt simulointimallien käyttöön tuotanto- ja palvelumallien kehitysprojekteissa ovat kustannustehokkuus, ajan säästö ja uusien vielä rakentamattomien järjestelmien kokeileminen.
2.2.3 Organisatoriset ja johtamiseen liittyvät perustelut
Kolmiulotteinen graafinen simuloinnin visualisointi auttaa tavallista tuotantohenkilöstöä ja insinöörejä ymmärtämään simulointimallien ja sen kuvaaman todellisen järjestelmän tai mahdollisen uuden toimintatavan toimintaa (Robinson 1994; Law 1998; Greasley 2004). Kun malli ei ole vain sarja numeroita, josta vain mallin tekijä osaa louhia oikean datan johtopäätösten tekemiseksi, vaan enemmänkin visuaalinen kokemus uuden
järjestelmän toiminnasta tai uudesta toimintatavasta, voidaan simulointia tuoda lähemmäs työntekijää ja käyttää mm. koulutustarkoituksiin.
Henkilöstö voidaan tutustuttaa, sopeuttaa ja kouluttaa uuteen toimintatapaan vaiheessa, jossa uutta tapaa ei ole vielä implementoitu lattiatasolla, vaan muutosprosessiin ollaan vasta lähdössä. Parempi kommunikointi, koulutus ja toimintatavan tuntemus vähentää myös henkilöstön muutosvastarintaa, joka voi olla kriittinen tekijä toimintatapoja muutettaessa, varsinkin perinteisillä aloilla, joilla henkilökunnan koulutustaso on korkea ja työhistoria mahdollisesti pitkä. Tämä kuvaus sopii myös terveydenhuoltoalaan.
Eräät simuloinnista kirjoittaneet, kuten Robinson (1994) ja Greasley (2004) nimeävät simuloinnin käytön syitä myös johtamis- ja organisaatiopsykologian perspektiivistä. Robinsonin ja Greasleyn mukaan useat kehitysehdotukset eivät koskaan toteudu, koska niiden pelätään epäonnistuvan. Simulointi mahdollistaa kuitenkin toiminnan kokeilemisen turvallisessa ympäristössä matalilla kustannuksilla, joten simulointi lisää organisaation innovatiivista ja luovaa ajattelutapaa.
Simulointi tarjoaa kokonaisvaltaisia ratkaisuja paikallisten ratkaisujen sijaan.
Monimutkaisessa järjestelmässä yhden ongelman havaitseminen voi olla helppoa, mutta ratkaisuksi tarjotaan usein paikallista parannusta, joka siirtää ongelman muualle järjestelmässä. Simuloinnin avulla saadaan kokonaiskuva systeemistä ja visualisoidulla mallilla havainnollistettua esimerkiksi, minne tuotannossa havaittu keskeneräisen tuotannon ylisuuri välivarasto siirtyy, jos ongelma ratkaistaan paikallisesti. (Robinson 1994; Greasley 2004)
Simulointi rohkaisee ihmisiä ajattelemaan. Simulointimallin rakentaminen ja ajaminen antaa usein tuloksia, joista vedettävät johtopäätökset olisi voitu vetää ilman malliakin. Mallin käyttäminen laukaisee kuitenkin ajatusprosessin ja johtaa ajatusten jakamiseen. Simulointia käyttäen voidaan siis saada organisaatio miettimään asioita, jotka eivät olisi tulleet mieleen ilman simulointiprojektia. (Robinson 1994; Greasley 2004)
Simulointi toimii kommunikaatiokeinona organisaatiossa. Ylempi johto saattaa suhtautua epäilevästi alaisen tekemään innovaatioon ja ehdotukseen toiminnan uudelleenorganisoimiseksi, jos se saa tiedot mahdollisista hyödyistä vain lukuina paperilla. Toimiva ja visuaalinen simulointimalli toimii hyvänä vakuuttimena ja sillä on helppo osoittaa käytännön edut järjestelmän kehittämisessä. (Robinson 1994; Greasley 2004)
2.2.4 Simuloinnin vaihtoehtoja
Perinteinen vaihtoehto simuloinnille on oikealla järjestelmällä kokeileminen, ja yritys-erehdys -menetelmällä parhaan lopputuloksen aikaansaaminen.
Tämä metodi on kuitenkin useimmiten mahdoton, järjettömän kallis eikä anna tuloksia kovinkaan nopeasti. Simuloinnin vaihtoehtoina voidaan pitää myös staattisia taulukkolaskenta-analyysejä, jonoteoriaan syventymistä ja lineaarisia malleja (Greasley 2004). Niiden kyky mallintaa dynaamisia ja monimutkaisia logistisia malleja on kuitenkin rajallinen, koska niissä systeemidynamiikkaa ei oteta kunnolla huomioon.
Simulointimallilla taas voidaan kuvata hyvinkin dynaamisia malleja, kuten miten yksi poikkeus järjestelmän normaalista toiminnasta saattaa aiheuttaa suuria ja pitkäaikaisia vaikutuksia järjestelmän toimintaan. Esimerkkinä liikennemalli, jossa tiiviissä jonossa ajavista autoista yksi jarruttaa, ja aiheuttaa täten haitariliikkeen, joka saattaa olla havaittavissa jonossa kilometrien päässä.
2.3 Tapahtumapohjaisen simuloinnin ohjelmistot
Tapahtumapohjaisen simuloinnin ohjelmistomarkkinat ovat laajat. Tässä kappaleessa listataan useita markkinoilla olevia ohjelmistoja, mutta perehdytään syvemmin vain kahteen ohjelmistoon, joista kirjoittajalla on käyttökokemusta. Ohjelmistoja on useita erityyppisiä, ja osa niistä on keskittynyt tietyn alan tai tietyn tyyppisten järjestelmien mallintamiseen.
Nämä ohjelmistot ovat kuitenkin markkinaosuudeltaan yleensä pieniä ja
suurimmat ohjelmistot ovatkin sellaisia, joilla luotavat mallit ovat ketterästi räätälöitävissä erityyppisten mallien kuvaamiseen.
Ohjelmistot voidaan käyttäjäystävällisyyden ja räätälöitävyyden suhteen jakaa karkeasti korkean tason ja matalan tason ohjelmistoihin. Matalan tason simulointityökalut vaativat käyttäjältään syvempää osaamista mallien rakentamisesta ja logiikkakoodin laatimisesta. Alkeellisimmat ohjelmistot eivät tarjoa graafista käyttöliittymää nopeaan ja yksinkertaiseen mallin luomiseen, vaan lähes kaikki tulee tehdä käsin. Korkean tason ohjelmistot tarjoavat helposti omaksuttavan ja loogisen käyttöliittymän, jolla kokematonkin henkilö rakentaa yksinkertaisia malleja. Nämä ohjelmat ovat luonnollisesti raskaampia kuin matalan tason ohjelmat, tarjoavat yleensä huonomman räätälöitävyyden sekä keskittyvät usein kapealle teollisuudenalalle. Tämä jako ei kuitenkaan ole yksinkertainen, sillä korkean tason simulointiohjelmisto voi tarjota myös työkalut täysin räätälöitävien mallien luomiseksi, jolloin käyttäjä voi pikku hiljaa osaamistaan syventäen siirtyä luomaan yhä monimutkaisempia malleja manuaalisesti. (Keiton ym.
2004)
Simulointiohjelmistoja on markkinoilla tarjolla kymmeniä, joista osa on keskittynyt tietyn alan prosessien kuvaamiseen, kun taas toiset ovat yleiskäyttöisiä ja käyttäjän helposti räätälöitävissä. Muutamia yleisesti käytössä olevia simulointiohjelmistoja:
1. Delmia QUEST (Delmia Corporation, USA. http://www.delmia.com) 2. Arena (Rockwell Software Inc, USA. http://www.rockwellsoftware.com) 3. ProModel ja MedModel (terveydenhuollon prosessien mallintamiseen
suunniteltu sovellus) (PROMODEL Corporation, USA.
http://www.promodel.com)
4. SimuIS (SimuIS Corporation, USA. http://www.simul8.com)
5. Automod ja Autosched AP (Brooks Software, USA, http://www.brookssoftware.com)
6. Simprocess ja Simscript II.5 (CACI Products Company, USA.
http://www.caciasl.com)
7. Plant Builder (Simulation Dynamics Inc., USA.
http://www.simulationdynamics.com)
8. Anylogic (XJ Technologies Company, Venäjä, http://www.xjtek.com) Tapahtumapohjaista simulointia ohjaa simulointilogiikka. Logiikalla ohjataan simulointimallissa tapahtuvaa päätöksentekoa, jonka seurauksena tapahtumat tapahtuvat. Yksinkertaisimmillaan logiikka on JOS-NIIN- MUUTEN (IF-THEN-ELSE) -logiikkaa, joka edustaa ohjelmoinnin yksinkertaisinta binääristä logiikkaa. Eri ohjelmistot tarjoavat erilaisia valmislogiikoita, työkaluja ja rajapintoja logiikan laatimiseen, mutta yleensä jokainen simulointiohjelmisto tarjoaa mallin rakentajalle mahdollisuuden ohjelmoida logiikka kokonaan manuaalisesti logiikkakoodia kirjoittaen.
2.3.1 Delmia QUEST
QUEST on ranskalaiseen Dassault Systémes -konserniin kuuluvan Yhdysvaltalaisen Delmia Corporationin myymä ja ylläpitämä kokonaan 3D- visualisuointiin perustuva tapahtumapohjainen simulointiohjelmisto.
Ohjelmisto tarjoaa simulointitoimintojen lisäksi kolmiulotteisen CAD- ympäristön, jolla voi luoda grafiikkaa ja grafiikkaan kineettisiä toimintoja kuvaamaan simuloinnin tapahtumia. Ohjelmisto on Delfoi Oy:n pääasiallinen tehdasmallien simulointiohjelmisto, ja kappaleessa kuusi esitelty Hyvinkään terveyskeskuksen simulointiprojekti toteutettiin QUESTillä.
Simulointimalli rakentuu QUESTissä osista (engl. ”part”) ja elementeistä (engl. ”element”). Osat ovat prosessissa kulkevia yksittäisiä kohteita (tuotteita, potilaita, jne.), joita prosessoidaan ja jotka kulkevat järjestelmässä.
Elementit ovat koneita, osien luomis- ja poistoelementtejä, varastoja, työntekijöitä, vihivaunuja ym. kohteita, jotka kuvaavat järjestelmän resursseja. Elementeissä tehdään reitityspäätöksiä, niissä osille tapahtuu tapahtumia ja niitä vaaditaan tietyn prosessin tai tapahtuman aikaansaamiseksi. Elementit yhdistetään toisiinsa yhteyksillä (engl.
”connection”), jotka ovat mahdollisia reittejä elementistä toiseen. Osat siis liikkuvat luomiselementistä logiikan määrittelemän reitin kautta eri elementteihin ja päätyvät yleensä prosessin valmistuttua poistoelementtiin, jossa osat hävitetään mallista. Elementeissä malleihin kohdistetaan tapahtumia, jotka vaativat tiettyjä resursseja, jotka siten varataan prosessin ajaksi.
Esimerkkinä tällaisesta projektista on osan siirto elementistä toiseen vihivaunun (AGV, Automated Guided Vehicle) avulla, jolloin osa ei siirry ennen kuin vapaa vihivaunu löytyy. Siirrolle on määritelty reitti ja kesto, jonka ajan vihivaunu on varattuna vain tähän toimenpiteeseen. Toinen esimerkki on koneessa tehtävä työ, joka vaatii paikalle kaksi työntekijää. Työtä ei tehdä ennen kuin vapaa henkilöresurssimäärä löytyy, ja työn ajan henkilöt ovat varattuna tälle työlle. Koneen ollessa varattuna muut koneelle tulossa olevat osat jäävät jonottamaan koneelle pääsyä.
Simuloinnin logiikkaan löytyy QUESTistä lukuisia valmiita prosesseja, ja yksinkertaisia simulointimalleja voidaan toteuttaa pelkän graafisen käyttöliittymän avulla. Mallin elementtejä luotaessa luodaan samalla kolmiulotteinen kuvaus mallista, ja jokaisella simuloinnin elementillä on kolmiulotteinen oletuskuva, joka asettuu 3D-maailmaan mallia rakennettaessa. Käyttäjällä on valittavanaan myös laaja kirjasto erityyppisien koneiden kuvia, joten mallista saa yksinkertaisesti vähäiselläkin työllä realistisen ympäristön näköisen.
QUESTin CAD-osio tarjoaa mahdollisuuden luoda tarkkojakin kuvauksia mallinnettavista elementeistä ja osista. Kuvien tuominen muista ohjelmista on myös mahdollista, ja usein monimutkaiset kuvat luodaankin Dassault
Syslernes CATIA V5-sovelluksella, joka on erillinen ohjelmisto 3D-kuvien luomiseen. Kuvia on kirjastojen avulla helppo käyttää useissa erilaisissa malleissa, jolloin kirjastoihin voidaan luoda kuvat esimerkiksi koko yrityksen tuotevalikoimasta, ja näitä kuvia käyttää kaikissa yrityksen toimintaa kuvaavissa malleissa. Kuva 3 esittää erästä Delfoi Oy:n terveydenhuollon mallia, jossa ei käytetty yhtään projektin työtuntia grafiikan luomiseen, mutta kirjastokuvilla pystyttiin visualisoimaan realistisen näköinen sairaalaympäristö.
Kuva 3: Esimerkki yksinkertaisesta Delmia QUESTillä toteutetusta simulointimallin 3D-visualisoinnista.
QUEST tarjoaa käyttäjälleen sekä korkean että matalan tason ohjelmiston edut. Simuloinnin logiikan voi luoda yksinkertaisilla oletuslogiikoilla, joita on valittavissa eri elementeille. Näille oletuslogiikoille voidaan antaa parametreja graafisen käyttöliittymän kautta. Parametreiksi voi antaa myös valmiita todennäköisyysjakaumia. Esimerkkinä oletuslogiikasta kone-luokan (engl.
”machine”) logiikaksi voidaan määritellä, että osalle tyyppiä 1 vaiheaika on
t=60 sekuntia, ja osalle tyyppiä 2 uniform-jakauman mukainen raja-arvoilla 10<t<90.
Graafinen käyttöliittymä mahdollistaa kuitenkin vain hyvin standardisoidut prosessit, ja tottuneet käyttäjät kirjoittavatkin logiikan yleensä ohjelmakoodina. QUESTissä logiikka ohjelmoidaan Delmian kehittämällä Simulation Control Languagella (SCL).
SCL muistuttaa ohjelmointikielenä Pascalia ja C:tä. Se sisältää tyypillisiä korkean tason ohjelmointikielen konventioita, joihin on lisätty tapahtumapohjaisen simulointilogiikan vaatimia ja simulointiympäristön mahdollistamia toimintoja (Delmia Corp. 2005a). SCL:n avulla voidaan mallissa ohjata seuraavia toimintoja (Delmia Corp. 2005a):
1. Reititystä 2. Prosessointia 3. Jonotusta
4. Vihivaunun (AGV) ja työntekijöiden liikettä 5. Päätöksentekopisteen aktiviteettejä
6. Mallin alustamista, päätöslogiikkaa ja ajon aikaista logiikkaa 7. Toimia ennen ja jälkeen tapahtuman
8. Käyttäjän määrittelemien SCL-painikkeiden ja -makrojen käyttäytymistä.
Simulation Control Language osaa lukea tiettyjä todennäköisyysjakaumia, joiden käyttö on yleistä simulointimallien ajamisessa. Logiikkaan voidaan syöttää lähtötietoja lisäksi lukemalla rivi- ja tabulaattorieroteltuja tekstitiedostoja (.txt) tai syöttämällä niitä manuaalisesti QUESTin simulointiajon aikana.
QUEST-ohjelmiston hallintaan voidaan normaalin graafisen käyttöliittymän lisäksi käyttää Batch Control Languagea (BCL). Kun SCL keskittyy itse simulointimallin logiikkaan ja yksityiskohtaiseen mallin käyttäytymisen ohjaamiseen, BCL mahdollistaa itse QUESTin hallitsemisen esimerkiksi käyttäjän luomien makrojen avulla. BCL toimii kuin tekstipohjainen käyttöliittymä, johon voidaan ohjelmoida valmiita komentosarjoja, joiden avulla voidaan esimerkiksi automatisoida simulointiajoja. Tämä ominaisuus on hyödyllinen, kun halutaan ajaa suurta ja raskasta mallia useaan kertaan, jolloin suurin osa ajasta menee vain mallin ajamisen odottamiseen. Ennen nykyisiä tehokkaita tietokoneita oli normaalia aloittaa simulointiajo työpäivän päätteeksi, jolloin 16 tunnin aikana ajo saatiin ajettua ja aamulla voitiin lukea simuloinnin tulokset. Nykyisillä tietokonetehoilla tämä ei ole tarpeen, mutta ajoja voidaan joutua toistamaan tilastollisen luotettavuuden saavuttamiseksi.
BCL-makrolla voidaan määritellä QUEST ajamaan samaa mallia eri parametreillä esimerkiksi tuhat kertaa, ja nämä tuhat lyhyttä ajoa voidaan ajaa automaattisesti yön aikana. (Delmia Corp. 2005b)
BCL tarjoaa myös mahdollisuuden luoda rajapinta toiseen sovellukseen esimerkiksi lähtötietojen syöttämistä varten sekä ajaa simulointimallia toisesta sovelluksesta. Myös SCL-koodista voi kutsua BCL-makroja ja muuttaa makron avulla ajon parametreja. SCL sekä BCL tekevät malleista ja QUESTin käyttämisestä taitavalle ohjelmoijalle erittäin räätälöitävää ja joustavaa. (Delmia Corp. 2005b)
QUEST on tapahtumapohjaisen simuloinnin työkalu, eikä sisällä ominaisuuksia jatkuvan simuloinnin mallien luomiseen ja ajamiseen.
Joustavuutensa ja hyvien 3D-grafiikkaominaisuuksiensa vuoksi se soveltuu hyvin tosielämän järjestelmien mallintamiseen. Siihen voidaan helposti yhdistää arkkitehtoninen tai layout-suunnittelu ja se tuottaa pienellä työllä näyttävää 3D-grafiikkaa, joka on eduksi mallia verifioidessa sekä mallin esityksessä esimerkiksi koulutus- tai myyntitapahtumissa. Tietyt QUESTin elementit saattavat olla kuitenkin hankalahkoja hallita SCL:llä, joten
esimerkiksi työvoimaresurssien ohjaukseen käytetään usein koneiden logiikoita, jolloin työvoimaresursseille ei kirjoiteta omaa logiikkaa laisinkaan.
2.3.2 Arena
Arena on yhdysvaltalaisen Rockwell Softwaren kehittämä simulointiohjelmisto, joka soveltuu sekä jatkuvaan, että tapahtumapohjaiseen simulointiin. Arena on laajassa käytössä yliopistoissa ja korkeakouluissa, ja useat simulointikursseja käyneet opiskelijat ovatkin saaneet ensikosketuksensa simulointiin Arenalla. Osasyynä tähän lienee Arenan helppo käytettävyys ja mahdollisuuden laajentaa Arenan käyttöä portaittain alemmalle ohjelmoinnin tasolle. Lisäksi Arenan opiskeluun on olemassa oppikirja (Keiton ym. 2004)
Arenassa simulointimalli koostuu yksilöistä (Entity) sekä moduuleista (Flowchart Modules). Yksiköt vastaavat QUESTin osia, ja moduulit periaatteessa elementtejä, eli ne kuvaavat esimerkiksi päätöksentekopisteitä ja koneita. Moduulit yhdistetään QUESTin tapaan yhteyksillä, joita pitkin osat voivat kulkea moduulista toiseen. (Keiton ym. 2004)
Arenan graafinen käyttöliittymä mahdollistaa taitavalta käyttäjältä hyvinkin monimutkaisten mallien rakentamisen. Esimerkiksi työntekijöiden kalenteria voi hallita puhtaasti graafisesta käyttöliittymästä, ja prosessi-, kuljetus- ja luomisaikojen määrääminen jakaumien mukaan on mahdollista. Osille voi lisäksi syöttää rahallisia arvoja, odotuskustannuksia, Value-Added- sekä Non-Value-Added-arvoja ja monia muita arvoja. Näiden arvojen ketterä muokkaaminen on mahdollista, koska Arena luo prosessiajoista, arvoista, resursseista ynnä muista valmiit taulukot, joissa navigoiminen on nopeaa ja tietojen muuttaminen yksinkertaista.
Visuaalisesti Arena edustaa yksinkertaisempaa kaksiulotteista grafiikkaa.
Malliin tulee luoda erillinen grafiikka, jos järjestelmää aiotaan visualisoida tarkemmin. Graafisen käyttöliittymän avulla malliin asetettavat moduulit
näkyvät vuokaavion (Flowchart) elementteinä, kuvaten havainnollisesti mallin logiikan etenemistä. Moduuleille syötetään yksinkertaisimmillaan logiikka graafisen käyttöliittymän ikkunan kautta.
Kuva 4 esittää yksinkertaista Arena-logiikkamallia. Osat kulkevat mallissa vuokaavion tavoin moduuleille määrättyjen logiikoiden mukaan. Create- moduuli luo osia, Process-moduuli toimii koneena, jolle kertyy jonoa (moduulin yläpuolella olevat kuvat) ja Dispose-moduuli hävittää osat prosessoinnin jälkeen. Ylemmässä linjassa on lisäksi Decide-moduuli (päätöksenteko), jolle on tässä esimerkissä määritelty kolmen prosentin hylkäysmäärä. Moduuli ohjaa keskimäärin kolme prosenttia osista suoraan poistettavaksi. Tällä mallinnetaan esimerkiksi alikokoonpanojen testauspistettä. Process-moduulien alapuolella olevat luvut kertovat moduulissa tällä hetkellä olevien osien määrän (kaksi jonossa, yksi prosessoitavana), Decide-moduulin uloskäyntien vieressä olevat luvut kertovat uloskäynnistä käyneiden osien määrän. Muiden moduulien vieressä olevat luvut kertovat moduulin läpi kulkeneiden osien määrän. Malliin on lisäksi luotu kaksi työntekijää, ja molemmille Process-moduuleille on määritelty tarve yhdelle työntekijälle prosessin suorittamista varten.
Vuokaaviomallinnuksessa työntekijät eivät kuitenkaan näy.
Kuva 4: Yksinkertainen Arena-malli moduuleineen ja prosessoitavine osineen.
Arenan käyttämän oletusgrafiikan etuna on sen loogisuus ja universaali ymmärrettävyys. Esimerkki (Kuva 4) kuvaa kahta konetta, joista toinen prosessoi jokaisen saapuvan kappaleen, toinen vain osan kappaleista. Kaikki yhteydet ovat näkyvillä, ja päätöksenteko tapahtuu erillisessä moduulissa (Decide 1), joten mallia tutkivalle prosessiajattelua ja vuokaavioita tuntevalle henkilölle on välittömästi selvää, mitkä osat kulkevat minnekin, ja että kaikki ylemmän linjan osat eivät päädykään koskaan prosessoitavaksi. Mallin reititys ja peruslogiikka on siis helposti nähtävillä, mutta henkilöstön koulutukseen tällainen visualisointi ei välttämättä ole omiaan.
Arenassa on olemassa omat, suhteellisen kankeat kaksiulotteisen visualisoinnin mahdollistavat kirjastot erilaisille kuville. Visualisointi tapahtuu eriytettynä vuokaaviosta, eli käyttäjälle jäävät rinnakkain näkyviin sekä visualisoitu logiikka että kaksiulotteinen grafiikka.
Vaikka Arena ensisilmäyksellä vaikuttaakin korkean tason ohjelmistolta, jolla mallit rakennetaan graafisen käyttöliittymän avulla ja joka siten ei tarjoa täyttä muokattavuutta monimutkaisten mallien rakentamiseen, sisältää se mahdollisuudet käyttää eri ohjelmointikieliä sekä mallien rakentamiseen että ohjausmakrojen luomiseen. Arenan rakenne on hierarkkinen siten, että
monipuolisen graafisen käyttöliittymän alla taitava ohjelmoija voi käyttää C, C++, Visual basic tai SIMAN -ohjelmointitaitojaan. (Keiton ym. 2004)
Arenan logiikka toimii moduulien alla Siman-simulointikielellä, ja käyttäjällä on mahdollisuus luoda Simanilla omia moduulejaan tai muokata olemassa olevia moduuleja. QUESTin BCL-makroja vastaavia makroja voi ohjelmoida Visual Basicilla, joka toimii myös integraattorina muihin ohjelmistoihin.
Arenan Visual Basic Editorilla voi luoda makroja, jotka ohjaavat toisia sovelluksia, kuten Microsoft Exceliä tai AutoCADia. Näillä makroilla saadaan luettua esimerkiksi lähtödataa tai kirjoitettua simuloinnin tuloksia suoraan Excel-taulukkoon koskematta koko sovellukseen. Arena pystyy lukemaan dataa myös yksinkertaisista tekstitiedostoista, mutta mahdollisuus ohjata suoraan Exceliä Arenasta monipuolistaa datan käsittelymahdollisuuksia ja Excelin automatisointi vähentää sovelluksen käyttöön kuluvaa työmäärää.
2.4 Simuloinnin ongelmakohtia ja rajoitteita
Edellisen perusteella voisi helposti ajatella, että simulointi on ratkaisu kaikkiin järjestelmäongelmiin, mahdollistaa minkä tahansa järjestelmän mallintamisen ja on aina oikea ratkaisu kehitysprojektien työkaluksi. Simuloinnilla on kuitenkin omat heikkoutensa ja rajoitteensa, jotka tulee ottaa huomioon sekä mallia käytettäessä että jo siinä vaiheessa, kun tehdään päätöstä simuloinnin käyttämisestä työkaluna.
Ensimmäinen ongelmakohta simuloinnin käytössä on tilastollisten analyysien tekemättä jättäminen ja siitä johtuvat väärät johtopäätökset. Jos simulointimalli kuvaa todellista järjestelmää mahdollisimman tarkasti, ja varsinkin kun visualisointi on toteutettu näyttävästi ja totuudenmukaisesti, voi luottamus simulointimallin tuloksiin kasvaa liian suureksi. Jos käyttäjä ei suorita satunnaisuutta sisältävällä mallilla tarpeeksi pitkiä tai useita ajoja, vaan perustaa tietonsa esimerkiksi vain yhteen tai kahteen lyhyeen ajoon, eivät tulokset ole välttämättä luotettavia. Stokastisen simuloinnin tulokset sisältävät aina satunnaisuutta, ja ajojen määrä, pituus ja tulosten tilastollinen
luotettavuus vaativat aina huolellista työtä. Luottaminen tietokonemallin antamiin lukuihin ilman tilastollista analyysiä vastaa tällaisessa tapauksessa arpapeliä. (Keiton ym. 2004)
Satunnaisuutta voidaan vähentää yksinkertaistamalla mallia. Liian yksinkertaistettu malli saattaa kuitenkin johtaa epävalidiin malliin, joka ei enää luotettavasti kuvaakaan todellista järjestelmää. Tässä tilanteessa saatavat tulokset eivät ole sovellettavissa todellisen järjestelmän ohjauksessa.
Simulointimallien kompleksisuus aiheuttaa siis paitsi lisätyötä tilastollisten analyysien laatimisessa myös kalliita työtunteja. Sekä ajankäyttö että projektin hinta tulee ottaa huomioon päätöksiä tehdessä. Jos ongelman ratkaisuun on luotettava, nopeampi ja edullisempi menetelmä, voi simulointimallin tekeminen olla epätaloudellista. Tämä pätee yleensä yksinkertaisiin järjestelmiin, joiden tutkiminen taulukkolaskentamalleilla ja jonoteorialla on mahdollista. Satunnaisuutta sisältävien mallien tutkiminen eri
skenaarioilla ja lähtödatalla on usein tehtävä simuloinnilla.
Projektin kustannukset tulee kuitenkin aina suhteuttaa savutettaviin hyötyihin.
Ongelmana tässä on se, että kustannusten arviointi on huomattavasti helpompaa kuin mahdollisten hyötyjen. Tuotantojärjestelmien kustannusrakennetta tuntematon henkilö ei usein edes käsitä millaisia potentiaalisia säästöjä yrityksen logistinen järjestelmä sisältää.
Kokonaishyödyt sisältävät keskeneräisen tuotannon vähenemisen, markkinoilletulo-, läpimeno- ja toimitusajan lyhenemisen sekä laadun ja henkilöstön osaamisen paranemisen. Simulointiprojekti on investointi, jonka takaisinmaksuajan laskeminen on monimutkainen ja usein epävarmuutta sisältävä toimitus. (Greasley 2004)
Vaikka taloudellisesti simulointi todettaisiinkin parhaaksi työkaluksi, voi aikataulu osoittautua ongelmalliseksi. Pelkkä simulointimallin rakentaminen kestää yleensä viikkoja, mutta vielä pidempi aika tarvitaan mahdollisesti
lähtötietojen keräämiseen. Simulointimallin layout ja prosessireititys voidaan tehdä staattisesta järjestelmästä nopeasti, mutta data, joka herättää mallin henkiin koostuu vaiheajoista, tuotejakaumista, resurssien ajankäytöistä, siirtoajoista jne. Jos tätä dataa ei ole projektin alussa käytettävissä, voi sen keräämiseen mennä jopa kuukausia. Jos päätöksenteolle on asetettu aikaraja, voi simuloinnin käyttö olla mahdotonta annetuissa aikaraameissa.
(Greasley 2004)
Jos lähtödata on heti käytettävissä, tulee sen olla myös oikeellista ja luotettavaa. Simulointimalli toimii aina tietotekniikkamaailmasta tutulla GIGO- periaatteella (Garbage in, Garbage out, suom. ”roskaa sisään, roskaa ulos”).
GIGO-periaate viittaa tietokoneiden kykenemättömyyteen analysoida syötettävän datan luotettavuutta ja tapaan prosessoida mitä älyttömimpiä lähtötietoja tuottaen vähintään yhtä älyttömiä tuloksia (Wikipedia). Jos siis simulointimallin lähtötiedot ovat epätarkkoja tai virheellisiä, ovat tulokset yhtälailla epätarkkoja ja virheellisiä, ja nämä ominaisuudet siirtyvät yleensä suoraan myös ihmisten tulosten perusteella tekemiin johtopäätöksiin.
Satunnaisuuden ja epävarmuuden lisääntyminen lisää myös simulointimallin rakentamisen haasteita. Antaakseen tilastollisesti järkeviä, vertailukelpoisia ja luotettavia tuloksia myös lähtötietojen tulee olla tiettyjen rajojen ja jakaumien mukaisia. Täysin satunnainen malli antaa täysin satunnaisia tuloksia, joiden informaatioarvo on mitätön. Kun mallissa esiintyy paljon inhimillisiä valintoja, lisääntyy tämän tyyppinen epävarmuus. Tämä on yksi terveydenhuollon projektien suurimpia haasteita, koska malleissa käytettävät resurssit ovat pääasiassa henkilöresursseja. Henkilöresurssien koulutustason ja työn itsenäisyyden lisääntyessä epävarmuus vain kasvaa. Esimerkiksi lääkäreiden työtapojen tiedetään olevan hyvin henkilökohtaisia, eikä korkeasti koulutettujen, kokeneiden ja vuosien aikana ainutlaatuisen ammattitaidon kehittäneiden lääkärien työtapojen istuttaminen standardoituun muottiin ole muutosvastarinnan ja työmoraalin ylläpitämisen vuoksi kovinkaan helppoa, jos edes mahdollista. Suurin osa palveluteollisuuden järjestelmistä nojaa
pääasiassa henkilöresurssien käyttöön ja inhimilliseen päätöksentekoon, ja nämä projektit asettavatkin täten suuren haasteen simulointimallien rakentajille ja käyttäjille. (Greasley 2004)
2.5 Simuloinnin käyttö terveydenhuollossa
Simuloinnin käytöstä terveydenhuollon kehityshankkeissa ja sen toiminnan kuvaamisessa ei ole olemassa laajaa kirja-aineistoa. Sen sijaan artikkeleja on julkaistu lukuisia, ja tieteellisten julkaisujen laatimisessa on kunnostauduttu varsinkin vuosittaisen Yhdysvalloissa järjestettävän Winter Simulation Conferencen puitteissa. Viimeisen kymmenen vuoden aikana konferenssissa on käsitelty lukuisia terveydenhuollon simulointisovelluksia, ja tutkimuksista on julkaistu laaja kokoelma artikkeleita, jotka ovat julkisesti saatavilla osoitteessa http://www.winsim.org. Tässä kappaleessa perehdytään muutamiin artikkeleihin, jotka koskevat simulointia terveydenhuollossa tai terveydenhuollon kehitysprojekteja, joissa on käytetty simulointia. Lisää kirjallisuutta löytyy mm. perehtymällä Junin, Jacobsonin ja Swisherin (1999) kirjallisuuskatsaukseen.
2.5.1 Simuloinnin soveltuvuus terveydenhuoltoon
Proctor (1996) käsittelee artikkelissaan tapahtumapohjaisen simuloinnin käyttöä sairaalaympäristössä, ja tuo esiin simuloinnin kyvyn testata järjestelmiä poikkeuksilla ja kuormituksilla, joilla todellisen järjestelmän testaaminen olisi vaikeaa tai vaarallista. Proctor toi jo kymmenen vuotta sitten esille mielipiteen, jonka mukaan tapahtumapohjainen simulointi on tehokas työkalu uusien terveydenhuollon toimintamallien etsimisessä.
Lowery (1996) ilmoitti samana vuonna näkemyksensä, jonka mukaan
"Nykyinen terveydenhoitoympäristö on kypsä simuloinnin käytölle”. Simulointi mahdollistaa Proctorin mukaan yksittäisten muutosten laajaan järjestelmään aiheuttamien vaikutusten tarkkailemisen ja arvioimisen. Sairaalajärjestelmät ovat kriittisiä ympäristöjä, joissa ei potilaiden kustannuksella voi kokeilla uusia toimintatapoja, ja jossa yksittäisten henkilöresurssien merkitys kasvaa.
Sairaalan johtajien vastuu on suuri, ja siksi Proctorin mukaan useat uudet ideat voivat jäädä käytännössä kokeilematta, ja vanhat perinteiset menetelmät saavat toimia jatkossakin.
Proctor (1996) ja Lowery (1998) vertaavat simulointia myös staattisiin analyyseihin mainitsemalla, että niiden kyky kertoa yhtäkkisten muutosten, kapasiteettitarpeiden ja muiden tapahtumien vaikutuksesta ja niistä toipumisesta on olematon. Tällaiset tilanteet tarvitsevat dynaamisia analyyseja. Lowery (1996) luettelee useita terveydenhuollon malleja, joiden käytössä tulisi kustannus-, tehokkuus- ja yksinkertaisuussyistä pidättäytyä simuloinnista ja käyttää perinteisiä analyyttisiä malleja. Esimerkkeinä hän mainitsee vuosittaisen henkilöstömäärän määrittämisen osastolle, jolloin voidaan pitäytyä keskiarvotyöajoissa ja -resurssitarpeissa, eikä hajonnalla ole suurta merkitystä. Lyhyemmän aikavälin suunnittelulle, resurssien hienokuormitukselle, simulointi on taas oikea työkalu, koska viikkotasolla henkilöstön työtuntien vaihtelu aiheuttaa jo merkittäviä vaihteluja.
Lowe ry n toteamus terveydenhuollon ympäristön kypsyydestä viittaa hänen näkemykseensä muutoksiin, joita artikkelin kirjoittamisen aikaan oli havaittavissa. Lowery listaa terveydenhuollon ongelmakohtia, jotka ovat hänen mukaansa esteitä simuloinnin implementoinnille terveydenhuollossa.
Kustannustietoisuus ja kustannusten hallitsemisen palkitseminen oli hänen mukaansa lyömässä läpi terveydenhuollossa vuonna 1996. Kustannusten leikkaaminen oli tuolloin äärimmäisen tärkeää, joten vanhat esteet simuloinnin tieltä olivat Loweryn mukaan kaatumassa. Näitä esteitä olivat mm:
1. Terveydenhuollon esimiesten perinteinen luottamus yksinkertaisiin ja deterministisiin päätöksentekotekniikoihin
2. Terveydenhuollon henkilökunnan näkemys simuloinnista epäinhimillisenä ja vieraana menetelmänä.
3. Simuloinnin luonne korkeana teknologiana.
Myöhemmässä artikkelissaan Lowery (1998) toteaa simuloinnin olevan houkuteleva työkalu terveydenhuollossa, koska ”simulointi on äärimmäisen käytännöllinen työkalu epävarmuuden mallintamiseen, joka on merkittävä luonteenpiirre sairauksissa”. Toiseksi houkuttelevuuden syyksi hän mainitsee terveydenhuollolle ominaisen monimutkaisuuden, jossa on useita vuorovaikutteisia osia. Hän muistuttaa kuitenkin terveydenhuollon simulointiprojektien hyötyjen riippuvan kuitenkin myös siitä, että terveydenhuollon ammattilaisten tulee ymmärtää, mihin ongelmiin simulointi voi tarjota ratkaisuja.
David M. Gaba (2004) ennustaa terveydenhuoltoon radikaalia organisaatiouudistusta, jossa simuloinnilla on avainasemassa tekniikkana, joka mahdollistaa muutoksen. Gaba painottaa simuloinnin käyttöä niin laadun, turvallisuuden kuin tehokkuuden parantamisessa. Yksi Gaban tarkoittama menetelmä on käyttää simulointia terveydenhuollossa henkilöstön koulutuksessa erilaisten toimenpidesimulaattorien avulla, kuten lentohenkilökuntaa koulutetaan lentosimulaattoreissa.
Isken ja Rajagopalan (2002) tutkivat tietojen louhimisen (data mining) käyttöä sairaalasimuloinnin lähtödatan laatimisessa. Heidän mukaansa simuloinnin etuna on se, että riittävällä työmäärällä voidaan mallintaa vaikka miten yksityiskohtaisia järjestelmiä, mutta yksityiskohtaisuuden lisääntyessä lähtödatan vaatimukset kasvavat. Artikkelissa kuvatussa projektissa käytettiin simulointimallia, jolla kuvataan sairaalan obstetrisen ja gynekologisen hoidon potilasvirtaa.
Iskenin ja Rajagopalanin mukaan sairaalaosastojen luonteeseen kuuluu, että monet muuttujat kapasiteetin mitoittamisessa ovat satunnaisia, ja siksi hoitovolyymit, hoidon kestot ja hoitomenetelmien resurssivaatimukset on vaikea muuttaa suoraviivaisesti resurssimääriksi ja tilojen mitoitukseksi.
Ilmentymää vahvistaa vielä saapumisten ja poistumisten aikariippuvaisuus.
Resurssien allokointi on kuitenkin äärimmäisen tärkeää, koska henkilöstökustannukset kattavat merkittävän osan kokonaiskustannuksista.
2.5.2 Terveydenhuollon simulointiprojektit
Guo, Wagner ja West (2004) esittelevät artikkelissaan simulointiprojektin, jossa mallinnettiin yhdysvaltalaisen lastensairaalan silmäklinikan toimintaa.
Projekti muistuttaa paljon myöhemmin tässä työssä esiteltävää Hyvinkään terveyskeskuksen mallinnusta, mutta sisältää paikallisia elementtejä, kuten potilaiden jaon hoidon maksajan mukaan (yksityinen tai julkinen vakuutus).
Projektin lähtödata oli Hyvinkään tavoin hyvin saatavilla vain pienin vajavaisuuksin, ja aikataulutukset hoidettiin samalla peruslogiikalla.
Molemmissa projekteissa oli tavoitteena kehittää mahdollisimman tehokas aikataulutusmenetelmä, jolla saadaan minimoitua potilaiden odotusajat ja maksimoitua resurssien käyttöaste. Molemmissa projekteissa pyrittiin lisäksi luomaan geneerisesti käyttökelpoinen simulointimallin alusta, joka on helposti muokattavissa useiden samankaltaisten järjestelmien mallintamiseen.
Lehaney, Kogetsidis ja Clarke (1996) esittelevät keskeneräisen simulointiprojektin rakennusvaiheen, jossa itse prosessimallinnus ja osa lähtötietojen keruusta on suoritettu. Artikkelissa esitellään yksinkertaisesti, miten sairaalan potilasvirtaa voidaan mallintaa ja simuloida ja mitä päätöksentekopisteitä malliin tulee. Tapahtumapohjaista simulointia tuntemattomalle terveydenhuollon ammattilaiselle artikkeli selventää projektin iteratiivista etenemistä, sekä simulointimallin yksinkertaisuutta detaljitasolla, mutta monimutkaisuuden lisääntymistä systeemin laajetessa ja yksityiskohtien lisääntyessä.
Ferrin, Miller, Wininger ja Neuendorf (2004) tutkivat suuren kaupunkisairaalan leikkaussalitoimintaa. Sairaalan johto halusi perustaa palkkiojärjestelmän, mutta oli epävarma järjestelmän rakenteesta ja sen tuomista hyödyistä. Epävarmuutta lähdettiin poistamalla simulointimallilla, josta oli tarkoituksena saada palkkiojärjestelmää tukevan datan lisäksi muita tietoja toiminnan kehittämiseksi. Leikkauspoliklinikan huoneluku haluttiin optimoida suhteessa potilaiden odotusaikoihin, käyttöasteisiin, kustannuksiin ja huonemäärän vaikutukseen koko järjestelmän toimivuuteen.
