SOA and HL7 V3

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

2. Introduction • The purpose of this presentation is to discuss how SOA and HL7 V3 can fit together without losing the major benefits of either. • The discussion is broken down into the following sections: • Background • SOA • Issues and Discussion • Suggested Solutions • Conclusions • Appendix – Initial Analysis of HL7 Transmission Wrapper • Note - All opinions and views expressed are personal views held by the author and do not necessarily represent official Kaiser Permanente policy.

3. Background 1. SOA and HL7 Fundamental Questions 2. Vision for Healthcare Services Network 3. HSSP 4. HL7 V3 Key Relevant Concepts

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

5. 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)

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

7. HL7 Key Relevant V3 Concepts • Dynamic Model • Storyboard – Contains a short description of purpose and interaction diagram showing progression of interactions between application roles and a narrative describing a real-life event to provide context for development of a specific interaction described in the storyboard. • Application Roles - Represent a set of communication responsibilities that might be implemented by an application. Thus they describe system components or sub-components that send and/or receive interactions. Domain specific and general communication roles. • Interaction - A unique association between a specific message type (information transfer), a particular trigger event that initiates or "triggers" the transfer, and the application roles that send and receive the message type. It is a unique, one-way transfer of information. • Trigger Event - An explicit set of conditions that initiate transfer of information between system components (application roles). A real-world event such as placing a laboratory order or drug order. Must be systematically recognizable by an automated system

8. HL7 Key Relevant V3 Concepts • Message Infrastructure (I) • Content (payload) – the actual clinical or business information • Control Acts • Trigger Event Control Act - Contains administrative information related to the "controlled act" being communicated as a messaging interaction. • Query Control Act – Query Specification and Query Response interactions contain elements that are needed to establish and control a logical query session between two applications • Master File / Registry Acts – Identifies extensions specific to master file and registry interactions.

9. HL7 Key Relevant V3 Concepts • Message Infrastructure (II) • Transmission Wrapper – Mandatory wrapper including information needed by sending application or message handling service to package and route V3 Composite Messages to receiving application(s) and/or message handling service(s). Also includes attributes that identify a generic messaging mode (handling behavior consistent with HL7 defined messaging interaction for which the composite message instance has been created. • Reliable Message Delivery Protocol – Covers accept and application level message acknowledgements by a message receiver and an optional sequence number protocol • Transport Profiles – Indicates how to transport HL7 V3 composite messages over different transport protocols, e.g. ebXML, MLLP, Web Services.

10. Service Oriented Architecture 1. What is SOA? 2. SOA Principles 3. Benefits of SOA 4. Interface/Interaction Contract

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

12. Principles of SOA (Architecture/Design) • The following are some of the key principles of SOA: • Well defined contract of interaction – explicitly defines information and behavior model and quality of service (see next slide). • Coarse-Grained Services - Services should be coarse-grained to reduce network traffic and to more closely align with the business processes which they serve. • Loose Coupling / Separation of Concerns • Separate interface from implementation. Interactions are based on the interface definition only and not technology or structure of the service implementation. • Technology platform and business logic (semantics) should be able to change independently without unduly impacting the other. • Process and Service logic are also separated into different layers • Minimize Coding - Drive processing decisions by automated reference to explicit policies and metadata rather than in-line application coding. • Advertise and discover services using standards-based service registries. • Use a model driven approach

13. Principles of SOA (Architecture/Design) • Well defined contract of interaction - A key component of SOA • Explicitly defines behavior, information, security and quality of service policies (client should not require additional knowledge of the service implementation), and sometimes legal, contractual and charging aspects • Wherever possible should use strong typing at the interface level • Automated system management can manage to SLAs against the contract • For Web Services, WSDL provides a machine-readable form of SOME of this (although WSDL 2.0 may extend the coverage) • Often structured into separate parts for logical (information and behavior) and physical (transport bindings and location) • Services are not really SOA services without it!

14. Business Benefits of SOA • Some of the business related benefits of SOA are listed below: • Responsiveness - Rapid adaptation and delivery of key business services to meet market demands for increased service levels. • Adaptability - Process changes applied throughout the business with minimal complexity and effort, saving time and money. Easier replacement of components or complete systems with minimal impact on other systems. • Business-IT Alignment - Application services can be closely aligned with meaningful business activities and business strategy. • B2B opportunities arise and interactions are cheaper and quicker to set up. • Shared Services - Business functions transformed from replicated silo processes into highly leveraged, shared services that cost less to maintain and enable focus on improving quality. • Consistency – Enables increased consistency of business-processes.

15. I.T. Benefits of SOA • Some of the I.T. benefits of SOA are listed below: • Reuse - Reduced duplication and redundant development work. More efficient development and delivery through reuse of shared services. • Cost Reduction - Reduced variability, adherence to standards and leverage of legacy applications as re-usable services lower cost of maintenance and integration. • Cheaper and easier to implement - Can use standard, inexpensive (free?) tooling, • Speed of Delivery - Service based approaches are quicker and easier for implementation and maintenance than traditional integration and development mechanisms. • Risk Reduction – Risk is reduced through modular, incremental implementation. • Reduced Error Rates - Reuse of existing services reduces errors and raises overall solution quality.

16. Benefits of SOA • The previous two slides identified some of the main business and IT benefits of SOA. Plain messaging also delivers some* of these benefits, but less so (or to use a circumstantial argument :-) • Messaging products have been around significantly longer • The IT industry is moving to SOA wholesale in almost every industry in an unprecedented fashion • Deduction – there must be a reason to do it! • We need to go with the tide, not resist it. • * - Which ones exactly and to what extent would be a very long discussion. However, this deck is aimed at those organizations implementing SOA.

17. Issues and Discussion 1. Achieving benefits of SOA 2. How Far should HL7 standard go for SOA? 3. Use of HL7 Wrappers in SOA 4. Business Agility 5. Generic vs Specific WSDL?

18. Achieving SOA Benefits • There are three areas where realizing the benefits of SOA may be impaired using HL7 V3 as currently defined • 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 • Some of these and other specific issues are discussed on the next few slides

19. How far should HL7 standard go for SOA? • Need to ENABLE interoperability, not over-constrain or over-specify it. • Semantics and clinical content structure/syntax are rightly in HL7s realm. • Concentrate on clinical/business function and content and semantic agreements. Includes Roles, Information Content, Code values, identifier (OID) structures, Services, Events (and messages) • Organizations need freedom to implement their own standard transport, security, reliability, management and transformation mechanisms. • How far should HL7 go? How much should be left to organizations? • Use of intermediaries (side effects, transformations, message distribution etc)? • Changing of message IDs? • Internal messaging vs External – B2B (raises different issues)? • Focus should be on providing a good, robust and efficient solution to most cases, with extensibility for exception or localization rather than explicitly catering for all individual cases • IT projects apply cost-benefit analysis to requirements, standards should too!

20. How far should HL7 standard go for SOA? • Separation of Concerns • HL7 should be about business function, not about infrastructure technology (but what about “transmission”?) • Implementation aspects (e.g. message identification and correlation) of the interaction patterns can (should?) be left to the infrastructure to implement, not the application. • Reliability, security, routing are NOT unique or specific to HL7 • Need to enable separation of the (dynamic) “process” from the (static) services / endpoints. • Today, each standard should focus on its own subject matter, be modular, composable and adoption-friendly across different architectures and platforms. • Let OMG, OASIS, WS-I and others deal with other layers. • For V2, it made sense to define “the whole stack” in HL7. It may still do for MLLP, but not for SOA.

21. How far should HL7 standard go for SOA? • Some examples for consideration: • Application and transport level acknowledgements • What is the real requirement? (It is not “I need a commit ack” - this is a messaging solution concept) Maybe 100% guaranteed delivery? Non-repudiation? Legal requirement? SLA for message return within x minutes? • Message level or part of service contract (type or instance)? • Example MEP - Request, Synchronous Ack followed by Asynchronous response (in SOA, separate operations and orchestration offer one solution, there are others - WSDL 2 MEPs maybe?) • Message IDs • Should definition of when these change be an issue for HL7 at all, or left to the organization(s) and the interaction contract? Even in B2B this can be contractual.

22. Use of HL7 Wrappers in SOA • Current HL7 V3 Web Services Profiles • Specifies how to wrap full HL7 Composite Messages (including control act and transmission wrappers) in SOAP and gives rules for WSDL. • Advantages: • From an HL7 processing perspective, it uses the same constructs as other “transports” • May make transporting HL7 messages across multiple protocols simpler. • Challenges: • Based in a messaging perspective rather than a SOA perspective and may limit the resulting benefits • Web Services are treated as more of a simple transport mechanism based around a messaging paradigm. • HL7 messages within a SOA framework may be handled differently from other content types using a content specific infrastructure, resulting in potentially less flexibility and slower and more costly development. • Inclusion of explicit Transmission layer adds unnecessary complexity and message bulk • Explicit dependencies between HL7 and WS-* standards may create a continual synchronization challenge between the different standards

23. Use of HL7 Wrappers in SOA • Transmission Wrapper • Most or all items have standard (or emerging standard) SOAP/WS equivalents, some of which can be determined by infrastructure automatically (Appendix A includes some initial analysis) • Some of these can be specified at the contract level (rather than individual message or interaction) • Control Act (needs further analysis) • Some of Control Act headers are valid business content and need to be included. • Some (particularly in query) may be unnecessary in SOA environments • Query infrastructure • HL7 infrastructure appears particularly complex for queries. Queries are generally simple in SOA environments (especially using WS over HTTP). How much of the complexity is really necessary? • Messaging as a paradigm is in general too heavyweight for most query functions • XML ITS • This is not a wrapper, but the way that XML and XML Schema are defined in current V3 also needs to be considered for appropriateness to SOA implementations. (see slide notes)

24. Business Agility • Business Process Management • Separation of control of the dynamic interaction into a process or choreography layer brings a different approach to control of interactions, which HL7 messaging defines as the responsibility of the HL7 applications themselves • Pre-determined vs discovered destination • SOA enables a much more dynamic model. Physical addressing and logical system addressing can be “late bound” • Dynamic nature of interaction • SOA encourages the use of separate configurable policies to drive interaction processing. This provides a much more flexible model than when this is embedded in endpoints or fixed by the infrastructure in advance. • Complex Event Processing (CEP) • A relatively new approach for real time business intelligence decision making that is based on intercepting messages within distributed environments and drawing inferences for real time action. This is made far easier within an SOA framework.

25. Business Agility • Use of Intermediaries • A key perceived benefit of SOA is enabling business agility / flexibility. Much of this will be achieved by unforeseen dynamic / ad-hoc use of intermediaries, particularly for intra-organization interactions. This requires access to message content in a simple, easy to use manner. Some examples are: • New regulations on privacy, need for selective encryption • Business Activity Monitoring based on particular key fields, e.g. all messages containing a specific medication • Raising alerts based on specific business information • New regulatory reporting requirements • Orchestration and web services tools can provide such capabilities simply and cheaply, providing messages on the wire adhere to industry wide WS standards, with only the business “content model” varying.

26. Generic vs Specific WSDL • One related issue that also needs further consideration is the “generic vs specific” WSDL issue. • For dynamic queries, generic can make sense (e.g. XQuery) • SOA encourages dynamic interactions (using intermediary components for side effects, business monitoring, orchestration etc.) This is a great deal easier using technology that is web services aware but not necessarily party to “out of band’ arrangements between two endpoints, i.e. the schema is exposed at the web service level. • Where one of the endpoints is actually a custom development by our own IT staff, possibly a web UI application, using standard web service aware tooling that can take the exposed schema makes this significantly easier (particularly if the wrappers are simplified). • In some cases, a specific WSDL that allows flexible (open) fine grain content within certain complex data structures may be a reasonable compromise • Some guidelines are needed.

27. Some Suggested Solutions 1. Scope for HL7 in SOA 2. Mapping V3 Concepts to Services 3. Layered Conformance and Profiling 4. Methodology

28. Proposed Scope for HL7 (in SOA) Proposed Rule - Infrastructure not specific to HL7 should not be defined by HL7 Examples - Message Correlation, Reliable delivery, routing to system instances and security should be out of scope

29. Proposed Scope for HL7 (in SOA) Scenario – A physician orders a Prescription and indicates it should be filled at a specific Pharmacy location (this is business content and in HL7 scope). The SOA infrastructure will determine that the specific pharmacy is served by a specific system instance. This is a “middleware” function not an application one, so if the mapping changes, it can be carried out once, not in every sending application, also the same logic may be needed for other content types not covered by HL7, e.g. DICOM, NCPDP SOA to V3 Mapping – Most or all of Transmission Wrapper and possibly some of Control Act is really unnecessary in SOA and adds bloat and complexity

30. Mapping HL7 V3 Concepts to SOA • HSSP will define some service standards. It would be valuable to have a standard approach where HSSP has not defined an explicit standard. • I believe that we can do SOA and make appropriate use of some of the excellent work done in MCCI and related areas. But SOA is NOT messaging – the development process and infrastructure are different. • One potential mapping is: • Service = Collection of related Application Roles • Interface = Application Role (usually) • Operation = Interaction • Operation input/output = message content or message content part (note the latter option, not necessarily tied to granularity of specific HL7 message) • Process Orchestration handles some of dynamics / interaction • Interaction Contract handles some of the Transmission concepts • Some of this is reflected on the next slide (diagram courtesy of Ioana Singureanu - VHA) • The use of conformance and profiling mechanisms could also help in the overall solution (on following slides)

31. findCandidatesQuery getDemographicsQuery findIdentifiersQuery Person Registry Query Fulfiller Mapping HL7 V3 Concepts to SOA Interface Based on Application Role Person Registry Query Fulfiller  (QUPA_AR101102 ) PERSON REGISTRY SERVICE Operation based on Find Candidates Query  (QUPA_IN101103) Input param Return type Operation QUPA_MT101104 findCandidatesQuery (parameter list) based on response interaction’s (QUPA_IN101104) message definition type based on Control ActQUQI_MT020001UV01 based on interaction TriggerQUPA_TE101103

32. Layered Conformance for HL7 “Transport” (WS, ebXML, MLLP) Profile Level 4 HL7 Transmission Wrapper Level 3 HL7 Control Act / Query Wrapper Level 2 XML ITS Encoded Content Level 1 HL7 Medical Data (Content) Level 0 Level 0 – Uses HL7 content model (not even XML necessarily) Level 1 – Uses HL7 HDF and XML ITS (XML Schema from HL7 ballots) Level 2 – Uses the Control Act Wrapper as defined by HL7 Level 3 – Uses all of the HL7 wrapper layers (Control Act, Transmission etc) Level 4 – Uses all layers plus HL7 Transport Profile (e.g. Web Services) (Other combinations may also be valid)

33. Profiling • Profiling is a mechanism being proposed in HSSP to deal with optionality and localization. • A basic profile for a service would define the mandatory operations • Other profiles would group otherwise optional operations into groups where they become mandatory if the profile is supported • A similar approach can be taken to apply specificity to content models within generic operations (for localization or content specialization). • This may also include different operations that provide data structures that are subsets of a full message type • This could also be extended to identify the conformance level a particular service is using, possibly profiles which identify alternate bindings of HL7 content in HSSP Services.

34. Methodology Considerations • Service Definition • HSSP will define new standard services and profiles. • There will also be a need for healthcare organizations and software vendors to be able to define Services within an SOA framework that • Use HL7 V3 content in a consistent way (this is not just a “transport” profile – maybe an ITS or something else) • Enable service definition to be driven from business service requirements, not always directly from message descriptions • Uses standard web services tooling • Content • Information content development still relevant for SOA (although service operations may use partial schema) • RIM -> DMIM -> RMIM -> HMD -> XML Schema etc. • May define XML Schema more directly • HSSP Service definitions may drive need for new or changed information content models

35. Conclusions 1. Discussion Summary 2. Recommendations 3. Value Proposition

36. Discussion Summary • The following key points have been covered: • Vision of standards based services network (long term) • HSSP providing standard service definitions • Organizations implementing SOA frameworks need a way to include HL7 V3 in a consistent manner that maximizes value of SOA and HL7, using (cheap) industry standard tooling • Messaging and SOA are different paradigms, but share a great deal of common ground. Content definition is common, but interaction implementation and infrastructure are different • Separation of concerns across standards. For SOA, HL7 should define information content, but only infrastructure that is truly specific to HL7. • The Transmission Wrapper and possibly some or all of Control Act Wrapper may not be needed in SOA implementations. Web Services standards, Process Orchestration and Interaction/Interface Contract cover transmission issues • Layered Conformance and Profiling may help to address some of the issues. • Methodology needs to be re-considered

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

38. 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)

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

40. Appendix A Transmission Wrapper in SOA

41. Appendix A – Transmission in SOA • Although many of the details discussed in this deck have not yet been fully thought through, some initial analysis has been carried out. • A summary is given here of how a SOA infrastructure (specifically Web Services) may provide the same functionality as some of the HL7 Transmission items. Only the “message” class itself is covered here, but it is believed that analysis of “device” and others would yield similar results. • Batch considerations have also not yet been addressed in this section (may or may not be relevant). • At this stage, this is NOT intended to be definitive, just to identify possible options. In some cases, there may be several different ways of achieving the same purpose within SOA.

42. Appendix A – Transmission in SOA Message Class - Mandatory Items:

43. Appendix A – Transmission in SOA Message Class - Optional Items: