Healthcare Services Specification Project The Business Case for Healthcare SOA Standards

1. March 2008 Healthcare Services Specification Project The Business Case for Healthcare SOA Standards HL7 Service-Oriented Architecture SIG OMG Healthcare Domain Task Force Open Health Tools

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

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), Open Health Tools, IHE, 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

4. Interop Testing IHE HSSP Approach Vendors, OHT, Healthcare Orgs Implementations Profiles IHE, SDOs, Healthcare Orgs TechnicalSpecifications OMG, RFP Submitters OMG Healthcare Domain Task Force RFP Service Functional Model HL7 Domain Committees, CEN, Standards Bodies (SDOs) InformationModels HL7, openEHR, CEN, … Requirements Healthcare Organizations Policy Business Drivers Government, Professional Societies,…

5. HSSP is part of the bigger health IT landscape…

6. What type of products do you produce? • SOA Functional Standards [Service Functional Models] • CTS II - Terminology Maintenance/Navigation • CRFQ – Clinical Research Filtered Query • PASS – Privacy, Access, and Security Services • HSD – Human Services Directories • Technical Specifications for balloted Functional Standards • EIS - Entity Identification Service (such as MPI) • RLUS - Retrieve/Locate/Update Service • DSS - Decision Support Service • Implementation Guidance & White Papers • Practitioners Guide to SOA in Health Care • Implementation Guides

7. 2008 HSSP Project Schedule (planned, major milestones)

8. 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

9. 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

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

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

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

13. 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

14. Context of HSSP Specifications High Ability to Interoperate Low Information Design and Technology & Semantics Interoperability Platform Bindings Model-based Platform-independent component Specifications Model Fragment Computationally- Independent Specification Reference Information Model HL7 Application Roles Data Types and Terminology Bindings Middleware Frameworks Standard Terminologies and Vocabularies Messaging Specifications (HL7, others) HL7 Community and Open Participation Physical/Software Infrastructure

15. Two Dimensions of Interoperability • Behaviorally, there are a lot of solutions • Need to marry Semantic Interoperability with Behavior • The touchstone business case is the notion of automated discovery, composition, and delivery • What can HSSP provide to get us to the goal? Ideal Target HSSP Reference Arch Semantics HL7 Messaging HSSP RLUS (Profiled) HSSP EIS OWL-S Web Services UDDI v3 CORBA Java RMI HSSP RLUS Behavioral From the RM-ODP Informational Viewpoint

16. SOA ≠ Web Services

17. The Value of HSSP …

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

19. 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

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

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

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

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

24. Supplemental Slides: HSSP Stakeholder Benefits and Impacts

25. 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

26. For Product Consumers and Users…The Impacts and Rationale of HSSP Specifications

27. Product Vendor …The Impacts and Rationale of HSSP Specifications

28. Regulatory/Policy/Legislative …The Impacts and Rationale of HSSP Specifications

29. Research …The Impacts and Rationale of HSSP Specifications

30. Implementer/Integrator …The Impacts and Rationale of HSSP Specifications

31. SDOs …The Impacts and Rationale of HSSP Specifications

32. Composition of Profiles - Example Conformance Profile - Name - Version - Date - etc Entity Identification Service Patient Cross Reference Profile Version: 1.0 Date: 10/22/2007 Description: ………….. Entity Cross-Reference Version 1.0 - Link Entity - Unlink Entity - List Linked Entities Functional Profile - Name - Version - Capability 1 - Capability 2 - Capability N…. HL7 RIM V2.14 Patient - HL7 RIM - V2.14 - Model: Set of traits taken from Patient Billing Account RMIM (FIAB_DM000000UV01). (EIS SFM included sample model) Semantic Profile - Information Model ID - Version - Source - etc