hl7 interoperability paradigms

04/19/23 21:19

HL7 Interoperability ParadigmsHL7 Interoperability Paradigms

September 2007 WGM, Atlanta, GASeptember 2007 WGM, Atlanta, GA

John Koisch, OCTL ConsultingAlan Honey, Kaiser PermanenteGrahame 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 ParadigmsThree Interoperability Paradigms

• The following paradigms have been identified to date:

– Messaging

– Services

– Documents

Messaging ParadigmMessaging 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 ParadigmServices 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 ParadigmDocument 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.

Relationship of IP to Solution ArtifactsRelationship of IP to Solution Artifacts

Information Dynamics / Behavior Other

Independent DAM, Some DIMs,Some reusable constructs (e.g. CMETs)

Business ProcessBusiness EventsBusiness Roles, Responsibilities, PIM (?)

Analysis Models, Requirements, Business Rules

Dependent CIM (some),Message Model

Trigger Events (some),Application Roles / InterfacesCommunication Patterns, End points

Design Models,Message Platform, Technology Bindings, Message headers / wrappers, Protocols

ConformanceConformance

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

Conformance Levels per IPConformance Levels per IP

Level Messaging (proposed, additive)

Documents (actual, additive)

Services(proposed)

1 Uses HL7 RIM as abstract information model.

The unconstrained CDA specification.

Proposed – Ties to HL7 Balloted SFM

2 Uses HL7 DIM or CIM as abstract information model.

The CDA specification with section-level templates applied.

Proposed – Ties to SOA Sig Conformance Profiles

3 Uses message wrappers (DIM/CIM).

The CDA specification with entry-level (and optionally section-level) templates applied.

Proposed – Conforms to the OMG Technical Specification

4 Uses all of the HL7 Static and Dynamic Models.

N/A Proposed – Aligns with the SOA Sig Service Interoperability Profile

TemplatesTemplates

• 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 ParadigmsTemplates Usage within Interoperability Paradigms

Paradigm Template Usage Notes

Messaging Message Validation

Documents Payload constructionPayload ValidationBusiness Rule Validation

Service Oriented

Interface ParametersInformation Bindings

Services can implicitly or explicitly support all of the above

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

Use of Templates in Messaging IPUse of Templates in Messaging IP

Use of Templates in Document IPUse of Templates in Document IP

Use of Templates in Services IP

Use of Templates in Services IP

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

RecommendationsRecommendations

• 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, MessagesVision: Services, Documents, Messages

Orchestration, Choreography, and Interaction Patterns

Contents: Domain& Document Models

Trading Partner Agreements: BindingServices and ContentModels

Made by HL7, IHE, Realms, Projects

Messaging: Binding the Servicesand Contents to a transportationPlatform (HL7 Wrappers & ATS)

Services

VisionVision

• 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

Questions?Questions?

• Presentation available at:– http://hssp-education.wikispaces.com/hl7_presentations