MIF based code generation

Summary

When it comes to code generation the best (most complete) code should be generated from the MIF. Code Generation tends to be a mechanism for the creation of RIMBAA applications.

• An alternative code generation method is Schema based code generation.

Analysis

The primary source for the code generation is likely to be one of the options shown below:

1. MIF - the code generator has to be aware of the structure of the MIF
2. alternate model representation format - the code generator has to be aware of the alternate model representation format (e.g. UML, inclusive of a few extensions that are v3 specific, or EMF in Eclipse). The alternate model representation format is a transformation of the MIF.

Overview

Code Re-use

Re-use of code can be based on

• Separating code for the wrappers from the code for the payload model. Wrapper models are shared by lost of interactions
• Creating a separate library with code to support CMETs. The library could make use of the fact that CMETs have a spezialization hierarchy, i.e. CMETs with an identified flavour are a spezialization of identified-confirmable, which in turn is a psecialization of thye universal flavour of the CMET.

Open Issues

There are a number of open issues related to MIFs that may cause problems when using MIF based code generation:

1. MIFs aren't stable nor normative.
2. Incompatible MIF versions (no guaranteed backwards compatibility, only guaranteed transformability -both ways). If one has a tool which supports a newer MIF version than the MIFs one has, one has to create new MIFs from the original HMDs. Effectively this turns HMD into the source of all truth, not MIF. MIF transform XSLTs can be found in the v3generator package on GForge, in the toolfiles directory.
3. Lack of a formal constraints language: (e.g. OCL, or NLR). Constraints in R-MIM are phrased in human language, not in software processable terms.
   • Lloyd: Need tools to help people author and validate requirement; without that there's not a lot we can do.
4. Currently there is no usable datatypes MIF file. A library to support the v3 datatypes has to be developed as a piece of custom code

UML as an alternate format

Galen Mulrooney/Dave Carlson/Iona (all involved on behalf of the VA): These software components are being built as part of the Open Health Tools project, "Modeling Tools for Healthcare", which is an open-source project to produce tooling that can be used by Standards Development Organizations to produce and publish interoperability specifications (i.e., Messaging, Documents, SOA) using UML and other Open Standards-based platforms.

Anyone concerned that we cannot represent HL7 concepts in UML ignores the fact that UML can be extended using something called a "UML profile". When RIM.coremif is imported all the HL7-specific extensions are imported into stereotype properties. Nothing is lost. We are using two profiles:

1. HDF profile based on the profile authored by Abdul Malik, if you recall, some time ago
2. RIM profile that allows us to track clones to the RIM and to store the class/type and moodCode which would a look redundant to an audience outside HL7.

To install and use these profiles (along with the vocabulary and abstract datatypes) you need update Eclise-based UML 2 tool and install the HL7 plugin as specified in: RSM Quickstart.doc. IBM is providing free RSM licenses for those who need UML tools for HL7 standard development (DAM, DIM, etc.).

If you wish to learn more about the UML extensions and how they are represented as UML stereotypes, please take a look at: UML BOF Wiki.

The HL7 plugin will be maintained and improved by the Open Health Tools' Modeling Tools for Healthcare project.

We have imported RIM.coremif into UML and checked into SVN at: this directory (RIM.emx).