SOA versus Message Transmission

Many organizations are adopting Service Oriented Architecture (SOA, see Wikipedia for a description) as their fundamental architecture for integration. The SOA SIG and HSSP (see HSSP Wiki for details) is working on an SOA architecture for HL7.

The issue

There are two conceptual viewpoints (both valid)

1. Implementing a general SOA framework (common infrastructure, tools and approaches). "HL7 is just another content type"
2. Implementing an HL7 based messaging architecture that can use different messaging and transports. "Webservices is just another transport type"

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. This leads to the following key questions:

• How do the worlds of SOA and HL7 V3 messaging intersect?
• How can we maximize the benefits of both approaches?

Complete end-to-end full-stack solutions as standards were essential a few years ago to get anything to work, for example HL7's work to fully define an operating model for those using less complete frameworks such as basic MLLP messaging. For V2, it also made sense to define “the whole stack” in HL7. It may still do for MLLP, but not for SOA. Increasingly, standards need to be used together, across a number of layers and partitions.

Summary, ongoing work

HL7 V3 RIM-based definitions are to be used in the definition of the interfaces to services within an HL7 SOA, and these will be developed in a way that is consistent with the use of HL7v3 messaging and documents (CDA). Service definitions require specifications that go beyond information structures to be exchanged, including the functional definitions of the services, and technical definitions of how they interoperate. This is being worked on within HL7. The best approach to delivering this richer set of definitions is being progressed within HL7 by the SOA SIG and the HSSP project, and these will inform the release 2 dynamic model work being done in INM.

SOA and the current HL7 Messaging Architecture

The fact that the HL7 Messaging Architecture defines “the whole stack” in HL7 maps to issues on the use of the various wrapper layers around HL7 content and the level of overlap between their functionality and that of advanced general frameworks such as web services and ebXML.

Some of the areas of overlap:

• HL7 should be about business function, not about infrastructure technology (but what about “transmission”?)
• Reliability, security, routing are NOT unique or specific to HL7
• Need to enable separation of the (dynamic) “process” from the (static) services / endpoints.
• Implementation aspects (e.g. message identification and correlation) of the interaction patterns can (should?) be left to the infrastructure to implement, not the application.
• 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

Project plan

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, Specification Infrastructure domains
  • Define for generic SOA (and at a later stage for 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 and creating service implementations, including approaches to conformance and profiling (in line with other SOA SIG work)

The main tasks are listed below:

• Define objectives, principles and approach (kick-off and should involve all participants)
• Define Requirements (Requires detailed MCCI knowledge and SOA understanding)
  • Analyze HL7 V3 MCCI (Wrappers, Control Query Infrastructure etc). Re-cast as requirements
  • Define requirements to achieve SOA benefits (Requires Knowledge of HDF and SOA)
• Define Conceptual SOA Approach that meets requirements and adheres to principles (requires detailed SOA knowledge and some MCCI knowledge)
• Define Methodology/(-ies) for identifying and defining services
  • Based on HL7 V3 artifacts
  • Based on top-down business process and mapping to V3 artifacts
  • Consider and define conformance approach (consider profiling)
• Define Physical Solution(s)
  • Define WS-* stack implementation of conceptual view (requires detailed SOA knowledge and some MCCI knowledge)
  • Define approach to XML Schema definition (Requires detailed knowledge of XML and current XML ITS)
• Map solution to current HL7 V3 infrastructure for transformation purposes (Requires detailed MCCI knowledge and SOA understanding)