MIF based code generation

Summary

Code generation is a process whereby the source code (in a particular programming language) is automatically generated. It is an example of Model Driven Software Design. 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 most RIMBAA applications.

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

Analysis

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

1. MIF - the code generator has to be aware of the structure of the MIF. MIF is the primary meta model format as used for HL7 version 3.
   • See MIF for a more detailed description, as well as some notes on the current lack of a formal constraint language in HL7 v3.
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, EMF in Eclipse, OWL). The alternate model representation format is a transformation of the MIF.

Overview

MIF based code generation has the benefit that it is based on the normative and full specification of a HL7 v3 model, inclusive of documentation. MIF based code generation has the disadvantage that cross-industry tools can't be used.

The figure below shows some of the functional programming units contained in RIMBAA applications.

The programming units include:

1. Target Model: the payload message type of an interaction.
   • Could be either MIF or DSL
   • Lesson learned (Mohawk, MIF): Preserving all information in MIF into the code generation framework, including documentation, has been shown to be very useful.
   • Lesson learned (Mohawk, DSL): tried to only use business names, but had to switch back to pure RIM semantics. People couldn't understand the business names, no consistent use. Mixture of RIM terms and business names doesn't work. have to do either/or. Ann confirms that UK had similar experience. In other words: either use a DSL (ONLY) or use CIMs. Don't mix them.
2. Vocabulary: vocabulary definitions and CTS services
3. Datatypes: custom library with support for HL7 v3 datatypes R1 and/or R2.
   • 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.
4. Reusable model components: common class models (e.g. CMETs, wrappers)

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.

Alternate representation format

Code generation based on an alternate model representation has the main advantage that one can use off-the-shelve cross-industry tools. One has to take however that all relevant information present in the MIF can be transformed to an expression in the alternate representation. It is not necessarily a requirement that the entire MIF contents be transformed into the alternate representation.

If we look at UML as the prime example of an alternate format: All HL7 concepts can be expressed in UML because of 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. Two profiles are being used: the HDF profile, and a RIM profile that allows the tracking of clones to the RIM, and the class/type and moodCode values for clone classes which are redundant to an audience outside HL7.