Hl7 interoperability paradigms
1 / 19

HL7 Interoperability Paradigms - PowerPoint PPT Presentation

  • Uploaded on

HL7 Interoperability Paradigms. September 2007 WGM, Atlanta, GA. John Koisch, OCTL Consulting Alan Honey, Kaiser Permanente Grahame Grieve, Jiva Medical. Interoperability Paradigms (IP). Formally introduced in the Template Ballot

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about ' HL7 Interoperability Paradigms' - matthew-russo

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Hl7 interoperability paradigms

HL7 Interoperability Paradigms

September 2007 WGM, Atlanta, GA

John Koisch, OCTL Consulting

Alan Honey, Kaiser Permanente

Grahame Grieve, Jiva Medical

Interoperability paradigms ip
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

Three interoperability paradigms
Three Interoperability Paradigms

  • The following paradigms have been identified to date:

    • Messaging

    • Services

    • Documents

Messaging paradigm
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.

Services paradigm
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

Document paradigm
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.


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


  • 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

Templates usage within interoperability paradigms
Templates Usage within Interoperability Paradigms

Note that other usages of templates are not being precluded or dismissed.

Use of templates
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


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

Vision services documents messages
Vision: Services, Documents, Messages

Orchestration, Choreography,

and Interaction Patterns


Contents: Domain

& Document Models

Trading Partner

Agreements: Binding

Services and Content


Made by HL7, IHE, Realms, Projects

Messaging: Binding the Services

and Contents to a transportation

Platform (HL7 Wrappers & ATS)


  • 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


  • Presentation available at:

    • http://hssp-education.wikispaces.com/hl7_presentations