MIF based code generation

Summary

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

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. UML (derived from the MIF) - the code generator has to know UML, including a few extensions that are v3 specific

• Major open issue:
  • A. MIFs aren't normative. Lloyd: doesn't matter that much whether they're normative or not, in terms of stability.
  • B. 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.
• Open issue: 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.

Code Re-use & Datatypes support

1. 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
2. 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.

UML

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