Standardit ja tietoarkkitehtuuri valitse viisaasti KAOS tapaaminen Espoo, 6.10.2010 Juha Mykkänen HIS-tutkimusyksikkö Tietojenkäsittelytieteen laitos Itä-Suomen yliopisto, Kuopion kampus juha.mykkanen@uef.fi 1
Puhujan ja sisällön taustaa Juha Mykkänen, FT tutkimusjohtaja, Itä-Suomen yliopisto, Kuopion kampus, HIS-tutkimusyksikkö, tutkimuslinjan johtaja, Kuopio Welfare Research Center KWRC health and wellbeing information systems, interoperability, SOA, EA, modeling projekteja palvelupohjaisen kokonaisarkkitehtuurin ja integrointiratkaisujen tutkimiseen ja kehittämiseen, tähän esitykseen liittyvät: SOLEA: palvelupohjainen paikallisesti sovitettava kokonaisarkkitehtuuri 2008-2011 Sosiaalialan tietoteknologiahanke - Tikesos 2006-2011 Healthcare services specification project (HSSP) / HL7 and OMG, 2005- Integrating the Healthcare Enterprise - IHE.fi 2008- Various HL7 Finland and web services standards implementation guides, 2004-2009 standardien määrittely, arviointi ja hyödyntäminen: HL7 Finland 2004-, varapuheenjohtaja + IHE SIG + SOA SIG, HL7 International SOA ambassador OMG, Object Management Group (erityisesti Healthcare DTF), 2000-2009 SFS 2007-, SR:t 301 Terveydenhuollon tietotekniikka ja 310 Verkkosovellukset JHS standardisalkku 2010-2
Sisältö Johdanto Standardit ja standardoinnin kohteet tietoarkkitehtuuri suurennuslasin alla Standardien arviointi ja valinta Tärkeät valinnat Keskustelu Painotettavat näkökulmat: yhteentoimivuuden tukeminen kokonaisarkkitehtuurissa EA-tulokulma [Dragstra, 2005]: Business-IT alignment (IT centric) Manage and improve business processes (Business process centric) Understand and govern business better (Governance centric) 3
konsensus: hyväksyminen uudelleenkäyttö asiakirja lain ja ohjeen välimaastossa Standard(is)ointi STANDARDI = tunnustetun osapuolen hyväksymä dokumentti, jossa on määritelty yleistä ja toistuvaa käyttöä varten sääntöjä, ohjeita tai piirteitä tuotteille, prosesseille tai palveluille [Project management institute] Standardoinnin tavoitellut hyödyt: teknisiä ja taloudellisia koordinaation muoto yhteensopivuuden lisääntyminen eri toimijat, eri toimittajien tuotteet mahdollisuus keskittyä korkeamman tason ominaisuuksiin edistää teknologian vähittäistä kehittämistä vähentää teknisesti ja kaupallisesti merkityksettömiä eroja visio avoimesta järjestelmästä, johon voidaan kehittää uusia tuotteita tietojärjestelmät yhä enemmän yhteiskäyttöisiä, verkottuneita, alueellisia ja kansallisia 4
Standardoinnin kohteita tietosisällöt (kohdealueen, järjestelmien, asiakirjojen, rajapintojen...) tiedon siirto/esitysmuodot (viestit, asiakirjamuodot, rakenteisuus, tietotyypit jne.) järjestelmien toiminnalliset ominaisuudet arkkitehtuuri (osat, niiden suhteet + kehittämisperiaatteet) rajapintatekniikat turvallisuusratkaisut tietoliikenne, viestit, sanomat palvelurajapinnat jne. medicine and healthcare processes, pathways quality of care information models and elements terminologies, classifications, codes guidelines, knowledge standardization relevant to ehealth and HIS healthcare IT and IS electronic health records security and confidentiality support for processes service and API interfaces archiving and long term storage message interfaces electronic clinical documents data types and formats architecture IT, domain-neutral and cross-domain software production / development security process description and definition interface technologies messaging and enveloping electronic documents egovernmenance and architecture identification data communications TOIMIALAKOHTAISET, (YHDISTELMÄ), YLEISET JA TEKNISET 5
Yhteentoimivuustasot European Interoperability Framework Technical tekninen liitettävyys Avoimet rajapinnat, liitettävyyspalvelut, tietointegraatio, väliohjelmistot, tietojen esitys- ja siirtomuodot, saatavuus- ja turvallisuuspalvelut Semantic tietojen ymmärrettävyys Siirretyn tiedon tarkka merkitys, jotta se voidaan ymmärtää myös sovelluksissa jotka eivät ole tiedon lähteitä, tietojen yhdistely Organizational organisaatioiden yhteistoiminta Toiminnan tavoitteet, toimintaprosessien yhteensopivuus, hallintojen luomat edellytykset, palvelujen saatavuus ja tunnistettavuus käyttäjille yleiset ja toimialariippumattomat standardit tukevat kaikkia tasoja, mutta sisältöjen sopiminen usein toimialaspesifiä 6
Standardit syötteinä tietonäkökulman kuvauksille kokonaisarkkitehtuurissa (TOGAF) Preliminary Phase Principles catalog Phase A, Architecture Vision Stakeholder Map matrix Value Chain diagram Solution Concept diagram Phase B, Business Architecture Organization/Actor catalog Driver/Goal/Objective catalog Role catalog Business Service/Function catalog Location catalog Process/Event/Control/Product catalog Contract/Measure catalog Business Interaction matrix Actor/Role matrix Business Footprint diagram Business Service/Information diagram Functional Decomposition diagram Product Lifecycle diagram Goal/Objective/Service diagram Use-Case diagram Organization Decomposition diagram Process Flow diagram Event diagram Phase C, Data Architecture Data Entity/Data Component catalog Data Entity/Business Function matrix System/Data matrix Class diagram Data Dissemination diagram Data Security diagram Class Hierarchy diagram Data Migration diagram Data Lifecycle diagram Phase C, Application Architecture Application Portfolio catalog Interface catalog System/Organization matrix Role/System matrix System/Function matrix Application Interaction matrix Application Communication diagram Application and User Location diagram System Use-Case diagram Enterprise Manageability diagram Process/System Realization diagram Software Engineering diagram Application Migration diagram Software Distribution diagram Phase D, Technology Architecture Technology Standards catalog Technology Portfolio catalog System/Technology matrix Environments and Locations diagram Platform Decomposition diagram Processing diagram Networked Computing/Hardware diagram Communications Engineering diagram Phase E. Opportunities & Solutions Project Context diagram Benefits diagram Requirements Management Requirements catalog 7
Tietonäkökulman standardivalintoja metataso käytämme näitä mekanismeja tietomallien ilmaisemiseen mallinnusnotaatiot tai -käytännöt, rajapintatekniikat tyyppitaso käytämme näitä tietorakenteita toimialan ja sovellusten / rajapintojen tietomallit looginen ja fyysinen / tekninen sisältötaso käytämme näitä tietoja terminologiat, koodistot, luokitukset (varsinainen tieto ja master data harvoin standardoitua) 8
Yhteentoimivuustasot 1 standardi ottaa kantaa joihinkin ja vaikuttaa joihinkin järjestelmän elinkaari toiminnallinen arkkitehtuuri Lait, ohjeet, toimintatavat Prosessit Kehitysprosessin liittymät Toiminnallinen viitemalli Semantiikka Toiminnalliset liittymät sovellusarkkitehtuuri tekninen arkkitehtuuri ratkaistava kaikissa sovellusintegraatiotilanteissa Sovellusinfrastruktuuri Tekninen infrastruktuuri Tekniset liittymät Verkot Laitteet [Peter Herzum, Oliver Sims] 9
Tasojen sisältöä tietoarkkitehtuurin näkökulmasta Prosessien tunnisteet, niiden osana olevien toimintojen rajapinnat Metatason standardivalinnat (notaatiot), tietomallinnuskäytännöt Yhteinen käsitemalli, yhteinen tietomalli (esim. RIM) tai käyttökohde- / sovelluskohtaiset tietomallit Prosessit Kehitysprosessin liittymät Toiminnallinen viitemalli Koodistot, terminologiat, luokitukset Tyyppitason standardivalinnat, rajapinnoissa käytettävät tietomallit, dokumenttimäärittelyt, parametrimäärittelyt, tietohakemistokuvaukset MDM-arkkitehtuurivalinnat, keskitys- ja hajautusvalinnat Viestinvälitys- ja integraatioalustat (ESB), muunnos- ja provisiointipalvelut Viestinvälitys- ja integraatioalustat (ESB), muunnos- ja provisiointipalvelut Semantiikka Toiminnalliset liittymät Sovellusinfrastruktuuri Tekninen infrastruktuuri Tekniset liittymät 10
Standardien arviointi ja valinta - esimerkkiprosessi [Mykkänen JA, Tuomainen MP. An evaluation and selection framework for interoperability standards. Inform Software Tech 2008:50(3):176-197.]
Arviointiprosessi piirreanalyysin ja yleisten arviointisuositusten (SA-CMM) hyödyntäminen periaate: ensin yleiskuva standardista, VAIN TARVITTAESSA porautuminen tarkemmin tutkittaviin seikkoihin vaiheet 1-3: vaatimusten dokumentointi, materiaalin hankinta, arvioinnin suunnittelu vaiheet 4-8: yleiskuvan luonti standardista (scope, kenelle ja mihin tarkoitukseen, päälähestymistavat, miten laajasti käytössä (päätös tutkitaanko tarkemmin standardisalkkutyössä EI?) vaiheet 9-15: tarkka eri vaikutusten analysointi vaiheet 16-17: yhteenveto ja tulosten koostaminen myös yksinkertainen kaava standardien pisteyttämiseen tapauskohtaisia vaatimuksia vasten
Arviointikehys 1-9 täytettävää lomaketta, max 54 arvioitavaa kohtaa [Mykkänen JA, Tuomainen MP. An evaluation and selection framework for interoperability standards. Inform Software Tech 2008:50(3):176-197.]
JHS-standardisalkkuluonnoksessa korostettavia + soveltuvuus julkisen hallinnon EA-kehikkoon
EVALUATION FORM FOR INTEROPERABILITY STANDARDS Evaluation date: [YYYY-MM-DD] Evaluator: [Names, contact information] I BASIC INFORMATION AND SCOPE OF THE STANDARD 1. Abbreviation: [official abbreviation preferred] 2. Name of the [official] specification: 3. Version: [or date of the specification, if applicable] 4. Standard [name of organization, how available (address, limited/freely etc.)] organization and availability: 5. Scope statement of [citation] the standard: 6. Intended audience: technical business domain: combination/other 7. If domain specific: what is the business domain and [description] detailed sub-domain (see also form IX) 8. Number the relevant aspects (only), which standard specifies in relation to applications [20] (1 = most relevant) a) Organizational or individual goals, procedures or activities [#] b) Information or data in information systems or interfaces [#] c) Functionality, operations or workflows in information systems or [#] interfaces d) System architecture, components and connections [#] e) Interface or implementation technologies [#] 9. For the numbered aspects above, which are Concrete (what is in the [a-e] specified on concrete (what) level, which are specified on meta (how) level? solution): Meta (how it is specified or described): [a-e] Perustiedot-lomake (I) 10. Number the relevant aspects (only), which are specified in the standard [15] (1 = most relevant) (you can also describe how, unless you do not use more specific forms below) a) Interface technology [#] b) Implementation technology [#] c) Technology infrastructure (what is needed in [#] the technical environment, in relation to e.g. communication technology) d) Physical system distribution (e.g. servers, [#] clients, network connections) e) Logical system architecture (e.g. functional [#] parts or components) f) Data elements or information in interfaces [#] g) How to specify data elements or information [#] h) Operations or functions in interfaces [#] i) High-level information model or data [#] dictionary j) Workflows or processes [#] k) How to specify operations, functions, [#] workflows or processes l) Semantics for the data or information [#] m) Codesets, terminologies, classifications [#] n) Methods or procedures for human activities [#] in the application domain o) Methods or procedures for application or [#] software development 11. For the numbered aspects above, which are Concrete (what is in the [a-o] specified on concrete (what) level, which are specified on meta (how) level? solution): Meta (how it is specified [a-o] or described): 12. What are the main external (other) standards referenced? [description, references] 13. Short description of [description] how the standard is typically used: [Mykkänen JA, Tuomainen MP. An evaluation and selection framework for interoperability standards. Inform Software Tech 2008:50(3):176-197.] 15
II INFORMATION AND SEMANTICS 14. Is there an information model or a [description or n/a] concept model? How is it specified? 15. Are the main concepts specified? [description or n/a] What are they and what type are they? 16. Are the relationships between concepts [description or n/a] specified? How? 17. Is the scope of the concepts and [select one + description] relationships one application, specific domain, generic, or representation? [40] 18. Which of the following types of information does the standard specify [27],[1]? How? a) specific or allowed values or names (e.g. [description or n/a] list of terms, terminology, value sets) instance level b) names of parameters or data elements [description or n/a] type level c) data types of parameters or elements [description or n/a] type level d) relationships to related other types of [description or n/a] objects or information context level e) how to specify a,b,c or d meta level [description or n/a] 19. (if 18a): Is the specification one of the following? a) set of restricted coded values, with related explanation or definition (code set) [y/n, description] b) an arranged list or collection of words or phrases with explanation or [y/n, description] definition (vocabulary) c) as 19a or 19b with identified or grouped collections of included concepts [y/n, description] (classification) d) as 19c + hierarchical system with super- and subclasses (hierarchical [y/n, description] classification) e) one of the above + set of defined relationships between instances [y/n, description] (terminology) Information and semantics lomake (II) 1/2 16
20. (if 18b, 18c, 18d or 18e): Information syntax and granularity in interfaces a) Are parameters or elements described, using what [y/n, description] notation, syntax and technology are? b) Are there message or document structures specified? [y/n, description] How? c) Are there specified data types used? How? [y/n, description] d) Are parameters, messages or structures atomic or are [y/n, description] they grouped or structured to form real world objects? e) Does the information rely on identifiers, and how are [y/n, description] these identifiers used? 21. (if 18b, 18c, 18d or 18e): Information semantics in interfaces: Which mechanisms are used to specify the meaning or semantics in parameters or data elements? a) Natural language [y/n, description] b) Higher level reference model (e.g. RIM) or ontology [y/n, description] c) Formal constraint definition (languages, templates) [y/n, description] d) References to external code sets, classifications or [y/n, description] terminologies and their versions 22. Does the specification contain following flexibility features or guidelines for them? a) Separate content definitions from abstract interfaces [y/n, description] b) Information content versioning [y/n, description] c) Code set (classification, terminology) versioning [y/n, description] d) Automatic adaptation of system to content definitions [y/n, description] e) Other [description] 23. Are required and optional elements documented? [y/n] 24. Is the meaning of missing or empty values (or null [y/n, description] flavours) defined? 25. Does the information (see 18) assume use of a given [y/n, description] methodology for the user or the developer (e.g. procedure or guideline, given modelling tools or notation etc.) 26. Additional considerations [description] Information and semantics lomake (II) 2/2 17
ICD-10 (International Classification of Diseases) Käyttötarkoitus: Tautiluokitus ja -koodisto, sisältää myös useita sanamuotoja samalle koodille Standardointiorganisaatio WHO / Stakes / -perhe: Lisämateriaali: Www: ICD-10 2003: http://195.236.0.10/pls/terveysportti/icd10.koti ICD 10: http://www.who.int/whosis/icd10/ ICD-10-tautiluokitus (Stakes): http://www.stakes.fi/oske/luokitukset/icd10/index.html Ensisijaiset RM-ODPtasot: Information Ensisijaiset 7-tasomallin Semantiikka (5) tasot: Esimerkkejä - minimitaulukoita CCOW (ent. Clinical Context Object Workgroup) Käyttötarkoitus: Terveydenhuollon työpöytäintegraatio, sovellusten koordinointi. Standardointiorganisaatio HL7 / -perhe: Lisämateriaali: (Komulainen, Tuomainen 2002), (Tuomainen et al., 2004), (Seliger, Royer 2002) Www: HL7 CCOW Committee: http://www.hl7.org/special/committees/visual/visual.cfm HL7 Finland Common Services SIG (HL7-yhdistyksen sivuilla: http://www.hl7.fi/ Ensisijaiset RM-ODPtasot: Computational Ensisijaiset 7-tasomallin Liittymien sisältö (4) tasot: 18
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ökulmat (Engineering) Liittymät on määritelty OMG IDL:llä, toteutus vaatii ORB-tuotteen 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 OMG IDL-kielen avulla kuvaaminen Tietosisällön Parametrien merkitys kuvattu standardissa merkitys Toimintomalli Liittymien operaatiot Toimintomallin OMG IDL-kielen avulla kuvaaminen Toimintojen Operaatioiden merkitys kuvattu standardissa merkitys Koodistot tai Ei ota kantaa luokitukset Ihmisten (käyttäjien) Ei ota kantaa toiminnan kuvaaminen Laajempi esimerkki 19
Sovellusarkkitehtuuri Osien tunnistaminen Asiakas ja palvelin (hajautettu palvelu) Yhteistoiminnan Oliopalvelut perusmalli Integrointitapa Yhteinen infrastruktuuri Hajautus Hajautetut palvelut Kutsutapa Pyyntö-vastaus, toiminnon (palvelun) suorittaminen Tekniikka Tiedon esitys OMG IDL Toimintojen OMG IDL määrittely Kutsutekniikka Operaatiokutsut määritelty OMG IDL:n avulla Verkkoliikenne IIOP (CORBA) Suoritukseen ORB-tuote, nimipalvelu, vaihtopalvelu tarvittava tekninen infrastruktuuri Toteutuksessa IDL-kääntäjät, ohjelmointikielet tarvittavat välineet Suhde järjestelmän elinkaaren vaiheisiin Vaatimukset Soveltuu henkilön tunnistukseen liittyvien vaatimusten toteuttamiseen Kohdealueen Nojautuu oliopohjaiseen analyysiin ja suunnitteluun, oletuksena analyysi yksikäsitteisen henkilötunnisteen puuttuminen Tietosisällön ja ks. yllä toimintojen määrittely 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 Vaatii suoritusympäristöön palvelimen, jolle palvelu asennetaan, ja ORBtuotteen, joka huolehtii verkkokommunikaatiosta asiakkaan ja palvelimen käyttöönotto 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ä Laajempi esimerkki jatkuu 20
Esimerkki: Tikesos-standardisalkku / 2009 Asiakasasiakirjojen standardit (yht. 14 kpl) SosXML, XML-perhe, JHS 170 XML-skeemat, UTF-8, PDF/A, OOXML, CCTS, SFS 2487 Viestinvälityksen standardit (yht. 5 kpl) HL7 v3 Medical Records, HL7 v3 WS Transport, CDA R2 header, SOAP, Mime Content-Transfer-Encoding Yksilöinnin standardit (yht. 2 kpl) ISO OID, JHS 159 ISO OID-yksilöintitunnuksen soveltaminen julkishallinnossa Tietoturva- ja tietosuojastandardit (O kpl) Kehitystyössä hyödynnettävät standardit (yht. 2 kpl) BPMN, JHS 152 Prosessien kuvaaminen Muut noudatettavat standardit ja määritykset (yht. 3 kpl) 21
Tikesos-standardisalkku esimerkki Lyhenne CCTS Nimi Core Components Technical Specification - Part 8 of the ebxml Framework Versio Versio 2.01 Kehittäjä United Nations Centre for Trade Facilitation and Electronic Business (UN/CEFACT) Status 15.11.2003 Käyttötarkoitus CCTS tavoitteena on määrittää eri toimijoiden eri asiakirjojen sisältöjen semanttinen yhteensopivuus. CCTS on yleiskäyttöisten semanttisten rakennusyksiköiden kuvausmenetelmä. Yleiseen käyttöön on muodostettu ydinkomponentit, jotka sisältävät liiketoimintaan liittyviä tietoja. Ydinkomponenttien sisältämä tieto on semanttisesti ymmärrettävää eri toimijoiden kesken. Käyttäjät CCTS määrittelee keinot ydinkomponenttien tunnistamiseen, tallentamiseen sekä uudelleenkäyttöön. Sisältää nimeämiskäytäntöjä ja suunnitteluperiaatteita. Parantaa tiedonkulkua eri toimijoiden välillä. SosXML:n kehittäjät. Välillisesti näyttömuotojen ja sähköisten lomakkeiden kautta sosiaalihuollon asiakkaat, sosiaalityöntekijät ja muut sosiaalipalveluiden käyttäjät. Tikesos-status Suositeltu hyödynnettäväksi (Huttunen ym. 2009): XML-komponenttien suunnittelutyössä ja vastaavassa sanastotyössä PITÄISI käyttää UN/CEFACT CCTS -mukaista komponenttien suunnitteluprosessia. Hankkeessa PITÄISI kehittää ABIE- ja BBIE-tyyppisiä komponentteja. Perustelut JHS tulee aloittamaan julkishallinnon sanaston tekemisen CCTS-muotoon. Kaikki yleiskäyttöiset ydinkomponentit tullaan määrittelemään JHS:n toimesta CCTS-muotoisina. Sosiaalihuollon asiakasasiakirjat sisältävät paljon spesifistä tietoa, joten uusia komponentteja joudutaan määrittämään JHS-ydinkomponenttien lisäksi. Tällöin voidaan käyttää hyväksi CCTS-mallissa olevia sääntöjä. Kyseiset säännöt voivat olla sovellettavissa Tikesos-hankkeen tarpeisiin. Lähde http://www.unece.org/cefact/ebxml/ccts_v2-01_final.pdf Soveltamisohje - Laajuus Viittaukset 113 sivua CCTS käyttää komponenttien nimeämisen lähtökohtana ISO/IEC11179-5 standardin (Information technology - Specification for standardization and registration of data elements and associated metadata - Part 5: Naming and identification principles) ohjeistusta ja esimerkkinimeämiskäytäntöä. JHS 170 Julkishallinnon XML-skeemat -suosituksessa on käytetty soveltaen CCTS-mallin XML nimeämis- ja suunnittelusääntöjä. NIEM- ja CCTS-mallit ovat vastaavia päätarkoituksen osalta. Esim. tekninen toteutus on erilainen mallien kesken. Tuki UN/CEFACT (http://www.unece.org) Levinneisyys Standardia on sovellettu useassa Euroopan maassa. Muuta - Näkökulmat A: Tieto, B: 5, 6, 4, 7 Päivitetty Lisätty 25.8.2009. Päivitetty 15.9.2009. http://www.sosiaaliportti.fi/file/8bfd7c38-2899-418a-a623-227f10e57b8f/standardisalkku.pdf 22
Tosielämän kauhukertomus : HL7 version 3 RIM historiasta HL7-standardiperhe laajimmin kyätetty terveydenhuollon tiedonsiirron standardi HL7 versio 3 standardin kehittäminen käyntiin n. vuonna 1997 aiempien versioiden ongelmat, paikalliset tulkinnat, paikallisten toteutusten erot mallipohjaisuuden hyödyntäminen, XML hyödyntäminen pohjaksi toimialan tietomalli: Reference Information Model ja ajan mukaisesti oliopohjaiset mallinnusmenetelmät, UML-pohjainen notaatio, mallivarasto RIM pohjalta tarkempien mallien (domain, message) tuottaminen v.0.92, marraskuu 1999 [lukujen lähde: Woody Beeler] 41 subject areas, 120 classes, 712 attributes, 167 associations, 41 generalizations, 3 composition relationships n. 3 x 1,8 m lakana seinällä, fontti 7 kaikenkattavan yksityiskohtaisen mallin ylläpito yli eri komiteoiden / projektien, muutosten ja uusien tarpeiden harmonisointi? uudelleenstrukturointi, yleistäminen, rakenteisten sanastojen käyttöönotto versio 1.14, 2002 5 subject areas, 46 classes, 196 attributes, 8 associations, 40 generalizations, 1 composition relationship muuttuvien osien kapselointi yleistämisen, kohdealue- ja sanomakohtaisen erikoistamisen ja muuttuvien sanastojen eristämisen kautta kaikenkattavaan tyyppitason malliin lisäjoustavuutta koodistojen käytön ja abstraktien perusluokkien kloonaamisen kautta nykyisin ISO-standardi, hyödynnetty monipuolisesti lukuisissa hankkeissa ja tarkemmissa sovellusalueissa 23
Standardisalkku Päiväys Versio Nimi Versio Julkaisija Valmistumisvuosi Kuvaus Käyttötarkoitus Hyödyt Tila Lähde/viite Ratkaistavia kysymyksiä tietoarkkitehtuurimme tarkoitus ja käyttötapa? vakioimmeko meta- vai tyyppitason (ja standardin avulla vai ei?) yhteisen tietomallin laajuus: yksi kaikenkattava vai useita tilannekohtaisia? invasiivisuus: sovellukset rakennettava tietomallin ehdoilla? NIH ylittäminen : hyöty jo tehdystä komiteatyöstä vs. opiskelun ja sovittamisen vaikeus (standardin tekijät jo törmänneet tarpeisiin joita paljastuu vasta projektimme loppuvaiheessa?) arkkitehti- vai projektipäällikkövetoinen määrittely.. kansainvälisen tai toimialojen välisen yhteensopivuuden vaatimukset 24
25 Kiitokset www.uku.fi/solea/ juha dot mykkanen ät uef.fi