Ringholm-Logo Ringholm
Ringholm page header
Training    |   Whitepapers    Blog    Events    Links   |   About us    Partners    Clients    Contact

The HL7 MIF - Model Interchange Format

This whitepaper is published under the Creative Commons Attribution-Non-commercial license.
See http://www.ringholm.com/docs/03060_en_HL7_MIF.htm for the latest version of this document.
Authors: Rene Spronk, Sr. Consultant, Ringholm.
Document status: Draft, version 1.1 (2010-02-03)
Please send questions and comments to rene.spronk@ringholm.com.


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. It is the pre-publication format of HL7 v3 artefacts used by tooling. It is also the formal definition of the HL7 metamodel. The MIF can be transformed into derived forms such as UML/XMI or OWL.

1. Introduction

Implementers of HL7 version 3 increasingly hear about 'the MIF', mostly in the context of tooling. This paper seeks to answer some basic questions related to the MIF: what is it? What purpose does it serve? How does it relate to XMI and OWL? Why does HL7 use its own metadata format, why not use UML?

2. Model Interchange Format (MIF)

The formal specification and documentation of all HL7 v3 artefacts is stored in a model repository. The Model Interchange Format (MIF) is a set of XML formats used to support the storage and exchange of artefacts as part of the the HL7 version 3 development process (as defined in the HL7 Development Framework, the HDF). It also encodes the validation rules around what constitutes valid HL7 v3 artefacts and provides documentation of what the semantics of the different parts of an HL7 v3 artifact are.

The following structures (amongst other things) are documented by the MIF:

  • Requirements-analysis related structures: including the Domain Analysis Model (DAM), glossary, and storyboards.
  • Static model related structures: RIM-derived static models, and serializations thereof.
  • Dynamic model related structures: includes the Trigger Event, interaction, and Application Roles.
  • Infrastructure related structures: including data types, and vocabulary
  • Structures related to testing: defines test cases for HL7 interactions and documents.
  • Conformance-related HL7 structures: includes the conformance profile, and interaction profiles.
  • Publication related structures: for representing publications such as implementation guides, ballots and normative editions.

MIF files exist to support tooling - tools exist to write it, tools exist to use it (e.g. code generation, message validation, publishing) as well as to provide documentation of HL7 methodology. The MIF effectively is a pre-publication form of how HL7 stores its own data. HL7 tools (e.g. the Eclipse instance editor, the XML schema generator) are based on MIFs. The v3 standards publication (in HTML) as well as the XML schema are generated from the MIF files.

"No human should ever see MIF, except for programmers, and those aren't human anyway", to quote Grahame Grieve, one of the HL7 toolsmiths, "it should be kept in the background as an HL7-only thing for use by HL7 tools".

HL7 has gone through a lot of work to create a single unified metamodel (expressed in MIF) that spans all of its artifacts. The metamodel is maintained and under the sole control of HL7. The metamodel represents all HL7 artifacts in a consistent fashion. There will always be a "newer" and "better" technology out there, but there is currently no alternative metamodel representation that covers all of HL7's metamodel. To use distinct solutions for static models (e.g. UML), dynamic models, vocabulary (e.g. OWL) , datatypes, conformance profiles, etc. makes no sense and has caused significant grief in the past. Hence the decision by HL7 to use its own expression of its metamodel in MIF.

3. Derived forms

The MIF format can be transformed into UML, XMI, OWL, Docbook, DITA and other valid forms. When MIF is transformed to other forms some of the v3-specific details may/will be 'lost in translation'. To ensure compatibility with other tools, any tool that uses a derived form would need to be able to convert artefacts to and from MIF format.

Diagram whish shows relationship between MIF and derived forms

The requirement to create a derived form is especially of value for implementers that use off the shelf tooling.


XMI is OMG's XML-based standard format for serialising MOF based models including UML (anything that can be expressed as in terms of MOF can be serialized as XMI). XMI can, in theory, express anything, given that one can add new tags, including complex object tags, to ones heart's content.

XMI can be used to encompass all aspects of HL7 artefacts, including a large variety that have direct no correspondence in UML, including vocabulary domains, coding strength, documents, publications, etc. HL7 has defined UML profiles that contain stereotypes for any HL7-specific extensions.

Once the MIF has been imported into UML one can use UML tools for such things as dynamic modelling, service specifications, business process modelling, whilst using/referencing the HL7 v3 static model. Few UML tools would however know what to do with the v3 specific XMI elements. There are a number of ongoing projects to extend standard tools with such capabilities.

3.2 OWL

In terms of OWL, there are two options in mapping:
  1. Define a mapping from the existing MIF structures to OWL for the vocabulary portion only. This probably makes sense given that OWL is very well suited to express this kind of information.
  2. Convert the entire MIF to OWL. There's ongoing discussion within the implementer community if one can express all of the contents of MIF in OWL.

3.3 HL7 API

The core HL7 artefacts (Data types, Vocabulary, the RIM) are also expressed in MIF. Because of this, the MIF is the closest thing to an HL7 API. Programmers should ideally have access to an API they can leverage in order to use (manipulate, build, etc) HL7 models without worrying about the underlaying serialization format. The API could be generated by means of MIF-based code generation.

Examples of open source tools that support MIF (or alternative format) based code generation:

  • The MARC-HI Everest (Note: this website is subject to frequent timouts) is a MIF based API generator for .net. The Everest tool is very well integrated into Visual Studio.
  • The JavaSig API has a MIF-based Java API. The API are still very low-level and most of the time they resemble the structure of the MIF as opposed to higher-level concepts (e.g. classes, associations, attributes).
  • The Eclipse OHT tools use Ecore models (EMF, the Eclipse UML dialect) as a derived format. An Ecore model can be easily edited, annotated and discussed in standard object oriented terms; it can be used to generate Java (or other) implementations; it can be transformed to other formats such as the MIF. In terms of the Technology Matrix (a reference model for applications that use the RIM as their core data model) the Ecore model is a perfect fit for the MO/RO cells; the persistence and presentation models can be directly generated and further customized.

4. Summary

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. It is the pre-publication format of HL7 v3 artefacts used by tooling. It is also the formal definition of the HL7 metamodel.

5. See also

About Ringholm bv

Ringholm bv is a group of European experts in the field of messaging standards and systems integration in healthcare IT. We provide the industry's most advanced training courses and consulting on healthcare information exchange standards.
See http://www.ringholm.com or call +31 33 7 630 636 for additional information.