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, and XML Schema). 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 model one needs to support. For HL7 version 3 interactions this is the payload message type.
   • Could be either MIF or DSL. Mohawk and the NHS have tried to use a mixture of both -with the DSL based on business names of the classes-, but users found the mixture to be too confusing. One should either opt to use HL7 version 3 models or one should use a DSL (to hide the complexity of HL7 v3 models).
   • Mohawk recommends that one preserves all information in MIF into the code generation framework, including documentation. The documentation as present in the MIF is of help when using the generated code, and it can be used to create documentation (e.g. of the API) as well.
2. Vocabulary: the management of vocabulary definitions and terminology services. This could be a third party terminology server, or a terminology manager with a HL7 CTS API.
3. Data types: a custom library with support for HL7 v3 data types R1 and/or R2.
   • Currently there is no usable data types MIF file. A library to support the v3 data types 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 specialization of identified-confirmable, which in turn is a psecialization of thye universal flavour of the CMET.

Serialization

The generated code allows one to create object graphs that conform to one or more CIMs/LIMs. The serialization and encoding are ITS specific. For example: the serialization and deserialization of XML-encoded HL7 v3 objects depends on the ITS used, either the XML ITS or the RIM ITS.

The actual encoding and decoding in XML is taken care of by the generated code. This has the advantage that as a programmer one doesn't have to worry about XML at all - one only has to deal with the object representation within an Object Oriented framework.

Alternate representation formats

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.

The XML schema (notably: the XML ITS schema as shipped with the publication) effectively also represents an alternate format representation. The transformation from MIF to XML schema is lossy in nature. See schema based code generation for details.