Alan Honey - Kaiser Permanente John Koisch - VA / OCTL Consulting

1. April 2007 Healthcare Services Specification Project (HSSP)HL7 Services Oriented Architecture SIGMethodology Mapping (Update April 2007) Alan Honey - Kaiser Permanente John Koisch - VA / OCTL Consulting

2. Introduction • The purpose of this presentation is to discuss an analysis carried out between current (and proposed) HL7 V3 Message Development Methodology (particularly the Dynamic Model) and SOA. The aim was to look for possible synergies and convergence. • This will cover: • Background • Approach • Comparative Analysis • Proposed Process

3. Background • HL7 is in progress in re-defining some aspects of the dynamic model for V3. Details are available on the Informatics Wiki at: • http://informatics.mayo.edu/wiki/index.php/Dynamic_Model • Under the banner of “SOA4HL7”, the HL7 SOA SIG has also produced a draft methodology for defining services based on existing HL7 V3 (or V2) Artifacts, which was submitted for ballot as an informative document. • In an HSSP Implementation subgroup meeting, Lloyd McKenzie presented the latest dynamic model thinking and the group discussed the possibility of looking for synergies with SOA. An initial/draft analysis (carried out by Alan Honey and John Koisch) was presented at San Diego in January. This is an update based on feedback received.

4. Approach Taken • Research • Current V3 documentation and Mayo Wiki pages • SOA4HL7 Methodology • Industry SOA analysis (mainly from CBDI Forum) • Continuing Kaiser and VA work • Defined generic process and artifacts to enable comparison • Carried out comparative analysis for each main development stage. • Produced initial recommendations • Reviewed and updated based on feedback to date

5. Comparative Analysis • A comparative analysis of HL7 V3 Messaging Methodology and SOA was carried out for each of the main phases from the generic methodology • Overall conclusions are summarized on the next two slides, followed by the findings for each phase. • Recommendations are included (together with a High/Medium/Low priority rating) • Note that these are based on the assumption that we do wish to use the same basic set of artifacts for the dynamic model (at least as far as the platform/technology specific ITS) • Another alternative is to use separate artifacts for dynamic model, but still can use the same information models (with some latitude for granularity differences at message level)

6. Overall Conclusions – Similarities and Differences • Mapping between V3 messaging concepts and SOA Service Definitions is not automatic/deterministic. However, the quality/appropriateness of a Service Definition is subjective and there is a reasonable mapping if judgment is used.

7. Similarities and Differences (Cont)

8. Business Analysis • Comparative Analysis • Information Analysis: Same underlying information model • Business Process Design: HL7 uses Storyboards (and has added Use Cases and other UNL Artifacts in the latest HDF). SOA usually defines explicit Process Models with Business Events and Business Roles • Business Capability Definition: Not really defined in HL7 Methodology, SOA identifies “Business Services” • Recommendations • Add the “Business Service” as a normative concept (irrespective of whether SOA or Messaging is being used). This provides a more formal mechanism for grouping model elements together. (H) • Use a formal, structured set of artifacts to describe the business domain. Although probably optional/non-normative, the use of Business Process, Business Roles, Business Events as outlined in this document can provide a basis. (M) (This is fairly close to the approach documented in the latest HDF, although the HDF still appears to mix business and IT models to some degree and in our view a clearer separation is valuable)

9. Systems Requirements and Functional Specification • Comparative Analysis • Information Analysis: Detailed domain model (no real difference) • Define Systems Scenarios: Current V3 deliverables described in the HDF are the Storyboard, Use Case, Actor, Process Flow (Activity Diagram) and State Transition Diagram. Most SOA methods would also use similar deliverables for this purpose, with the addition of a more formally defined “Choreography” or “Collaboration”. • Define Functional Capabilities: The Application Role is the nearest thing in HL7, although this is somewhat multi-purpose. SOA defines explicit Service and Interface concepts. In HSSP, the SFM provides the functional specification. • Recommendations • Formally describe functional capabilities for all scenarios (including messaging) using a layered structured mechanism (i.e. the “Business Functionality” Service, Interface and Capability structure used in the HSSP Service Functional Model). For messaging, this should eventually take the place of Application Roles (or at least for some/many of the current uses of Application Roles – see slide 16). (H) • Use formal System Use Cases for describing scenarios. Introduce a standard layout for their descriptions. Standardize a set of actors. (M) • Formally name and define each Choreography (as defined by W3C in WS-CDL[1], which is basically also equivalent to the ebXML notion of a “Collaboration”). This sets the context for interactions that are to be described and standardized. (H) • Use a formal artifact to define the functional specification. A slimmed down HSSP-style SFM could be used for messaging. (M) • [1] http://www.w3.org/TR/2005/CR-ws-cdl-10-20051109/

10. Systems Analysis and Logical Design • Comparative Analysis • Information Design: Detailed information design. Same techniques and constructs, some use of different constraints (e.g. for different granularity) • Define Choreography and Capabilities: HL7 V3 - Application Roles, Interactions and the CPM. SOA - Service, Interface, Operation for structure and various dynamic model diagrams, WS-CDL (W3C standard for defining Choreographies). • Define System Behavior: • HL7 uses receiver responsibilities and now the CPM. SOA defines operation level pre-conditions, post-conditions etc. • HL7 use of message instance level switches to direct behavior. In SOA, this tends to be contractual.

11. Systems Analysis and Logical Design • Recommendations • Recognize the “Service” and “Interface” as first class modeling constructs, irrespective of SOA or messaging. Deprecate (over time) the use of Application Roles (at least for some/many of the current uses). (H) • Define an explicit behavior construct, i.e. the Operation that allows for defining behavior explicitly and normatively. Use pre-conditions, post-conditions, invariants and state transitions as appropriate. Relate or tie this construct to interactions where they are used. (H) • Introduce an additional construct (e.g. The Interoperability Paradigm Specification) that reflects differences in “paradigm” (messaging, SOA, maybe others) (H). • Move several current concepts into The Messaging IPS, namely: The acknowledgment model solution (as opposed to requirements), Trigger Events as a run time mechanism, Transmission Wrapper • The SOA IPS would contain details of SOA interface contracts, policies and potentially orchestration details

12. Systems Analysis and Logical Design • Recommendations (cont) • Use the HL7 static model structure for the information model across the board. When finalized, consider the new UML-ITS mechanism for UML modeling and schema generation (H) • Track the Behavioral Contract Wrapper construct proposals being discussed in INM. In the SOA IPS, in some cases this (or parts of) may be used as an optional construct. (H) • Adopt Web Services Choreography Description Language (from W3C) WS-CDL[1] (or at least their concepts and structure), which provides an IT industry standard formal language for describing “Choreographies”, including Interactions, Roles and Participants. Note – the interactions do not have to be web services at all. (H) • [1] http://www.w3.org/2002/ws/chor/ • In implementation terms, WS-CDL has not yet had great adoption, however provides a good, rigorous model for defining Choreographies • Despite the “WS”, the endpoints do not have to be web services at all. • The WS-CDL Interaction is different from the current HL7 concept of Interaction in that both messages of a request-response scenario are part of the same interaction.

13. Technology Specification • Comparative Analysis • Message Schema: Refer to new-ITS work in UK • Message Headers and Interface Contracts: HL7 uses Transmission Wrappers as part of the “Composite Message”. SOA (web services) uses SOAP Headers. The dynamic model needs to define infrastructure requirements rather than solutions and then use the concept of the IPS (see previous slide) to define the implementation specifics. • Implementation Choreography: SOA includes the concept of process “orchestration”, where a separate middleware component effectively becomes the controller of one or more related interactions within a overall business transaction or process. • Recommendations • Define normative technical specifications (at least for some specific IPS, e.g. SOA). The ITS concept of non-normative generated technical specifications based on deterministic, derivative relationships between the logical view (PIM) and technical implementation is reasonable for information viewpoint but creates many issues for dynamic models, processes and functions. For SOA, this must also be considered in light of the current partnership between HL7 and OMG for HSSP Services where the technical specification is standardized by the OMG. (H) • Use an ITS specific form of a formal implementation contract to match the interface specification. For SOA web services ITS, this would be WSDL plus Policy declarations as appropriate. (M)

14. Proposed “Merged” Process

15. Summary • Overall, many of the same artifacts and processes can be used to define both SOA and messaging solutions. • Some of the structural aspects for behavior from SOA could be of benefit to the Messaging solution, and the same information models can be used (i.e. the RIM based V3 models), however some of the message level chunking of content may be different. • A more formal mechanism for describing choreography, such as WS-CDL, would be of benefit across the board. • Different infrastructure approaches are used for transmission and some behavior aspects. A new concept is needed, such as the IPS proposed on slide 12 (this is also referred to in the current Templates ballot). It is feasible to keep most differences to this and the technology specific specification / ITS.

16. Appendix - Use of Application Roles • The Application Role is being currently used to cover different levels of concept in HL7 V3, including: • A complete system or application • HR Comprehensive Tracker, Dispensing System (Prescription processing), Electronic Health Record • A Service or Interface • Person Registry Request Fulfiller • A processor of a single message/interaction (basically an Operation in SOA terms) • Elig Query Mgr-Rx • A specific event publisher or subscriber in an EDA • Patient Billing Account Informer, Patient Billing Account Tracker • A general event publisher in an EDA • Broadcast Informer • A service consumer (again potentially at various levels) • Elig Rqstr – ChiroPhysio • Maybe some are a misinterpretation of the intended concept, however this highlights the fact that there are missing structural levels in the current methodology. Se recommendation on slide 11.

17. Questions? What Next?