Model Interchange Format

Glossary definition: The Model Interchange Format (MIF) is a set of XML formats used to support the storage and exchange of HL7 version 3 artefacts as part of the HL7 Development Framework (HDF). It is the pre-publication format of HL7 v3 artefacts used by tooling. The formats are defined by a set inter-related schemas. The MIF serves to document the HL7 metamodel, identifying all data elements of interest to version 3, as well as indicating correspondance to the UML meta-model.

The MIF makes use of schema constructs including simple type patterns, the use of choice and sequence structures as well as cardinality and attribute use to reflect HL7 requirements as tightly as possible. In some cases, w3c schema is not capable of expressing the rules required by HL7. In these cases, the rules are either encoded as embedded Schematron rules or by listing them as “programmatic” rules at the beginning of the schema. Instances must comply with the Schema, Schematron and programmatic rules to be considered HL7-compliant instances.

The definition of the MIF is a task of the Tooling Work Group. The MIF files are contained in the v3 publications. Comments can be submitted to the HL7 Tooling list or Lloyd McKenzie.

External links

• See MIF Whitepaper (with embedded Video explanation of the MIF).
• See MIF to UML mapping issues
• The released coremifs and (annotated) schema's can be found at [1] and at [2].
• See also Category:V3 Methodology Requirements, which acts as additional documentation of the MIF format.

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.
   • (January 2010) Lloyd is currently working on a MIF 2.1.4 <-> 2.1.3 transform. There should be existing transforms to go 2.1.4 <-> 2.1.5 and 2.1.5 <-> 2.1.6. Lloyd: The plan is to plug other transforms into the set as new releases are produced. (And if anyone feels like it, we can push back to 2.1.2 and earlier too . . .)
   • Hisotically, each Normative Edition is based on a particular MIF version: NE2007 is based on vX; NE2008 is based on vX; NE2009 uses 2.1.6, and NE2010 will probably be based on 2.1.6
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.
   • Ravi: The SMD roadmap supports this (authoring and validating OCL constraints) and at the moment (February 2010) we have hooks to capture them. We are currently not persisting them for further validation.
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

Example:

<mif:annotations>
        <mif:appInfo>
          <mif:formalConstraint>
            <mif:body>Some OCL goes here</mif:body>
            <mif:text>
              <mif:p>Textual expression goes here</mif:p>
            </mif:text>
          </mif:formalConstraint>
        </mif:appInfo>
      </mif:annotations>