HL7 Implementation Guide
Cross-Paradigm Interoperability Implementations
(X Paradigm): Immunization
Release 1
Services Oriented Architecture Work Group Co-Chairs:
Don Jorgenson
(Inprivia)
Stefano Lotti
(HL7 Italy / Invitalia. Government Agency for
Inward Investment Promotion and Enterprise Development)
Vincent McCauley, MB BS, PhD
(Medical Software Industry Association - Australia)
Ken Rubin
(Hewlett-Packard Enterprises Services)
Preface
Acknowledgements
Project Lead: / Alean Kirnak:(Software Partners - USA)
Authors: / Ken Lord:
(Semantix - USA)
Stefano Lotti:
(Invitalia - HL7 Italy)
Zoran Milosevic:
(Deontik - Australia)
In addition to the listed authors, the following individuals are acknowledged for their contributions during the development of this document:
- Cory Casanave (ModelDriven - USA)
- Ann Wrightson (NHS Wales)
- …
Legend (for draft):
· [TBD] To Be Developed
· [TBC] To Be Completed
· [TBR] To Be Revised
Summary
1 Introduction 4
2 Scope 4
3 Approach 4
3.1 Service-Aware Interoperability Framework (SAIF) 4
3.2 Model Driven Message Interoperability (MDMI) 7
4 Current results 8
5 Document organization 8
6 Already existing artifact used in the document 8
6.1 Mapping on ISM Matrix 8
7 Enterprise Dimension 9
7.1 Conceptual perspective 9
8 Information Dimension 10
8.1 Conceptual Perspective 10
8.2 Logical Perspective 10
8.2.1 Introduction 10
8.2.2 Common Information Model 10
8.3 Implementable perspective 10
9 Behavioral Dimension 11
9.1 Conceptual perspective 11
9.1.1 Process 12
9.1.2 Business Capabilities 14
9.2 Logical Perspective 16
9.2.1 Services Structure 17
9.2.2 Service architecture 18
9.3 Implementable perspective 18
9.3.1 OMG/HSSP 19
9.3.2 IHE – TF 19
9.3.3 FHIR 20
9.3.4 Deployment 21
10 Appendix X 21
1 Introduction
[Extension required about methods and scope. Should be as an executive summary.]
2 Scope
[Scope definition. Starting point is the previous Project need section]
3 Approach
[In Figure 2 the Information Dimension content must be verified by KenL]
X Paradigm has no clear precedent to guide its methodology. The project’s goal is to assist organizations in achieving interoperability in an environment comprising multiple different data exchange paradigms as messages, documents and services. The challenge is that many organizations, in the real-world, facing complex environments where the realty resulting from investment in different products and systems over time.
Effectively these aspects, until now, have received little or no attention. We have different standardization effort that, in the real world, that stratify different generation of implemented standard in different systems. Otherwise
These aspect is not really managed in any new standard generation. A new step in evolution start, obviously, with a “fresh look” mindset. As a consequence iimplementers, in each point of time , face a myriad of standards which are themselves often incompatible across implementations and versions. At the end of the day we should accept that the coexistence of different paradigms is, and will be, a reality.
The approach designed by X Paradigms is a way to address this ‘standardization hole’ with a concrete set of methods and tool useful to catch the objective of a sustainable integration among the different standards implementation effectively in place in point of time.
3.1 Service-Aware Interoperability Framework (SAIF)
In this effort the use of Service-Aware Interoperability Framework (SAIF)[1] in X Paradigm represents cornerstone to organize a Service-Aware interoperability solution that address the integration among existing standards. SAIF and especially its Specification Interoperability Matrix (ISM ) play a relevant role in the game giving us a framework were the necessary artifact can be identified and placed in a meaningful way .
SAIF is essential to clearly separate business[2] and logical aspect from platform specific ones. It is otherwise too complex to easily understand the differences and commonality among different technical paradigms because, frequently, different technical specification mix business, architectural and implementable aspect in different ways.
Enterprise Dimension / InformationalDimension / Computational
(Behavioral) Dimension / Engineering
Dimension / Technology
Dimension
Conceptual Perspective
Logical Perspective
Implementable Perspective
Figure 1 – SAIF Interoperability Specification Matrix (ISM)
The ISM matrix is composed to five Dimensions (Enterprise, Informational, Computational/Behavioral, derived from RM-ODP[3] standard and three Perspectives (Conceptual, Logical, Implementable) roughly related with level s of abstraction of Model Driven Architecture (MDA)[4]. See the HL7 SAIF-CD[5] for a complete description of ISM.
Must be noted that, in SAIF, Perspectives are not formally linked with MDA viewpoints (CIM, PIM and PSM), however in X Paradigm the correspondence is substantially formal.
In the context of X Paradigm as a standard specification not all the cell defined by the matrix are used. The effort is focused to specify the critical artifact to support a X Paradgm environment
Possibly a specific instance can use more cell (e,g. Engineering and technology dimension should be relevant ) not relevant in our context.
In the Figure 2 the main X Paradigm artifact are listed[6]
Enterprise Dimension / InformationalDimension / Computational
(Behavioral) Dimension / Engineering
Dimension / Technology
Dimension
Conceptual Perspective / · Storyboards
· Use cases / · Data element Identification (MDMI semantic element identification) / · BPMN2 Process Model
· Capability Identification (SoaML Capabilties)
Logical Perspective / · Common Information Model (MDMI Reference Index) / · Common behavioral model (SoaML Service Architecture)
Implementable Perspective / · Syntax elements definition
· Local syntax element definition and mapping / · Paradigm SoaML Service Architecture and structure)
· Mapping between paradigms
Figure 2 – ISM and X Paradigm
The figure below shows the logical progression of artifacts in X Paradigm Interoperability Specification Matrix. must be stressed the point that the X Paradigm uses a meet-in-the-middle approach and in some areas, for example the Information dimension, mainly a bottom-up approach is taken.
It’s relevant to note that a meet-in-the-middle approach it’s frequently different from the most common practice in many integration efforts that realize transformation substantially at implementable level without a framework that can support an adequate abstraction. This approach, practically, avoid to integrate systems in an ad-hoc manner with subsequent issues in maintainability and reuse.
After that an X Paradigm interoperability specification is realized, if a "new paradigm" join the community[7], large part of specification can be used as-is and only the specific mapping with the added paradigm must be realized.
Figure 3 - Logical progression in XParadigm ISM [TBR]
This is possible because the technology aspects are pushed down mainly to a pure implementable level and the compliance of each paradigm can be mapped on a common conceptual and logical model.
As a consequence the X Paradigm approach largely use Model Driven standard as MDMI[8] to simplify and govern the mapping between Paradigms .
3.2 Model Driven Message Interoperability (MDMI)
[TBR/TBD from KenL]
The MDMI standard, crucial for the SAIF Information Dimension, is a transformation model. The critical design points of MDMI are the syntax component, which enables parsing of the source message and the creation of the structure for the target message, and the semantic component which includes the Referent Index that enables semantic mapping between data elements between any two paradigms. Because the MDMI model can produce a machine executable file, this model driven approach can then provide computable semantic interoperability between different models. As long as any two MDMI models use the same referent index, interoperability can be achieved in the HL7 SAIF Information Dimension.
This model driven approach does not require writing software or generating software to achieve interoperability. It is declarative; one populates the MDMI for their paradigm and a machine computable file is generated. The models and files are re-usable and extensible. Tools have also been built in the Open Health Tools MDHT / MDMI project make it easy to develop MDMI maps. So far, use of MDMI appears to both greatly improve the mapping methodology (for “Information Dimension”), and to provide more rigorous traceability among the SAIF perspectives (Conceptual, Logical, and Implementable). In other words, MDMI assists in translating the data elements of one message, document to another; and it helps in connecting requirements, models, and implementable standards in a rigorous way, ultimately producing machine-readable artifacts that can be used in an implementation as well.
4 Current results
[Should be Heavily revised. More focused on methods.] [KenL, Alean?]
A relevant aspect of the X Paradigm approach is that. The result come from a concrete experience in immunization domain were existing specifications have been managed and transformed with a practical verification of the methods explained here.
5 Document organization
The document is organized in conformance with SAIF ISM Matrix with a Dimension lead approach. The table below shown how the document sections are mapped onto ISM Matrix.
Enterprise Dimension / InformationalDimension / Computational
(Behavioral) Dimension / Engineering
Dimension / Technology
Dimension
Conceptual Perspective / § 7.1 / § 8.1 / § 9.1
Logical Perspective / § 8.2 / § 9.2
Implementable Perspective / § 8.3 / § 9.3
6 Already existing artifact used in the document
[Revision of previous Organizations and Artifacts section] [Alean?]
6.1 Mapping on ISM Matrix
[Simple mapping of exiting artifacts on ISM] [Stefano]
7 Enterprise Dimension
[Introduction] [Alean?]
7.1 Conceptual perspective
[Based on storyboards and Use Case from Immunization DAM (p 19)] [Alean?]
8 Information Dimension
[Introduction] [KenL, Alean?]
8.1 Conceptual Perspective
[Briefly describe the scenario and conceptually and identify the information objects involved, considering the different involved flavors/paradigms] [KenL, Alean?]
8.2 Logical Perspective
8.2.1 Introduction
[Starting point the Common Information Model/Approach section with MDMI explanation] [KenL, Alean?]
8.2.2 Common Information Model
[The Unraveling the ‘cascade of templates’ between standards and subsequent section rewritten with MDMI] [KenL, Alean?]
8.3 Implementable perspective
[Explanation on how MDMI is used at implementable level (the implementable artifacts are included in index as atomic element and “constructed” at rutime etc.)] [KenL?]
9 Behavioral Dimension
The Behavioral Dimension is at a different development level against the Information Dimension. Currently is at methodological level and a tool to support the transformation among the conceptual, logical and implementable perspective is not proven.
However the simple methods shortly presented here can be used in several real project. Should be considered that the different paradigms used for behavioral interoperability are more stable and common than the information models. So if it's surely relevant to have a tool that can be combined with MDMI, on the other hand the different development level do not affect the usability of the specification as whole.
Anyway the content of this section can be considered only as a short introduction to the approach used in Behavioral Dimension consistent with the approach of Information Dimension.
The next version of the X Pardigm specification will include a more comprehensive method presentation ad a better integration with the standard tools used in information dimension.
Currently the method use a combination of modeling language:
· BPMN2[9] (Business Process Model and Notation) for the process design and analysis
· SoaML[10] (Soa Modelig Language) for the services modeling.
Formal modeling languages have been demonstrated as critical for a fast and affordable identification of the required functions and the appropriate mapping with the service interfaces and operations.
Another relevant point is the use of the HSSP specification stack.
HSSP specification stack is composed by two standard document and tree model:
· HL7, Service Functional Models (SFM): defines the characteristic and feature of candidate services
In term of SAIF it correspond to conceptual perspective and in term of MDA viewpoint it correspond to a CIM (Computation-Independent Model)
· OMG, Service Techinical Model (STM): defines the computable specification and cover the Logical and implementable perspective of SAIF. In term of MDA Viewpoint the STM include:
o A PIM (Platform- Independent Model) . The model is computationally complete without any reference to a specific implementable platform)
o A PSM (Platform Specific Model). Represent a specific implementable specification (e.g. WS*, REST)[11]
Currently a the direction taken is combination of MDMI for structural part of the different service paradigms[12] and fUML[13]/ALF[14] for the behavioral mapping. This direction will be verified and eventually presented in the next version of X Paradigm specification.
9.1 Conceptual perspective
The objective of Conceptual perspective in Behavioral Dimension is to transform and specify process models derived from storyboard an use case identified in the Enterprise Dimension.
9.1.1 Process
In the figure below is shown an example derived from Record Immunization History Storyboard. The process is represented with BPMN 2.
The use of a formal modeling language as BPMN2 is important to understand the process and identify the messages exchanged by the participant of the process.
In a service aware architecture this is a critical aspect because from the messages we can derive the required capabilities at business level. In our specification case study the base is mainly by the HL7 Immunization DAM obviously in a concrete project this task should be realized by a business analyst[15].
Figure 1 - Record Immunization History Storyboard – Process model.
9.1.2 Business Capabilities
From the messages identified in Business process we can identify the required capabilities . The identification of capability in a business process is the first step in the identification of service candidate. In the contest of an X Paradigm environment the scope is to identify the common functional characteristic of the services involved in the envinronment.
Figura 2 - Record Immunization History Participants
In the exemplary process the messages among the components EHR System, ISS and Patient Registry are considered and each pair of messages identify an operation. The identified operations are grouped in a set of capability considering the functional scope. So the generic high level capability Record Immunization History uses:
• Patient Identification (create identity)