SOA ja yhteensopivuusstandardit

Transkriptio

1 SOA ja yhteensopivuusstandardit IIR SOA-seminaari Helsinki, Juha Mykkänen HIS-tutkimusyksikkö Tietojenkäsittelytieteen laitos Itä-Suomen yliopisto, Kuopio 1

2 Puhujan taustaa Juha Mykkänen, FT Itä-Suomen yliopisto, Kuopion kampus, HIS-tutkimusyksikkö projekteja integrointiratkaisujen ja SOA:n kehittämiseen ja soveltamiseen SOLEA : SOA ja EA, teollisuus ja terveydenhuolto SerAPI : palveluarkkitehtuuri ja sovellusintegraatio, terveys OmaHyvinvointi (MyWellbeing) , asiakaskeskeiset hyvinvointipalvelut PlugIT , sovellusintegraatio terveydenhuollossa ekat / terveyspalvelujen ajanvarauksen arkkitehtuurin suuntaviivat 2008 Healthcare services specification project (HSSP) / HL7 and OMG, Integrating the Healthcare Enterprise - IHE.fi Sosiaalialan tietoteknologiahanke - Tikesos HL7- ja web services -standardit ajanvarauksiin, sähköiseen reseptiin, sähköiseen potilastietoarkistoon, potilasryhmittelyihin, työpöytäintegraatioon jne. HL7 Finland ry varapuheenjohtaja, Itä-Suomen yliopiston edustaja International Medical Informatics Association / WG Health Information Systems ja Object Managemet Group -järjestöissä, HL7 SOA Ambassador 2

3 Sisältö Johdanto Yhteentoimivuus ja sitä tukevat standardit SOA ja standardointi Yhtäläisyydet ja erot toimialaspesifit standardit ja SOA Esimerkki terveydenhuollon SOA-standardointi kahden standardointijärjestön rajapinnassa: Healthcare Services Specification Project

4 tämän esityksen asiat pohjautuvat pääosin soveltavaan tutkimukseen v useita hankkeita terveydenhuollon toimialalla, 25+ yritystä ja käyttäjäorganisaatiota komponenttipohjainen sovellustuotanto sovellusintegraatio palveluarkkitehtuuri standardointi, kokonaisarkkitehtuuri SOLEA-, SerAPI- ja PlugIT- hankkeiden tuloksiin Specification of Reusable integration solutions for Health Information Systems - väitöskirjaan, Kuopion yliopisto, 2007 julkaisuihin integroinnin suunnittelupäätöksistä, standardeista, määrittelymenetelmistä ja monenvälisistä integrointihankkeista esiintyjän työhistoriaan: ohjelmistokehittäjä välinekehittäjä tutkija (ITarkkitehtuuri) standardoija 4

5 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 5

6 Standardoinnin kohteita tietosisällöt (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 6

7 Yhteentoimivuus (interoperability) The ability of two or more systems or components to exchange information and to use the information that has been exchanged. Functional interoperability ability to exchange information Semantic interoperability ability to understand the information exchanged [IEEE Standard Computer Dictionary: A Compilation of IEEE Standard Computer Glossaries, IEEE, 1990] 7

8 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 Mutta jotta tasoista päästään edes keskustelemaan, on huomioitava, mitä mihin tahansa integrointiin tarvitaan 8

9 ratkaistavat asiat ohjelmistoja liitettäessä järjestelmän elinkaari toiminnallinen arkkitehtuuri Lait, ohjeet, toimintatavat Prosessit Kehitysprosessin liittymät Toiminnallinen viitemalli Semantiikka sovellusarkkitehtuuri tekninen arkkitehtuuri Toiminnalliset liittymät Sovellusinfrastruktuuri ratkaistava kaikissa sovellusintegraatiotilanteissa Tekninen infrastruktuuri Tekniset liittymät Verkot Laitteet [Peter Herzum, Oliver Sims] 9

10 standardiesimerkkejä SOA-alueella ABQC Process Classification Framework OASIS SOA Reference Model, OMG SoaML, Open Group SOA ontology, BPMM, OSIMM ebxml RIM, HL7 RIM, HL7 EHR-S FM, HL7 PHR-S FM, HL7 D-MIM OASIS UBL, BizTalk specifications, HSSP, RosettaNet, ebxml CPP/CPA, (OMG Domain Technical Committees), HL7 Scheduling, HL7 Finland minimikontekstinhallinta IEEE P1723 (S3), OASIS RA4 SOA Foundation, Open Group SOA Reference Architecture WS-RM, WS-Security, SAML, XACML, WS-Trust, WS-SecureConversation, BPEL, SCA, WS-Policy, UDDI v3 WSDL, SOAP, WS-I, JMS, CORBA, HTTP, FTP, XML-RPC Prosessit Kehitysprosessin liittymät Toiminnallinen viitemalli Semantiikka Toiminnalliset liittymät Sovellusinfrastruktuuri Tekninen infrastruktuuri Tekniset liittymät 10

11 standardiesimerkkejä SOA-alueella ABQC Process Classification Framework OASIS SOA Reference Model, OMG SoaML, Open Group SOA ontology, BPMM, OSIMM ebxml RIM, HL7 RIM, HL7 EHR-S FM, HL7 PHR-S FM, HL7 D-MIM OASIS UBL, BizTalk specifications, HSSP, RosettaNet, ebxml CPP/CPA, (OMG Domain Technical Committees), HL7 Scheduling, HL7 Finland minimikontekstinhallinta IEEE P1723 (S3), OASIS RA4 SOA Foundation, Open Group SOA Reference Architecture WS-RM, WS-Security, SAML, XACML, WS-Trust, WS-SecureConversation, BPEL, SCA, WS-Policy, UDDI v3 WSDL, SOAP, WS-I, JMS, CORBA, HTTP, FTP, XML-RPC Prosessit Kehitysprosessin liittymät Toiminnallinen viitemalli Semantiikka Toiminnalliset liittymät Sovellusinfrastruktuuri Tekninen infrastruktuuri Tekniset liittymät 11

12 kuinka paikallisesti kukin integrointitaso ratkaistaan / vakioidaan? yrityksen tuotteet A kansainvälinen tuote B Euroopan markkinoille C kotimaan markkinoille D tuoteräätälöinti E asiakasräätälöinti F pilotointi standardoinnin taso laitos alue / tuote FI CEN ISO [Antero Ensio] 12

13 SOA vs. vertikaalinen standardointi? SOA joukko periaatteita ja käytäntöjä palvelupohjaiseen kehittämiseen standardit: viitearkkitehtuureita, käsitteellisiä malleja, rajoitteita toteutuksissa usein web services-standardit etenkin infrastruktuurialueen standardioletukset epäyhteensopivia eri valmistajilla vertikaaliset business-standardit sisältöjen ja toiminnallisuuksien sopiminen keskeisintä sanomat, dokumentit, toiminnalliset rajapinnat usein oletuksia käytettävästä vuorovaikutusmallista ja infrastruktuurista (ottavat kantaa myös horisontaalisiin asioihin) vertikaalistandardien käyttäminen SOA:n pohjana järkevää mutta vaatii usein kompromisseja SOA-periaatteista tai standardipinon joistakin oletuksista konfliktityypit (ristiriita tai puute): ristiriita horisontaalistandardin ja vertikaalistandardin välillä (esim. SOA-teknologia) ristiriita SOA-periaatteiden ja vertikaalistandardin välillä (esim. karkeajakoisuus) ristiriita standardin ja paikallisten vaatimusten välillä

14 SOA-peruspiirteet vs. vertikaalistandardit esimerkki SOA ominaisuus RosettaNet* HL7 versio 3** Business level service ++ + Interface (set of related functions) ++ - Operation (functional capability) + - Message (payload semantics) + + Interface technologies ++ ++/-- Messaging technologies ++ +/-- Supporting technical infrastructure + + Semantic definitions + ++ Provider and consumer roles - - * Rosettanet PIPs in Cluster3 Order Management ** HL7 version 3, Scheduling Domain

15 SOA-periaatteet vs. vertikaalistandardit esimerkki SOA periaate RosettaNet* HL7 versio 3** Service contract - - Loose coupling Service abstraction ++/- ++/- Service reusability + + Service autonomy ++ + Service statelessness Service discoverability - - Service composability + + Separation of business level functionality + - Separation of computation / information - -- Separation of process from service interface - -- * Rosettanet PIPs in Cluster3 Order Management ** HL7 version 3, Scheduling Domain

16 Yhteenveto Mitä ovat SOA-standardit ja onko niitä lainkaan? web services-standardeja runsaasti (tekniset liittymät) toteutustekniikka on kuitenkin eri asia kuin SOA teknisen infrastruktuurin standardeja paljon ( component containers ) SOA-arkkitehtuuriperiaatteiden standardit (viitemalleja, referenssiarkkitehtuureja) SOA- ja B2B-alueen tekniset standardiperheet alkaneet osin muistuttaa J(2)EE vs. CORBA vs. Microsoft-standardipinoja luvuilta oleellisimmat SOA-palvelujen (muut kuin infrastructure services) standardit yhteentoimivuuden kannalta: palvelujen toiminnalliset määrittelyt sanomien / dokumenttien sisällön määrittelyt TOIMINNALLISIA, USEIN TOIMIALAKOHTAISIA MALLEJA - pohjana mm. prosessimäärittelyjen standardoinnille tällä alueella perinteiset standardointijärjestöt tuottaneet pohjaa vuosikymmenten ajan haasteena kuitenkin standardijärjestöjen oletukset: väliohjelmistot, tekniset protokollat, integrointitapa-oletukset (esim. dokumenttipohjaisuus, sanomapohjaisuus, rpc-malli?)

17 Change of hats If I learn SOA concepts in one standards organization, will I have to relearn them to understand the specifications in another organization? Navigating the SOA open standards landscape around architecture: SEURAAVAKSI: esimerkki SOA-palvelujen standardien tuottamisesta terveydenhuollon toimialalla

18 HL7 and Service-oriented Architecture (SOA) Ambassador Briefing Huhtikuu 2010 As an HL7 Ambassador, I personally participate and contribute to the activities and standards being discussed. I attend meetings, teleconference calls, and actively engage in the standards development process. Note that all HL7 Ambassador presentations are presented by authorized speakers of HL7, called HL7 Ambassadors.

19 Aiheet Miksi kansainvälisiä SOA-standardeja terveydenhuoltoon? HSSP (Healthcare Services Specification Project) -esittely Standardityön tilanne Yhteenveto

20 Ensin terminologia HSSP = Healthcare Services Specification Project HL7 = Health Level Seven OMG = Object Management Group OHT = Open Health Tools SOA = Service-oriented Architecture DSTU = Draft Standard for Trial Use (HL7)

21 Miksi kansainvälisiä SOAstandardeja terveydenhuoltoon?

22 Käytännön haasteita potilaiden yksilöinti ja perustietojen integrointi järjestelmien ja organisaatioiden välillä? uudet pienet kliiniset sovellukset ja niiden tietojen integrointi ydinjärjestelmään tai kliinikon yhteenvetonäkymään? sairaalan satojen potilastietoja käsittelevien sovellusten yhdenmukainen käyttökokemus? uusien asennusten tai laitteiston tai ohjelmistojen hajautuksen toteuttaminen siten, että järjestelmät säilyvät ehjänä (tai jopa käytössä)? terveydenhuoltolain tai suostumusten hallinnan aiheuttamien lakimuutosten vaikutukset järjestelmiin? yksilön tai kuntalaisen asiointipalvelujen kehittäminen olemassaolevien järjestelmien pohjalta?

23 Miksi kehitetään terveydenhuollon SOAstandardeja? Terveydenhuollon organisaatioilla runsaasti yhteentoimivuusvaatimuksia Sanomanvälitys ei ole ideaalinen lähestymistapa kaikkiin yhteentoimivuustarpeisiin SOA osoittautunut toimivaksi ratkaisuksi useissa organisaatioissa ja eri vertikaalisilla markkinoilla palveluorientoituneisuus on luonnollinen osa terveydenhuoltoa (IT siirtymässä samaan malliin) Monissa avaintuotteissa jo palvelurajapintoja (standardointi luonteva jatke)

24 SOA suhteessa sanomanvälitykseen? Riittävä toiminnallinen yhdenmukaisuus eri sovelluksissa SOA hyvät arkkitehtuurikäytännöt Loogisesti keskitetyillä palveluilla master-tietolähteiden toteuttaminen Uudelleenkäyttö, päällekkäisen datan, kehitystyön ja tietojen syöttämisen vähentäminen Sanomat voivat olla palvelujen tietosisältö tai infrastruktuuri SOA:n hyödyntämisessä erityisesti yhteiskäyttöisten palvelujen osalta tarvitaan standardeja SOA on kuitenkin toteutettava oikein on halvempaa kuin koskaan tuottaa huonosti suunniteltuja sovelluksia ja spagetti-integraatiota

25 SOA Web Services SOA Web Services Teknologia-alusta? Ei Kyllä Tiedonsiirtoprotokolla? Ei Kyllä Liiketoiminta omistaa ensisijaisesti? Kyllä Ei Keskittyy työnkulkuihin ja prosesseihin? Mahdollistaa liiketoiminnan ja tekniikan muutokset? Kyllä Kyllä Ei Kyllä Teollisuusstandardi? Ei Kyllä

26 Yhteentoimivuuden tason nostaminen

27 HSSP Healthcare Services Specification Project

28 Healthcare Services Specification Project (HSSP) Pyrkii luomaan yhteisiä, kansainvälisiä palvelurajapintojen määrittelyjä terveydenhuollon tietotekniikkaan Standardien kehityshanke, jonka pääosapuolina ovat HL7 (Health Level Seven International) ja Object Management Group (OMG) linkit myös mm. IHE (Integrating the Healthcare Enterprise)- ja Open Health Tools -toimintaan Tavoitteet: tuottaa terveydenhuollon standardeja, joissa määritellään toiminnallisuus, tietojen semantiikka sekä tekniset ratkaisut täydentää ja hyödyntää valmiita standardeja keskittyä käytännön tarpeisiin eikä täydellisyyden tavoitteluun hyödyntää avoimen yhteisön asiantuntijoiden osaamista

29 Technical Specifications Profiles Interop Testing Implementations IHE, SDOs, Healthcare Orgs OMG, RFP Submitters IHE Vendors, OHT, Healthcare Orgs RFP Service Funct. Model OMG Healthcare Domain Task Force HL7 Domain Committees, CEN, Standards Bodies (SDOs) Information Models HL7, openehr, CEN, Requirements Healthcare Organizations Policy Business Drivers Government, Professional Societies, page 30

30 OMG HDTF RFP Responders HL7 SOA WG Standardien kehittäminen yli standardiorganisaatioiden / HSSP HL7 Service Functional Model HL7 Draft Stds for Trial Use (DSTU) OMG OMG Request for Proposal (RFP) ANSI Standard Technical Specification

31 Tuotokset Asset Purpose Functional Spec-DSTU Entity Identification Service (IXS) Retrieve Locate Update Service (RLUS) Decision Support Service (DSS) Common Terminology Service (CTS II) [Healthcare] Access Control Service (PASS Access Control) Human Svcs Directory (HSD) [Healthcare] Audit Service (PASS Audit) To manage identities and identifying traits (e.g., MPI) To manage location and retrieval of healthcare content To analyze patient data and assess against knowledge rules. Defines behavior for managing/maintaining terminologies Manages security policy as pertaining to access to health information To find providers & services in allocated areas, e.g., referrals. Security-oriented service to manage audit record Technical Spec Functional Spec-Norm Implementation Availability Complete Complete Complete Commercially Available Complete Complete Expected 9/2010 Complete Complete Expected 9/2010 Complete Expected 12/2010 Expected 5/2011 Commercially Available In development In development Complete In process TBD TBD N/A In process Complete TBD In process TBD TBD TBD page 32

32 Entity Cross-Reference Service (IXS) määrittelee toiminnallisella ja käsitteellisellä tasolla toiminnot, jotka tarvitaan henkilötietojen päälähteen (esim. Master Person Index) toteuttamiseen käsittelee erilaisia entiteettityyppejä (henkilöt, potilaat, palvelujen tarjoajat, laitteet jne.) ja eri toteutustasoja (valtakunnallinen, alueellinen, organisaatioiden sisäiset ja väliset) mahdollistaa entiteettien tunnistamiseen käytettävien ominaisuuksien (traits) dynaamisen määrittelyn aiempi nimi Entity Identification Service (EIS)

33 Esimerkki IXS / EIS -toteutus Local/Regional Domain 2 Regional Identity Service (EIS) Implementation Skenaariot 1. kysely paikalliseen domainiin: löytyy paikallisesta varastosta 2. kysely paikallisesn domainiin : ei löydy paikallisesta varastosta,, haetaan master domainista 3. kysely master domainiin: haetaan toisiinsa linkitetyt entiteetit master-domainista 4. ulkoisen järjestelmän kysely: haetaan master-domainista External organization s system Interface 4.1 National/Master Domain service client National Identity Service Local/Regional Domain 1 Implementation Local Identity Service Implementation Interface 3.2 service client Interface service client

34 Common Terminology Service II (CTS II) tietomalli ja toiminnallinen malli terminologisten järjestelmien käytölle ja suhteille kuinka tietoelementtejä rajoitetaan sallittujen arvojen joukoiksi kuinka valintalistat kootaan ja niitä kysellään kuinka terminologinen tieto validoidaan interaktiot terminologiapalvelujen tarjoajien ja käyttäjien välillä korjausten ja laajennusten pyytämisen toiminnallisuus yksilöinti, koodistojen jakelut, revisioiden integrointi käynnissä oleviin järjestelmiin terminologioiden ja tietomallien välisten vastaavuuksien määrittelyn toiminnallisuus logiikkapohjaisiin terminologioihin (esim. Snomed) kohdistuvat kyselyt (mm. hierarkkiset ja loogiset päättelysuhteet)

35 Decision Support Service (DSS) käyttää potilastietoja johtopäätösten ja suositusten tekemiseen vartioi yhtä tai useampaa tietämysmoduulia kukin tietämysmoduuli kykenee käyttämään kooditettua potilastietoa, jonka avulla päästään johtopäätöksiin potilaan suhteen, esimerkiksi: lääkkeen (vaikuttavan aineen) tunniste, ikä, sukupuoli, paino, seerumin kreatiniinitaso suositellut minimi- ja maksimiannostukset potilaan munuaisten toimintakyky huomioiden ikä, sukupuoli, aiemmat hoitotoimenpiteet luettelo ajankohtaisista tai lähiaikana ajankohtaisista tarvittavista hoitotoimenpiteistä palvelun semanttisia profiileja - case: rokotusten suunnitteleminen

36 Retrieve Locate and Update Service (RLUS) terveydenhuollon organisaatioissa syntyvien tietojen saantiin tarkoitettu yleiskäyttöinen palvelu rajapinnat, joilla paikallistetaan, noudetaan ja päivitetään resurssien tietoja organisaatioissa ja niiden välillä ei ole tarkoitettu korvaamaan olemassaolevia järjestelmiä tai toteutuksia, läpinäkyvä tapa tietojen paikallistamiseen ja saantiin riippumatta toteutuksiin käytetyistä tietorakenteista, turvallisuusratkaisujen yksityiskohdista tai tiedonsiirtomekanismeista tietosisällöt määritellään semanttisten profiilien avulla (esimerkiksi HL7 versio 3 -sanomien tietomallit, ISO/CEN standardin arkkityyppimäärittelyt)

37 Privacy Access and Security Services (PASS) PASS - Access Control Tavoitteena yhdenmukaistaa pääsynvalvonnan toteuttamista terveydenhuollon SOA-arkkitehtuurissa Palvelu perustuu policy-määrittelyjen käyttöön ja voi huomioida kontekstin Access decision -palvelu, jossa terveydenhuollon laajennuksia Pääsynvalvontapäätösten tekemiseen tarvittavien tietojen kokoamiseen tarvittavia toiminnallisuuksia PASS - Audit Toiminnallisuudet joilla voidaan generoida auditointitapahtumatietoja (lokiin) Auditointitietojen turvalliseen lähettämiseen (prosessointia ja tallentamista varten) tarkoitetut toiminnallisuudet Toiminnallisuudet, joilla voidaan tarkastella ja raportoida auditointitietoja

38 Healthcare and Community Services Provider Directory (HCSPD) Hyvinvointipalvelujen löytämistä ja varaamista (ja tätä varten tarvittavaa hallintaa) tukeva palvelu organisaation sisällä tai niiden välillä Avaintoiminnallisuuksia mm. resurssien sitominen sijainteihin, palvelupaikkojen sijaintien määrittely ja palveluntuottajien ja organisaatioiden välisten suhteiden hallinta Voidaan käyttää mm. etsimään palvelun tarjoajia tiettyyn tarkoitukseen, etsimään suunnitelmassa mainittu palveluntarjoaja, etsimään palvelujen antajia joilla on vapaata kapasiteettia jne. Ei ole rajattu pelkästään suoriin hoitopalveluihin, voi tukea tarvittaessa esim. liikkuvien ateriapalvelujen toteuttamista

39 SOA ja Enterprise Architecture (kokonaisarkkitehtuuri) HL7:ssa HL7-organisaatio on kehittänyt HL7-standardien tuottamiseen menettelytavan SAIF (services-aware interoperability framework) sisältää SOA-pohjaisen toiminnallisen mallin (behavioral framework) ja conformance-ohjeistuksen HL7-standardeille yhteentoimivuusparadigmat: HL7 versio 2 ja versio 3 sanomat CDA-dokumentit palvelut hyödyntää SOA:n ja MDA:n (Model-Driven Architecture) periaatteita policy-, hallinta- ja jäljitettävyysseikkojen eksplisiittisissä määrittelyissä palvelustandardit nojautuvat HL7 SOA-työryhmän ja HSSPprojektin työhön HL7:ssa useat aktiiviset työkohteet ovat SAIF-menetelmän mukaisesti kehitettäviä (alpha projects)

40 Interoperability Realized Context Requirements Constraints page 41

41 Practical Guide for SOA in Healthcare Kohderyhmänä SOA-kehittäjät Yksi esimerkki terveydenhuollon organisaation SOA-kehittämismallista Yhdistää käytännöllisiä kokemuksia ja hyviä käytäntöjä Ei ole (eikä ole tarkoitus olla) itsessään teollisuusstandardi Ei ole (eikä ole tarkoitus olla) virallinen HL7-standardin osa Versioon 2 tulossa mm. HL7 SAIFmenetelmän mukaisia lisäyksiä Osoite:

42 For More Information. Contact us! (ambassador, myös suomeksi ) ken.rubin@eds.com (co-chair, ambassador) ann.wrightson@wales.nhs.uk (co-chair, hefyd i mewn Cymraeg) galen.mulrooney@va.gov (co-chair) djorgenson@inpriva.com (co-chair) Events... SOA in Healthcare, Washington DC, July 2010 visit Visit our project wiki. (look for Service oriented architecture)

43 Summary How do you know that the [web-] services you re building are not just the next generation of stovepipes? Janet Martino, LTC, USAF (Retired) to a panel of Healthcare IT Leaders