12/19/2015 7:19 AM HL7 Service-Oriented Architecture SIG OMG Healthcare Domain Task Force Open Health Tools Healthcare Services Specification Project The Business Case for Healthcare SOA Standards January 2012

Page 2 Acknowledgements Contributions to this content have come from: Health Level Seven (HL7) Object Management Group (OMG) With additional contributions from: Integrating the Healthcare Enterprise (IHE) Open Health Tools

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

Page 4 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.

Page Key Milestones Jan: HL7 Meeting (San Antonio) Jul: Feb:Aug: Mar: OMG Meeting (Washington) Sep: HL7 Meeting (Baltimore) > Ballot: Medication Stmt Profile Ballot anticipated > Ballot: Common Terminology Svcs 2 Normative Edition OMG Meeting (Jacksonville) > Anticipated adoption: Services Directory (ServD) > RFP for Clinical Info Model Profile for UML to be issued April: Interconnected Health Conf (Chicago) > Conference Proceedings can be found here Interconnected Health Confhere Oct: May: HL7 Meeting (Vancouver) > Finalize Retrieve, Locate, Update Service Normative Spec Nov: Jun: OMG Meeting (Boston/Cambridge) > Revised submission of Services Directory (ServD) > “Information Day” on Healthcare Services HL7 Italy “Open Days” (Rome, IT) HL7 Singapore SOA “Town Hall” HL7 Italy “Open Days” Dec: OMG Meeting (SFO/Burlingame) > Ballot: Medication Stmt Profile Ballot anticipated

Page 6 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

Page 7 HL7 OMG The HSSP Process HL7 SOA SIG HL7 DSTU Service Functional Model Requirements OMG RFP RFP Responders Technical Specification Lessons Learned ANSI Standard OMG HDTF

Page 8 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 ID’s supported technical platforms Audience is community with implementation interest Produced by OMG Member “Submitters” Defines the service’s 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 Conforms with a “service profile” Audience are consumers of the system or service

Page 9 page 9 Asset Inventory AssetPurposeFunctional Specification Technical Specification Implementation Availability Entity Cross-Reference Service ( IXS ) To manage and correlate identities and identifying traits (e.g., MPI) Complete Commercially Available Retrieve Locate Update Service ( RLUS ) To manage location and retrieval of healthcare content Complete In Development Decision Support Service ( DSS ) To analyze patient data / assess knowledge rules. Complete Open Source Common Terminology Service ( CTS II ) Defines behavior for managing/maintaining terminologies Complete Open Source PASS [Healthcare] Access Control Service Manages security policy as pertaining to access to health information Trial Use Standard Complete (Beta) Commercially Available PASS [Healthcare] Audit Service Security-oriented service to manage audit record Trial Use Standard Complete (Beta) Commercially Available Healthcare and Community Services Provider Directory (HCSPD) To find providers & services in allocated areas, e.g., referrals. Complete September 2012 Under Development hDATA Record Format Specification A hierarchical format with metadata tagging for organizing / representing [clinical] data CompleteN/AOpen Source & Commercial hDATA RESTful Transport Specification REST binding for data retrieval using SOA (RLUS for REST) CompleteExpected 9/2011 Open Source

Page 10 Which services are being done next? We do not prioritize new work based on a roadmap. Even if we pick priorities, that doesn’t assure that people will do the work This approach is not business-driven The committee is unfunded New should conceptually align with the roadmap We strive for consistency in service granularity Work that does not conceptually align will be considered and perhaps undertaken or adapted.

Page 11 We will start new work when… There is a single person personally committed to lead it Why? Without a leader with day-job support, the cycles simply aren’t sufficient to get the work done. A core group of at least 3 organizations will participate. Why? Without a core group of three there is not enough diversity to justify an international standard There is a clear scope-of-work achievable in months Why? If work cannot be done in this timeframe, the scope is probably either unclear or too ambitious There is an agreement to work within the rules Why? This doesn’t mean that everything we do is right. It does mean that if something doesn’t work, we need to fix it together. We take on new work “top down” aligned with the roadmap with “bottom-up” prioritization

Page 12 Context of HSSP Specifications

Page 13 page 13 Interoperability Realized ContextConstraints Requirements Enterprise Information Computational Engineering

Page 14 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

Page 15 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

Page 16 Where would these specifications be used Inter-Enterprise (such as NHIN, RHIOs, HIE’s) 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

Page 17 HL7 ’s Services-Aware Interoperabilty Framework identifies architectural perspectives and levels describing and affecting interoperability Conceptually HSSP activities are aligned with SAIF. 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 HSSP and the HL7 SAIF

Page 18 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

Page 19 Why participate in standards at all? This is happening, with or without you. We’d rather it be with you… Unparalleled Networking. Standards work provides access to the industry’s 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.

Page 20 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

Page 21 How do I Participate? Participation is open to everyone. You don’t 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

Page 22 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

Page 23 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

Page 24 References All HSSP artifacts and work in process are open. Visit us at:

Page 25 Supplemental Slides: HSSP Stakeholder Benefits and Impacts

Page 26 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

Page 27 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

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