1. 4/12/2015 7:43 AM HL7 Interoperability Paradigms September 2007 WGM, Atlanta, GA John Koisch, OCTL Consulting Alan Honey, Kaiser Permanente Grahame Grieve, Jiva Medical

2. Page 2 Interoperability Paradigms (IP) Formally introduced in the Template Ballot An interoperability paradigm is a set of fundamental principles that establishes the ground rules for the different approaches to V3 based information exchange –When information is exchanged –In what form it is exchanged –How application implementation details are specified –How templates are to be used Templates are used as our use case focus, but other issues are addressed

3. Page 3 Three Interoperability Paradigms The following paradigms have been identified to date: –Messaging –Services –Documents

4. Page 4 Messaging Paradigm The implicit messaging interoperability paradigm is defined by the current V3 dynamic model – interactions, trigger events etc. – and heavily influenced from the V2.x roots Focus is on defining the “Message” (Information Viewpoint) for development and governance. Focus on tightly coupled interoperability profiles e.g. (both sides of interaction, message ID constraints) Behavior is mainly directed by individual message content (e.g. Message instance level switches) Technology platform (e.g. Web services) used as pure transport mechanism Template Considerations: –Each interaction is associated with fixed static model and wrapper models that specify the content to be exchanged. Other models are applied as templates on an instance that conforms to the static model specified in the interaction. –Profiles constrain both the dynamic and static model, and are bound to the root class of the outer wrapper of the interaction. Templates can be applied by the profiles. –Applications cannot reject messages because of the presence or absence of any particular templateId unless the message does not conform to the applied templates, ie, Templates cannot be used to alter the basic semantics of the interaction.

5. Page 5 Services Paradigm Behavior is driven by the Contract (Service, Operation and Behavior - Computational Viewpoint) and is explicit at the interface. Focus on reuse and controlled flexibility (and responsibilities of service provider only) as opposed to tight interoperability with both sides of interaction locked down Web services standard wrappers used to drive behavior and processing Template usage: –An example might be where a functional model is associated with specific static models for specific function parameters, and an open or controlled set of templates are available. –Profiles could be associated with the entry points of the selected models, and the service specification may make its own determination for how applications process templates, depending on their relevance to the functionality provided by the service. –Templates may contain additional semantics that are not specified in a particular interaction but which are explicit in the interface. That is, templates can serve a conditional role in business semantics

6. Page 6 Document Paradigm The CDA and SPL specifications establish an implicit document interoperability paradigm where there is a single fixed static model. Documents conforming to this model may be exchanged whenever and however applications wish – there is no fixed dynamic model. All other models, including potentially CMETs from messaging models, may be used as templates. Under certain circumstances, when explicitly described in the interface contract, applications are entitled to reject documents if a template is not applied where it is expected.

7. Page 7 Relationship of IP to Solution Artifacts InformationDynamics / BehaviorOther IndependentDAM, Some DIMs, Some reusable constructs (e.g. CMETs) Business Process Business Events Business Roles, Responsibilities, PIM (?) Analysis Models, Requirements, Business Rules DependentCIM (some), Message Model Trigger Events (some), Application Roles / Interfaces Communication Patterns, End points Design Models, Message Platform, Technology Bindings, Message headers / wrappers, Protocols

8. Page 8 Conformance The concept of layered conformance has been introduced into the current working draft of the HDF (due for January 2008 ballot). The conformance layers are specifically from the point of view of the Messaging IP. –Level 1 – Uses HL7 RIM as abstract information model. –Level 2 – Uses HL7 DIM or CIM as abstract information model. –Level 3 - Uses message wrappers (DIM/CIM). –Level 4 – Uses all of the HL7 Static and Dynamic Models.

9. Page 9 Conformance Levels per IP LevelMessaging (proposed, additive) Documents (actual, additive) Services (proposed) 1Uses HL7 RIM as abstract information model. The unconstrained CDA specification. Proposed – Ties to HL7 Balloted SFM 2Uses HL7 DIM or CIM as abstract information model. The CDA specification with section-level templates applied. Proposed – Ties to SOA Sig Conformance Profiles 3Uses message wrappers (DIM/CIM). The CDA specification with entry-level (and optionally section-level) templates applied. Proposed – Conforms to the OMG Technical Specification 4Uses all of the HL7 Static and Dynamic Models. N/AProposed – Aligns with the SOA Sig Service Interoperability Profile

10. Page 10 Templates Templates provide an interesting point of comparison regarding IP’s Template Definitions: –Templates are constraints on a static model that are applied on a portion of an instance of data which is an expression of some other static model –Templates represent a realization of business rules that are applied to information exchanged between partners

11. Page 11 Templates Usage within Interoperability Paradigms ParadigmTemplate UsageNotes MessagingMessage Validation DocumentsPayload construction Payload Validation Business Rule Validation Service Oriented Interface Parameters Information Bindings Services can implicitly or explicitly support all of the above Note that other usages of templates are not being precluded or dismissed.

12. Page 12 Use of Templates in Messaging IP

13. Page 13 Use of Templates in Document IP

14. Page 14 Use of Templates in Services IP

15. Page 15 Use of Templates The UML diagrams differ in regards to how information exchange is described The UML diagrams differ in the level of detail in how template usage is described The actual use of templates is conceptually the same in each case

16. Page 16 Recommendations To Include the choice of Interoperability Paradigm in the HDF as a methodological step and as a set of pathways for development of standards and implementations SOA Sig should define the Services Interoperability Paradigm SOA Sig should define the Service Conformance Levels

17. Page 17 Vision: Services, Documents, Messages Orchestration, Choreography, and Interaction Patterns Contents: Domain & Document Models Trading Partner Agreements: Binding Services and Content Models Made by HL7, IHE, Realms, Projects Messaging: Binding the Services and Contents to a transportation Platform (HL7 Wrappers & ATS) Services

18. Page 18 Vision The HDF should work towards a single framework for interoperability paradigms so that technical artefacts only need to be defined once and can migrate across the paradigms as appropriate Define Once, Reuse Everywhere

19. Page 19 Questions? Presentation available at: –http://hssp-education.wikispaces.com/hl7_presentationshttp://hssp-education.wikispaces.com/hl7_presentations