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. Multiple MIF versions co-exist. Versions may be incompatible (i.e. 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 either use a MIF-version-transform (published by HL7), or create new MIFs from the original HMDs.
   • The MIF format is versioned to allow it to keep up with changes in the modeling methodology.
     • The modeling material is "relatively" stable and has been for the last 5+ years. However it does, and needs to, continue to evolve. New structural codes are introduced. Corrections are made to old ones. On occasion, more significant changes are made to fix things that are either seriously broken or are causing issues for implementers. The most recent of these would be the changes to context conduction agreed at the last harmonization meeting. In addition to changes to the RIM and vocabulary, we occasionally change datatypes and also revise wrappers and CMETs. Even the ITS may change from time to time. All of these things are "infrastructure" that our other v3 specifications rely on.
     • To not change any of them would put us back in the permanent backward compatibility world of v2 which left the standard hamstrung and unwieldy. It would be even worse in an object-based standard like v3.
     • Changes are not made willy-nilly. Those participating in the harmonization process definitely consider impacts on existing specifications (because most of those around the table are those who are going to have to revise those specifications). And there's a second round of approval process through the HL7 ballot process which now happens for the RIM and structural vocabulary on an annual basis.
     • Implementers can, should and do standardize on a particular version of the "infrastructure" (and MIF) when they implement. Someone who rolled out lab or patient registry a year ago is not going to switch to the new context conduction approach or new datatypes just because they're available. They'll consider migrating the next time there's a major change. In the meantime, if they need to inter-operate with a system that has adopted a newer version of the infrastructure they'll need to use transforms to do it. In many ways, this isn't that different from what we had in v2. The only major change is there's no guarantee of wire format interoperability.
     • In any event, the harmonization process and the documentation of constraints in the RIM and structural vocabulary is existing HL7 methodology and has been since the inception of v3.
   • 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
   • 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 . . .)
2. 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.
3. 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>