Standardien arviointi ja valinta terveydenhuollon sovellusintegraatiossa

Koko: px
Aloita esitys sivulta:

Download "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 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ä (http://www.qualisan.fi/fim.htm), Monitor: potilaan omatoimisuuden asteen ja hoitotyön tarpeen arvioinnin perusteella toteutettu hoito henkilöstön määrän mitoittamiseksi (http://www.uku.fi/vaitokset/2002/isbn pdf), 26 PLUGIT-HANKKEEN SELVITYKSIÄ JA RAPORTTEJA 3

27 Rafaela : Hoitotyön määrän ja vaativuuden arviointi henkilöstön mitoittamiseksi (http://www.qualisan.fi/rafaela.htm), RAI (Resident Assessment Instrument): asiakkaan kokonaisvaltainen arviointi hoitosuunnitelmia varten (RAI:ssa hyödynnettyä RUG-luokitusta käsitellään tämän luvun luettelossa) (http://www.stakes.fi/verkkojulk/pdf/aiheita pdf). 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

Terveydenhuollon komponentt ipohjainen soveiiusintegraat io, Juha Mykkänen, Kuopion YO

Terveydenhuollon komponentt ipohjainen soveiiusintegraat io, Juha Mykkänen, Kuopion YO SUOMEN KUNTAUITTO Sosiaali - ja terveysyksikkö TERVEYDENHUOLLON 27. ATK-PAIVAT 4. - 5.6.2001 Sosiaali- ja terveydenhuollon tietotekniikan ja tiedonhallinnan tutkimuksen päivät Terveydenhuollon komponentt

Lisätiedot

Integrointi. Ohjelmistotekniikka kevät 2003

Integrointi. Ohjelmistotekniikka kevät 2003 Integrointi Ohjelmistotekniikka kevät 2003 ERP (Toiminnanohjausjärjestelmä) Myynti Henkilöstö, palkanlaskenta Kirjanpito Myynti Myyjät Extranet Tietovarasto Laskutus, reskontrat Asiakas ERP Asiakasrekisteri

Lisätiedot

Paikkatietorajapinnat IT arkkitehtuurin näkökulmasta 21.12.200 7

Paikkatietorajapinnat IT arkkitehtuurin näkökulmasta 21.12.200 7 Paikkatietorajapinnat IT arkkitehtuurin näkökulmasta 21.12.200 7 Mikä on IT arkkitehtuuri? Liiketoimintamalli määrittelee IT arkkitehtuurin IT arkkitehtuuri ottaa kantaa sovelluksen laadullisiin vaatimuksiin

Lisätiedot

PlugIT-projektin työsuunnitelma 3. jaksolle 1.11.2002-30.4.2003 EHDOTUS johtoryhmälle, 27.10.2003. Koko projektin keskeiset tehtävät

PlugIT-projektin työsuunnitelma 3. jaksolle 1.11.2002-30.4.2003 EHDOTUS johtoryhmälle, 27.10.2003. Koko projektin keskeiset tehtävät PlugIT-projektin työsuunnitelma 3. jaksolle 1.11.2002-30.4.2003 EHDOTUS johtoryhmälle, 27.10.2003 Tässä työsuunnitelmassa on esitetty vain tutkimussuunnitelman mukaisten tärkeimpien tuotosten aikaansaamiseksi

Lisätiedot

Sovellusarkkitehtuurit

Sovellusarkkitehtuurit HELIA TiKo-05 1 (9) Sovellusarkkitehtuurit ODBC (Open Database Connectivity)... 2 JDBC (Java Database Connectivity)... 5 Middleware... 6 Middleware luokittelu... 7 Tietokanta -middleware... 8 Tapahtumamonitorit

Lisätiedot

TIEKE Verkottaja Service Tools for electronic data interchange utilizers. Heikki Laaksamo

TIEKE Verkottaja Service Tools for electronic data interchange utilizers. Heikki Laaksamo TIEKE Verkottaja Service Tools for electronic data interchange utilizers Heikki Laaksamo TIEKE Finnish Information Society Development Centre (TIEKE Tietoyhteiskunnan kehittämiskeskus ry) TIEKE is a neutral,

Lisätiedot

Master data tietojen ja kriteeristön sekä hallintamallin määrittely ja suunnittelu TRE:933/02.07.01/2011

Master data tietojen ja kriteeristön sekä hallintamallin määrittely ja suunnittelu TRE:933/02.07.01/2011 Lisätieto 15.2.2011 Master data tietojen ja kriteeristön sekä hallintamallin määrittely ja suunnittelu TRE:933/02.07.01/2011 Vastaukset täydentävät vaatimusmäärittelyämme lisätietona ja ne tulee ottaa

Lisätiedot

KODAK EIM & RIM VIParchive Ratkaisut

KODAK EIM & RIM VIParchive Ratkaisut ATK Päivät 2006 Mikkeli KODAK EIM & RIM VIParchive Ratkaisut 29.-30.5. 2006 Stefan Lindqvist HCIS Sales Specialist Health Care Information Systems Kodak Health Group 3/24/2013 1 Arkistoinnin haasteita

Lisätiedot

Tietojärjestelmäarkkitehtuurit

Tietojärjestelmäarkkitehtuurit Tietojärjestelmäarkkitehtuurit ITK130 Johdatus ohjelmistotekniikkaan Syksy 2003 Sami Kollanus 1 Aluksi Tietojärjestelmäarkkitehtuurit vs. ohjelmistoarkkitehtuurit Pohjana Tietojärjestelmäarkkitehtuurit

Lisätiedot

HOJ J2EE & EJB & SOAP &...

HOJ J2EE & EJB & SOAP &... HOJ J2EE & EJB & SOAP &... Ville Leppänen HOJ, c Ville Leppänen, IT, Turun yliopisto, 2012 p.1/18 Missä mennään... 1. Johdanto (1h) 2. Säikeet (2h) 3. Samanaikaisuudesta (2h) 4. Hajautetuista sovelluksista

Lisätiedot

Tiedonsiirto- ja rajapintastandardit

Tiedonsiirto- ja rajapintastandardit Tiedonsiirto- ja rajapintastandardit Viitekehys Julkishallinnon perustietovarantojen rajapinnat (PERA) työryhmän tulokset valmiit syksyllä 2011 Määrittelee teknisen arkkitehtuuriratkaisun tietovarantojen

Lisätiedot

Toiminnallisten vaatimusten jäljitettävyys tietotarpeisiin ja ohjelmistoratkaisuihin terveydenhuollon tietojärjestelmissä

Toiminnallisten vaatimusten jäljitettävyys tietotarpeisiin ja ohjelmistoratkaisuihin terveydenhuollon tietojärjestelmissä Toiminnallisten vaatimusten jäljitettävyys tietotarpeisiin ja ohjelmistoratkaisuihin terveydenhuollon tietojärjestelmissä Juha Mykkänen, Irmeli Minkkinen, Assi Pöyölä, Annamari Riekkinen Kuopion yliopisto

Lisätiedot

HSMT J2EE & EJB & SOAP &...

HSMT J2EE & EJB & SOAP &... HSMT J2EE & EJB & SOAP &... Ville Leppänen HSMT, c Ville Leppänen, IT, Turun yliopisto, 2011 p.1/15 Missä mennään... 1. Johdanto (1h) 2. Säikeet (2h) 3. Samanaikaisuudesta (2h) 4. Hajautetuista sovelluksista

Lisätiedot

Järjestelmäarkkitehtuuri (TK081702) Web Services. Web Services

Järjestelmäarkkitehtuuri (TK081702) Web Services. Web Services Järjestelmäarkkitehtuuri (TK081702) Standardoidutu tapa integroida sovelluksia Internetin kautta avointen protokollien ja rajapintojen avulla. tekniikka mahdollista ITjärjestelmien liittämiseen yrityskumppaneiden

Lisätiedot

Tietojärjestelmän osat

Tietojärjestelmän osat Analyysi Yleistä analyysistä Mitä ohjelmiston on tehtävä? Analyysin ja suunnittelun raja on usein hämärä Ei-tekninen näkökulma asiakkaalle näkyvien pääkomponenttien tasolla Tietojärjestelmän osat Laitteisto

Lisätiedot

PlugIT-projektin rajapintojen määrittely, dokumentointi ja hyväksyminen

PlugIT-projektin rajapintojen määrittely, dokumentointi ja hyväksyminen PlugIT-projektin rajapintojen määrittely, dokumentointi ja hyväksyminen LUONNOS Johtoryhmälle 25.10.2002 2 Sisällys 1 Johdanto...3 2 Integrointiprosessi...3 3 Määrittelydokumentit...6 3.1 Integrointivaatimukset...7

Lisätiedot

Muutos Tutkimusyhteistyösopimukseen. PlugIT: Terveydenhuollon sovellusintegraatio

Muutos Tutkimusyhteistyösopimukseen. PlugIT: Terveydenhuollon sovellusintegraatio Muutos PlugIT-tutkimusyhteistyösopimukseen, sivu 1/29 Muutos Tutkimusyhteistyösopimukseen PlugIT: Terveydenhuollon sovellusintegraatio 1. Projektiosapuolet: 1.1 Tutkimusosapuolet KUOPION YLIOPISTO, projektin

Lisätiedot

Copyright by Haikala. Ohjelmistotuotannon osa-alueet

Copyright by Haikala. Ohjelmistotuotannon osa-alueet Copyright by Haikala Ohjelmistotuotannon osa-alueet Ohjelmiston elinkaari 1. Esitutkimus, tarvekartoitus, kokonaissuunnittelu, järjestelmäsuunnittelu (feasibility study, requirement study, preliminary

Lisätiedot

Taltioni teknisen alustan arviointi

Taltioni teknisen alustan arviointi Taltioni teknisen alustan arviointi Taltioni sidosryhmätilaisuus, 10.1.2012 Jaakko Lähteenmäki, Niilo Saranummi 1/11/2012 2 Selvitystyön kohde Selvitystyö: VTT & Fujitsu Keskeiset vaatimukset Taltioni-palvelulle?

Lisätiedot

Vastausten ja tulosten luotettavuus. 241 vastausta noin 10 %:n vastausprosentti tyypillinen

Vastausten ja tulosten luotettavuus. 241 vastausta noin 10 %:n vastausprosentti tyypillinen Vastausten ja tulosten luotettavuus Vastaukset 241 vastausta noin 10 %:n vastausprosentti tyypillinen Kansainväliset IT:n hallinnan hyvät käytännöt. Luotettavuusnäkökohdat Kokemukset ja soveltamisesimerkit

Lisätiedot

Arkkitehtuurin kansallinen toteutus ja yhteistyö

Arkkitehtuurin kansallinen toteutus ja yhteistyö 1 Arkkitehtuurin kansallinen toteutus ja yhteistyö Terveydenhuollon Atk-päivät Turku 29.5.2007 Riitta Alkula 2 Esityksen sisältö Arkkitehtuurin nyky- ja tavoitetila Arkkitehtuurimäärittelyt Määrittelyjen

Lisätiedot

Alueellisia kokemuksia elektronisen kertomuksen käytöstä

Alueellisia kokemuksia elektronisen kertomuksen käytöstä TERVEYDENHUOLLON 25. ATK-PAIVAT Kuopio, Hotelli Scandic 31.5-1.6.1999 erityisasiantuntija Anita Kokkola Suomen Kuntaliitto Elektroninen kertomus - Valtakunnallinen kertomusmaarittelytyö Alueellisia kokemuksia

Lisätiedot

Järjestelmäarkkitehtuuri (TK081702) Lähtökohta. Integroinnin tavoitteet

Järjestelmäarkkitehtuuri (TK081702) Lähtökohta. Integroinnin tavoitteet Järjestelmäarkkitehtuuri (TK081702) Integraation tavoitteita Lähtökohta Web-palvelut Asiakasrekisteri ERP, Tuotannon ohjaus Tuotanto Myynti Intranet Extranet? CRM Johdon tuki Henkilöstö Kirjanpito Palkanlaskenta

Lisätiedot

HIMSS European EMR Adoption Model. Ari Pätsi Terveydenhuollon ATK päivät Helsinki 15 16.05. 2012

HIMSS European EMR Adoption Model. Ari Pätsi Terveydenhuollon ATK päivät Helsinki 15 16.05. 2012 HIMSS European EMR Adoption Model Ari Pätsi Terveydenhuollon ATK päivät Helsinki 15 16.05. 2012 HIMSS Analytics Europe on myöntänyt 23.04.2012 Itä-Savon sairaanhoitopiirille EMR Adobtion Model -tason 6.

Lisätiedot

Yhteentoimivuutta kokonaisarkkitehtuurilla

Yhteentoimivuutta kokonaisarkkitehtuurilla Yhteentoimivuutta kokonaisarkkitehtuurilla Terveydenhuollon atk-päivät 20.5.2014 Juha Rannanheimo Ratkaisupäällikkö, sosiaali- ja terveydenhuollon ratkaisut Esityksen sisältö Kehittämisvaatimukset sosiaali-

Lisätiedot

Tietojärjestelmien standardointityön organisointi ja kehittäminen terveydenhuollossa: nykytila ja toimenpide-ehdotukset

Tietojärjestelmien standardointityön organisointi ja kehittäminen terveydenhuollossa: nykytila ja toimenpide-ehdotukset Juha Mykkänen, Maritta Korhonen, Jari Porrasmaa, Tuula Tuomainen, Antero Ensio Tietojärjestelmien standardointityön organisointi ja kehittäminen terveydenhuollossa: nykytila ja toimenpide-ehdotukset Standardointiselvitystyön

Lisätiedot

Liiketoimintajärjestelmien integrointi

Liiketoimintajärjestelmien integrointi Liiketoimintajärjestelmien integrointi Vierailuluento 2.3.2015 Esa Heikkinen Mystes Oy Agenda Liiketoimintajärjestelmien integrointi EAI: Enterprise Application Integration EAS: Enterprise Application

Lisätiedot

Ohjelmistoarkkitehtuurit Syksy 2009 TTY Ohjelmistotekniikka 1

Ohjelmistoarkkitehtuurit Syksy 2009 TTY Ohjelmistotekniikka 1 3. Komponentit ja rajapinnat 3.1 Komponenttien idea: ohjelmistotuotannon rationalisointi 3.2 Mikä on ohjelmistokomponentti? 3.3 Komponentit ohjelmistoyksikköinä 3.4 Rajapinnat 3.6 Komponenttien räätälöinti

Lisätiedot

Yhteentoimivuutta edistävien työkalujen kehittäminen

Yhteentoimivuutta edistävien työkalujen kehittäminen Yhteentoimivuutta edistävien työkalujen kehittäminen Semantiikkaa organisaatioiden välisen tiedonvaihdon helpottamiseksi Mikael af Hällström, Verohallinto Esityksen sisältö Taustatekijöitä (OKM:n hallinnonala,

Lisätiedot

Helpottuuko sovellusten välinen integraatio XML:n avulla - kokemuksia ja ratkaisuja, teknologiajohtaja Sauli Tujunen, atbusiness Communications Oyj

Helpottuuko sovellusten välinen integraatio XML:n avulla - kokemuksia ja ratkaisuja, teknologiajohtaja Sauli Tujunen, atbusiness Communications Oyj SUOMEN KUNTALIITTO Sosiaali- ja terveysyksikkö Helpottuuko sovellusten välinen integraatio XML:n avulla - kokemuksia ja ratkaisuja, teknologiajohtaja Sauli Tujunen, atbusiness Communications Oyj ~ (operatiiviset-/tiedonjakelu-/si~llönhallinta~velluk~et)

Lisätiedot

BUILDINGSMART ON KANSAINVÄLINEN FINLAND

BUILDINGSMART ON KANSAINVÄLINEN FINLAND BUILDINGSMART ON KANSAINVÄLINEN TOIMINNAN TARKOITUS Visio buildingsmartin tavoitteena on vakiinnuttaa tietomallintaminen osaksi rakennetun ympäristön hallintaa. Missio buildingsmart edistää kaikille rakennetun

Lisätiedot

Alkuraportti. LAPPEENRANNAN TEKNILLINEN YLIOPISTO TIETOJENKÄSITTELYN LAITOS CT10A4000 - Kandidaatintyö ja seminaari

Alkuraportti. LAPPEENRANNAN TEKNILLINEN YLIOPISTO TIETOJENKÄSITTELYN LAITOS CT10A4000 - Kandidaatintyö ja seminaari LAPPEENRANNAN TEKNILLINEN YLIOPISTO TIETOJENKÄSITTELYN LAITOS CT10A4000 - Kandidaatintyö ja seminaari Alkuraportti Avoimen lähdekoodin käyttö WWW-sovelluspalvelujen toteutuksessa Lappeenranta, 30.3.2008,

Lisätiedot

Terveydenhuollon avoimet sovellusrajapinnat - koodistorajapinnat

Terveydenhuollon avoimet sovellusrajapinnat - koodistorajapinnat Terveydenhuollon avoimet sovellusrajapinnat - koodistorajapinnat HL7 Finland ry, SerAPI-projekti, PlugIT-projekti OID: 1.2.246.777.11.2005.12 Ydinpalvelurajapinnat Yhteyshenkilö: Juha.Mykkanen@uku.fi Versio

Lisätiedot

Sisällys. Valtion tietotekniikan rajapintasuosituksia. XML:n rooleja sähköisen asioinnin tavoitearkkitehtuurissa. dbroker - asiointialusta

Sisällys. Valtion tietotekniikan rajapintasuosituksia. XML:n rooleja sähköisen asioinnin tavoitearkkitehtuurissa. dbroker - asiointialusta Palveluita ja sisältöä portaaliin - XML:n mahdollisuuksista XML-tietokannat ja julkishallinnon XML-sovellukset, 28.05.2002 Lasse Akselin, TietoEnator Oyj Sisällys Valtion tietotekniikan rajapintasuosituksia

Lisätiedot

FiSMA 1.1 Toiminnallisen laajuuden mittausmenetelmä Ohje monikerrosarkkitehtuurin mittaamiseen

FiSMA 1.1 Toiminnallisen laajuuden mittausmenetelmä Ohje monikerrosarkkitehtuurin mittaamiseen FiSMA 1.1 Monikerrosarkkitehtuuri 1 (6) FiSMA 1.1 Toiminnallisen laajuuden mittausmenetelmä Ohje monikerrosarkkitehtuurin mittaamiseen 1. Yleiset periaatteet FiSMA 1.1 -menetelmässä mitataan sovellusperiaatteen

Lisätiedot

papinet -sanomastandardit

papinet -sanomastandardit papinet -sanomastandardit Tapio Räsänen Puutavaralogistiikan kehittämishaasteita 14.6.2007 1 papinet on An international paper and forest products industry e-business initiative. A set of standard electronic

Lisätiedot

HL7-standardien soveltuvuus sosiaalihuoltoon

HL7-standardien soveltuvuus sosiaalihuoltoon HL7-standardien soveltuvuus sosiaalihuoltoon Terveydenhuollon ATK-päiv ivät Turku, 29.5.2007 Esa Paakkanen ATK-suunnittelija HIS-tutkimusyksikk tutkimusyksikkö Kuopion yliopisto Sisält ltö Sosiaalihuolto

Lisätiedot

.NET 2006 ja sen jälkeen

.NET 2006 ja sen jälkeen .NET 2006 ja sen jälkeen Ahti Haukilehto FC Sovelto Oyj Microsoft Regional Director, Finland Superior tools, niin mitkä? Visual Studio Team System Team Foundation Server DSL Tools 2 Visual Studio Team

Lisätiedot

Järjestelmäarkkitehtuuri (TK081702) Avoimet web-rajapinnat

Järjestelmäarkkitehtuuri (TK081702) Avoimet web-rajapinnat Järjestelmäarkkitehtuuri (TK081702) SOA yleistyvät verkkopalveluissa Youtube Google... Avaavat pääsyn verkkopalvelun sisältöön. Rajapintojen tarjoamia tietolähteitä yhdistelemällä luodaan uusia palveluja,

Lisätiedot

Toimilohkojen turvallisuus tulevaisuudessa

Toimilohkojen turvallisuus tulevaisuudessa Toimilohkojen turvallisuus tulevaisuudessa Turvallisuusseminaari ASAF 30.10-1.11.2006 Mika Strömman Teknillinen korkeakoulu 1 Sisältö Luotettavuuden lisääminen hyvillä tavoilla Toimilohkokirjastot Turvatoimilohkot

Lisätiedot

ALUEARKKITEHTUURI WEB PALVELUITA KÄYTTÄEN. Niilo Saranummi VTT Tietotekniikka niilo.saranummi@vtt.fi

ALUEARKKITEHTUURI WEB PALVELUITA KÄYTTÄEN. Niilo Saranummi VTT Tietotekniikka niilo.saranummi@vtt.fi ALUEARKKITEHTUURI WEB PALVELUITA KÄYTTÄEN Niilo Saranummi VTT Tietotekniikka niilo.saranummi@vtt.fi MISTÄ ALUETIETOJÄRJESTELMÄSSÄ ON KYSYMYS? Asiakkaan tietojen tulisi olla saatavissa vain niiden käyttöön,

Lisätiedot

Espoon arkkitehtuurin kehittäminen - Tiedonhallinta ja arkkitehtuuri kaupungin näkökulmasta

Espoon arkkitehtuurin kehittäminen - Tiedonhallinta ja arkkitehtuuri kaupungin näkökulmasta Espoon arkkitehtuurin kehittäminen - Tiedonhallinta ja arkkitehtuuri kaupungin näkökulmasta Arkistosektorin KDK- yhteistyöverkosto 10.11.2014 Marko Kukkonen, Konserniesikunta - Tietohallinto Kokonaisarkkitehtuuri

Lisätiedot

Paikkatiedot ja Web-standardit

Paikkatiedot ja Web-standardit Paikkatiedot ja Web-standardit Ossi Nykänen Tampereen teknillinen yliopisto (TTY), Digitaalisen median instituutti (DMI), Hypermedialaboratorio W3C Suomen toimisto Esitelmä Hyvin lyhyt versio: World Wide

Lisätiedot

FiSMA 1.1 Toiminnallisen laajuuden mittausmenetelmä Ohje monikerrosarkkitehtuurin mittaamiseen

FiSMA 1.1 Toiminnallisen laajuuden mittausmenetelmä Ohje monikerrosarkkitehtuurin mittaamiseen FiSMA 1.1 Monikerrosarkkitehtuuri 1 (7) FiSMA 1.1 Toiminnallisen laajuuden mittausmenetelmä Ohje monikerrosarkkitehtuurin mittaamiseen 1. Yleiset periaatteet FiSMA 1.1 -menetelmässä mitataan sovellusperiaatteen

Lisätiedot

7. Product-line architectures

7. Product-line architectures 7. Product-line architectures 7.1 Introduction 7.2 Product-line basics 7.3 Layered style for product-lines 7.4 Variability management 7.5 Benefits and problems with product-lines 1 Short history of software

Lisätiedot

Terveydenhuollon standardoinnin tilanne tänään, tietohallintopäälli kkö Pekka Ruotsalainen, Stakes

Terveydenhuollon standardoinnin tilanne tänään, tietohallintopäälli kkö Pekka Ruotsalainen, Stakes SUOMEN KUNTAUITTO Sosiaali- ja terveysyksikkö TERVEYDENHUOLLON 27. ATK- PAIVAT 4. - 5.6.2001 Terveydenhuollon standardoinnin tilanne tänään, tietohallintopäälli kkö Pekka Ruotsalainen, Stakes cncydcnhuollon

Lisätiedot

Automaatiojärjestelmän hankinnassa huomioitavat tietoturva-asiat

Automaatiojärjestelmän hankinnassa huomioitavat tietoturva-asiat Automaatiojärjestelmän hankinnassa huomioitavat tietoturva-asiat Teollisuusautomaation tietoturvaseminaari Purchasing Manager, Hydro Lead Buyer, Industrial Control Systems 1 Agenda / esityksen tavoite

Lisätiedot

Arkkitehtuurikuvaus. Ratkaisu ohjelmistotuotelinjan monikielisyyden hallintaan Innofactor Oy. Ryhmä 14

Arkkitehtuurikuvaus. Ratkaisu ohjelmistotuotelinjan monikielisyyden hallintaan Innofactor Oy. Ryhmä 14 Arkkitehtuurikuvaus Ratkaisu ohjelmistotuotelinjan monikielisyyden hallintaan Innofactor Oy Ryhmä 14 Muutoshistoria Versio Pvm Päivittäjä Muutos 0.4 1.11.2007 Matti Eerola 0.3 18.10.2007 Matti Eerola 0.2

Lisätiedot

Hoitoisuuden ja rakenteisen kirjaamisen kumppanuus. Pia Liljamo, erikoissuunnittelija, TtM Pohjois-Pohjanmaan sairaanhoitopiiri 16.5.

Hoitoisuuden ja rakenteisen kirjaamisen kumppanuus. Pia Liljamo, erikoissuunnittelija, TtM Pohjois-Pohjanmaan sairaanhoitopiiri 16.5. Hoitoisuuden ja rakenteisen kirjaamisen kumppanuus Pia Liljamo, erikoissuunnittelija, TtM Pohjois-Pohjanmaan sairaanhoitopiiri 16.5.2012 Sähköisen potilaskertomustiedon hyödyntäminen johtamisessa Sähköisen

Lisätiedot

11.10.2013 Tekijän nimi

11.10.2013 Tekijän nimi 11.10.2013 Tekijän nimi Arkkitehtuuri kehittämisen välineenä Kokonaisarkkitehtuuri hallitun muutoksen avaimena Etelä-Savon maakuntaliitto 10.10.2013 Markku Nenonen Tutkijayliopettaja Mikkelin ammattikorkeakoulu

Lisätiedot

SÄHKE- ja Moreqvaikutukset. dokumenttienhallinnan järjestelmäkehitykseen. Juha Syrjälä, Affecto Finland Oy

SÄHKE- ja Moreqvaikutukset. dokumenttienhallinnan järjestelmäkehitykseen. Juha Syrjälä, Affecto Finland Oy SÄHKE- ja Moreqvaikutukset asian- ja Ju dokumenttienhallinnan järjestelmäkehitykseen Juha Syrjälä, Affecto Finland Oy Affecto Enterprise Information Management -ratkaisujen edelläkävijä Pohjois- Euroopassa

Lisätiedot

www.solita.fi solita@solita.fi

www.solita.fi solita@solita.fi www.solita.fi solita@solita.fi JAVA-SOVELLUSTEN RAKENTAMINEN INTEGROITUUN YMPÄRISTÖÖN Jarno Peltoniemi Solita Oy 10.5.2005 Aiheet Johdanto Portaalit, portletit Oracle Portal Java-sovelluksen rakentaminen

Lisätiedot

Järjestelmäarkkitehtuuri (TK081702) Järjestelmäarkkitehtuuri. Järjestelmäarkkitehtuuri

Järjestelmäarkkitehtuuri (TK081702) Järjestelmäarkkitehtuuri. Järjestelmäarkkitehtuuri Järjestelmäarkkitehtuuri (TK081702) ja Järjestelmäarkkitehtuuri Sovellukset ovat olemassa Järjestelmien uudistaminen vie yleensä arvioitua enemmän resursseja ja kestää arvioitua kauemmin Migration (Migraatio

Lisätiedot

KAOS 2015: Integraatioiden standardointi suunnittelumallien avulla. Ilkka Pirttimaa, Chief ICT Architect, Stockmann ICT

KAOS 2015: Integraatioiden standardointi suunnittelumallien avulla. Ilkka Pirttimaa, Chief ICT Architect, Stockmann ICT KAOS 2015: Integraatioiden standardointi suunnittelumallien avulla Ilkka Pirttimaa, Chief ICT Architect, Stockmann ICT 1 2 Integraatioiden nykytila 2015 Standardoidut: Integraatiotyökalut Suunnittelumallit

Lisätiedot

JHS 179 Kokonaisarkkitehtuurin suunnittelu ja kehittäminen Liite 4. Soveltamisohje perustason kuvauksien tuottamiseen

JHS 179 Kokonaisarkkitehtuurin suunnittelu ja kehittäminen Liite 4. Soveltamisohje perustason kuvauksien tuottamiseen JHS 179 Kokonaisarkkitehtuurin suunnittelu ja kehittäminen Liite 4. Soveltamisohje perustason kuvauksien tuottamiseen Versio: Luonnos palautekierrosta varten Julkaistu: Voimassaoloaika: toistaiseksi Sisällys

Lisätiedot

Rakentamisen 3D-mallit hyötykäyttöön

Rakentamisen 3D-mallit hyötykäyttöön Rakentamisen 3D-mallit hyötykäyttöön 1 BIM mallien tutkimuksen suunnat JAO, Jyväskylä, 22.05.2013 Prof. Jarmo Laitinen, TTY rakentamisen tietotekniikka Jarmo Laitinen 23.5.2013 Jarmo Laitinen 23.5.2013

Lisätiedot

TURVAVÄYLÄSEMINAARI. Erilaiset kenttäväylät ja niiden kehitys 13.11.2002. Jukka Hiltunen

TURVAVÄYLÄSEMINAARI. Erilaiset kenttäväylät ja niiden kehitys 13.11.2002. Jukka Hiltunen TURVAVÄYLÄSEMINAARI Erilaiset kenttäväylät ja niiden kehitys 13.11.2002 Jukka Hiltunen Miksi väylätekniikkaa? 1. luonnolliset perusteet: : kehittyneiden kenttälaitteiden ja ylemmän tason laitteiden välille

Lisätiedot

TERVEYDENHUOLLON 25. ATK-PAIVAT Kuopio, Hotelli Scandic 31.5-1.6.1999. toimitusjohtaja Antero Ensio Ensitieto Oy. SUOMEN KUNTALIITTO Sairaalapalvelut

TERVEYDENHUOLLON 25. ATK-PAIVAT Kuopio, Hotelli Scandic 31.5-1.6.1999. toimitusjohtaja Antero Ensio Ensitieto Oy. SUOMEN KUNTALIITTO Sairaalapalvelut TERVEYDENHUOLLON 25. ATK-PAIVAT Kuopio, Hotelli Scandic 31.5-1.6.1999 toimitusjohtaja Antero Ensio Ensitieto Oy Terveydenhuollon tietotekniikan standardoinnin tilannekatsaus SUOMEN KUNTALIITTO Sairaalapalvelut

Lisätiedot

Uutisjärjestelmä. Vaatimusmäärittely. Web-palvelujen kehittäminen. Versio 1.3

Uutisjärjestelmä. Vaatimusmäärittely. Web-palvelujen kehittäminen. Versio 1.3 Uutisjärjestelmä Vaatimusmäärittely Versio 1.3 Sisällys 1 Muutoshistoria... 4 2 Viitteet... 4 3 Sanasto... 4 3.1 Lyhenteet... 4 3.2 Määritelmät... 4 4 Johdanto...5 4.1 Järjestelmän yleiskuvaus... 5 4.2

Lisätiedot

IHE XDS.b - Kuinka Se Toimii Käytännössä?

IHE XDS.b - Kuinka Se Toimii Käytännössä? IHE XDS.b - Kuinka Se Toimii Käytännössä? Ensemble Käyttäjätapaaminen 20.10.2011 Anssi Kauppi / InterSystems Nordics / Suomi Seuraava Aihe IHE ja IHE Suomessa IHE Profiilit XDS.b Profiili Muita Profiileja

Lisätiedot

Projektin tilannekatsaus

Projektin tilannekatsaus Kuntasektorin yhteinen KA Asianhallinnan viitearkkitehtuuri Projektin tilannekatsaus Heini Holopainen Kuntien Tiera Oy heini.holopainen@tiera.fi Sisältö» Taustaa Mitä tarkoitetaan viitearkkitehtuurilla

Lisätiedot

Sosiaalihuollon toimintaprosessien mallinnus. Päivi Röppänen Terveydenhuollon Atk-päivät 26.-27.5.2009 Jyväskylä

Sosiaalihuollon toimintaprosessien mallinnus. Päivi Röppänen Terveydenhuollon Atk-päivät 26.-27.5.2009 Jyväskylä Sosiaalihuollon toimintaprosessien mallinnus Päivi Röppänen Terveydenhuollon Atk-päivät 26.-27.5.2009 Jyväskylä Sisältö Taustaa Tavoite Lähtökohta Tuotokset Prosessien kuvaaminen esimerkkinä lasten päivähoito

Lisätiedot

Muutos Tutkimusyhteistyösopimukseen. PlugIT: Terveydenhuollon sovellusintegraatio

Muutos Tutkimusyhteistyösopimukseen. PlugIT: Terveydenhuollon sovellusintegraatio Muutos PlugIT-tutkimusyhteistyösopimukseen, sivu 1/29 Muutos Tutkimusyhteistyösopimukseen PlugIT: Terveydenhuollon sovellusintegraatio 1. Projektiosapuolet: 1.1 Tutkimusosapuolet KUOPION YLIOPISTO, projektin

Lisätiedot

RAKENNETUN(OMAISUUDEN( DIGITALISAATIO

RAKENNETUN(OMAISUUDEN( DIGITALISAATIO RAKENNETUN(OMAISUUDEN( DIGITALISAATIO TOMI%HENTTINEN Arkkitehti SAFA buildingsmart Finland,%puheenjohtaja ABOUT ME TOMI HENTTINEN M.Sc. (Archit.) SAFA buildingsmart Finland, Chair Gravicon Oy, Founder,

Lisätiedot

JHS 179 ICT-palvelujen kehittäminen: Kokonaisarkkitehtuurin kehittäminen Liite 2 Arkkitehtuurikehyksen kuvaus

JHS 179 ICT-palvelujen kehittäminen: Kokonaisarkkitehtuurin kehittäminen Liite 2 Arkkitehtuurikehyksen kuvaus JHS 179 ICT-palvelujen kehittäminen: Kokonaisarkkitehtuurin kehittäminen Liite 2 Arkkitehtuurikehyksen kuvaus Versio: 1.0 Julkaistu: 8.2.2011 Voimassaoloaika: toistaiseksi Sisällys 1 Arkkitehtuurikehyksen

Lisätiedot

Järjestelmäarkkitehtuuri (TK081702) Yritysarkkitehtuuri. Muutostarpeet

Järjestelmäarkkitehtuuri (TK081702) Yritysarkkitehtuuri. Muutostarpeet Järjestelmäarkkitehtuuri (TK081702) Ympäristö Muutostarpeet ja niihin vastaaminen Yritysarkkitehtuuri Liiketoiminta-arkkitehtuuri Tavoitteet, Palvelut, Prosessit Informaatioarkkitehtuuri Tietotarpeet,

Lisätiedot

IT-OSAAJA, TIETOJENKÄSITTELYN ERIKOISTUMISOPINNOT

IT-OSAAJA, TIETOJENKÄSITTELYN ERIKOISTUMISOPINNOT IT-OSAAJA, TIETOJENKÄSITTELYN ERIKOISTUMISOPINNOT KOULUTUKSEN KOHDERYHMÄ SISÄLTÖ Koulutuksen tavoitteena on antaa opiskelijalle valmiudet uusien tietoteknisten menetelmien ja välineiden hyödyntämiseen.

Lisätiedot

HELSINKI AREA TESTBED. Martti Mäntylä, HIIT 12.3.2003

HELSINKI AREA TESTBED. Martti Mäntylä, HIIT 12.3.2003 HELSINKI AREA TESTBED Martti Mäntylä, HIIT 12.3.2003 Pääkaupunkiseudun innovaatioympäristö Pääkaupunkiseudulla hyvät lähtökohdat uusien ICTyritysten syntymiseen Innovaatioympäristöä täytyy kehittää edelleen:

Lisätiedot

Yliopistollisten sairaanhoitopiirien klusteri

Yliopistollisten sairaanhoitopiirien klusteri Yliopistollisten sairaanhoitopiirien klusteri Kehittämispäällikkö Sinikka Ripatti HUS Tieto- ja lääkintätekniikan tulosalue Kehittämis- ja sovelluspalvelut Osapuolet Helsingin ja Uudenmaan sairaanhoitopiiri,

Lisätiedot

Julkisen hallinnon kokonaisarkkitehtuuri JHKA

Julkisen hallinnon kokonaisarkkitehtuuri JHKA Julkisen hallinnon kokonaisarkkitehtuuri JHKA Tilanne 2.10.2012 neuvotteleva virkamies Jukka Uusitalo Julkisen hallinnon kokonaisarkkitehtuuri Julkisen hallinnon kokonaisarkkitehtuuri on rakenne, jonka

Lisätiedot

Smart cities - nyt ja huomenna

Smart cities - nyt ja huomenna Smart cities - nyt ja huomenna Älykaupungin standardit Jari Reini 14.04.2015 Standardisointi - Miksi? Minimoidaan päällekkäistä kehittämistyötä, ohjataan tietojärjestelmien kehittämistä ja saadaan aikaan

Lisätiedot

Käytettävyyslaatumallin rakentaminen web-sivustolle. Oulun yliopisto tietojenkäsittelytieteiden laitos pro gradu -suunnitelma Timo Laapotti 28.9.

Käytettävyyslaatumallin rakentaminen web-sivustolle. Oulun yliopisto tietojenkäsittelytieteiden laitos pro gradu -suunnitelma Timo Laapotti 28.9. Käytettävyyslaatumallin rakentaminen web-sivustolle Tapaus kirjoittajan ABC-kortti Oulun yliopisto tietojenkäsittelytieteiden laitos pro gradu -suunnitelma Timo Laapotti 28.9.2005 Kirjoittajan ABC-kortti

Lisätiedot

Luento 12: XML ja metatieto

Luento 12: XML ja metatieto Luento 12: XML ja metatieto AS-0.110 XML-kuvauskielten perusteet Janne Kalliola XML ja metatieto Metatieto rakenne sanasto Resource Description Framework graafikuvaus XML Semanttinen Web agentit 2 1 Metatieto

Lisätiedot

JHS XML suositus. XML Finland tapahtuma 20.1.2009 Mikael af Hällström ylitarkastaja, Verohallinto JHS XML työryhmän vetäjä

JHS XML suositus. XML Finland tapahtuma 20.1.2009 Mikael af Hällström ylitarkastaja, Verohallinto JHS XML työryhmän vetäjä JHS XML suositus XML Finland tapahtuma 20.1.2009 Mikael af Hällström ylitarkastaja, Verohallinto JHS XML työryhmän vetäjä JHS XML suositus Esityksen sisältö: Suositustyön lähtökohdat ja taustat (Vielä)

Lisätiedot

Sanastotyö luokittelun tukena Tikesos-hankkeessa. NordTERM 2011 Antero Lehmuskoski ja Maarit Laaksonen

Sanastotyö luokittelun tukena Tikesos-hankkeessa. NordTERM 2011 Antero Lehmuskoski ja Maarit Laaksonen Sanastotyö luokittelun tukena Tikesos-hankkeessa NordTERM 2011 Antero Lehmuskoski ja Maarit Laaksonen Esityksen sisältö Tikesos-hankkeen lähtökohdat ja tavoitteet Sanastotyö osana Tikesos-hankkeen tietoarkkitehtuurityötä

Lisätiedot

HP OpenView ratkaisut toiminnan jatkuvuuden turvaajina

HP OpenView ratkaisut toiminnan jatkuvuuden turvaajina HP OpenView ratkaisut toiminnan jatkuvuuden turvaajina - Käytännön esimerkkejä ITIL ja ITSM mukaisista IT palveluhallinnan toteutuksista ja mahdollisuuksista Ville Koskinen Sales Specialist, HP Software

Lisätiedot

From selling to supporting - using customer data for the benefit of the customer

From selling to supporting - using customer data for the benefit of the customer From selling to supporting - using customer data for the benefit of the customer Hannu Saarijärvi Johdanto Yritykset ovat perinteisesti keskittyneet asiakasdatan hyödyntämisessä (CRM) omiin, yrityksen

Lisätiedot

Kanta-palvelut, Kelan näkökulma

Kanta-palvelut, Kelan näkökulma Kanta-palvelut, Kelan näkökulma Pia Järvinen-Hiekkanen Lääkäriliitto 6.3.2014 Kela Kanta-palvelujen toteuttajana Kela on myös iso IT-talo Tietohallinnon toimialalla toimii IT-osasto, Tietohallinto-osasto

Lisätiedot

Sosiaalihuollon valtakunnallisten tjpalveluiden. I-vaihe

Sosiaalihuollon valtakunnallisten tjpalveluiden. I-vaihe Sosiaalihuollon valtakunnallisten tjpalveluiden käyttöönotto I-vaihe Tueksi pilottihankkeen suunnitteluun 4.9.2015 THL/OPER-yksikkö 1 Käyttöönoton vaiheistus I vaihe: PDF- tallennus ja tiedon saatavuus

Lisätiedot

7 Viestipohjaisten yritysjärjestelmien suunnittelumallit

7 Viestipohjaisten yritysjärjestelmien suunnittelumallit 7 Viestipohjaisten yritysjärjestelmien suunnittelumallit Hohpe G., Woolf B.: Enterprise Integration Patterns. Addison-Wesley 2004. Ohjelmistoarkkitehtuurit Syksy 2010 TTY Ohjelmistotekniikka 1 Viestinvälitykseen

Lisätiedot

Suomen avoimien tietojärjestelmien keskus COSS ry

Suomen avoimien tietojärjestelmien keskus COSS ry Viisaat hankinnat: Avoimuudet uusissa JIT 2015 -ehdoissa JulkICTLab-seminaari 20.11.2015 Martin von Willebrand, puheenjohtaja Avoin arkkitehtuuri Luo jäsenien menestystarinoita avoimilla ratkaisuilla Avoimet

Lisätiedot

Kuntien integraatioalusta. Hannes Rauhala 3.11.2015

Kuntien integraatioalusta. Hannes Rauhala 3.11.2015 Kuntien integraatioalusta Hannes Rauhala 3.11.2015 Johdantoa asiaan Espoon kaupunki on toiminut edelläkävijänä kansallisen palveluväylän (Xroad) käyttöönotossa. Asiasta järjestettiin Espoossa ja Lahdessa

Lisätiedot

Aluetietojärjestelmien migraatio kansallisten palveluiden käyttöön

Aluetietojärjestelmien migraatio kansallisten palveluiden käyttöön Aluetietojärjestelmien migraatio kansallisten palveluiden käyttöön Pegasos - klusteri Terveydenhuollon atk-päivät Turku 29.-30.5.2007 Kuopion kaupunki sosiaali- ja terveyskeskus Juhani Ahola Tietohallintopäällikkö

Lisätiedot

Kristian Appel, Traficon Oy. EETS ja monipalvelu älyliikenteessä seminaari 31.5.2011

Kristian Appel, Traficon Oy. EETS ja monipalvelu älyliikenteessä seminaari 31.5.2011 Missä mennään EETS standardisoinnissa ja määrittelyissä Kristian Appel, Traficon Oy EETS ja monipalvelu älyliikenteessä seminaari 31.5.2011 Esityksen pääkohdat Yleistä standardisoinnista CEN TC 278 WG1

Lisätiedot

Sähkönjakeluverkon hallinnan arkkitehtuuri. Sami Repo

Sähkönjakeluverkon hallinnan arkkitehtuuri. Sami Repo Sähkönjakeluverkon hallinnan arkkitehtuuri Sami Repo Miksi? Energiansäästö Muut lämmitysmuodot korvautuvat lämpöpumpuilla Nollaenergiarakentaminen (ZEB) Sähköautot Lämmityskuormien ohjaaminen hinnan perusteella

Lisätiedot

Julkisen hallinnon kokonaisarkkitehtuurin tilanne. KAOS 12.5.2015 neuvotteleva virkamies Jari Kallela

Julkisen hallinnon kokonaisarkkitehtuurin tilanne. KAOS 12.5.2015 neuvotteleva virkamies Jari Kallela Julkisen hallinnon kokonaisarkkitehtuurin tilanne KAOS 12.5.2015 neuvotteleva virkamies Jari Kallela Sisältö Mitä on tehty kokonaisarkkitehtuurissa? Mikä on arvio nykytilasta? Mihin mennään seuraavaksi?

Lisätiedot

Tenttikysymykset. + UML- kaavioiden mallintamistehtävät

Tenttikysymykset. + UML- kaavioiden mallintamistehtävät Tenttikysymykset 1. Selitä mitä asioita kuuluu tietojärjestelmän käsitteeseen. 2. Selitä kapseloinnin ja tiedon suojauksen periaatteet oliolähestymistavassa ja mitä hyötyä näistä periaatteista on. 3. Selitä

Lisätiedot

SFS:n IT-standardisoinnin vuosiseminaari 16.12.2014

SFS:n IT-standardisoinnin vuosiseminaari 16.12.2014 SFS:n IT-standardisoinnin vuosiseminaari 16.12.2014 Tomi Dahlberg Tietohallinto ISO/IEC 20000 ISO/IEC 38500 Liiketoiminta Liiketoimintaprosessit ISO/IEC 30105 2 SFS:n seurantaryhmä SR 308 seuraa ISO/IEC

Lisätiedot

SOLEA palvelupohjainen paikallisesti sovitettava kokonaisarkkitehtuuri. Service-Oriented Locally adapted Enterprise Architecture

SOLEA palvelupohjainen paikallisesti sovitettava kokonaisarkkitehtuuri. Service-Oriented Locally adapted Enterprise Architecture SOLEA palvelupohjainen paikallisesti sovitettava kokonaisarkkitehtuuri Service-Oriented Locally adapted Enterprise Architecture "Miten meillä mennään SOA:an?" @ SOLEA-project participants Hankkeen osapuolet

Lisätiedot

Hyvin määritelty on puoliksi tehty kuinka vältetään turha tekeminen jo alussa

Hyvin määritelty on puoliksi tehty kuinka vältetään turha tekeminen jo alussa 1 Hyvin määritelty on puoliksi tehty kuinka vältetään turha tekeminen jo alussa Passion leads to design, design leads to performance, performance leads to SUCCESS! OLLI NIEMI Yoso Oy Mitä määrittelyltä

Lisätiedot

SUOMEN KUNTALIITTO RY

SUOMEN KUNTALIITTO RY Karttaliittymä Versio: 18.10.2011 Julkaistu: 27.10.2011 Voimassaoloaika: Toistaiseksi Sisällys 1 Johdanto... 2 1.1 Suosituksen tausta... 2 1.2 Suosituksen rakenne... 2 2 Soveltamisala... 2 3 Lyhenteet...

Lisätiedot

Computing Curricula 2001 -raportin vertailu kolmeen suomalaiseen koulutusohjelmaan

Computing Curricula 2001 -raportin vertailu kolmeen suomalaiseen koulutusohjelmaan Computing Curricula 2001 -raportin vertailu kolmeen suomalaiseen koulutusohjelmaan CC1991:n ja CC2001:n vertailu Tutkintovaatimukset (degree requirements) Kahden ensimmäisen vuoden opinnot Ohjelmistotekniikan

Lisätiedot

J2EE vs..net Olli Sakari

J2EE vs..net Olli Sakari TEEMA-ARTIKKELI J2EE vs..net Olli Sakari J2EE ja.net ovat tietojärjestelmäteknologioita, joiden varaan suuri osa tulevaisuuden tietojärjestelmistä tulee rakentumaan. Molemmat teknologioista tarjoavat välineitä

Lisätiedot

Vaatimusmäärittely Ohjelma-ajanvälitys komponentti

Vaatimusmäärittely Ohjelma-ajanvälitys komponentti Teknillinen korkeakoulu 51 Vaatimusmäärittely Ohjelma-ajanvälitys komponentti Versio Päiväys Tekijä Kuvaus 0.1 21.11.01 Oskari Pirttikoski Ensimmäinen versio 0.2 27.11.01 Oskari Pirttikoski Lisätty termit

Lisätiedot

Web-palvelukonsepti tarjoaa yhden tavan toteuttaa SOA. Tämä tapa perustuu Web-palvelustandardien käyttöön: palvelut kuvataan WSDL-kielen avulla ja

Web-palvelukonsepti tarjoaa yhden tavan toteuttaa SOA. Tämä tapa perustuu Web-palvelustandardien käyttöön: palvelut kuvataan WSDL-kielen avulla ja 1 Web-palvelukonsepti tarjoaa yhden tavan toteuttaa SOA. Tämä tapa perustuu Web-palvelustandardien käyttöön: palvelut kuvataan WSDL-kielen avulla ja kommunikointi toteutetaan SOAPin avulla. Näihin kieliin

Lisätiedot

Lisensointikuulumisia - Kustannustehokkuus Oracle lisensoinnissa

Lisensointikuulumisia - Kustannustehokkuus Oracle lisensoinnissa Lisensointikuulumisia - Kustannustehokkuus Oracle lisensoinnissa Osa II OUGF / 12.5.2004 c Sisält ltö Mitä uutta? Yleistä lisensoinnista Lisensointiin liittyviä ongelmia Hankinnassa muistettavia asioita

Lisätiedot

Käsitemallit muistiorganisaatioiden kuvailun yhdenmukaistamisen välineenä

Käsitemallit muistiorganisaatioiden kuvailun yhdenmukaistamisen välineenä Käsitemallit muistiorganisaatioiden kuvailun yhdenmukaistamisen välineenä Pekka Henttonen KDK:n arkistosektorin seminaari 6.2.2012 Kansallisarkisto Esityksen sisältö Semanttisen webin visio Käsitemallien

Lisätiedot

JHS XXX ICT-palvelujen kehittäminen: Laadunvarmistus Liite 6: Katselmointi

JHS XXX ICT-palvelujen kehittäminen: Laadunvarmistus Liite 6: Katselmointi JHS XXX ICT-palvelujen kehittäminen: Laadunvarmistus Liite 6: Katselmointi Versio: 0.9 Julkaistu: n.n.2011 Voimassaoloaika: toistaiseksi Sisällys 1 Katselmointi osana laadunvarmistusta... 2 2 Yleistä katselmoinneista...

Lisätiedot

Tuottavatko pilotoinnit tuloksia riittävän nopeasti käytännön hankkeiden kokemuksia

Tuottavatko pilotoinnit tuloksia riittävän nopeasti käytännön hankkeiden kokemuksia Tuottavatko pilotoinnit tuloksia riittävän nopeasti käytännön hankkeiden kokemuksia Tuottavat ja eivät tuota Tulokset riippuvat niistä tekijöistä, jotka projektia perustettaessa on määritelty ja miten

Lisätiedot

Tekninen suunnitelma - StatbeatMOBILE

Tekninen suunnitelma - StatbeatMOBILE Tekninen suunnitelma - StatbeatMOBILE Versio Päivämäärä Henkilö Kuvaus 1.0 13.12.2013 Pöyry Alustava rakenne ja sisältö 1.1 22.12.2013 Pöyry Lisätty tekstiä ilmoituksiin, turvallisuuteen ja sisäiseen API:in

Lisätiedot