Standardien arviointi ja valinta terveydenhuollon sovellusintegraatiossa

Transkriptio

1 PLUGIT-HANKKEEN SELVITYKSIÄ JA RAPORTTEJA 3 STUDIES AND REPORTS OF THE PLUGIT PROJECT 3 Juha Mykkänen, Kristiina Häyrinen, Saara Savolainen, Jari Porrasmaa Standardien arviointi ja valinta terveydenhuollon sovellusintegraatiossa KUOPION YLIOPISTO SAVONIA-AMMATTIKORKEAKOULU KUOPIO 2004

2 Tekijät: Juha Mykkänen (myös toim.) Saara Savolainen Jari Porrasmaa HIS-tutkimusyksikkö, Tietotekniikkakeskus Kuopion yliopisto Kristiina Häyrinen Shiftec, Terveyshallinnon ja talouden laitos Kuopion yliopisto Myynti: Tietotekniikkakeskus / kanslia Kuopion yliopisto puh tike@uku.fi ISBN (koko teos) ISBN (osa 3) ISBN (PDF) Kopijyvä Oy, Kuopio 2004

3 Mykkänen, Juha; Häyrinen, Kristiina; Savolainen, Saara; Porrasmaa, Jari. Standardien arviointi ja valinta terveydenhuollon sovellusintegraatiossa. PlugIT-hankkeen selvityksiä ja raportteja s ISBN (koko teos) ISBN (osa 3) ISBN (PDF) Tiivistelmä Avoimet standardit luovat pohjaa sovellusintegraatioratkaisujen menestyksekkäälle toteuttamiselle. Myös terveydenhuollon sovellusintegraatiossa on otettava kantaa siihen, mitkä standardit soveltuvat kulloiseenkin integrointitarpeeseen, mitä asioita standardit kattavat ja mitä jää paikallisesti tai tuotekohtaisesti ratkaistavaksi. Saatavilla on suuri joukko standardeja ja standardien muodostamia standardiperheitä, mutta standardit eivät ole keskenään yhteensopivia, eikä standardien käyttöönoton vaikutuksia terveydenhuollon toimintaan tai ohjelmistoihin voida helposti arvioida ilman selkeitä arviointi- ja viitemalleja. Tämä raportti sisältää viitemalleja ja arviointikehyksen, joita voidaan käyttää sovellusintegraatiossa käytettävien standardien arvioinnissa ja valinnassa. Lisäksi raportissa on lueteltu terveydenhuollon tietotekniikan standardeja sekä ryhmitelty niitä erityyppisiin standardeihin ja standardiperheisiin. Selvitys dokumentoi terveydenhuollon toimialakohtaisten ja yleisten teknisten standardien arvioinnissa ja valinnassa PlugIT-hankkeessa käytettyjä ja kehitettyjä menetelmiä ja malleja. Sen sisältöä on käytetty PlugIT-hankkeessa tuotettavien integrointiratkaisujen määrittelyssä ja toteutuksessa. Dokumentin malleja ja luetteloita voidaan käyttää myös yleisesti määriteltäessä integrointiratkaisuja ja valittaessa standardeja ratkaisujen toteutuksia varten. Käytettyä arviointimallia hyödyntämällä voidaan ryhmitellä standardeja eri tavoin mm. käyttötarkoituksen, standardien kattamien alueiden ja standardiperheiden mukaisesti. Ryhmittely ja arviointi helpottavat erityyppisiin integrointitilanteisiin ja -tarpeisiin soveltuvien standardien ja avointen määritysten valintaa. Yleinen kymmenluokittelu UDK: Asiasanat (YSA): tiedonhallinta, tietojärjestelmät, terveydenhuolto, standardointi, systeemityö, tietoteollisuus Medical Subject Headings (MeSH): medical informatics, information systems, information management, software, health care sector, hospital information systems

4

5 Esipuhe Tämä selvitys on tehty PlugIT-hankkeessa vuosina Selvitys dokumentoi terveydenhuollon toimialakohtaisten ja yleisten teknisten standardien arvioinnissa ja valinnassa PlugIThankkeessa käytettyjä ja kehitettyjä menetelmiä ja malleja. Sen sisältöä on käytetty PlugIThankkeessa tuotettavien integrointiratkaisujen määrittelyssä ja toteutuksessa. Dokumentin malleja ja luetteloita voidaan käyttää myös yleisesti määriteltäessä integrointiratkaisuja terveydenhuoltoon ja valittaessa standardeja ratkaisujen toteutuksia varten. Selvitys toimii taustana erityisesti PlugIT-hankkeen sarjassa ilmestyville selvityksille Terveydenhuollon sovellusintegraatioratkaisujen määrittely ja Avointen integrointiratkaisujen hyödyntäminen, toteuttaminen ja testaus. Selvityksen kohderyhmänä ovat terveydenhuollon ohjelmistoammattilaiset sekä terveydenhuollon tietohallinnon asiantuntijat, jotka ovat tekemisissä integraatiossa käytettävien standardien kanssa. PlugIT-hanketta ovat rahoittaneet ja siihen ovat osallistuneet TEKES, Mawell konserni, Medimaker Oy Ltd, Medici Data Oy, Mediweb Oy, Mylab Oy, Tietoenator Oyj, WM-data Novo Oyj, Atkos Oy, BEA Systems Oy, Commit; Oy, Enfo Oy, Fujitsu Services Oy, General Electric Healthcare CIS EMEA, Mediconsult Oy, Microsoft Oy, Oracle Finland Oy, Helsingin ja Uudenmaan sairaanhoitopiirin kuntayhtymä, Pirkanmaan sairaanhoitopiirin kuntayhtymä, Pohjois-Savon sairaanhoitopiirin kuntayhtymä, Pohjois-Pohjanmaan sairaanhoitopiirin kuntayhtymä, Satakunnan sairaanhoitopiirin kuntayhtymä, Varsinais-Suomen sairaanhoitopiirin kuntayhtymä, Kuopion kaupungin sosiaali- ja terveyskeskus sekä Siilinjärven ja Maaningan terveydenhuollon kuntayhtymä. Tekijät kiittävät kaikkia Tiimitiimin menetelmäkehitykseen osallistuneita. Kiitämme myös projektiin osallistuvien yritysten ja sairaaloiden edustajia hyvistä ideoista ja näkökulmista. Kuopiossa 30. elokuuta 2004 Tekijät

6

7 Sisällys 1 JOHDANTO JA TAUSTA PlugIT-projekti Standardit sovellusintegraatiossa VIITEMALLEJA STANDARDIEN LUOKITTELUUN ISO Reference Model for Open Distributed Processing (RM-ODP) Seitsemän tason yhteentoimivuusmalli STANDARDIEN ARVIOINTI Standardien arviointikehys Esimerkki STANDARDILUETTELO Terveydenhuollon tietotekniikan standardit ja määritykset Terveydenhuollon nimikkeistöt, luokitukset, sanastot ja koodistot Ohjelmistorajapintojen ja integroinnin teknisiä standardeja Standardien luokittelua STANDARDIPERHEET HL7-perheen standardit OMG-perheen standardit CEN:in ja ISO:n terveydenhuoltostandardit LÄHTEET...41

8

9 1 JOHDANTO JA TAUSTA Avoimet standardit luovat pohjaa tietojärjestelmien entistä paremmalle yhteentoimivuudelle ja kustannussäästöille järjestelmien hankinnassa, integroinnissa ja toteutuksessa. Myös terveydenhuollon sovellusintegraatiossa on otettava kantaa siihen, mitkä standardit soveltuvat kulloiseenkin integrointitarpeeseen, mitä asioita standardit kattavat ja mitä jää paikallisesti tai tuotekohtaisesti ratkaistavaksi. Saatavilla on suuri joukko standardeja ja standardien muodostamia standardiperheitä, mutta standardit eivät ole keskenään yhteensopivia, eikä standardien käyttöönoton vaikutuksia terveydenhuollon toimintaan tai ohjelmistoihin voida helposti arvioida ilman selkeitä arviointi- ja viitemalleja. Tämä dokumentti sisältää viitemalleja ja arviointikehyksen, joita voidaan käyttää standardien arvioinnissa ja valinnassa. Lisäksi dokumentissa on lueteltu terveydenhuollon tietotekniikan standardeja sekä ryhmitelty niitä erityyppisiin standardeihin ja standardiperheisiin. Selvitys sisältää vain lyhyesti ja esimerkinomaisesti varsinaisia standardien arviointeja. PlugIT-hankkeeseen liittyvissä muissa selvityksissä on käsitelty tai tutkittu tarkasti useita standardeja, joita mainitaan myös tässä dokumentissa: Terveydenhuollon ohjelmistojen yhteisten palvelujen standardit (Savolainen 2004), CCOW -standardi ja sen toteutus Sentillion Vergence Application SDK:lla (Komulainen, Tuomainen 2002), Component and Service Technology Families (Mykkänen et al. 2004b), Komponentit ja komponenttimallit: Corba, EJB, COM/DCOM,.NET (Päiväniemi 2002), JAAS - Java Authentication and Authorization Service (Sormunen 2003, Sormunen 2004b), Terveydenhuollon avoimet sovellusrajapinnat - yhteiset perusratkaisut (Sormunen ym. 2004a) ja käyttäjä- ja käyttöoikeusrajapinnat (Sormunen 2004b), Terveydenhuollon avoimet sovellusrajapinnat - koodistorajapinnat (Mykkänen et al.2004c). Tämä raportti tarjoaa välineitä standardien ja avointen määritysten tarvelähtöiseen arviointiin ja standardien käyttöönoton sovellus- ja toimintavaikutusten arviointiin. Se ei ota kantaa tai tee suosituksia siitä, mitä standardeja tulisi toteuttaa. Näihin seikkoihin on tehty kansallisia suosituksia esim. lähteessä (Ensio, Ruotsalainen 2004), jossa on myös lueteltu alueita, joille standardeja kansallisesti tarvitaan. 1.1 PlugIT-projekti PlugIT-projekti on vuosina toteutettu valtakunnallinen Tekes-rahoitteinen tutkimus- ja kehittämishanke, joka tuottaa avoimia ohjelmistorajapintojen määrityksiä sekä niihin liittyviä menetelmiä ja osaamista terveydenhuollon ohjelmistoyrityksille ja niiden asiakkaille. Hankkeen tavoitteena on tukea terveydenhuollon palvelutoimintaa ohjelmistotuotannon palveluketjun kautta, paremmin integroituvien ohjelmistokokonaisuuksien avulla (PlugIT 2004). Tutkimuksen sekä rajapintojen määrittelyn ovat toteuttaneet neljä Kuopion yliopiston ja Savonia-ammattikorkeakoulun yksikköä yhteistyössä 15 ohjelmistoyrityksen, kuuden sairaanhoitopiirin (mukaan lukien kaikki yliopistolliset sairaanhoitopiirit) sekä kahden kunnan tai kuntayhtymän kanssa. STANDARDIEN ARVIOINTI JA VALINTA TERVEYDENHUOLLON SOVELLUSINTEGRAATIOSSA 9

10 1.2 Standardit sovellusintegraatiossa Practice Practice guidelines, guidelines, protocols protocols Cochrane Cochrane collaboration collaboration on on Evidence Evidence Based Based Medicine, Medicine, care care protocols protocols Best practices Classifications, Classifications, nomenclatures nomenclatures and and terminology terminology ICD-10, ICD-10, ICPC, ICPC, Snomed-RT, Snomed-RT, LOINC, LOINC, terminology terminology servers servers (UMLS, (UMLS, Galen-in-Use) Galen-in-Use) De De facto facto and and de de jure jure standards standards HL7 HL7 (v3 (v3 RIM, RIM, CDA), CDA), DICOM, DICOM, CEN CEN (EHCRA), (EHCRA), ISO ISO 215, 215, Edifact Edifact Health Health care care specific specific objects objects & & projects projects HANSA HANSA / / HISA, HISA, CORBAmed, CORBAmed, MS MS HUG, HUG, Synapses, Synapses, GEHR, GEHR, emed, emed, Generic Generic standards standards and and tools tools XML XML / / W3, W3, SGML, SGML, HTML, HTML, WML, WML, SMS, SMS, ODP ODP & & messaging messaging platforms platforms (& (& generic generic common common services) services).net.net (COM, (COM, DCOM, DCOM, BizzTalk), BizzTalk), CORBA CORBA & CORBAmed, CORBAmed, Java Java (J2EE) (J2EE) Eri toimittajien tekemien järjestelmien yhteentoimivuuden perusta ovat standardit tai yhteiset sopimukset. Järjestelmien rakentaminen standardien mukaisiksi voi lisätä järjestelmän toteuttamistyötä ja toteutuskustannuksia. Järjestelmien hankkijoiden vastuulla on suosia standardien mukaisia järjestelmiä, jotta organisaation järjestelmäkokonaisuudesta voidaan rakentaa järjestelmien yhteentoimivuutta tukeva. Standardeja kehitetään hyvin monitahoisiin vaatimuksiin lähtien yleisistä teknisistä mekanismeista ja terveydenhuollon viestien ja palveluiden määrittelyistä aina yleisiin luokituksiin, sanastoihin, nimikkeistöihin ja hoito-ohjeisiin asti. Ohjelmistoteollisuus tarvitsee käytännöllisiä ja nopeasti toteutettavia standardeja (Ruotsalainen 2001). Eri organisaatioissa määriteltävien standardien arviointi ja vertailu on tarpeen näiden seikkojen selville saamiseksi ja toisiaan tukevien määritysten valitsemiseksi. Koska saatavilla on hyvin kirjava joukko erilaisia standardeja, tarvitaan tukea standardien arviointiin ja valintaan. Tässä dokumentissa esitetään malli tätä tarkoitusta varten. Mallia on käytetty siten, että esitellään yhteenvedonomaisesti muutamia tutkittuja ja käyttökelpoisia standardeja ja määrityksiä, joita voidaan hyödyntää terveydenhuollon sovellusintegraatiossa. Kuva 1.1 hahmottaa standardien roolia terveydenhuollossa ja terveydenhuollon tietojärjestelmissä. Infrastructure Kuva 1.1. Terveydenhuollon standardien hierarkia (Saranummi 2000). Terveydenhuollon sovellusintegraatioratkaisujen määrittelyssä standardeja voidaan hyödyntää ratkaisun määrittelyjen ja toteutusten eri vaiheissa (ks. kuva 1.2). Integrointiratkaisujen määrittelyn vaiheet on kuvattu tarkemmin dokumentissa (Mykkänen et al. 2004a). Toimialakohtaiset viite- ja sisältömallit ovat hyödynnettävissä sekä silloin, kun määritellään kohdealueen käsitteitä (vaihe 1 kuvassa 1.2) että silloin, kun määritellään tuotettavan ratkaisun sisältöä tiedon tai toiminnallisuuden osalta (vaihe 4). Esimerkki tällaisesta toimialakohtaisista viitemalleista on mm. HL7 version 3 RIM-malli. Standardoituja sisältöjä terveydenhuollossa ovat mm. terveydenhuoltospesifien prosessien tai toimintoketjujen (esim. IHE integration profiles), viestien tai dokumenttien tietosisältöjen (esim. HL7-viestit, CDA-dokumentit) tai ohjelmistorajapintojen (esim. OMG:n, HL7:n ja PlugIT-hankkeen ohjelmistopalveluiden) yleiset määrittelyt. Tässä vaiheessa voidaan yleensä määritellä tietosisältöjä ja tietotyyppejä, jaettavia toimintoja, käytettäviä tunnisteita ja koodistoja sekä esim. tietoturvan järjestämismalleja. 10 PLUGIT-HANKKEEN SELVITYKSIÄ JA RAPORTTEJA 3

11 -integrointivaatimukset -sovellusarkkitehtuuri -olemassaolevien sovellusten toiminnallisuus -sovellusten alusta 1. Kohdealueen analysointi 2.Sovellusarkkitehtuurin tunnistaminen 3. Olemassaolevien sovellusten tekniikoiden tunnistaminen 1. INTEGRAATIO- VAATIMUKSET -sisällölliset ja toimialan standardit -toiminnalliset integrointipisteet -integrointipisteet kohdearkkitehtuurissa -semanttiset vaatimukset 4. Toiminnallisten liittymien tunnistaminen -teknologiariippumattomat liittymät 5. Liittymätekniikoiden valinta -uusi sovellusinfrastruktuuri -integrointiteknologiat -olemassaoleva tekninen infrastruktuuri -tekniset standardit -uudet metodit, työkalut and teknologiat 2. TEKNIIKKA- RIIPPUMATON LIITTYMÄMÄÄRITTELY 6. Liittymien määrittely 3. TEKNINEN LIITTYMÄ- MÄÄRITTELY -tekniset liittymät 7. Toteutuksessa käytettävien tuotteiden valinta Kuva 1.2. Integrointiratkaisujen määrittelyprosessi. Viitemalleja ja toimialakohtaisia standardeja on tarkennettava teknisiksi määrittelyiksi, jotta sovellusohjelmistot toimivat teknisesti yhteen sovitulla tavalla. Sovellusten välisten rajapintojen Teknisissä liittymämäärittelyissä hyödynnetään teknisiä standardeja (vaihe 5). Teknisissä määrityksissä voidaan ottaa kantaa mm. tiedonsiirtotapoihin, tiedon siirtoesitykseen, rajapintojen teknisiin valintoihin, tietoturvan tekniseen toteutukseen jne., eli kuvata terveydenhuoltospesifien rajapintojen tai määritysten toteutus valituilla rajapintatekniikoilla. Tietyn standardin noudattaminen voi tulla integraation määrittelyprosessiin ulkoisena vaatimuksena (esim. kansalliset suositukset) (Ensio, Ruotsalainen 2004). Tällöin tämän raportin mukaista arviointimallia voidaan käyttää esim. paikallisesti ratkaistavien seikkojen tunnistamiseen tai sellaisten alueiden tunnistamiseen, joille tarvitaan lisäsuosituksia. STANDARDIEN ARVIOINTI JA VALINTA TERVEYDENHUOLLON SOVELLUSINTEGRAATIOSSA 11

12 2 VIITEMALLEJA STANDARDIEN LUOKIT- TELUUN 2.1 ISO Reference Model for Open Distributed Processing (RM- ODP) ISO on määritellyt Reference Model for Open Distributed Processing (RM-ODP)-mallin hajautettujen järjestelmien tarkastelemiseksi eri näkökulmista. Näkökulmien avulla voidaan erottaa toisistaan eri näkökulmia järjestelmien suunnittelua varten, koska kaikkien aspektien sisällyttäminen yhteen kuvaukseen on yleensä mahdotonta. Näkökulmat on määritelty seuraavasti (ISO/IEC 1995): the enterprise viewpoint, which is concerned with the business activities of the specified system; Enterprise specification of an ODP system is a model of the system and the environment with which the system interacts. It covers the role of the system in the business, and the human user roles and business policies related to the system. Standardin voidaan katsoa kuuluvan enterprise-näkökulmaan, jos se kattaa järjestelmän tai järjestelmien yli ulottuvan alueen, kokonaisia toimintaprosesseja, tai runsaasti muiden eri näkökulmien asioita siten, ettei mikään niistä ole ensisijainen. Myös jos määrityksessä kuvataan pelkästään ihmisen toimintaa tukevia ohjeita (hoito-ohjeet jne.), johon ei liity sinällään automaattista tietojenkäsittelyä, on määrityksen alue sovellustarkastelun ulkopuolella ja kuuluu enterprisenäkökulmaan. the information viewpoint, which is concerned with the information that needs to be stored and processed in the system; An information specification of an ODP system is a model of the information that it holds and of the information processing that it carries out. The information model is extracted from the individual components and provides a consistent common view which can be referenced by the specifications of information sources and sinks, and the information flows between them. Standardi kuuluu information-näkökulmaan, jos sen keskeisin anti on rajapintojen tietosisällön (tietokokonaisuudet, tietoelementit) tai tietosisällön viitemallin määrittely, sanaston, nimikkeistön tai luokituksen (ja niihin liittyvän koodiston) määrittely tai käsitemalli. Liki kaikissa standardeissa sivutaan jotain näistä asioista, mutta olennaista on löytää keskeinen standardin kattama alue. the computational viewpoint, which is concerned with the description of the system as a set of objects that interact at interfaces - enabling system distribution; A computational specification of an ODP system is a model of the system in terms of the individual, logical components which are sources and sinks of information. Using the computational language, computational specifications can express the requirements of the full range of distributed systems, providing the maximum potential for portability and interworking and enabling the 12 PLUGIT-HANKKEEN SELVITYKSIÄ JA RAPORTTEJA 3

13 definition of constraints on distribution, while not specifying the detailed mechanisms involved. Käytämme computational-näkökulmaa siten, että standardi kuuluu siihen, jos sen keskeisin anti on vuorovaikutuksen, kutsuttavien operaatioiden tai toimintojen määrittely. the engineering viewpoint, which is concerned with the mechanisms supporting system distribution; An engineering specification of an ODP system defines a networked computing infrastructure that supports the system structure defined in the computational specification and provides the distribution transparencies that it identifies. It describes mechanisms corresponding to the elements of the programming model, effectively defining an abstract machine which can carry out the computational actions. and the provision of the various transparencies needed to support distribution. Mallissamme standardi tai määrittely kuuluu engineering-näkökulmaan, jos se määrittelee sovellusarkkitehtuuria, järjestelmän hajautusta tai järjestelmän suoritusta tai hajautusta tukevaa infrastruktuuria. the technology viewpoint, which is concerned with the detail of the components from which the distributed system is constructed. A technology specification defines how a system is structured in terms of hardware and software components. Standardi tai määrittely kuuluu technology-näkökulmaan, jos se keskittyy teknologiseen toteutukseen, määrittelee tekniikan, jolla tiedon tai toiminnallisuuden yksityiskohdat toteutetaan sovelluksessa tai sen rajapinnassa. Kuva 2.1. Joidenkin standardien sijoittelua RM-ODP-mallin avulla (Culpepper 2001). Huom. erot tässä käytetyssä tarkastelussa Engineering ja Technology-tasoilla. Kuvassa 2.1 Näkökulmat eivät ole järjestelmän kerroksia tai suunnittelumenetelmiä, vaan joukko tiettyihin asioihin kohdistuvia kysymyksiä ja ratkaisuja. Näkökulmat eivät ole toisistaan STANDARDIEN ARVIOINTI JA VALINTA TERVEYDENHUOLLON SOVELLUSINTEGRAATIOSSA 13

14 riippumattomia. Järjestelmän määrittelyt kustakin näkökulmasta ovat osittaisia näkymiä koko järjestelmään, ja esim. samat käsitteet voivat esiintyä useissa näkökulmissa. 2.2 Seitsemän tason yhteentoimivuusmalli Toinen käyttökelpoinen malli myös standardien kattamien alueiden arvioinnissa on seitsentasoinen järjestelmien yhteentoimivuusmalli (Herzum, Sims 2000). Eri tasojen tunnistaminen on hyödyllistä yhteensovittamista suunniteltaessa ja käytettäviä tekniikoita ja standardeja valitessa. Kehitysprosessin liittymät Toiminnallinen viitemalli Semantiikka Toiminnalliset liittymät Sovellusinfrastruktuuri Tekninen infrastruktuuri Tekniset liittymät Seitsentasoinen yhteentoimivuusmalli (Herzum, Sims 2000). Mallissa on järjestelmien yhteentoimivuuden suhteen tunnistettu seuraavia tasoja: 1. Tekniset liittymät ovat ohjelmistomekanismeja, joilla kohdejärjestelmään ollaan yhteydessä. Tämän tason sopiminen tarkoittaa käytettävän tekniikan sopimista, esim. COR- BA:n, RPC:n, DCE:n tai suoran SQL-kielen käyttöä jaettuun tietoon pääsemiseksi. Teknisen liittymän protokolla voi olla myös usean tekniikan yhdistelmä, esim. XML:n käyttö CORBA-liittymän päällä. Tekninen liittymä voi olla tietokantaperusteinen, tiedostopohjainen yhdyskäytävä tai ohjelmointirajapinta (API) tai näiden yhdistelmä. 2. Tekninen infrastruktuuri. Mahdollisuus kutsua teknisesti toisen järjestelmän liittymää ei poista kahden järjestelmän välisen vuorovaikutuksen teknisiä ongelmia. Esim. kohdejärjestelmän on joko oltava käynnissä, jotta sitä voi kutsua, tai kohdeympäristön on tiedettävä, kuinka käynnistää kohdejärjestelmä kutsun tullessa. Se kuinka aktivointi tapahtuu, kuuluu teknisen infrastruktuurin vastuulle. Tekninen infrastruktuuri kattaa kahden järjestelmän välisen kommunikoinnin teknisen tuen, ja sisältää mm. virheidenkäsittelyn, nimeämisen, transaktiot jne. 3. Sovellusinfrastruktuuri. Toiminnallisen yhteensopivuuden saavuttamiseksi tarvitaan sovellusinfrastruktuuria, joka sisältää arkkitehtuuriset päätökset, käytännöt, liittymäkäytännöt ja suunnittelumallit. Kukin teknisen infrastruktuurin protokolla kääntyy joksikin sovellusinfrastruktuurin protokollaksi. Tällä alueella ei ole juuri standardeja, joten yleensä kehitetään projektin tarpeisiin oma ratkaisu, joka vaatii tulkkausta tai sovitinta yhteentoimivuuden tukemiseksi. Sovellusinfrastruktuurin protokollia ovat esim. tapa, jolla joillekin ryhmille sallitaan operaatioita ja toisilta ne kielletään sekä usein teknisten tai toiminnallisten virhetilanteiden käsittely. 14 PLUGIT-HANKKEEN SELVITYKSIÄ JA RAPORTTEJA 3

15 4. Liittymien sisältö (toiminnalliset liittymät). Mikäli projekti on päättänyt, että liittymien määrittelyyn käytetään tiettyä tekniikkaa, tiedetään, millainen tekninen infrastruktuuri tarvitaan ja miten liittymää kutsutaan teknisesti. Tällöin ei kuitenkaan tiedetä mitään toiminnallisesta liittymästä. Esim. teknisiin ratkaisuihin ei kuulu se, onko operaatio hae_potilas vai lisaa_tutkimus. Toiminnallisessa liittymässä määritellään operaatioiden toiminnalliset nimet ja parametrit. Teknisten ja toiminnallisten liittymien muodot ovat suorassa yhteydessä toisiinsa: toiminnallisten liittymien määrittelyssä käytetään teknisen infrastruktuurin tarjoamia mahdollisuuksia. Toiminnallisen liittymän määrittely voidaan tehdä prosessoinnin tyypin tai tiedon tyypin avulla. Esim. HL7 ja EDIFACT keskittyvät tiedon (viestin) sisällön standardointiin, kun esim. OMG:n määrittelemät toiminnalliset liittymät keskittyvät prosessointiin ja toiminnallisuuteen. Ohjelmointirajapintaa käyttävissä liittymissä nämä päätökset näkyvät operaatioiden nimien ja parametrien määrittelyissä sekä operaatioiden välisissä yhteyksissä. 5. Semantiikka. Kun toiminnallisista liittymistä on sovittu, on tarpeen sopia kunkin interaktion tarkasta merkityksestä. Pelkästään liittymiä tarkastelemalla ei operaation merkityksestä saa kuvaa. Toiminnan kannalta liittymän operaation tai tietoelementin merkitys on kuitenkin äärimmäisen tärkeä. Sama liittymä voi johtaa eri tapauksissa hyvin erilaiseen lopputilaan järjestelmissä, ja kutsujalle palautuvan tiedon merkitys voi poiketa paljonkin eri tapauksissa. Näin ollen alemmilla tasoilla tarkasti sovitulla liittymällä voi olla hyvin erilaisia merkityksiä. Myös eri tietoalkioiden koodauksessa käytettävät mittayksiköt ja koodistot kuuluvat semanttiseen yhteentoimivuuteen. Kuvaus on usein sanallinen, mutta tarkkoja semanttisia määrityksiä voidaan tuottaa myös johtamalla ja tarkentamalla käsitteet yleisistä ontologioista (stereotyypit). 6. Toiminnallinen viitemalli. Täyden yhteentoimivuuden saavuttamiseksi tarvitaan toiminnallinen viitemalli. Jos esimerkiksi kutsuvassa järjestelmässä potilaan tunniste on 10 merkkiä pitkä, ja kohdejärjestelmässä 36 merkkiä pitkä, kutsuva järjestelmä ei kykene käyttämään saamaansa tietoa oikein. Liittymillä voi siten olla hyvin suora suhde järjestelmän sisäiseen toteutukseen. Mikäli järjestelmillä ei ole yhteistä toiminnallista viitemallia, niiden toiminnallisuus rajoittuu toiminnallisuuden pienimpään yhteiseen osajoukkoon. Järjestelmässä toiminnallinen viitemalli on yleensä täysin sisäinen: esim. ainoa tapa kohdejärjestelmän tietokannan lukemiseen tarkoitetun hakulauseen kirjoittamiseen on tietää kohdejärjestelmän tietokantakuvaus. Poiketen (Herzum, Sims 2000) -lähteestä, toiminnallinen viitemalli voi olla myös järjestelmien välillä jaettava, esim. yhteisen sovellusalueen kattava malli toimialan tietosisällöstä, kuten HL7 RIM. 7. Kehitysprosessin liittymät. On tilanteita, joissa järjestelmässä tiedetään jo aikaisessa kehitysvaiheessa, minkä järjestelmien kanssa yhteistoiminnallisuutta tarvitaan. Tällöin mukana olevien järjestelmien rajoitukset ja mahdollisuudet voidaan ottaa huomioon jo varhain kehitysprosessissa. Esimerkiksi jotta järjestelmien yhteistoiminta on mahdollista jo suunnittelun ja kehitystyön aikana, voi olla tarpeen saada käyttöön toisen järjestelmän spesifikaatio, jotta järjestelmien integrointi tai yhteistoiminnallisuus saavutetaan. Kehitysprosessin liittymien protokollat voivat ottaa kantaa myös jakeluun, kuten määritellä tarkasti sellaisten tiedostojen loogisen tai jopa fyysisen sijainnin, joita yhteistoiminnallisuuden toteuttamiseen tarvitaan. Tasot 1-6 on sovittava järjestelmiä integroitaessa joko standardin tai tapauskohtaisen käytännön avulla. Malli perustuu yhteentoimivuusprotokollien tunnistamiseen ja määrittelyyn eri tasoilla. Yhteentoimivuusprotokolla (interaction protocol) on joukko sääntöjä, jotka määrittelevät kahden tietojärjestelmän välisen vuorovaikutuksen. Yhteentoimivuusprotokollat voivat sisältää järjestelmien STANDARDIEN ARVIOINTI JA VALINTA TERVEYDENHUOLLON SOVELLUSINTEGRAATIOSSA 15

16 välisten viestien muodon määrittelyjä ja myös näiden viestien vaihtamiseen käytettäviä tekniikoita. Järjestelmät voivat olla vuorovaikutuksessa hyvin eri tavoin, alkaen hyvin löyhästi määritellyistä protokollista, jotka vaativat tulkkaamisen molemmissa päissä, tiukasti integroituun yhteistoimintaan, jossa järjestelmät kommunikoivat natiivisti, eli käyttäen identtisiä protokollia kaikilla tasoilla. Esimerkiksi teknisissä liittymissä voitaisiin hyödyntää sekä XML- että CORBA-tekniikoita samassa rajapinnan operaatiossa, jos CORBA-operaation tietoparametrit olisi merkattu XMLmerkkausten avulla. Eri tasoilla tehdyillä ratkaisuilla ja käytetyillä standardeilla on myös vaikutuksia muille tasoille. Samoin kuin RM-ODP-näkökulmat, myös yhteentoimivuustasot ovat tietystä näkökulmasta ratkaisuun vaikuttavia seikkoja, mutta tietty RM-ODP näkökulma vaikuttaa usein moniin tämän mallin tasoihin, joten ne täydentävät toisiaan. 16 PLUGIT-HANKKEEN SELVITYKSIÄ JA RAPORTTEJA 3

17 3 STANDARDIEN ARVIOINTI 3.1 Standardien arviointikehys Tässä luvussa kootaan eri standardien suhteen esitettäviä kysymyksiä, joihin vastauksia etsimällä voidaan arvioida ja valita standardeja ja toisiaan tukevia standardipaketteja. Standardit keskittyvät yleensä pelkästään joihinkin seuraavista osa-alueista, eikä mikään standardi kata täysin kaikkia osaalueita. Onkin järkevää jättää kootusta tarkastelusta pois ne luettelon kohdat, joihin standardissa ei oteta kantaa. Viitemallin avulla voidaan muodostaa kuva siitä, mihin asioihin standardi ottaa ja ei ota kantaa, ja tarkempaa arviointia (esim. tietyn näkökulman suhteen) voidaan tehdä juuri kyseisen tyyppisten standardien arviointiin soveltuvilla menetelmillä. Useiden tarkasteltavien kohteiden kohdalla voidaan kysyä sekä Mitä standardi määrittelee? että Miten standardi määrittelee sen (mitä kuvaustapaa tai tekniikkaa käyttäen)?. Näiden kysymysten vastauksista on usein suora suhde etenkin seitsentasoisen viitemallin tasoille 4 (liittymien sisältö) ja 1 tai 7 (tekniset liittymät tai kehitysprosessi). Kohdealue (scope): sanallinen kuvaus standardin tarkoituksesta sanallinen kuvaus standardin kohdealueesta, esim. o liittyykö standardi terveydenhuoltoon yleisesti o liittyykö standardi johonkin terveydenhuollon erikoisalueeseen (clinical scope) tai tietyn tyyppisiin terveydenhuollon tietojärjestelmiin (esim. onko standardi kohdealueriippumaton, eli käytetäänkö sitä eri sovellusalueilla sijoittuminen RM-ODP-mallissa (ks. luku 2.1), ottaako standardi erityisesti kantaa johonkin näkökulmaan tai useisiin niistä (seuraavien kohtien kysymysten avulla voidaan tarkentaa vastausta tähän kysymykseen) o enterprise o information o computation o engineering o technology sijoittuminen seitsentasoisessa mallissa (ks. luku 2.2), ottaako erityisesti kantaa johonkin yhteentoimivuustasoon järjestelmien välisten liittymien määrittelyn kannalta (seuraavien kohtien kysymysten avulla voidaan tarkentaa vastausta tähän kysymykseen) 1. tekniset liittymät (toteutustekniikat tai liittymätekniikat) 2. tekninen infrastruktuuri (toteutusta tukeva tekninen pohja) 3. sovellusinfrastruktuuri (hajautus, sovellusarkkitehtuuri) 4. liittymien sisältö (määritellyt toiminnot tai tietosisältö järjestelmien välisessä integraatiossa) 5. semantiikka (määritellyn tietosisällön merkitys, koodistot, luokitukset jne.) 6. toiminnallinen viitemalli (toimialuekohtainen tieto- tai vuorovaikutusmalli tai tietty tuettu menetelmä) 7. kehitysprosessin liittymät (kuinka järjestelmiä kehitetään tai integroidaan) STANDARDIEN ARVIOINTI JA VALINTA TERVEYDENHUOLLON SOVELLUSINTEGRAATIOSSA 17

18 Toiminnot ja tietosisältö: kuvataanko standardissa yleinen tieto- tai käsitemalli tai tietosisältö o onko tunnistettu ja eritelty keskeiset käsitteet, mitkä ne ovat o onko tunnistettu ja eritelty käsitteiden väliset suhteet (käsitemalli) ja perustuuko malli siihen, että käsitteet on erikoistettu yleisestä mallista (ontologia) o onko tunnistettu ja määritelty eri käsitteisiin kuuluva tietosisältö (tarkat sisältöelementit) o onko määritelty viestien sisältöelementtejä tai niiden tietotyyppejä o onko määritelty, kuinka tietosisältö kuvataan tai merkataan (kuinka tarkat sisältöelementit määritellään, metatiedot) o onko sisältöelementtien merkitys kuvattu (sanallisesti tai ylemmän tason viitemallia käyttäen) o onko määritelty viestien rakenne o onko tietosisällön elementeille määritelty sallitut arvot tai arvoalueet (arvojoukko, nimikkeistö, koodisto) o jos kyseessä on esim. luokitus tai muu tietomäärittely, olettaako se tietyn menetelmän käyttöä (vaikutus toiminnalliseen viitemalliin) kuvataanko standardissa toimintoja, joita järjestelmät suorittavat tai tarjoavat toisilleen o järjestelmien välisiä toimintoja o järjestelmien välisiä transaktioita o järjestelmien toisilleen lähettämiä viestejä o järjestelmien kutsusuhteita o liittymien operaatioita o toimintaprosessien tai työnkulkujen määrittelyitä järjestelmien tai käyttäjän näkökulmasta o onko määritelty, kuinka toiminnallisuus kuvataan kuvataanko standardissa kohdealueen sanaston, luokituksen tai nimikkeistön tai niihin liittyvien koodistojen tietosisältöä kuvataanko standardissa järjestelmän kohdealueella tapahtuvaan toimintaan tai päätöksentekoon liittyviä ohjeita, esim. hoito-ohjeita, päätöksenteon logiikkaa jne. Sovellusarkkitehtuuri: mikä on yhteistoiminnallisuuden perusmalli tai otetaanko siihen kantaa, esim. o oliopohjaisuus o hajautetun palvelun käyttö o tapahtumien käyttö o viestien käyttö perustuuko standardi tai integrointitapa siihen, että o järjestelmät ottavat suoraan toisiinsa yhteyttä (suora yhteys) o järjestelmät tottelevat ulkoista koordinoivaa järjestelmää (koordinaattori) o järjestelmät mukautuvat saman ulkoisen määrittelyn käyttöön (silta) o järjestelmät jakavat yhteistä infrastruktuuria (infastruktuuri) kuvataanko nimenomaisesti järjestelmien hajautukseen liittyviä asioita onko määritelty, kuinka yhteistoimintaan osallistuvat järjestelmät toimivat, esim. o onko kyseessä tietosisältöviestin lähetys järjestelmästä toiseen o onko kyseessä toiminnon suorittaminen toisen järjestelmän avulla o onko kyseessä kutsu-vastaus-tyyppinen kommunikaatio onko määritelty, että järjestelmien kutsut (kutsu-vastaus) lähtevät aina samalta osapuolelta onko määritelty, onko yhteistoiminta välitöntä (synkroninen) tai ajallista (asynkroninen) 18 PLUGIT-HANKKEEN SELVITYKSIÄ JA RAPORTTEJA 3

19 onko määritelty, säilyttävätkö osapuolet yhteistoiminnan tilaa tai siirretäänkö sitä integrointitapahtumissa (sessio, transaktio, olion tila jne.) Tekninen luonne: kuvataanko tiettyä toteutustekniikkaa (tai useampia) liittyen o tiedon esitykseen o toimintojen tai operaatioiden kutsumiseen o liittymien määrittelyyn yleisesti (esim. liittyen kahteen edelliseen kohtaan) o tiedon siirtoon verkossa (siirtoprotokolla) minkä tyyppisiä ovat toteutuksissa käytettävät välineet kuvataanko edellytyksiä, joita tekniselle ympäristölle asetetaan (tekninen infrastruktuuri), esim. käytetty väliohjelmistostandardi, viestien reititys, transaktioiden tunnisteet onko standardissa määritelty nämä tekniikat vai viitattu ulkoisiin tekniikoihin Suhde järjestelmän elinkaareen: sijoittuuko standardi erityisesti johonkin järjestelmän tyypilliseen elinkaaren vaiheeseen, miten standardi huomioidaan järjestelmän elinkaaren eri vaiheissa: o vaatimusmäärittelyt (esim. lait, standardin käyttökohde jne.) o kohdealueen analyysi (esim. yleinen malli sovellusalueen tietosisällöstä) o tietosisällön ja toimintojen määrittely (esim. järjestelmien välillä jaettavan tiedon määrittelyt, järjestelmien väliset kutsut) o tekninen määrittely ja suunnittelu (esim. käytettävät liittymätekniikat) o toteutus (esim. toteutustekniikat ja toteutusvälineet) o asennus ja käyttöönotto (esim. sovittaminen eri ympäristöihin, konfigurointi) o ylläpitotoiminta ja uusien versioiden tekeminen sisältääkö standardi mukaisuusmääritykset, (conformance criteria), joiden avulla voidaan varmistua onko tietty toteutus tai malli standardin mukainen; onko tarjolla palveluita, joilla standardin mukaisuus voidaan puolueettomasti todentaa onko standardiin liittyviä soveltamisoppaita, esimerkkejä tai koulutusta saatavilla Levinneisyys: kansainvälinen standardi: o virallinen (ISO)-standardi o avoimen standardointijärjestön teollisuusstandardi (esim. HL7 tai OMG) o muun standardointijärjestön standardi (esim. CEN) o yleinen teollisuusstandardi kansallinen standardi tai suositus (esim. SFS, ANSI, JHS) arvio standardin käyttöasteesta Suomessa ja kansainvälisesti kuinka tiukkoja standardissa määritellyt asiat ovat, kuinka paljon jätetään toteutus- ja tilannekohtaisten käytäntöjen varaan Suhde muihin standardeihin: saman standardointijärjestön muut asiaan liittyvät (viitatut) määritykset viitatut muut standardit, viitemallit ja määritykset Yllä kuvattuja asioita arvioiden voidaan muodostaa kokonaiskuva siitä, mihin standardi soveltuu ja mitä vaikutuksia sillä on sovelluksiin, joissa se otetaan käyttöön. Toisaalta mallia käyttäen paljastuu myös seikkoja, jotka on syytä ratkaista tietyssä integrointitilanteessa, mutta joihin tutkittu standardi ei vastaa. Useissa integrointitilanteissa standardi saattaa osittain vastata tilanteen vaatimuksiin, mut- STANDARDIEN ARVIOINTI JA VALINTA TERVEYDENHUOLLON SOVELLUSINTEGRAATIOSSA 19

20 ta jotkin sen piirteet tai sivuvaikutukset saattavat estää sen hyödyntämisen. Tällöin on valittava, pyritäänkö ensisijaisesti noudattamaan standardia ja mukautetaan sovelluksia tavoitteena noudattaa standardia, vai sovelletaanko standardia soveltuvin osin, jolloin menetetään toteutuksen standardin mukaisuus, mutta voidaan säilyttää sen kanssa yhteensopivuus esim. sisältö- tai toiminnallisella tasolla. Standardijoukot ovatkin kehittymässä siten, että eri standardit täydentävät toisiaan tai tuetaan useita määriteltyjä standardin käyttötapoja, ja yhteen integrointitilanteeseen valitaan useita toisiaan tukevia standardeja. 3.2 Esimerkki Eri standardeista on kerätty lyhyitä kuvauksia ja luokitteluja käyttäen yllä kuvattuja malleja luvussa 4. Tässä esitetään esimerkki tarkemmasta standardin tarkastelusta yllä kuvattua arviointikehystä käyttäen. Esimerkissä ei ole jätetty pois ei-relevantteja osia kehyksestä. Mallia on hyödynnetty myös muissa PlugIT-projektin integrointimäärityksissä, vastaavia taulukoita löytyy esim. lähteestä Terveydenhuollon ohjelmistojen yhteiset koodistojen sovellusrajapinnat (Mykkänen et al. 2004c, luku ) OMG TQS- ja HL7 CTS-standardeille. Taulukko 3.1 PIDS-standardin arviointia. Standardi Person Identification Service (PIDS) (Corbamed 1999, Savolainen 2004) Standardointijärjestö OMG Healthcare Domain Task Force / -perhe Tutkittu versio 1.0 Kohdealue Tarkoitus Henkilön tunnistaminen Kohdealue Terveydenhuollon hajautetut sovellukset Ensisijainen RM- Computation: määritellään oliopalveluita ODP-näkökulma Muut RM-ODPnäkökulmagineering) Liittymät on määritelty OMG IDL:llä, toteutus vaatii ORB-tuotteen (En- Ensisijainen 7- Toiminnalliset liittymät (4) IDL:llä määriteltyjen operaatioiden nimet ja tasoisen mallin taso parametrit Vaikutukset muille Edellyttää CORBA-sovellusinfrastruktuuria (2), käyttää OMG IDL:ää (1), 7-tasomallin tasoille edellyttää puhtaasti sovellettuna hajautettua CORBA-arkkitehtuuria (3), edellyttää sovittimia, joilla voidaan käyttää henkilön erilaisia tunnisteita, jos niitä on sovelluksissa (6) Toiminnot ja tietosisältö Tieto- tai käsitemalli Keskeiset käsitteet ja niiden suhteet on määritelty Tietosisältö Liittymien parametrit, trait names-määrityksiä olemassa HL7 versio 2.3 (U.S.) PID-segmentille (kentät 5-30) ja vcard versio 2.1 standardille. Tietosisällön kuvaaminen OMG IDL-kielen avulla Tietosisällön merkitys Parametrien merkitys kuvattu standardissa Toimintomalli Liittymien operaatiot Toimintomallin kuvaaminen OMG IDL-kielen avulla Toimintojen merkitys Operaatioiden merkitys kuvattu standardissa Koodistot tai luokitukset Ei ota kantaa 20 PLUGIT-HANKKEEN SELVITYKSIÄ JA RAPORTTEJA 3

21 Ihmisten (käyttäjien) toiminnan kuvaaminen Sovellusarkkitehtuuri Osien tunnistaminen Yhteistoiminnan perusmalli Integrointitapa Hajautus Kutsutapa Tekniikka Tiedon esitys Toimintojen määrittely Kutsutekniikka Verkkoliikenne Suoritukseen tarvittava tekninen infrastruktuuri Ei ota kantaa Asiakas ja palvelin (hajautettu palvelu) Oliopalvelut Yhteinen infrastruktuuri Hajautetut palvelut Pyyntö-vastaus, toiminnon (palvelun) suorittaminen OMG IDL OMG IDL Operaatiokutsut määritelty OMG IDL:n avulla IIOP (CORBA) ORB-tuote, nimipalvelu, vaihtopalvelu Toteutuksessa tarvittavat välineet IDL-kääntäjät, ohjelmointikielet Suhde järjestelmän elinkaaren vaiheisiin Vaatimukset Soveltuu henkilön tunnistukseen liittyvien vaatimusten toteuttamiseen Kohdealueen analyysteisen henkilötunnisteen puuttuminen Nojautuu oliopohjaiseen analyysiin ja suunnitteluun, oletuksena yksikäsit- Tietosisällön ja toimintojen määrittely ks. yllä Tekninen määrittely Sisältää valmiit liittymien määrittelyt IDL:llä ja suunnittelu Toteutus IDL-kieliset liittymät voidaan toteuttaa eri välineillä ja ohjelmointikielillä Asennus ja käyttöönotttuotteen, joka huolehtii verkkokommunikaatiosta asiakkaan ja Vaatii suoritusympäristöön palvelimen, jolle palvelu asennetaan, ja ORB- palvelimen välillä. Ylläpito ja uudet Hyödyntää standardin mukaisesti vaihtopalvelua ajon aikana tapahtuvaa versiot päivitystä varten Arvio levinneisyydestä Kansainvälisesti Useita eri tarkoituksiin tehtyjä toteutuksia. Suomessa Henkilötunnus on toiminut yksikäsitteisenä tunnisteena, eivätkä OMG:n terveydenhuoltospesifit standardit ole levinneet yleiseen käyttöön. Suhde muihin standardeihin Vahva suhde OMG:n yleisiin middleware-standardeihin, OMG:n terveydenhuoltoryhmä neuvottelee yhteistyöstä HL7:n kanssa Muuta olennaista OMG-standardien jatkokehitystyö ja mahdollinen siirto muille kuin CORBA-alustoille riippuu terveydenhuoltoryhmän aktiivisuudesta (viime aikoina ei aktiivista), MDA-määritystyön etenemisestä ja siihen liittyvästä STANDARDIEN ARVIOINTI JA VALINTA TERVEYDENHUOLLON SOVELLUSINTEGRAATIOSSA 21

22 4 STANDARDILUETTELO Tässä luvussa luetellaan joitakin olennaisia standardeja ja määrityksiä ja linkkejä niihin liittyvään materiaaliin. Eri standardeista kuvataan tässä tiettyjä perustietoja ("minimitaso"), joiden avulla voidaan nopeasti muodostaa kuva standardin käyttötarkoituksesta ja -kelpoisuudesta erilaisiin integrointitilanteisiin. Lukuun on ryhmitelty ensimmäiseksi nimenomaisesti terveydenhuoltoon tarkoitettuja tietoteknisiä standardeja, toiseksi terveydenhuollossa luokituksia, ja kolmanneksi yleisesti eri aloilla käytettyjä teknisiä ja ohjelmistotuotannon integraatioon liittyviä standardeja. Standardit muodostavat usein tietyn standardointiorganisaation ympärille ryhmittyneitä "ryppäitä", jotka hyödyntävät ja täydentävät toisiaan, ja joihin kuuluu useita määrityksiä, ks. luku 5. Standardien tai standardiperheiden tarkempaa tutkimista varten voidaan soveltaa siis luvun 3.1 arviointikehystä, joka sisältää myös ohjeita standardien sijoitteluun tässä käytettyihin viitemalleihin ("ensisijaiset RM-ODP-tasot" ja "ensisijaiset 7- tasomallin tasot"). Myös raportti (Ensio, Ruotsalainen 2004) sisältää standardikatsauksen terveydenhuollon tietotekniikan standardeista. Raportissa on käytetty erilaista standardien (ja standardijärjestöjen) luokittelua kuin tässä raportissa, ja se sisältää tätä raporttia tarkempia kuvauksia mm. tietoturvaan liittyvistä standardeista. Terveydenhuollon tietotekniikan standardointia ja eri standardeja on käsitelty laajalti myös lähteessä (Ensio 1999). Standardien hyödyntämisen nyky- ja tavoitetilaa on selvitetty osana suoritettua kyselyä PlugIT-hankkeen selvityksessä (Porali et al. 2004). Luku on jaoteltu kolmeen osaan: Terveydenhuollon tietotekniikan standardit ja määritykset, Terveydenhuollon sanastot, nimikkeistöt, luokitukset ja koodistot, Ohjelmistotekniikan ja tietojenkäsittelyn standardit. 4.1 Terveydenhuollon tietotekniikan standardit ja määritykset Arden syntax Käyttötarkoitus: Standardointiorganisaatio Ensisijaiset RM-ODP Ensisijaiset 7-tasomallin Lääketieteellisen tietämyksen esittämiseen ja jakamiseen tarkoitettu kieli. HL7 Arden syntax SIG, HL7: The Arden Syntax for Medical Logic Systems - An ANSI Standard: Computational, Enterprise Tekniset liittymät (1), toiminnallinen viitemalli (6), liittymien sisältö (4), semantiikka (5) 22 PLUGIT-HANKKEEN SELVITYKSIÄ JA RAPORTTEJA 3

23 CCOW (ent. Clinical Context Object Workgroup) Käyttötarkoitus: Terveydenhuollon työpöytäintegraatio, sovellusten koordinointi. Standardointiorganisaatio HL7 (Komulainen, Tuomainen 2002), (Tuomainen et al., 2004), (Seliger, Royer 2002) HL7 CCOW Committee: HL7 Finland Common Services SIG (HL7-yhdistyksen sivuilla: Ensisijaiset RM-ODP Computational Ensisijaiset 7-tasomallin Liittymien sisältö (4) CDA (Clinical Document Architecture) Käyttötarkoitus: Terveydenhuollon sähköisten dokumenttien sisältö ja rakenne, XML-pohjaiset liittymät tietojärjestelmien välillä Standardointiorganisaatio HL7 (Ensio 2002) Kliinisen dokumentin arkkitehtuuri (Xrake): Berliinin CDA-konferenssin (lokakuu 2002) materiaalit: HL7 Finland dokumentti-sig (HL7-yhdistyksen jäsensivuilla): CDApaikallistamisprojektin toteutusopas, CDA Framework: Ensisijaiset RM-ODP Ensisijaiset 7-tasomallin Liittymien sisältö (4), Tekniset liittymät (1) CEN ENV Electronic Healthcare Record Communication Käyttötarkoitus: Sähköisen terveyskertomuksen tietoarkkitehtuuri ja kommunikaatio Standardointiorganisaatio CEN TC 251 (uudistustyö keskeneräinen) CEN/TC Health informatics Electronic health record communication-part 1: Reference model. Working Draft of EN : OpenEHR CEN EN Task Force: Ensisijaiset RM-ODP-, Engineering Ensisijaiset 7-tasomallin Sovellusinfrastruktuuri (3), liittymien sisältö (4), semantiikka (5), tekniset liittymät (1) STANDARDIEN ARVIOINTI JA VALINTA TERVEYDENHUOLLON SOVELLUSINTEGRAATIOSSA 23

24 CEN TC 251 Health Informatics Data Types Käyttötarkoitus: Terveydenhuollon tietojenkäsittelyn standardi- ym. määrittelyissä käytettävät abstraktit tietotyypit Standardointiorganisaatio CEN TC 251 Health Informatics Data Types: Ensisijaiset RM-ODP, Engineering Ensisijaiset 7-tasomallin Semantiikka (5), Toiminnallinen viitemalli (6) CIAS (Clinical Image Access Service) Käyttötarkoitus: Hajautettu palvelu ei-diagnostisten kuvien ja niihin liittyvän tiedon hakuun Standardointiorganisaatio OMG Healthcare DTF (Savolainen 2004). Ensisijaiset RM-ODP Computational Ensisijaiset 7-tasomallin Liittymien sisältö (4) COAS (Clinical Observation Access Service) Käyttötarkoitus: Hajautettu palvelu henkilöön liittyvän kliinisen tiedon hakemiseen Standardointiorganisaatio OMG Healthcare DTF (Savolainen 2004). Ensisijaiset RM-ODP Computational Ensisijaiset 7-tasomallin Liittymien sisältö (4) DICOM (Digital Imaging and Communication in Medicine) Käyttötarkoitus: Kliinisten kuvien siirto järjestelmästä toiseen Standardointiorganisaatio DICOM Standards Committee DICOM website: Ensisijaiset RM-ODP Ensisijaiset 7-tasomallin Liittymien sisältö (4) 24 PLUGIT-HANKKEEN SELVITYKSIÄ JA RAPORTTEJA 3

25 HISA (Healthcare System Architecture) Käyttötarkoitus: Terveydenhuollon sovellusten yhteiset palvelut, useita määriteltyjä palveluita Standardointiorganisaatio CEN TC 251 (Savolainen 2004). CEN HISA Healthcare Middleware Layer, Final draft 2: CEN TC 251 Open library: Ensisijaiset RM-ODP, Engineering Ensisijaiset 7-tasomallin Toiminnallinen viitemalli (6) HL7 (Health Level 7) -sanomamääritykset Käyttötarkoitus: Terveydenhuollon sovellusten viestinvälitys Standardointiorganisaatio HL7 HL7 Finland: Ensisijaiset RM-ODP Ensisijaiset 7-tasomallin Liittymien sisältö (4) HL7 MDF (Message Development Framework) ja HDF (HL7 Development Framework) Käyttötarkoitus: Terveydenhuollon sovellusten välisten viestien määrittelemisen menettelytavat Standardointiorganisaatio HL7 versio 3 (keskeneräinen) (Mykkänen ym. 2004a) HL7 Message Development Framework: Ensisijaiset RM-ODP, Computation, Engineering Ensisijaiset 7-tasomallin Kehitysprosessin liittymät (7) STANDARDIEN ARVIOINTI JA VALINTA TERVEYDENHUOLLON SOVELLUSINTEGRAATIOSSA 25

26 HL7 version 3 RIM (Reference Model) Käyttötarkoitus: Terveydenhuollon toimialan käsite- ja tietomalli Standardointiorganisaatio HL7 versio 3 (ei Suomeen paikallistettua versiota) HL7 Finland: Ensisijaiset RM-ODP Ensisijaiset 7-tasomallin Toiminnallinen viitemalli (6) IHE (Integrating Healthcare Enterprise) Käyttötarkoitus: Terveydenhuollon sovellusosien (aktoreiden) yhteistoiminta erityisesti radiologiassa Standardointiorganisaatio HIMSS / RSNA (hyödyntää HL7 ja DICOM-määrityksiä) (Mykkänen ym. 2004a) IHE Integration profiles esite: IHE Technical Framework, Integration profiles, transactions: Ensisijaiset RM-ODP, Computation Ensisijaiset 7-tasomallin Toiminnallinen viitemalli (6) RAD (Resource Access Decision) Käyttötarkoitus: Hajautettu palvelu nimettyjen resurssien käyttöoikeuksien saantiin Standardointiorganisaatio OMG Healthcare DTF (Savolainen 2004). Ensisijaiset RM-ODP Computational Ensisijaiset 7-tasomallin Liittymien sisältö (4) 4.2 Terveydenhuollon nimikkeistöt, luokitukset, sanastot ja koodistot Tämän luvun luettelo sisältää lähinnä avoimia sekä laajasti hyödynnettyjä luokituksia, sanastoja ja koodistoja. Siihen ei ole listattu luokituksia keskeisesti hyödyntäviä menetelmiä tai esim. tavaramerkillä suojattuja järjestelmiä. Tällaisia ovat esim. FIM : aikuisten kuntoutuksen laadunhallintamenetelmä ( Monitor: potilaan omatoimisuuden asteen ja hoitotyön tarpeen arvioinnin perusteella toteutettu hoito henkilöstön määrän mitoittamiseksi ( 26 PLUGIT-HANKKEEN SELVITYKSIÄ JA RAPORTTEJA 3

27 Rafaela : Hoitotyön määrän ja vaativuuden arviointi henkilöstön mitoittamiseksi ( RAI (Resident Assessment Instrument): asiakkaan kokonaisvaltainen arviointi hoitosuunnitelmia varten (RAI:ssa hyödynnettyä RUG-luokitusta käsitellään tämän luvun luettelossa) ( Tässä luvussa lueteltujen lisäksi mm. HL7 on määritellyt suuren joukon järjestelmien integraatiossa käytettäviä koodistoja. ATC-lääkenimikkeistö (Anatomical Therapeutic Chemical Classification Index) Käyttötarkoitus: Lääkkeiden luokittelu Standardointiorganisaatio WHO / Suomen Kuntaliitto WHO Collaborating Centre for Drug Statistics Methodology: ATC: Univ. of Manitoba Concept Dictionary Ensisijaiset RM-ODP Ensisijaiset 7-tasomallin Semantiikka (5), Toiminnallinen viitemalli (6) BeNMDS (Belgialainen hoitotyön minimitiedostojärjestelmä) Käyttötarkoitus: Standardointiorganisaatio Ensisijaiset RM-ODP Ensisijaiset 7-tasomallin Standardoitu nimikkeistö ja luokitus, jolla kuvataan hoitotyön käytännön toimintoja. Sisältää tietoja työstä, jota hoitotyöntekijät kohdistavat potilaisiin heidän sairaalassa ollessaan. Hoitotyön käytännön kuvaamisen yhtenäistäminen: Semantiikka (5), Toiminnallinen viitemalli (6) STANDARDIEN ARVIOINTI JA VALINTA TERVEYDENHUOLLON SOVELLUSINTEGRAATIOSSA 27

28 DRG (Diagnosis Related Groups) -luokitus Käyttötarkoitus: Hoidon vaativuuden arviointi, erikoissairaanhoidon vuodeosastopotilaiden resurssienkäyttö Standardointiorganisaatio Pohjoismainen luokituskeskus / Suomen Kuntaliitto / Qualisan Oy NordDRG 2004: DRG ja NordDRG: Ensisijaiset RM-ODP Enterprise (arviointi), Ensisijaiset 7-tasomallin Toiminnallinen viitemalli (6), Semantiikka (5) Fysioterapianimikkeistö 2000 Käyttötarkoitus: Luokittelu fysioterapiapalveluiden ja fysioterapeutin työn sisällöstä. Standardointiorganisaatio Suomen Kuntaliitto Fysioterapianimikkeistö 2000: path=1;29;65;353;40302;46660;46727 Ensisijaiset RM-ODP Ensisijaiset 7-tasomallin Semantiikka (5) ICD-10 (International Classification of Diseases) Käyttötarkoitus: Tautiluokitus ja -koodisto, sisältää myös useita sanamuotoja samalle koodille Standardointiorganisaatio WHO / Stakes ICD : ICD 10: ICD-10-tautiluokitus (Stakes): Ensisijaiset RM-ODP Ensisijaiset 7-tasomallin Semantiikka (5) 28 PLUGIT-HANKKEEN SELVITYKSIÄ JA RAPORTTEJA 3