2/11/2014 9:19 AM Healthcare Services Specification Project The Business Case for Healthcare SOA Standards HL7 Service-Oriented Architecture SIG OMG Healthcare

  • View
    215

  • Download
    3

Embed Size (px)

Text of 2/11/2014 9:19 AM Healthcare Services Specification Project The Business Case for Healthcare SOA...

  • Slide 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 Slide 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 Slide 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 Slide 4 Page 4 HSSP is part of the bigger health IT landscape Slide 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 Slide 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 Slide 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. Slide 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 Slide 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) Slide 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 Slide 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 Slide 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 Slide 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 Slide 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 Slide 15 Page 15 Context of HSSP Specifications Slide 16 Page 16 page 16 Interoperability Realized ContextConstraints Requirements Enterprise Information Computational Engineering Slide 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 Slide 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 Slide 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 Slide 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 Slide 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,