JUHA LÄHTEENMÄKI TERVEYDENHUOLLON SELAINKÄYTTÖISTEN TIETOJÄRJESTELMIEN ARKKITEHTUURISUUNNITTELU DIPLOMITYÖ

TAMPEREEN TEKNILLINEN KORKEAKOULU SÄHKÖTEKNIIKAN KOULUTUSOHJELMA JUHA LÄHTEENMÄKI TERVEYDENHUOLLON SELAINKÄYTTÖISTEN TIETOJÄRJESTELMIEN ARKKITEHTUURISUUNNITTELU DIPLOMITYÖ AIHE HYVÄKSYTTY SÄHKÖTEKNIIKAN OSASTONEUVOSTON KOKOUKSESSA 22.8.2001 TARKASTAJA: LEHTORI JUHA NOUSIAINEN

Alkusanat ALKUSANAT Tämä diplomityö on tehty TTKK:n Porin Tietotekniikan yksikössä (TTKK/Tietotekniikka Pori), jossa olen määräaikaisena tutkijana osallistunut ToolsOnLine-projektissa tehtyyn ohjelmiston suunnittelu- ja toteutustyöhön. Pääasiallisena tutkimuskohteena diplomityössäni ovat olleet arkkitehtuurisuunnittelu, arkkitehtuuriratkaisut ja niihin liittyvät tekniikat erityisesti terveydenhuollon ohjelmistokehitystä ja tarpeita silmälläpitäen. Ennen kaikkea haluan kiittää työni tarkastajaa lehtori Juha Nousiaista Ragnar Granit instituutista TTKK:lta hyvistä neuvoista ja kommenteista, jotka ovat auttaneet työn kehittämisessä ja kirjoituksessa monien ongelmatilanteiden yli. Samoin haluan osoittaa erityisen suuret kiitokset professori Pekka Loulalle Porin Tietotekniikan yksiköstä TTKK:lta asiantuntevasta avusta ja myötävaikutuksesta työn suhteen. Lisäksi kiitän kaikkia ToolsOnLine -projektiin osallistuneita henkilöitä, erityisesti projektipäällikkö Mika Huotaria sekä ohjelmistosuunnittelija Risto Suvantoa PhysioTools:sta. Samoin kiitokset TTKK/Tietotekniikka Porin, FD System:n sekä PhysioTools:n koko muulle henkilökunnalle. Yhdessä olette positiivisella suhtautumisellanne ja asiantuntemuksellanne olleet mukana myötävaikuttamassa työn syntymiseen ja siinä tarvittavan tietopääoman keräämiseen. Lopuksi vielä suuret kiitokset kotiväelle kannustuksesta ja kärsivällisyydestä kirjoitus- ja tutkimustyön aikana. Porissa 18.1.2002, Juha Lähteenmäki 2

Sisällysluettelo SISÄLLYSLUETTELO TIIVISTELMÄ...4 ABSTRACT...5 MERKINNÄT JA LYHENTEET...6 1. JOHDANTO...9 2. ARKKITEHTUURISUUNNITTELU TERVEYDENHUOLLON OHJELMISTOKEHITYKSEN OSANA...12 2.1 Ohjelmistokehityksen osa-alueet ja vaiheistaminen...12 2.2 Arkkitehtuurisuunnittelun tavoitteet ja merkitys ohjelmistokehitykselle... 15 2.3 Terveydenhuollon tietojärjestelmien erityispiirteet arkkitehtuurisuunnittelun kannalta... 17 3. ARKKITEHTUURIN OSITTAMINEN JA ARKKITEHTUURIRATKAISUT...26 3.1 Arkkitehtuurin jako suunnittelun näkökulmasta... 26 3.2 Asiakas-palvelin-mallin mukaiset sovellusarkkitehtuuri-ratkaisut... 28 3.3 Komponenttiarkkitehtuuriratkaisut... 33 4. SELAINKÄYTTÖISTEN JÄRJESTELMIEN TEKNOLOGIAT...45 4.1 Selainarkkitehtuuri... 45 4.2 WWW-palvelin ja palvelinteknologiat... 46 4.3 Yhteyskäytännöt ja Web-sovellusten tilanhallinta... 51 4.4 Asiakasteknologiat... 54 4.5 Tietoturvan huomioiminen selainsovelluksissa... 59 5. ARKKITEHTUURISUUNNITTELUN VAIHEET...64 5.1 Hajoita ja hallitse -menetelmä... 64 5.2 Teknisten arkkitehtuuriratkaisujen valinta... 70 5.3 Esimerkki projektina ToolsOnLine... 73 5.4 Vaiheistetun arkkitehtuurisuunnittelun ongelmia... 84 6. YHTEENVETO...87 LÄHDELUETTELO...89 3

Tiivistelmä TIIVISTELMÄ TAMPEREEN TEKNILLINEN KORKEAKOULU (TTKK) Sähkötekniikan osasto, Ragnar Granit instituutti Lähteenmäki Juha, Terveydenhuollon selainkäyttöisten tietojärjestelmien arkkitehtuurisuunnittelu. Diplomityö, 94s Tarkastaja: Juha Nousiainen Joulukuu 2001 Avainsanat: terveydenhuolto, tietojärjestelmä, ohjelmistot, arkkitehtuurisuunnittelu, selain, selaintekniikat. Tietojärjestelmien kehitystyö elää parhaillaan murroskauttaan. Monipuoliset oliolähtöiset teknologiat ja laajat selaimella käytettävät palvelinkeskeiset järjestelmät tarjoavat merkittäviä hyötynäkökohtia verrattuna perinteisiin työasemalähtöisiin sovelluksiin. Uusien teknologioiden ja ratkaisumallien tulo luo kuitenkin myös aivan uusia haasteita ohjelmien kehitykselle. Entistä laajemmat ja monipuolisemmat järjestelmät vaativat myös entistä huolellisempaa ja kokonaisvaltaisempaa rakenteen sekä teknisten ratkaisujen miettimistä eli arkkitehtuurisuunnittelua. Tämän työn tarkoituksena oli kuvata arkkitehtuurisuunnittelua ja selainkäyttöisten järjestelmien teknologioita sovitettuna Suomen terveydenhuollon tarpeisiin. Suunnitteluprosessin avuksi kehitettiin myös yleiskäyttöinen arkkitehtuurisuunnittelun vaiheistusmalli, jota olisi helppo soveltaa työn taustalla olevan ToolsOnline-projektin ja useimpien muidenkin terveydenhuollon tietojärjestelmien arkkitehtuurisuunnittelun yhteydessä. Kehitetyn mallin mukaisesti arkkitehtuurisuunnittelu jaetaan viiteen erilliseen osavaiheeseen. Kukin osavaihe muodostaa järjestelmän arkkitehtuurista oman erillisen kuvauksensa, jota seuraava vaihe yleensä tarkentaa pureutumalla lähemmin yksityiskohtiin. Näin suunnittelun edetessä toisaalta pilkotaan järjestelmää pienempiin palasiin ja toisaalta luodaan pohjaa tarkemmalle suunnittelulle eli ohjataan seuraavien suunnitteluvaiheiden kulkua. Tästä syystä kehitetty malli nimettiinkin hajoita ja hallitse -menetelmäksi. Kokemukset hajoita ja hallitse -menetelmän mukaisesta arkkitehtuurisuunnittelusta olivat ToolsOnLine:n myötä pääosin positiivisia. Vaikka ongelmiakin tuli esille, malliin perustuva ja kontrolloitu arkkitehtuurisuunnittelu oli kuitenkin huomattavasti helpompaa ja nopeampaa kuin perinteinen ad hoc -tyyppinen arkkitehtuurisuunnittelu. 4

Abstract ABSTRACT TAMPERE UNIVERSITY OF TECHNOLOGY Ragnar Granit Institute Lähteenmäki, Juha: Development of browser based healthcare information system architectures Masters Thesis, 94p. Advisor: Juha Nousiainen December 2001 Keywords: healthcare, information system, software, architecture development, browser, browser-based software technologies. The development of information systems is currently under a rapid change. Versatile object-oriented technologies and browser-based Thin-Client systems offer many advantages over traditional workstation dependent Fat-Client solutions. However they also require more broadly-based structure and technique analysis i.e. more carefully done software architectural design. The purpose of this study was to describe the design cycle of browserbased software architecture and the architectural solutions, adapted for Finnish healthcare needs. To make the architectural design easier a generic phase model was also developed. The goal was that the model would be easy to apply especially to healthcare software development. According to the developed model the architectural design cycle was divided into five separate phases. Each of these phases usually generates its own separate description of the architecture as a whole, which is then further specified in detail in the next phase. In this way each phase divides system into smaller pieces but also controls the next phase by creating base for it. For this reason the model was named as hajoita ja hallitse (divide and control). Hajoita ja hallitse -phase model and the selected technical solution were applied and tested to one typical healthcare specific software project, ToolsOnLine. The results were mainly positive. Even though there were some restrictions and lacks in the developed model, the model-based and controllable software architectural design was easier and faster than the traditional ad hoc design. 5

Merkinnät ja lyhenteet MERKINNÄT JA LYHENTEET ADO ADO.NET API ASCX ASP ASPX ja ASP.NET CDA CGI CLR COM ja COM+ CORBA CSS ActiveX Data Objects Uusin.NET:n mukainen versio ADO:sta Aplication Interface.NET:n userkontrollin tiedostotunniste Active Server Pages Uusin.NET arkkitehtuurin mukainen versio ASP:sta Clinical Document Architecture Common Gateway Interface Common Language Runtime Component Object Model Common Object Request Broker Architecture Cascading Style Sheets C# Uusi.NET:n tarjoama ohjelmointikieli (Csharp) DCOM DDCF DICOM DLL DOM EAI EJB EXE Distributed-COM Distributed Document Component Facility Digital Imaging and Communications in Medicine Dynamic Link Library Document Object Model Enterprise Application Integration Enterprise JavaBeans Executable file (suoritettavan tiedoston tunniste) 6

Merkinnät ja lyhenteet HL7 Health Level 7 HOST HTML HTTP HTTPS IDL IE IIOP IIS IP ISAPI ISO JDBC JDK JIT MOM MS MSIL MTS OLE OLEDB tai OLE-DB OMA OMG Isäntä sovellus HyperText Markup Language HyperText Transfer Protocol HTTP over Secure Sockets Layer Interface Definition Language Microsoft Internet Explorer WWW-selain Internet Inter-ORB Protocol Internet Information Server Internet Protocol Internet Server API International Organization of Standardization Java Database Connectivity Java Development Kit Just-In-Time Compiler Message Oriented Middleware Microsoft Microsoft Intermediate Language Microsoft Transaction Monitor Object Linking and Embedding Microsoftin universaalia tietovarastojen (DB = Data- Base) käsittelyä varten kehittämä tekniikka Object Management Architecture Object Management Group 7

Merkinnät ja lyhenteet OOD ORB PC PDA PDF PVX RPC SOAP SQL TCP/IP TON TTKK UI UML URL VB.NET VPN VS.NET WWW = Web XML.NET Object Oriented Design Object Request Broker Personal Computer Personal Digital Assistant Portable Document Format ProVIREX Remote Procedure Call Single Object Access Protocol Structured Query Language Transmission Control Protocol/Internet Protocol ToolsOnLine (ToolsOnLine projekti ja järjestelmä) Tampereen teknillinen korkeakoulu User Interface Unified Modelling Language Uniform Resource Locator Uusin.NET:n mukainen Visual Basic:n versio (VB7) Virtual Private Network Microsoftin sovelluskehittimen (Visual Studio) uusin versio. World Wide Web Extensible Markup Language Microsoftin uusi sovelluskehysarkkitehtuuri 8

Johdanto 1. JOHDANTO Suomalaisen sosiaaliturva ja terveydenhuolto perustuvat pohjoismaiseen hyvinvointiajatteluun [1], jonka ensisijaisena periaatteena on tarjota kansalaisille tasapuolisesti mahdollisimman korkealaatuisia terveydenhuoltopalveluita. Viimeisen vuosikymmenen aikana tämän periaatteen noudattamiselle on kuitenkin tullut uusia haasteita (ks. kuva 1.1). Toisaalta suurten ikäluokkien vanheneminen ja tätä kautta lisääntynyt terveydenhuoltopalvelujen käyttö, toisaalta potilaiden oman aktiivisuuden ja kiinnostuksen lisääntyminen hoitotapahtumaansa kohtaan [2], on kasannut koko terveydenhuollon sektorille muutospaineita. Myös viime lamavuosien seurauksena tehdyt laajat budjettileikkaukset ovat pakottaneet terveydenhuoltoa kehittymään kustannustehokkaampaan suuntaan, eikä perinteinen työvoiman lisäys ole muutenkaan perusteltavissa, onhan terveydenhuolto Suomessa jo ennestään yksi työvoimavaltaisimmista aloista [3]. Kuva 1.1 Suomen terveydenhuollon haasteet lähitulevaisuudessa Ratkaisua uusille vaatimuksille onkin haettu entistä pontevammin tietoteknologian hyödyntämisestä. [24] Sosiaali- ja terveysministeriö asetti 26.4.1995 työryhmän, jonka tehtävänä oli laatia sosiaali- ja terveysministeriön hallinnonalan tietohallinnon toimintastrategia siten, että uuden tietotekniikan avulla parannetaan sosiaaliturvan saatavuutta, laatua ja tehokkuutta. [1]. Tämän 9

Johdanto tietoteknologian hyödyntämisstrategian keskeisiä linjauksia tietojärjestelmien kannalta ovat mm. [1] Kohti tietoyhteiskuntaa kaikille Tietosuojan ja tietoturvan kehittäminen Tietojärjestelmien integraation ja yhteensopivuuden parantaminen Yhdistävänä tekijänä linjauksissa on tietoverkkojen tehokas hyödyntäminen. Internetin käytön räjähdysmäinen laajeneminen ja selainkäyttöiset globaalit järjestelmät ovatkin viimeisten viiden vuoden aikana luoneet uusia valtavia mahdollisuuksia myös terveydenhuollon tietojärjestelmien kehitystyölle. Samalla ohjelmistojen huolellisen etukäteissuunnittelun merkitys on kuitenkin kasvanut. Mutkikkaammat ja avoimet järjestelmät vaativat toteutusta varten paloittelua useampiin osakokonaisuuksiin ja edelleen näiden välisten liityntä- sekä toteutustekniikoiden miettimistä [4]. Tätä prosessia sanotaan tietojärjestelmien arkkitehtuurisuunnitteluksi [5]. Se hahmottaa ohjelmiston rakennuspalikat (komponentit, moduulit jne.) ja tekniikat, joilla nuo palaset liitetään yhteen toimivaksi järjestelmäksi. Hyvin suunniteltu ja oikein valittu arkkitehtuuri näkyy myös järjestelmän valmistuttua helpon ylläpidon, pitkän elinkaaren ja jatkokehityksen mutkattomuuden kautta. Perustellusti voidaankin sanoa, että arkkitehtuurisuunnittelu on ohjelmistokehityksen tärkeimpiä, mutta samalla vaikeimpia osa-alueita, jolla on merkittävä vaikutus koko järjestelmän tulevaisuudelle. Tämän työn tavoitteena oli kartoittaa terveydenhuollon selainkäyttöisten tietojärjestelmien tekniikoita, arkkitehtuuriratkaisuja ja ennen kaikkea arkkitehtuurisuunnittelua kokonaisvaltaisena prosessina. Arkkitehtuurisuunnittelun avuksi pyrittiin myös kehittämään yksinkertainen vaiheistusmalli, joka selkiyttäisi kuvaa suunnitteluprosessin kulusta. Edellä mainittuihin tavoitteisiin liittyi tärkeänä osana aihepiirin tarkastelu terveydenhuollon ja nimenomaan Suomen terveydenhuollon tietojärjestelmäkehityksen kannalta. Tämä näkyy mm. kehitetyn vaiheistusmallin vaiheiden, terveydenhuollon sovellusalueen tarpeiden ja erityispiirteiden kuvauksen yhteydessä. Toisaalta tekniikoiden esittelyssä terveydenhuollon sovellusalue pyrittiin huomioimaan paitsi alueen erityisratkaisujen kautta, myös käsittelemällä ensisijassa vain sellaisia tekniikoita, jotka parhaiten soveltuvat juuri Suomen terveydenhuollon tietojärjestelmätarpeisiin. Työn tavoitteiden taustalla on terveydenhuollon tutkimus- ja tietojärjestelmähanke ToolsOnLine eli TON, jossa kirjoittaja on ollut mukana TTKK:n Porin Tietotekniikkaosaston tutkijana sovellusarkkitehtuurin- 10

Johdanto ja teknisten ratkaisujen suunnittelussa. Työn aihepiirit on pyritty valitsemaan juuri siten, että niitä voitaisiin hyödyntää mahdollisimman paljon TON:n yhteydessä tehtävässä arkkitehtuurisuunnittelutyössä. Erityisen keskeinen osuus TON:lla on ollut kehitetyn vaiheistusmallin koostamisessa, jossa yhtenä tavoitteena oli juuri mallin soveltuminen ainakin tärkeimmiltä osiltaan TON:n käyttöön. Vastaavasti TON on puolestaan tarjonnut arvokasta kokemusta kehitetyn mallin soveltamisesta ja toiminut työssä tavallaan esimerkkiprojektina, joka on tuonut myös käytännön syvyyttä muuten melko teoreettiselle selvitykselle. Työn sisältö Luvussa 2 on esitelty arkkitehtuurisuunnittelu ja sen nivoutuminen ohjelmistokehityksen osaksi. Samalla on myös tarkasteltu mitä erityispiirteitä terveydenhuollon tietojärjestelmiin ja terveydenhuollon ohjelmistokehitykseen liittyy arkkitehtuurisuunnittelun kannalta. Luvussa 3 on paneuduttu arkkitehtuuriratkaisuihin ja arkkitehtuurin osittamiseen. Tässä yhteydessä on käsitelty mm. asiakas-palvelinmalliin liittyvät sovellusarkkitehtuuriratkaisut, middleware ja komponenttiarkkitehtuurit sekä -teknologiat. Luku 4 on omistettu selainkäyttöisten järjestelmien teknologioiden läpikäynnille. Tekniikoista esitellään mm. tavallisimmat selainkäyttöisten järjestelmien palvelin- ja asiakasteknologiat, tilanhallinnan menetelmät sekä asiakkaan ja palvelimen väliset yhteyskäytännöt. Myös selainkäyttöisten järjestelmien kannalta tärkeää tietoturvaa on käsitelty olennaisimmilta osiltaan. Luvussa 5 kuvataan varsinainen arkkitehtuurisuunnitteluprosessi ja sen vaiheet. Tätä silmälläpitäen selvitetään ensin arkkitehtuurisuunnittelua varten työssä kehitetty vaiheistusmalli (hajoita ja hallitse) ja käydään läpi tekniikoiden valintaprosessia ja valinnan perusteita. Tämän jälkeen esitellään ToolsOnLine:n liittynyttä arkkitehtuurisuunnitelmaa esimerkkinä vaiheistusmallin soveltamisesta. Lopuksi luvussa 5 käsitellään vielä arkkitehtuurisuunnitteluun liittyviä ongelmia ja niiden mahdollisia ratkaisumalleja. 11

Arkkitehtuurisuunnittelu terveydenhuollon ohjelmistokehityksen osana 2. ARKKITEHTUURISUUNNITTELU TERVEYDENHUOLLON OHJELMISTOKEHITYKSEN OSANA Ohjelmiston tie kehitysideasta käyttäjälle on usein mutkikas ja pitkä. Monenlaisia vaiheita tarvitaan jo ennen kuin itse ohjelmaa voidaan edes varsinaisesti alkaa pystyttämään. Toisaalta kehitystyö jatkuu yleensä vielä pitkään senkin jälkeen, kun käyttäjälle on toimitettu periaatteessa valmis ohjelma. Jokainen tietokonetta vähänkin käyttänyt lienee tutustunut erilaisiin service pack tyyppisiin päivityksiin, jotka ovat osa tätä ohjelmien valmistumisen jälkeistä kehitystyötä. Yhdessä ohjelmiston rakennuksen eri vaiheita sanotaan ohjelmistokehitykseksi. Tässä luvussa on tarkoitus käsitellä miten arkkitehtuurisuunnittelu liittyy osaksi ohjelmistokehitystä ja mitä erityispiirteitä terveydenhuollon tietojärjestelmiin ja niiden arkkitehtuurisuunnitteluun liittyy. 2.1 Ohjelmistokehityksen osa-alueet ja vaiheistaminen Ohjelmistokehitykseen kuuluu olennaisena osana vaiheistaminen ja vaiheiden yhdistäminen järkeväksi kokonaisuudeksi jonkin vaiheistusmallin kautta. Kuvassa 2.1 on esitettynä ohjelmistokehityksen tärkeimpiä vaiheita vesiputousmalli-tyyppisenä vaiheistuksena: Määrittely Määrittelyvaiheessa (josta voidaan omaksi vaiheekseen vielä erottaa esitutkimus) pyritään luomaan selkeä kuva siitä, mitä toteutettavalta järjestelmältä halutaan. Vaiheen alkuosalle ovatkin tyypillisiä erilaiset käytettävyysselvitykset [18], joiden avulla selvitetään asiakkaan mielestä tärkeitä kehitysnäkökohtia nykyisestä tai muista vastaavista järjestelmistä. Määrittelyvaiheen olennaisin osa on kuitenkin muuntaa asiakkaiden esittämät, usein ristiriitaiset, epämääräiset ja laajat toivomukset eli asiakasvaatimukset ohjelmiston kannalta täsmällisiksi ja järkeviksi toiminnallisuuden kuvauksiksi. [17] [19] [20] Paitsi suoranaisten asiakasvaatimusten priorisointia ja muokkausta määrittelyvaiheeseen liittyy myös paljon muuta selvitys- ja tutkimustyötä kuten järjestelmään liittyvien lakien, asetusten ja standardien selvitys [22][21]. Tämä on olennaista nimenomaan terveydenhuollon ohjelmistoille, joiden toiminta saattaa joissain tilanteissa olla tarkastikin viranomaisten säätelemää [23]. Oliopohjaisessa ohjelmistokehityksessä on tärkeää myös analysoida järjestelmän tietosisältöä ja luokkarakennetta alustavasti jo määrittelyvaiheessa [28], jotta arkkitehtuu- 12

Arkkitehtuurisuunnittelu terveydenhuollon ohjelmistokehityksen osana risuunnittelussa alkuun pääseminen olisi helpompaa ja toteutuksen kannalta ongelmalliset vaatimukset saataisiin karsittua heti projektin alkumetreillä. Kuva 2.1 Ohjelmistokehityksen vaiheet ja kussakin vaiheessa mahdollisesti syntyviä dokumentteja. Vaiheita kuvaavien laatikoiden osittainen päällekkäisyys kuvaa tilannetta käytännön projekteissa. Joskus saatetaan myös joutua palaamaan projektin vaiheissa taaksepäin esim., jos vaatimukset muuttuvat suunnittelun aikana. Suunnittelu Määrittelyvaiheen luonnolliseksi jatkeeksi liittyy yleensä suunnitteluvaihe. Kun määrittely kertoo, miten järjestelmän pitäisi toimia, niin suunnittelu kertoo, millä tavalla tuo toiminnallisuus ja järjestelmä yleensäkin pitäisi toteuttaa [17]. Tavoitteena on päästä mahdollisimman yksinkertaiseen, ymmärrettävään mutta kuitenkin toimivaan ratkaisuun. Suunnittelun tärkeänä osana on arkkitehtuurisuunnittelu, jonka ympärille koko muu suunnittelu ja järjestelmä yleensä rakentuvat. Arkkitehtuurisuunnittelua tarkastelemme yksityiskohtaisesti myöhemmin tässä työssä. 13

Arkkitehtuurisuunnittelu terveydenhuollon ohjelmistokehityksen osana Ohjelmiston arkkitehtuurin miettimisen lisäksi suunnitteluun liittyy järjestelmän yksityiskohtaiset moduulien ja niiden rajapintojen kuvaukset (moduulisuunnittelu). Kustakin moduulista ja komponentista kuvataan riittävän tarkasti sen tarjoamat palvelut, niihin liittyvä toiminnallisuus, poikkeukset sekä muu virhetilanteiden hallinta [28]. Suunnittelun tuloksena syntyy ainakin tekninen määrittely (suunnittelu-dokumentti), johon toisinaan liitetään arkkitehtuurisuunnitelman lisäksi moduulikuvausdokumentit. Komponenttiperustaisessa ohjelmistokehityksessä sen sijaan kunkin komponentin tarjoamat palvelut ja rajapintaluokat kuvaava dokumentti on yleensä omana erillisenä dokumenttinaan. Näin mahdollistetaan se, että komponentin dokumentaatiota voidaan tulevaisuudessa käyttää myös erillään muusta projektin dokumentaatiosta. Toteutus Varsinainen toteutusvaihe alkaa suunnittelun jälkeen. Jo suunnitteluvaiheessa saattaa kuitenkin olla hyödyllistä protoilla joidenkin teknisten ratkaisujen toimivuutta varsinkin, jos sovellettavana on uusia tai tekijöille tuntemattomia tekniikoita. Samalla saadaan suunnitteludokumenttiin arvokkaita esimerkkejä, jotka kertovat yleensä toteutusvaiheessa enemmän kuin tarkkakin sanallinen kuvaus. Toisaalta näitä syntyneitä protoiluversioita ei tulisi käyttää sellaisenaan varsinaisessa toteutusprojektissa, koska niiden rakennetta ei ole loppuun asti tehokkuuden tai muidenkaan teknisten seikkojen osalta mietitty [29]. Toteutusvaiheen onnistumisen edellytyksenä on yleensä huolellisesti ja oikein tehty (arkkitehtuuri)suunnittelu. Järkevä moduuli / komponentti -jako mahdollistaa toteutuksen hajautuksen sopiviin ja toisistaan riippumattomiin palasiin. Toisaalta suunnittelun yhteydessä oikein valitut tekniset ratkaisut helpottavat huomattavasti koodaustyötä ja valmiiden palikoiden yhteensovitusta. Testaus Testausvaihe kuuluu oikeastaan osittain jo toteutusvaiheen yhteyteen. Sen ensisijaisena tarkoituksena on löytää mahdollisimman suuri osa toteutusvaiheessa tehdyistä virheistä [30]. Kukin ohjelmoija testaa oman moduulinsa jo ennen sen virallista valmistumista yleensä itse rakentamallaan testipenkillä. Tätä vaihetta sanotaan moduulitestaukseksi [17]. Lisäksi testaukseen kuuluvat yhteentoimivuutta testaava integrointitestaus ja koko järjestelmälle lopussa suoritettava järjestelmätestaus. 14

Arkkitehtuurisuunnittelu terveydenhuollon ohjelmistokehityksen osana Ylläpito Järjestelmätestauksen jälkeen ohjelmisto on periaatteessa valmis markkinoille. Tulee kuitenkin muistaa, että ohjelmiston kehitys ei yleensä koskaan lopu markkinoille tuloon. Tästä alkaa uusien versioiden kehittäminen, mutta myös usein uuvuttava ylläpitovaihe [17][31], joka on erityisen tärkeä terveydenhuollon tietojärjestelmille ominaisilla pienillä markkinoilla. Myös ylläpitovaiheeseen voi vaikuttaa hyvin tehdyllä suunnittelulla ja hyvin suunniteltu arkkitehtuuri näkyy erityisesti sekä ylläpitovaiheen että jatkokehityksen helppoutena ja pidentää huomattavasti järjestelmän elinkaarta. 2.2 Arkkitehtuurisuunnittelun tavoitteet ja merkitys ohjelmistokehitykselle Sovellusten koko ajan mutkistuessa ohjelmistokehityksen painopiste on vähitellen siirtymässä perinteisestä toteutuksesta eli koodauksesta suunnitteluun [24]. Myös teknisten ratkaisujen monipuolistuminen ja mutkistuminen on lisännyt erityisesti arkkitehtuurisuunnittelun tarpeellisuutta. Aiemmin ohjelmistoyrityksillä saattoi olla vain yksi hallitseva arkkitehtuuriratkaisu jota käytettiin kaikissa sovelluksissa [32]. Nykyisin varteenotettavia ratkaisuja yksinkertaisellekin sovellukselle on vähintään muutamia, joista sopivan löytäminen saattaa edellyttää hyvin perusteellista tietämystä sekä järjestelmän toiminnasta että sovellusympäristöstä ja tietenkin itse ratkaisuista. Valituilla arkkitehtuuriratkaisuilla on myös kauaskantoisia vaikutuksia koko ohjelmistoyrityksen liiketoimintastrategiaan. Kuva 2.2 Arkkitehtuurisuunnittelu osana ohjelmistokehitystä ja suunnittelua. Arkkitehtuurisuunnitteluvaiheessa tunnistetaan järjestelmän perusosat (esim. moduulit ja niiden palvelut), jotka sitten moduulisuunnittelun yhteydessä tarkemmin spesifioidaan. Arkkitehtuurisuunnittelu on siis keskeinen osa ohjelmistokehitystä. Suunnittelun osana se muodostaa järjestelmän teknisen määrittelyn rungon, jota moduulisuunnittelu sitten täydentää lisäämällä tähän run- 15

Arkkitehtuurisuunnittelu terveydenhuollon ohjelmistokehityksen osana koon pienemmät yksityiskohdat arkkitehtuurisuunnitelman sanelemien periaatteiden mukaisesti (ks. kuva 2.2). Tästä lähtökohdasta voidaankin todeta, että arkkitehtuurisuunnitelma tarjoaa ratkaisut, joiden avulla määrittelyn sekavasta toimintojoukosta saadaan järkevä kokonaisuus eli toimiva ja luotettava järjestelmä. Siten se ei enää olekaan pelkästään yksi irrallinen ohjelmistosuunnittelun osa-alue vaan koko ohjelmistokehitysprosessin perusta. Arkkitehtuurisuunnittelun tavoitteet Ohjelmistokehityksen perustavoitteena on yleensä käyttäjää mahdollisimman hyvin palveleva järjestelmä, mahdollisimman vähällä vaivalla (= kustannuksia säästäen) ja yksinkertaisesti. Tähän pyritään mm. laadukkaan arkkitehtuurisuunnittelun kautta. Laadukkaasta arkkitehtuurisuunnitelmasta ja arkkitehtuurista voidaan yleensä erottaa seuraavia tunnusmerkkejä: vaatimusten mukaisuus (oikeellisuus) [42], selkeys, yksinkertaisuus ja systemaattisuus [34], tehokkuus ja hajautettavuus (skaalautuvuus), osittuvuus [28] ja joustavuus [35] Yksi laadukkaan arkkitehtuurin peruslähtökohtia on sen kyky täyttää vaatimukset eli vaatimusten mukaisuus. Vaikka mitään ehdotonta ja oikeaa ratkaisumallia ei olekaan, tulee järjestelmän vaatimukset huomioida tarkoin arkkitehtuuriratkaisun valinnassa. Vaatimusten kannalta riittämätön ratkaisumalli johtaa yleensä joko projektin keskeytymiseen tai vähintään ohjelmiston arkkitehtuurin rapautumiseen, kun ohjelmoinnissa ja moduulisuunnittelussa joudutaan kiertämään arkkitehtuurin puutteita erilaisilla vippaskonsteilla. Toisaalta vaatimuksiin nähden liian raskaan arkkitehtuurimallin käyttö kuluttaa turhaan resursseja ja lisää kustannuksia, eikä sen tuloksena syntyvä järjestelmäkään yleensä toimi parhaalla mahdollisella hyötysuhteella. Vaatimusten mukaisuuskaan ei kuitenkaan vielä ole riittävä tae arkkitehtuurisuunnittelun laadukkuudelle. Itse asiassa hyvästäkään arkkitehtuurisuunnitelmasta ei ole mitään hyötyä, jos kukaan muu ei sitä suunnittelijan lisäksi ymmärrä. Turha mutkikkuus on aina pahasta ja epäjohdonmukainen tai muuten epäyhtenevä ratkaisu ylläpidon painajainen. Tästä syystä arkkitehtuurisuunnittelun tulisikin olla niin yksinkertainen ja selkeä kuin muita perusperiaatteita romuttamatta on mahdollista. Yhtenevä ratkaisutapa tekee myös suunnitelmasta helposti noudatettavan [34] ja keventää näin suunnittelijankin taakkaa, kun joka kohtaa ei tarvitse selittää toteutusporukalle erikseen. 16

Arkkitehtuurisuunnittelu terveydenhuollon ohjelmistokehityksen osana Hajautettavuus ja tehokkuus esitetään usein arkkitehtuurisuunnittelun ensimmäisinä tavoitteina. Viime aikoina niiden merkitys onkin huomattavasti kasvanut, kun laajat verkkopalvelut ja tietojärjestelmät ovat yleistyneet voimakkaasti Internetin vanavedessä. Erityisesti selainkäyttöisissä järjestelmissä on lisäksi tärkeää suhteellisen suureenkin resurssien vaihteluun sopeutuminen eli skaalautuvuus. Tässä tulee puhtaan tehon tarpeen lisäksi tärkeäksi myös resurssien hajautuksen mukauttaminen kuormituksen mukaan, eli jousto siten, että järjestelmä toimii aina mahdollisimman hyvällä hyötysuhteella. Itse asiassa skaalautuvuus kuuluukin yhtenä osatekijänä tässä listatun joustavuuskäsitteen alle, johon käyttäjämääräjoustavuuden lisäksi voidaan lukea myös joustavuus muutosten, virheiden ja käyttöympäristön suhteen. Olipa ohjelma suunniteltu ja toteutettu miten hyvin tahansa, kaikkien laadukkuusvaatimusten noudattaminen täydellisesti on mahdotonta. Arkkitehtuurin laadukkuuden arvioinnin suhteen on myös eri järjestelmien välillä painotuseroja. Esim. potilaan turvallisuuden kannalta kriittisissä reaaliaikajärjestelmissä virhekäsittely on huomioitava aivan eri tasolla kuin vaikkapa perinteisen potilas-kertomusjärjestelmän arkkitehtuurissa. Silti kaikki arkkitehtuurin laadukkuuteen vaikuttavat seikat tulisi ottaa huomioon vähintään pikaisen pohdinnan kautta jokaisessa ohjelmistoprojektissa. Näin taattaisiin järjestelmälle sekä sen arkkitehtuurille pitkä ja huoleton elinikä ja vältyttäisiin tulevaisuudessa ikäviltä yllätyksiltä, joita huolimattomasti tehdyt arkkitehtuuriratkaisut saattavat poikia vielä vuosienkin käytön jälkeen. 2.3 Terveydenhuollon tietojärjestelmien erityispiirteet arkkitehtuurisuunnittelun kannalta Jotta arkkitehtuurisuunnittelu voisi parhaiten vastata sille asetettuihin tavoitteisiin, tulee myös kehitettävän tietojärjestelmän sovellusalue ja sen arkkitehtoniset tarpeet huomioida riittävästi suunnittelun eri vaiheissa. Käytännössä tämä tarkoittaa usein sovellusaluespesifisten arkkitehtuurivaatimuksen selvittämistä ja suunnittelufilosofian sovittamista näiden vaatimusten mukaiseksi. Tässä auttaa ennen kaikkea tietojärjestelmän sovelluskohteiden tuntemus ja sen sovellusaluekohtaisten erityispiirteiden tunnistaminen. Tässä alakohdassa onkin tarkemmin käsitelty, miksi ja mihin tietojärjestelmiä tarvitaan terveydenhuollossa. Lisäksi on pyritty tuomaan esille joitakin terveydenhuollon tietojärjestelmiin liittyviä erityispiirteitä ja erityisratkaisuja ennen kaikkea arkkitehtuurisuunnittelun kannalta. 17

Arkkitehtuurisuunnittelu terveydenhuollon ohjelmistokehityksen osana Tietojärjestelmien sovellusalueet terveydenhuollossa Terveydenhuollon tietojärjestelmällä tarkoitetaan kaikkia terveydenhuollon sektorin toimintaan liittyviä tietojärjestelmiä, kattaen julkisen ja yksityisen terveydenhuollon, itsenäisen ammatinharjoittajan sekä tarpeelliselta osin viranomaistoiminnan [3]. Järjestelmien käyttötarkoitus vaihtelee paljon. Toisaalta tarvitaan pelkästään tiettyyn tarkoitukseen suunnattuja erikoissairaanhoidon järjestelmiä ja toisaalta hyvin laajoja ja muidenkin sovellusalojen käytössä olevia taloushallinnon ja ajankäytön järjestelmiä. Seuraavassa on lueteltu joitakin tyypillisimpiä tietojärjestelmien käyttökohteita terveydenhuollossa [3]: potilas/sairaskertomustietojen hallinta ja varastointi (potilaskertomusjärjestelmät) ajanvaraus (esim. potilaskäyntien ajanvarausjärjestelmät) laskutus ja hallinto (esim. potilaskäyntien laskutus- ja budjetointi- järjestelmät) tilastointi (esim. potilaskäyntien syyn tilastointia tekevät järjestelmät) varastonvalvonta (varastonhallinnan ja -valvonnan järjestelmät esim. liikuntarajoitteisille lainattavien välineiden lainojen hallinta) laboratorio (esim. kliinisen kemian laboratoriojärjestelmät) apteekit (esim. apteekkien lääkevaraston hallintajärjestelmät) hammashuolto (hammashuollon järjestelmät) tieteellinen tutkimus (lääketieteellisessä tutkimuksessa apuna käytetyt, yleensä hyvin spesifiset järjestelmät) erikoissairaanhoito (esim. radiologian järjestelmät) vuodeosasto (esim. vuodeosaston hoitopaikkojen tilannetta seuraavat järjestelmät) avohoito (avohoidon järjestelmät) tehostetun hoidon potilasvalvonta (esim. teho-osaston monitorointijärjestelmät) potilaan yksilöllisen hoito-ohjelman suunnittelu (esim. fysioterapian hoito-ohjejärjestelmät) hoito/tutkimuslaitteet (esim. EKG-monitorointi ja röntgenlaitteiden järjestelmät) elektroniset sanakirjat ja muut hakuteokset (esim. lääkärin CD, elektroninen Pharmaca Fennica jne.) konsultaatio [10] [11] (esim. etäkonsultaation järjestelmät) päätöksenteon tukijärjestelmät (esim. diagnostiset tai hoidonohjausjärjestelmät) Lisäksi tarvitaan tietojenkäsittelyyn luonnollisesti tavallisia toimistoohjelmia (Office-paketti jne.) sekä erilaisia johtamisen järjestelmiä 18

Arkkitehtuurisuunnittelu terveydenhuollon ohjelmistokehityksen osana [3]. Näitä ei kuitenkaan voida pitää varsinaisesti terveydenhuollon tietojärjestelminä. Esimerkkinä Pegasos-terveyskeskusjärjestelmä Pegasos-terveyskeskusjärjestelmä on Novo-konsernin tuottama laaja, lähinnä terveyskeskuksille tai pienehköille sairaaloille suunnattu ohjelmistoperhe, jonka keskeisin osa on Pegasos-terveyskertomus. Pegasoksen ensimmäiset versiot asennettiin keväällä 1992 [12] ja siitä pitäen järjestelmä on ollut erityisen suosittu etenkin pienissä ja keskisuurissa terveyskeskuksissa. Kuva 2.3 Pegasos-terveyskertomusjärjestelmän keskeisimpiä osia [13] Pegasoksen rungon muodostavat yleensä Windows NT -palvelimelle tallennettu järjestelmän tietokanta ja Windows-käyttöjärjestelmällä varustetut työasemat, joihin kuhunkin on asennettu Pegasostyöasemaohjelmisto [13]. Tietokantaa päivitetään reaaliaikaisesti, joten tiedot pysyvät palvelimella aina ajan tasalla. Tämä helpottaa järjestelmän tietojenhallintaa ja varmuuskopiointia, mutta asettaa toisaalta tietoverkolle suurempia kapasiteettivaatimuksia. 19

Arkkitehtuurisuunnittelu terveydenhuollon ohjelmistokehityksen osana Nykyisten tietojärjestelmien yleisen kehityssuuntauksen mukaisesti Pegasoskin on rakenteeltaan modulaarinen eli koostuu helposti lisättävistä ja päivitettävistä palasista (ks. kuva 2.3), jotka mahdollistavat järjestelmän sovittamisen hyvin erilaisten ja erikokoisten terveydenhuollon organisaatioiden tarpeisiin. Terveyskeskusjärjestelmille ominaisen filosofian mukaisesti pyritään samassa paketissa tarjoamaan kaikki terveyskeskukselle tarpeellinen, mikä helpottaa ennen kaikkea pienten organisaatioiden ATK-henkilöstön ylläpitotaakkaa ja poistaa osajärjestelmien välisen kommunikoinnin ongelmia. Terveydenhuollon tietojärjestelmien arkkitehtuurien kehitys ja erityispiirteet Tietokoneet ja tietojärjestelmät tulivat Suomenkin sairaaloihin jo 1960-luvulla [24][7]. Ensimmäiset järjestelmät perustuivat suuriin keskuskoneisiin, joissa käytettiin lähinnä tilastoinnin ja taloushallinnon sovelluksia. Käyttäjät olivat pääosin ATK-alan ammattilaisia [24] eivätkä terveydenhuollon henkilöstöä. Alkuaikojen tietojärjestelmille oli myös tyypillistä, että ne olivat arkkitehtuuriltaan laitteistosidonnaisia (ks. kuva 2.4) ja yleensä järjestelmät joko toimitettiin laitteistojen mukana tai ohjelmoitiin itse laitteistospesifisellä kielellä tai murteella. 1970-luvun loppupuoli ja 1980-luvun alku olivat minitietokoneiden tulemisen aikaa. Samalla laitteistot myös halpenivat huomattavasti ja monet sairaalat saivat omat tietojärjestelmänsä näihin aikoihin. Tyypillinen sairaalan tietojärjestelmä 1980-luvun alussa oli tilaustyönä tai julkisena projektina toteutettu, näyttöpäätteeltä käytettävä palvelinkeskeinen ja merkkipohjainen järjestelmä, jossa oli suljettu ja räätälöity arkkitehtuuri. Tällaisia olivat esim. terveyskeskuksien tarpeisiin suunnattu FINSTAR ja 1980-luvun puolivälissä käyttöön otettu MUSTI [8][7]. Myös erilaisia teho- ja leikkaussaleille suunnattuja monitorointijärjestelmiä alkoi ilmestyä entistä enemmän [8]. 1990-luku merkitsi tietojärjestelmille suurta ulkoasun muutosta. Käyttöliittymiä muutettiin kiireesti graafiseksi [24] uuden ja nopeasti yleistyneen Windows-käyttöjärjestelmän myötä. Kehitysfilosofiaan kuului varsinkin perusterveydenhuollon suurempien järjestelmien alueella organisaatiokohtaisesti räätälöitävät ns. paketti-järjestelmät (esim. Pegasos [12], Sinuhe [25], MedTrak [15]). Ideana oli, että valmistaja tarjosi valmiin ja yhteisen sovelluskehikon eli järjestelmän rungon, jota kukin organisaatio sitten täydensi tarvitsemillaan osapaketeilla 20

Arkkitehtuurisuunnittelu terveydenhuollon ohjelmistokehityksen osana 1971 Ensimmäiset varsinaiset terveydenhuollon tietojärjestelmät. Laitteistosidonnainen arkkitehtuuri. Suuret keskuskoneet 1981 Päätelaite Päätelaite Suljetut merkkipohjaiset järjestelmät 1991 Tulostin PC PC Unix-palvelimet ja graafisen käyttöliittymän tarjoavat Windows-työasemat 2001 PDA-laite Kannettava Linux, Windows NT tai 2000 Server Linkkitorni Skannerit yms. PC Windows 2000 tai Windows 98 Tulostin Selainkäyttöiset järjestelmät, monipuoliset verkot Kuva 2.4 Tietojärjestelmien 30 -vuotinen kehityshistoria terveydenhuollossa 21

Arkkitehtuurisuunnittelu terveydenhuollon ohjelmistokehityksen osana (räätälöitävyys). Arkkitehtuuriltaan järjestelmät perustuivat yleensä Fat-Client-ratkaisuun, jonka pohjana oli TCP/IP-verkko, Unixpalvelin ja Windows-käyttöjärjestelmällä varustetut työasemat. Eri järjestelmien välinen kommunikointi oli edelleen hankalaa, mikä lisäsi organisaatioiden järjestelmä- ja toimittajasidonnaisuutta [9]. 1990- luvun puolivälissä useimmat Suomen terveyskeskuksetkin siirtyivät ATK-aikaan, sairaaloiden pysyessä edelleen entisissä merkkipohjaisissa järjestelmissään [2]. Avoimuus [9], järjestelmien välisen kommunikoinnin helpottaminen ja selainkäyttöliittymät ovat nykyisiä tietojärjestelmäkehitystrendejä myös terveydenhuollossa. Kaksitasoisista Fat-Client-arkkitehtuureista ollaan vähitellen siirtymässä Thin-Client-monitasoarkkitehtuureihin. Erityisesti Web-sovellukset ja niihin liittyen hajautetut oliotekniikat ovat lisänneet suosiotaan. Myös langattomiin tekniikoihin perustuvat järjestelmät ovat tulossa arkipäiväisiksi erityisesti monitorointijärjestelmien puolella. Toimintaympäristön muutokset ja alan kehittämiseen kohdistuneet haasteet ovat osaltaan jouduttaneet tietojärjestelmien käyttöönottoa pienemmissäkin terveydenhuollon yksiköissä. Toisaalta arkkitehtuuriltaan avoimemmat ja helpommin hajautettavissa olevat järjestelmät ovat laajentaneet ja edelleen laajentamassa huimasti perinteisiä tietojärjestelmien sovellusmahdollisuuksia. Perustarve järjestelmien käytölle terveydenhuollon toimijoiden tiedonhallinnan apulaisina on kuitenkin säilynyt samana koko niiden kehityshistorian ajan. Näin arkkitehtuurisuunnittelunkaan olennaisimmat lähtökohdat eivät ole teknisten arkkitehtuuriratkaisujen ja -mallien vaihtumisesta huolimatta muuttuneet kovin paljon 30 vuoden aikana. Terveydenhuollon tietojärjestelmien erityisteknologiat Vaikka terveydenhuollon tietojärjestelmät eivät juuri eroa muista tietojärjestelmistä, niiden arkkitehtuurisuunnitteluun liittyy joitakin erikoisratkaisuja sekä tekniikoita, jotka arkkitehtuurisuunnittelijan on hyvä vähintään tunnistaa niistä puhuttaessa. Yleensä nämä ratkaisut ovat nimenomaan tietojärjestelmien väliseen kommunikaatioon liittyviä standardeja joista tässä esitellään lyhyesti kaksi keskeisintä: HL7 ja DICOM. HL7 ja DICOM HL7 eli Health Level 7 on terveydenhuollon tietojärjestelmien väliseen peruskommunikaatioon tarkoitettu standardi. Se on suunnattu erityisesti sairaaloiden tietojärjestelmien keskinäiseen viestintään, mutta 22

Arkkitehtuurisuunnittelu terveydenhuollon ohjelmistokehityksen osana sopii yleisyytensä vuoksi myös muihin terveydenhuollon alueen tietojärjestelmätarpeisiin. HL7:n perustana ovat sen määrittelemät ja standardoimat erilaiset tekstipohjaiset viestityypit ja niiden rakenne esim. CDA (Clinical Document Architecture) (ks. kuva 2.5). Näin sitä tukevat järjestelmät voivat kommunikoida keskenään yhteisen rajapinnan kautta. HL7:n kehityksestä vastaa HL7 Standards Committee Yhdysvalloissa. Suomessa kehitystä ja soveltamista puolestaan koordinoi HL7 yhdistys, joka toimii nykyisellään VTT:n alaisuudessa. Kuva 2.5 Esimerkki HL7:n määrittelemän CDA-muotoisen sanoman rakenteesta. Sanomassa on ensin ns. otsikko-osa, joka yksilöi ja luokittelee dokumentin ja sisältää tarpeellista tietoa dokumentin varsinaisesta sisällöstä. Otsikko-osan jälkeen seuraa sisäkkäisistä osioista koostuva runko-osa, jossa itse sanoma kulkee [75]. HL7 ei tekstipohjaisena juurikaan sovi kuvainformaation välitykseen. Kuvainformaation siirtäminen on kuitenkin yksi tärkeimmistä tietojärjestelmien kommunikaatiotarpeista terveydenhuollossa ja erityisesti sairaalaympäristössä. Tätä tarkoitusta varten onkin kehitetty oma standardinsa DICOM eli Digital Imaging and Communications in Medicine, joka juuriltaan on HL7:kin vanhempi ja käytännössä myös suositumpi. DICOM on itse asiassa hyvin samankaltainen kuin HL7. Erona kuitenkin on, että sovellusalueena onkin nyt lääketieteellinen kuvantaminen ja välitettävänä datana binäärimuotoista kuvadataa. DICOM toimii HL7:n tapaan tässä vain välikätenä määritellen kielen ja kehykset [26] siirrettäville kuville ja niihin liittyvälle datalle. Tämä toteutetaan mm. spesifioimalla oma yleisluontoinen tiedostoformaatti (Vrt. HL7:n CDA), joka koostuu paitsi kuva-alkioista myös kuvaan liittyvästä yleisestä informaatiosta (meta-data eli DICOM Header) (ks. kuva 2.6). 23

Arkkitehtuurisuunnittelu terveydenhuollon ohjelmistokehityksen osana Kuva 2.6 Esimerkki DICOM-tiedoston rakenteesta. Kuten HL7:n määrittelemässä CDA:ssakin myös DICOM:ssa on ns. header- eli otsikko-osa, joka luokittelee ja yksilöi kuvan sekä sisältää informaatiota kuvan sisällöstä ja potilaasta [26]. Standardien tulevaisuudennäkymiä Terveydenhuollon tietojärjestelmien standardointityö on viimevuosina edelleen lisännyt merkitystään. Mm. HL7:sta ja DICOM:sta saadut positiiviset kokemukset ovat osaltaan auttaneet standardien kehitystyötä eteenpäin. Entistä enemmän on kuitenkin pyritty siirtymään yleisempään suuntaan eli hyödynnetään terveydenhuollossakin jo olemassa olevia ratkaisuja ja tyydytään mieluummin vain esittämään sovellusaluekohtaisia implementointi-ohjeita. Näin vältetään turhaa työtä. Tämän seurauksena mm. XML-pohjaiset ratkaisut kuten esimerkiksi SOAP tulevat olemaan vahvoilla tulevaisuuden standardeja suunniteltaessa. Standardointityö ei kuitenkaan tapahdu silmänräpäyksessä, vaan laahaa aina jonkin verran tekniikkamuotien perässä. Toisaalta tämä on hyväkin asia. Näin käyttöön tulevat aina taatusti koetellut ja turvalliset ratkaisut. Vaikka haavekuvien keskenään täysin yhteensopivista ja kommunikoivista tietojärjestelmistä ollaan vielä kaukana, jo nyt saadut positii- 24

Arkkitehtuurisuunnittelu terveydenhuollon ohjelmistokehityksen osana viset kokemukset ovat osoitus siitä, että standardoinnin avulla voidaan helpottaa paljon tietojärjestelmien välistä yhteydenpitoa. Tämän valossa voidaankin todeta, että tulevaisuudessa järjestelmien lähes täydellinen yhteensopivuus voi muuttua unelmasta todellisuudeksi. Yksi asia kuitenkin on miltei varma, jos näin tulee käymään, se tapahtuu tietysti entistä parempien standardien avulla. 25

Arkkitehtuurin osittaminen ja arkkitehtuuriratkaisut 3. ARKKITEHTUURIN OSITTAMINEN JA ARKKITEHTUURIRATKAISUT Arkkitehtuurisuunnittelun onnistumisen tärkeimpiä edellytyksiä on hahmottaa ja erotella järjestelmän arkkitehtuurista sen keskeiset osakokonaisuudet ja valita sitten kuhunkin osaan siihen parhaiten sopivat arkkitehtuuriratkaisut. Tätä silmälläpitäen onkin järkevää yleensä jo ennen varsinaisen suunnittelun aloittamista tutustua siihen mitä osia arkkitehtuuriin kuuluu ja minkälaisia arkkitehtuuriratkaisuja kuhunkin osaan on tarjolla. 3.1 Arkkitehtuurin jako suunnittelun näkökulmasta Tietojärjestelmän arkkitehtuuri on laaja ja monipuolinen kokonaisuus. Tästä syystä myös arkkitehtuurin osittaminen voidaan tehdä monella eri tavalla. Kuvassa 3.1 on lähestytty arkkitehtuurin jakoa suunnittelun näkökulmasta. Tietojärjestelmän arkkitehtuuri Sovellusarkkitehtuuri Komponentti- ja olioarkkitehtuuri Tietovarastoarkkitehtuuri Laitteisto- ja verkkoarkkitehtuuri Kuva 3.1 Tietojärjestelmän arkkitehtuurin jakautuminen osa-alueisiin 26

Arkkitehtuurin osittaminen ja arkkitehtuuriratkaisut On huomattava, että arkkitehtuurin osa-alueiden nimitykset ja tehtävänjako vaihtelevat runsaasti eri lähteissä. Taulukossa 3.1 on listattuna kunkin elementin merkitys sen mukaisesti kuin sitä on käytetty tässä dokumentissa. Taulukko 3.1 Arkkitehtuurin osa-alueiden tehtävät. Osa-alue: Sovellusarkkitehtuuri Komponentti- ja olioarkkitehtuuri Kuvaus Kuvaa ne tekniset mallit ja periaatteet, joiden avulla järjestelmä jaetaan sopiviin kokonaisuuksiin karkeimmalla tasolla. Monet arkkitehtuuriratkaisumallit ovat sovellusarkkitehtuuritason malleja. Joissain lähteissä esim. [33] käytetään tässä kuvatun sovellusarkkitehtuurien merkityksessä myös järjestelmäarkkitehtuurinimitystä Määrittelee järjestelmän komponentti/luokkatason rakenteen sekä kuvaa järjestelmän komponenttitason osittamisessa käytettävät ja/tai komponenttien välisen yhteyskäytännön tekniikat. Tietovarastoarkkitehtuuri Kuvaa järjestelmän käyttämän tietovaraston rakenteen (esim. tietokannan taulut, kentät ja relaatiot). Lisäksi tietovarastoarkkitehtuuriin liittyy monesti tietovaraston hajautuksen ja yhteyskäytännön ym. tietokantatekniikoiden kuvaus. Laitteisto- ja verkkoarkkitehtuuri Spesifioi järjestelmän toimintaympäristön, siihen kuuluvat verkko- ja laitteistokokoonpanot sekä näiden välisen yhteistoiminnan. Yllä esitellyistä arkkitehtuurin osa-alueista lähinnä sovellus- sekä komponentti- ja olioarkkitehtuuri kuuluvat varsinaisen ohjelmistoarkkitehtuurisuunnittelun piiriin. Silti on muistettava, että arkkitehtuurisuunnitelma on aina pyrittävä saamaan mahdollisimman yhtenäiseksi kokonaisuudeksi, joten myöskään tietovarastoja tai laitteisto/verkkoratkaisuja ei saisi unohtaa ohjelmistoarkkitehtuurisuunnittelun yhteydessä. 27

Arkkitehtuurin osittaminen ja arkkitehtuuriratkaisut 3.2 Asiakas-palvelin-mallin mukaiset sovellusarkkitehtuuriratkaisut Useimmat selain-sovellukset perustuvat nykyisin ns. asiakas-palvelin (Client-Server) -arkkitehtuurimalliin [36]. Asiakas-palvelin-malli on nimensä mukaisesti asiakas- ja palvelinkoneen välinen yhteydenpitomalli. Yksinkertaisimmillaan sen mukainen järjestelmä toimii siten, että asiakas(järjestelmä) (client) lähettää sopivan tiedonsiirtoprotokollan (esim. HTTP) välityksellä palvelupyynnön toiselle järjestelmälle (palvelin eli server), johon tämä sitten pyynnön tulkittuaan vastaa (ks. kuva 3.2). Vastaukseen voi liittyä esim. tietokantahaku, jonka tulokset palautetaan kysyjälle. Asiakas-palvelin-mallia noudattavaan järjestelmään liittyy siis kolme perustekijää: asiakasjärjestelmä, joka pyytää palvelua, palvelinjärjestelmä, joka vastaa palvelupyyntöön pyynnön edellyttämällä tavalla, sekä yhteyskäytäntö, joka määrää, miten tieto siirtyy asiakkaan ja palvelimen välillä. Oleellista on, että asiakas ja palvelin voivat sijaita millä tahansa laitteistoalustalla ja missä tahansa paikassa, jossa tiedon välitykseen käytettävän protokollan mukainen yhteys eli yhteyskäytäntö on mahdollinen [33]. Myöskään järjestelmän roolin (asiakas vai palvelin) ei tarvitse olla mallin mukaisissa järjestelmissä välttämättä pysyvä, vaan palvelin voi yhtä hyvin itse toimia asiakkaana, vaikkapa kysyessään jotain saamansa palvelupyynnön toteuttamisessa tarvittavaa palvelua edelleen toiselta palvelimelta. Yhteyskäytäntö (esim. HTTP) Palvelupyyntö Palvelin Vastaus Asiakas Kuva 3.2 Asiakas-palvelin-mallin periaate. 28

Arkkitehtuurin osittaminen ja arkkitehtuuriratkaisut Sovellusarkkitehtuurin tasot eli kerrokset Selainkäyttöisten, pääosin verkossa toimivien järjestelmien arkkitehtuurin tärkeimpinä vaatimuksina voidaan pitää hyvää hajautettavuutta ja osittuvuutta. Useimmat arkkitehtuuriratkaisumallit keskittyvätkin juuri järkevästi hajautettavissa sekä ositettavissa olevan järjestelmän aikaansaamiseen. Lähtökohtana on sovelluksen jako kuormituksen ja toiminnallisuuden suhteen optimaalisiin mutta toisaalta mahdollisimman itsenäisiin osiin, joita sovellusarkkitehtuuriratkaisujen yhteydessä usein kutsutaan tasoiksi tai kerroksiksi (tiers). Kunkin tason komponentit käyttävät vain alemman tai saman tason tarjoamia komponentteja, mikä helpottaa järjestelmän riippuvuussuhteiden hallintaa. Seuraavassa on lueteltu sovellusarkkitehtuurin perustasot. Käyttöliittymä- eli esitystapataso hoitaa tietojen esittämisen käyttäjäystävällisessä muodossa (käyttöliittymä) ja toisinaan myös syötteiden tarkistuksen. Esitystapakerroksen tehtävät ovatkin pääosin käyttäjäkeskeisiä, minkä takia sen tarjoamia palveluja kutsutaan usein käyttäjäpalveluiksi (User Services). Sovelluslogiikkataso toimii tavallaan järjestelmän aivoina. Siinä hoidetaan varsinainen tietojen käsittely ja muokkaus [38]. Tietovarastotason tehtävänä on suorittaa pyydetyt tietokantakyselyt ja välittää tulokset edelleen käsiteltäväksi ylemmälle sovelluslogiikkakerrokselle. Nämä tasot voidaan tietysti hajauttaa eri tavalla, niitä voidaan yhdistellä tai jakaa edelleen pienempiin osiin [33]. Tässä esiteltävät sovellusarkkitehtuurimallit eroavatkin juuri kerrosjakonsa suhteen. Arkkitehtuuriratkaisujen jako tasojen sijainnin suhteen Sovellusarkkitehtuuritasojen sijainnin perusteella arkkitehtuuriratkaisut jaetaan kahteen pääryhmään. Jos järjestelmän toiminnallisuuden kannalta tärkeimmät kerrokset eli sovelluslogiikka ja tietovarasto sijaitsevat kokonaan palvelimella puhutaan Thin-Client-ratkaisusta. Jos taas vähintään sovelluslogiikka on edes osittain sijoitettu asiakasjärjestelmään, on kyseessä Fat-Client-ratkaisu. Taulukossa 3.2 on vertailtu näiden ratkaisujen hyviä ja huonoja puolia. 29

Arkkitehtuurin osittaminen ja arkkitehtuuriratkaisut Taulukko 3.2 Thin-Client ja Fat-Client-ratkaisujen vertailua. Hyvät puolet on merkitty +:lla ja huonot -:lla. Thin-Client Fat-Client Sovelluslogiikka ja tietovarasto ovat kokonaan palvelimella. Käyttöliittymä on kuitenkin useimmiten asiakaspäässä. Vähintään osa sovelluslogiikasta käyttöliittymän lisäksi on asiakaspäässä. + Järjestelmä helppo ylläpitää ja päivittää. + Ei riipu asiakasjärjestelmästä. Toiminnallisuuden integrointi käyttöliittymään hieman vaikeampaa. + Ei kuormita palvelinta yhtä paljon kuin Thin-Client-ratkaisu. + Kehitystyökaluja hyvin saatavilla. Riippuvainen käyttäjän järjestelmästä. Järjestelmän päivitykset ja ylläpito hankalaa Vaatii asennuksen myös jokaisen asiakkaan koneelle. Kuormittaa tietoverkkoa [33]. Selainkäyttöisissä järjestelmissä Thin-Client-ratkaisut ovat yleensä paremmin perusteltavissa kuin ns. rikkaan käyttöliittymän Fat-Clientmalli. Selain itsessään ei rajoitettuine skriptikielineen sovi mutkikkaan sovelluslogiikan alustaksi. Toisaalta laajojen erillisten komponenttien ja ohjelmistojen asentaminen asiakaskoneelle vie pohjan koko selaimen käytön mielekkyydeltä. Fat-Client-ratkaisujakin tarvitaan mutta selainkäyttöisiin sovelluksiin ne eivät vielä nykyisellään hyvin sovi. Myös palvelimen kuormituksen tasaamiseen on olemassa suositeltavampia keinoja monitasoarkkitehtuurien ja niihin liittyvien hajautusteknologioiden myötä. Arkkitehtuuriratkaisut jaoteltuina tasojen lukumäärän suhteen Paitsi arkkitehtuuritasojen sijainnin mukaan arkkitehtuuriratkaisut voidaan jakaa myös tasojen lukumäärän perusteella. Yleensä nämä ratkaisumallit ovat yksitaso-, kaksitaso- ja monitasoarkkitehtuuri (ks. kuva 3.3 ja taulukko 3.3). Yksitasoarkkitehtuurissa sovelluksen kaikki tasot (tietovarasto, sovelluslogiikka ja käyttöliittymä) ovat yhdessä ja yhdellä palvelimella siis yhdellä laitteistoalustalla. Tämän ratkaisumallin mukaista tapaa edustaa mm. järjestelmien etäkäyttö ns. pääteohjelmien avulla [33]. 30

Arkkitehtuurin osittaminen ja arkkitehtuuriratkaisut Vaikka yksitasoarkkitehtuuri on toteutuksen kannalta yksinkertainen, ei sitä huonon ylläpidettävyyden ja hajautettavuuden takia voi suositella edes kaikkein yksinkertaisimpiin sovelluksiin. Kun arkkitehtuurin kaikki tasot ovat yhdessä, myös osittuvuus kärsii ja yksitasoarkkitehtuuri sopii näin heikosti nykyisiin laajoihin selainkäyttöisiin sovelluksiin. Yksitasoarkkitehtuurista seuraava kehitysaskel on luonnollisesti kaksitasoarkkitehtuuri. Siinä tietokannan käsittely on eriytetty omaksi erilliseksi arkkitehtuurin kerrokseksi, mikä helpottaa tietokantariippumattoman koodin kirjoittamista. Yksitasoarkkitehtuuriin nähden kaksitasoarkkitehtuuri on myös paremmin hajautettavissa, koska tietokanta ja sen käsittely ovat irrallisina siirrettävissä erilliselle palvelimelle [6]. Kaksitasoarkkitehtuurin ongelmana on kuitenkin edelleen sovelluslogiikan ja käyttöliittymätason liittyminen kiinteästi toisiinsa. Tämä vaikeuttaa sovelluksen päivittämistä ja muutakin ylläpitoa. Esimerkiksi käyttöliittymää on hankala muokata tai päivittää erikseen, koska muutoksesta saattaa samalla seurata sovelluslogiikan toimimattomuus [39]. Myös sovelluksen kunnollinen hajauttaminen on hankalaa. Tästä syystä kaksitasoarkkitehtuuria käyttävät järjestelmät ovatkin perinteisesti olleet rikkaan käyttöliittymän Fat-Client-ratkaisuilla toteutettuja järjestelmiä, jotka vaativat monimutkaista syötteiden sekä käyttöliittymän hallintaa asiakaspäässä, eivätkä hyödynnä palvelinta muuten kuin yhteisen tietokantansa ja sen käsittelyn osalta. Esitystapa Esitystapa Esitystapa Sovelluslogiikka Sovelluslogiikka Sovelluslogiikka Kannanhallinta Kannanhallinta Kannanhallinta Yksitasoarkkitehtuuri Kaksitasoarkkitehtuuri Monitasoarkkitehtuuri Kuva 3.3 Yksi-, kaksi- ja kolmetasoisen sovellusarkkitehtuurin rakenne. Monitasoarkkitehtuurin mukainen järjestelmä on loogisten osien erottelun vuoksi joustavampi kuin yksi- tai kaksitasoiset ratkaisut. 31