SOA and HL7 V3 Proposal Overview

1. SOA and HL7 V3Proposal Overview Alan Honey Kaiser Permanente March 7, 2006

2. Introduction • The purpose of this presentation is present a proposal to define an approach for how SOA and HL7 V3 should fit together. • This deck is purposefully brief and at a summary level. The more detailed full deck entitled “SOA for HL7 V3 – Full” provides further background and more detailed proposals.

3. SOA and HL7 - Fundamental Questions • Many organizations (including KP) are adopting SOA as their fundamental architecture for integration. • Most healthcare organizations use HL7 V2 messaging and will migrate to V3 over time • Two conceptual viewpoints (both valid) • Implementing a general SOA framework (common infrastructure, tools and approaches). “HL7 is just another content type” • Implementing an HL7 based messaging architecture that can use different messaging and transports, including web services. • The first tends to lead to the conclusion that HL7 should just define content. The second tends to lead to HL7 defining the whole stack • How do the worlds of SOA and HL7 V3 messaging intersect? • How can we maximize the benefits of both approaches?

4. Vision for Healthcare Services Network • Vision – standards based network of services • Medical information available and shared across the nation (world?) subject to appropriate privacy and security • A standards based healthcare internet (HL7, DICOM, X.12, other content) • Must be standards based, but also simple and low cost to join • Web services based • Cheap (in some cases free) infrastructure and tools • Must separate concerns, i.e. Content separate from transmission and technical infrastructure (evolve independently) • Need standard “common” services: • Business - Record location, Entity Identification, Terminology etc. • Infrastructure – Security, Auditing, Management etc. • Vision is long term and worldwide (epidemics, bio-terrorism etc)

5. HSSP (HL7 SOA SIG and OMG HDTF) • Joint HL7-OMG effort to define standard healthcare services • HL7 does logical/functional/business model, OMG does technical implementation through RFP process • Current specifications in progress • Entity Identification (EIS) • Record Locate and Update (RLUS) • Common Terminology (CTS II) – with Vocab TC • Decision Support (DSS) – with CDS TC • Defined a methodology framework (based on HDF) and specification template. • Work is needed to integrate into “mainstream” HL7 and to bring the worlds together.

6. What is Service Oriented Architecture (SOA)? • SOA is an architecture that enables business agility through the use of common services. • Services are independent, self-contained, reusable business functions (such as eligibility checking) or infrastructure functions (such as security) • Services can be combined and orchestrated to automate complex business processes • Important aspects for SOA are: • Semantics (models of process, service, information and relationships) • Behavior and mindset of business and IT staff • Clear processes, roles and responsibilities • Explicit interaction/interface specifications and contracts • Governance of Services

7. Benefits of SOA • Some business related benefits of SOA: • Responsiveness - to meet market demands for increased service levels • Adaptability - Process changes with minimal complexity and effort, saving time and money • Business-IT Alignment - Application services aligned with business activities and business strategy. • B2B opportunities arise and interactions are cheaper and quicker to set up. • Shared Services - cost less to maintain and enable focus on improving quality. • Consistency – Enables increased consistency of business-processes. • Some IT benefits of SOA • Reuse - More efficient development and delivery through reuse of shared services. • Cost Reduction - Maintenance and integration. • Cheaper and easier to implement - Can use standard, inexpensive (free?) tooling • Speed of Delivery - quicker and easier than traditional mechanisms. • Risk Reduction – Risk is reduced through modular, incremental implementation. • Reduced Error Rates – through reuse of existing services.

8. Achieving SOA Benefits • Benefits may be impaired using current HL7 V3 approach • Business • SOA defines services top-down based on business processes, maximizes alignment and agility to adapt to business needs. Driving from messages will not always align as well (sometimes it will) • Adaptability/Responsiveness to change. Use of simple, dynamic/ad-hoc intermediary capability within SOA is key to this flexibility. Constraints and complexity need to be minimized. • Development Tools • Standard web service tooling makes it (relatively) cheap and easy for organizations to incorporate services into the enterprise (both on client and server side). These are increasingly configured to work with domain independent OASIS, WS-I standards etc. Should not handle different content in different ways • Infrastructure • Standards based infrastructure for security, policy definition and run time evaluation, reliable messaging etc. Again, needs to deal with all content in same way for time and cost efficiencies and simplicity

9. Recommendation • Define an approach for how HL7 V3 and SOA fit together. I propose the following: • Discuss within INM (based on this deck) • Charter the SOA SIG to define a proposed architecture (initially at informal level – white paper rather than standards speak) • Invite participation from interested parties • Define the architecture (see next slide for scope) • Bring to INM first to get agreement on basic approach and discuss the way to bake into HL7 V3 standard (separate ITS or other mechanism?) • Where appropriate, review with other HL7 groups • Then produce appropriate material for HL7 ballot • See speaker notes for estimated timelines

10. Recommendation • Proposed scope of initial HL7-SOA proposal • An architecture/approach describing how HL7 V3 content would be consumed and produced by Services within an overall SOA • Cover transmission and transport issues • Consider role of: Current XML ITS, Control/Query infrastructure, Transmission wrappers • Define for generic SOA and then specific technologies (e.g. XML, SOAP, WSDL and WS-* initially, subsequent versions may consider ebXML, REST etc.) • A mapping of current V3 artifacts to the SOA approach • This should provide at least rules for deriving or transforming from SOA elements (contract or headers) to (at least) mandatory HL7 Wrapper items (to enable transformations to/from SOA environment) • Identification of those elements that should be left to other protocol and technology standards and any constraints that should be imposed on those elements (probably in the form of requirements) • Outline methodology for defining services (outside of formal HSSP process) and creating service implementations, including approaches to conformance and profiling (in line with other SOA SIG / HSSP work)

11. Value Proposition • The aim is to provide a means to realize or maximize the benefits of SOA for HL7 content areas • For organizations implementing a SOA framework: • Provide a means to fully realize the benefits of SOA using HL7 V3 content in a consistent, standardized way • For connecting vendor systems within an enterprise • For interacting with other organizations (e.g. for sharing patient data, evaluating and paying claims, referrals) • Enable more business agility, e.g. the ability to quickly create new applications and ways of doing business. • Faster and cheaper integration between systems through use of standards-based automated development tooling. • For healthcare software vendors: • More flexibility in providing standard-conformant solutions • Easier and quicker way to evolve products and meet requirements of customers migrating to SOA