1. 2/11/2014 9:19 AM Healthcare Services Specification Project The Business Case for Healthcare SOA Standards HL7 Service-Oriented Architecture SIG OMG Healthcare Domain Task Force Open Health Tools HL7 Service-Oriented Architecture SIG OMG Healthcare Domain Task Force Open Health Tools April 2009

2. Page 2 Acknowledgements Contributions to this content have come from: –Health Level Seven (HL7) http://www.hl7.org http://www.hl7.org –Object Management Group (OMG) http://www.omg.org http://www.omg.org With additional contributions from: –Integrating the Healthcare Enterprise (IHE) http://www.ihe.net http://www.ihe.net –Open Health Tools http://www.openhealthtools.org http://www.openhealthtools.org

3. Page 3 page 3 What is the Healthcare Service Specification Project? A joint standards development activity occurring in multiple organizations, including Health Level 7 (HL7), the Object Management Group (OMG), IHE, Open Health Tools, and others An effort to create common service interface specifications tractable within Health IT Its objectives are: –To create useful, usable healthcare standards that address business functions, semantics and technologies –To complement existing work and leverage existing standards –To focus on practical needs and not perfection –To capitalize on industry talent through open community participation Policy Business Drivers Information Models Service Funct. Model RFP Profiles Technical Specifications Implementations Requirements Government, Professional Societies,… Healthcare Organizations HL7, openEHR, CEN, … HL7 Domain Committees, CEN, Standards Bodies (SDOs) OMG Healthcare Domain Task Force IHE, SDOs, Healthcare Orgs IHE OMG, RFP Submitters Interop Testing Vendors, OHT, Healthcare Orgs

4. Page 4 HSSP is part of the bigger health IT landscape…

5. Page 5 SOA and Enterprise Architecture in HL7 HL7 has started developing the Services-Aware Enterprise Architecture Framework (SAEAF), and which embraces services, messages and documents Includes SOA-based behavioral framework and conformance framework for HL7 standards (including HL7 v2 and v3 messages, CDA documents and services) Utilizes SOA and Model-Driven Architecture principles for explicit expression of policy, governance and traceability Service standards rely on SOA WG and HSSP work Framework development in progress, will influence future development of standards within HL7

6. Page 6 page 6 HSSP Asset Inventory AssetPurposeFunctional Spec-DSTU Technical Spec Functional Spec-Norm Implementation Availability Entity Identification Service (EIS) To manage identities and identifying traits (e.g., MPI) Complete In BallotCommercially Available Retrieve Locate Update Service (RLUS) To manage location and retrieval of healthcare content Complete Expected 9/2009 Commercially Available Decision Support Service (DSS) To analyze patient data and assess against knowledge rules. CompleteExpected 9/09 Expected 5/2010 In development Common Terminology Service (CTS II) Defines behavior for managing/maintaining terminologies Expected 5/2009 TBD-- [Healthcare] Audit Service (PASS Audit) Security-oriented service to manage audit record Expected 9/2009 TBD-- Human Svcs Directory (HSD) To find providers & services in allocated areas, e.g., referrals. Expected 9/2009 TBD-- Practical Guide for SOA in Healthcare Informative reference on how to approach SOA N/A

7. Page 7 What type of products do you produce? SOA Functional Standards [Service Functional Models] –Define the scope, purpose, and information content of industry standard healthcare services Technical Specifications for balloted Functional Standards –Bind functional specifications into specific technologies, transport protocols; technical conformance criteria Implementation Guidance & White Papers –Non-normative guidance to help consumers apply and use HSSP specifications within their organizations. Not standards.

8. Page 8 Practical Guide for SOA in Healthcare Targeted to help those interested in SOA to do SOA Is one approach for SOA-enabling healthcare organizations Brings together practical experience with recommended best-practices Is not (nor is it intended to be) an industry standard Is not (nor is it intended to be) officially sanctioned by HL7 Alignment with the HL7 SAEAF is underway Available at http://hssp.wikispaces.com/PracticalGuidehttp://hssp.wikispaces.com/PracticalGuide

9. Page 9 2009 Events (planned, major milestones) Jan: SFM Ballots (CRFQ, Security) HL7 Orlando Jul: Feb:Aug: Mar: OMG Washington EIS Tech. Spec. Adopted (OMG) RLUS Tech. Spec. Adopted (OMG) Sep: OMG San Antonio (Sep 14-18) HL7 Atlanta (Sep 20-25) PASS Audit Ballot (HL7) Issue CTS II RFP (OMG) Develop HSD SFM RFP (OMG) Revised Practical Guide (HSSP) Apr:Oct: May: HL7 Kyoto EIS SFM Normative Ballot (HL7) CTS2 SFM Ballot (HL7) Nov: Jun: SOA in Healthcare Workshop (Chicago) OMG San Jose (Costa Rica) DSS RFP Initial Submission (OMG) Dec: OMG Long Beach (Dec 7-11) Issue PASS Audit RFP (OMG) Issue HSD RFP (OMG)

10. Page 10 Core Project Principles Leverage each community to its strength Organizations jointly participate in all activities Work products will be owned by only one organization but used collaboratively Operate as one project as a principle Actively seek vendor participation Recognize that participation is an investment

11. Page 11 OMG HL7 The HSSP Process HL7 SOA SIG HL7 DSTU Service Functional Model OMG RFP RFP Responders Technical Specification ANSI Standard OMG HDTF

12. Page 12 SFM Understanding HSSP Artifacts, Roles, Attributes Owned / Produced by HL7 Community RFP Submission Implementation Defines what a service does but not how Independent of technical platform Audience is tech leads, EAs, tech spec developers Produced / owned by OMG community Translates SFM into technical requirements IDs supported technical platforms Audience is community with implementation interest Produced by OMG Member Submitters Defines the services technical spec Defines interfaces, platform bindings, and conformance profiles Audience is project team architect, lead developers, etc. Owned by organizations and vendors Builds the service that lives behind the interface Complies with a conformance profile Audience are consumers of the system or service

13. Page 13 How are HSSP services expressed? Semantic Space/ Universe Formalism (Structure) Semantic Signifiers (profile-relevant semantic structures) Usage Context (interoperability paradigm) Functional Subset List (enumerate Supported Functions) Version Submitter Name Metadata

14. Page 14 Why services?* A common practice in healthcare, just not yet in healthcare IT Many key products use them but do not expose interfaces Ensures functional consistency across applications Accepted industry best practice Furthers authoritative sources of data Minimizes duplication across applications, provides reuse Messages can be either payloads in or infrastructure beneath services Service-oriented architecture provides the framework for automation of common services *slide adapted from a Veterans Health Administration Presentation, used with permission

15. Page 15 Context of HSSP Specifications

16. Page 16 page 16 Interoperability Realized ContextConstraints Requirements Enterprise Information Computational Engineering

17. Page 17 SOA Web Services SOAWeb Services Is a technology platform?NoYes Is a transport protocol?NoYes Primary ownership is business-line owned? YesNo Affects workflow and business processes?YesNo Is an enabler for business and IT transformation? Yes Is an industry standard?NoYes

18. Page 18 The Benefits of HSSP Standards… Define industry standard behaviors for healthcare- oriented service functions Eliminate different flavors of web services from occurring in different organizations Rapid-pace stds development: ~18-24 months Methodology embracing cross-group standards development

19. Page 19 Where would these specifications be used Inter-Enterprise (such as NHIN, RHIOs, HIEs) –By functionally specifying behavior, roles between applications and products are clarified, and the technologies supporting them can be profiled and sharpened Intra-Enterprise –Standardization on functionality allows for better integration of off-the-shelf and custom development environments, and promotes more of a plug and play environment Intra-Product –Facilitates vendors ability to integrate third-party value-add components and speed design phase with higher confidence Custom-Implementation –Affords organizations wishing to custom-develop the opportunity to later integrate off-the-shelf

20. Page 20 The Value of HSSP … ValueRationale Promotes deployment ease and flexibility Specifications will support multiple topologies and technologies Consistency at the interface level assures asset protection Standard interfaces means that conformant components are substitutable Multiple vendor product use/ interoperability Using compliant products means side-by-side interoperation of multiple product offerings Increased buyer/product offeringsConsumer demand will create increased marketplace competition Facilitates integrationUnity in purpose and consistency in interface eases integration burden Time to marketAvailability of an industry-accepted component interface eases product development burden Requirements definition – influence vendors in a direct way Participation by provider and payer community is direct expression of business need Lower cost = wider deployment = higher quality service

21. Page 21 How is this project different? Active participation from three continents and 15+ organizations Significant cross-cutting community involvement –Providers & Payers (Blue Cross/Blue Shield, DoD Military Health System, Duke University, Kaiser-Permanente, Mayo Clinic, Veterans Health Administration) –Vendors, Integrators, Value-added Providers (Booz-Allen Hamilton, CSW Group, EDS, IBM, Initiate Systems, Intel, Northrop-Grumman, Ocean Informatics, Software Partners, 88Solutions) –Governments (Canada Health Infoway, DoD Military Health System (MHS), National Cancer Institute, NeHTA (Australia), SerAPI (Finland), Veterans Health Administration, Victoria Health (Australia)) Managing differences between SDOs in terms of membership, intellectual property, and cost models

22. Page 22 Why should I participate in HSSP? This effort is focused on and driven by business-need –It is not an academic exercise striving for perfection –Standards must be used to be useful –Focused on the practical and achievable –Short timelines –Based upon business value and ROI Leveraging talent from multiple communities Being run like a project and not a committee We recognize that participation is an investment and not an expense

23. Page 23 Why participate in standards at all? This is happening, with or without you. Wed rather it be with you… Unparalleled Networking. Standards work provides access to the industrys best and brightest Benefit from lessons learned from others. Someone else may have already solved your biggest problem. Industry Leadership. Standards work provides a platform for you to establish market presence. Risk avoidance. Increasingly, standards compliance is mandatory. Make them work for you and not against you.

24. Page 24 How do I Participate? Participation is open to everyone. You dont need to be a member (though we encourage you to do so) Join appropriate standards organizations –HL7 for functional work –OMG for technical specification work Allocate resources to actively engage in the project –Engage existing, knowledgeable resources in the areas they are working already. –Subgroups form based on industry need and priority –Teleconferences are weekly; meetings approximately bimonthly

25. Page 25 Who should I involve? Involve the staff that can best address your business needs: –You will get out what you put in. Senior staff will drive more value and ROI to you than a junior associate. –Organizations that commit resources garner more influence and more mindshare –Your business interests are being represented by your attendees

26. Page 26 References All HSSP artifacts and work in process are open. Visit us at: http://hssp.healthinterop.org

27. Page 27 Supplemental Slides: HSSP Stakeholder Benefits and Impacts

28. Page 28 What Participants are Saying… Kaiser Permanente I.T. is currently transitioning to an SOA-based approach to business and systems integration. Availability of industry standard services will bring many benefits towards this goal in terms of speed of implementation, flexibility and reduced cost. I am very pleased that both HL7 and OMG are committed to this timely effort., Alan Honey, Enterprise Architect (Principal), Kaiser-Permanente The creation of a health Informatics infrastructure based upon a service-based architecture grounded in comparable data has the potential to improve healthcare delivery and greatly enhance patient safety., Peter L. Elkin, MD, FACP, Professor of Medicine, Mayo Clinic College of Medicine The Eclipse Foundation is pleased to support an open source project dedicated to building frameworks, components, and exemplary tools to make it easy and cost-effective to build and deploy healthcare software solutions. This Eclipse Open Healthcare Framework project will leverage the Eclipse Platform developed by IBM, Intel, Wind River, Actuate, Borland, BEA, Computer Associates and others. Mike Milinkovich, Executive Director, Eclipse Foundation The time is now and the place is here in this joint OMG/HL7 project. Never before has the industry been closer to cogent, clear healthcare IT data model and service standards that can provide true interoperability in a short timeframe, with open- source implementations making availability abundant., Richard Mark Soley, Ph.D., Chairman and CEO, OMG

29. Page 29 For Product Consumers and Users… The Impacts and Rationale of HSSP Specifications ImpactsRationale Promotes deployment ease and flexibility Specifications will support multiple topologies Consistency at the interface level assures asset protection Standard interfaces means that conformant components are substitutable Multiple vendor product use/ interoperability Using compliant products means side-by-side interoperation of multiple product offerings Increased buyer/product offeringsConsumer demand will create increased marketplace competition Facilitates integrationUnity in purpose and consistency in interface eases integration burden Time to marketAvailability of an industry-accepted component interface eases product development burden Requirements definition – influence vendors in a direct way Participation by provider and payer community is direct expression of business need Lower cost = wider deployment = higher quality service

30. Page 30 Product Vendor … The Impacts and Rationale of HSSP Specifications ImpactsRationale Market opportunity – ability to grow business / Grow the pie Standardization of interfaces eases cost-of-entry to markets Conformance adds legitimacy to product offering Consumers view conformance as a confidence metric Reduced time and cost to market Use of 3 rd party components Simplify / reuse of design Ability to reuse design ideas, incorporate off-the- shelf components into value-add offerings Participation provides the ability to influence the standard You can shape the standard to be supportive of your product architecture

31. Page 31 Regulatory/Policy/Legislative … The Impacts and Rationale of HSSP Specifications ImpactsRationale Establishing objective assessment criteria: Measurement criteria for regulatory compliance Inclusion of rigorous conformance assertions benefits compliance and verification Allows for technology change within the regulation Concurrent support of multiple technologies allows for technology evolution Offering an easy/easier solution that is complete and actionable / ease the path to adoption: How do we Pick the winning horse? Opportunity cost of using the wrong standard has big implications HSSP integrates function/ behavior, data, and protocol promoting an integrated solution set Solution that complements existing standards HSSP is using HL7 semantics, OMG processes, IHE testing, and established technology protocols

32. Page 32 Research … The Impacts and Rationale of HSSP Specifications ImpactsRationale Promotes accessibility to raw information Strong emphasis on semantically rigorous data and query/retrieval Enabler for collaborative studies, e.g. de-identification, retrieval, etc. Leveraged use of identity service enables de- identification Enlarges cell and sample sizes based on interoperability Facilitates responsiveness to bio- surveillance requirements Standard interfaces accommodate dynamic and emerging strategies and tools Enables construction of higher-order service stacks with less investment Composable nature of services promotes construction

33. Page 33 Implementer/Integrator … The Impacts and Rationale of HSSP Specifications ImpactsRationale Reduced integration time and cost resulting from the use of standard tooling Use of standard in off-the-shelf tools facilitates their use Risk mitigation (skill portability/ training advantage, vendor independence, substitutability) By training staff in the standard, skills are portable across tools Creates a value offering opportunity based on the ability to deliver using these service standards Allows staff and solutions to build upon the use of the standard and not technologies Improved ability to deliver and support interfaces that have been implemented Using services speeds project design phases and promotes reuse

34. Page 34 SDOs … The Impacts and Rationale of HSSP Specifications ImpactsRationale Useable standardsEmphasis on practicality Market-focused standards based on commercial implementations Shortens time required to develop specifications and encourages collaboration Promotes harmonization, cooperation, cohesion among standards communities Integration of function, data, and technology promotes leveraged reuse More members/involvement = more revenue & better specs Practical, market-focus and iterative timeline promotes participation and results