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

Model Interchange Format

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

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

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.
  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
  5. See OCL.

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>