This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

MIF based code generation

From HL7Wiki
Revision as of 12:56, 15 February 2010 by Rene spronk (talk | contribs) (→‎Details)
Jump to navigation Jump to search

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.

Details

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 code gen.JPG

  • 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.
  • Lesson learned: Preserve all information in MIF into the framework, including documentation.
  • Lesson learned: 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.

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.

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

Discussion