Model Interchange Format (version 2.2.0)

The term MIF (Model Interchange Format) is used to refer to two things:

• a set of schemas used to define HL7's artifact meta-model and a format for persisting and exchanging HL7 artifacts
• the various artifact instances published in MIF format

This ballot deals with the former.

The MIF schemas consist of a number of w3c XML Schema files that together define all HL7 v3 artifacts produced by HL7, as well as a few that are not yet produced by HL7. These schemas define public elements for all artifacts that might reasonably be maintained or published independently. They also define complex types, simple types, groups and other schema structures used to fully define the set of content allowed (and required) in HL7 artifacts.

One of the major purposes of the MIF is documentation. Every complex type, element, attribute and other component definition includes descriptive documentation explaining what function that element provides and what type of data it is intended to represent. The documentation also frequently includes the correspondence of the element to the corresponding concept (if any) in the UML meta-model.

In addition to defining the HL7 meta-model, MIF schemas also define the official syntax used by HL7 to publish "computable" [1] representations of HL7 artifacts and is the format recommended for use when exchanging information between HL7 tooling. HL7 makes no commitment about longevity of other formats such as the Access repository used by RoseTree, .HMD files, Visio's .XML files and other formats. However, the organization has committed to maintaining the MIF syntax, including a formal maintenance process for revisions to the MIF format. This process is documented by the Tooling Workgroup and can be found on the HL7 gForge site here

NOTE: MIF is not designed for use in runtime solutions such as terminology services like CTS (Common Terminology Services). Considerations such as performance, scoping, partitioning, etc. have only been taken into account as they impact the HL7 artifact development and publication process. That does not mean that external specifications could not make use of MIF structures if they are found to be appropriate, merely that it is not designed for such use.

The MIF serves two purposes. It documents HL7's version 3 meta-model and therefore forms a part of HL7's methodology documentation. It also defines a formal computational exchange format for HL7 artifacts. The MIF's primary intended audience is internal HL7 constituents, both those who develop tools for HL7 use and for those who are interested in the details of HL7's methodology beyond what is exposed by those tools. However, because the MIF is used as the computational syntax for publishing HL7 artifacts, it may also be of interest to implementers of HL7 standards. Many implementers have chosen to construct applications that load information about HL7 standards from their MIF representation. Because the MIF is more complete than the schema representations, this allows software to take advantage of such information as whether elements are mandatory, vocabulary bindings, etc.

The Model Interchange Format was first developed in 2002 as a replacement for the meta-model found in MDF (Message Development Framework) 99. The effort was undertaken for several reasons:

• The actual metadata associated with artifacts actually being created and maintained had evolved significantly from the metadata documented in MDF 99 specification
• There was recognition that the meta-model would continue to evolve as the organization worked through the experience of designing and implementing HL7 v3 specifications
• There was no "feedback loop" in place to ensure that HL7's existing UML meta-model would be kept up to date as HL7's actual methodology, reflected in the capabilities of tools, evolved
• HL7 tools were persisting artifacts and exporting artifacts in a variety of proprietary formats with no coherence or commonality
• Changes to tooling persistence and exchange formats were uncoordinated and were making it difficult for other organizations to create tooling that leveraged HL7 artifacts.
• There was a growing recognition that several artifacts that had been historically been treated as completely distinct - the RIM (Reference Information Model), RMIMs and HMDs were actually all really one type of artifact with subtle differences in the rules for design and how the artifacts were represented.

The MIF attempted to resolve these issues by combining two functions:

• Documentation of HL7's meta-model; and
• Definition of a format for the persistence and exchange of HL7 artifacts

The logic for this was that HL7's methodology was largely being driven by HL7's custom-maintained tooling. As the organization's requirements changed, these changes were reflected in the tools and thus in the tooling exchange formats. By using MIF to define exchange formats, there would thus be a feedback loop that ensured that the "meta-model" would be kept up-to-date to reflect the reality of the methodology in practice.

The technology chosen for MIF was w3c's XML schema specification. It was selected for several reasons:

• HL7 was an organization that was quite "XML-aware"
• The technology for representation needed to be platform-agnostic and tool agnostic (i.e. not MS Windows-specific or requiring any particular software to parse or use)
• Schema, particularly when supplemented with Schematron, allowed very tight validation of instances to confirm they complied with our meta-model.
• We wanted instances that were human-readable so that tool developers (and on occasion, modelers) could look at the instances and understand what was in them.
• XML instances were very easy to render into other forms, including schemas, HTML, etc. as needed for our publication process using XSLT.

After its initial development, the MIF was subject to peer reviews with participation from MnM, publishing and tooling. It was identified as a core element of HL7's tooling architecture with a declared intention to move to a MIF-centric tooling base. Over the intervening years, all HL7 tools have been converted to either use the MIF directly or have had their custom outputs translated to MIF as part of processing within the V3 generator.

The MIF has undergone several significant revisions since its development.

The change from MIF 1.0.x to 1.1.x included a reduction of the scope of covered artifacts to those actually in use. However, the major change was to 'align' the MIF with UML 1.4. This included modifying the type hierarchy and element and attribute names as well as adding annotations indicating the mapping of the individual elements within the MIF. This was intended to help identify the relationship between HL7 artifacts and UML. It also helped justify the requirement for an HL7-specific meta-model, as less than 1/3 of the classes and attributes had a direct correspondence to the UML meta-model, and many of these were handled in uncommon ways. For example, Value Sets are technically enumerations. However, in practice they are far more sophisticated than the UML enumeration structure can handle.

The change from MIF 1.1.x to 2.1 included a revising the markup to align with XHTML, adding support for additional elements and a significant re-factoring of the representation of vocabulary artifacts. In some places, it simplified element names where the UML alignment created undue complexity and confusion rather than clarity.

The MIF was initially constructed as, and to a certain extent remains, a mixture of "current practice" and "to be" representation of HL7 artifacts. That is, in addition to defining all of the elements and structures presently used by existing HL7 tools and artifacts, it references methodology capabilities that have been identified as requirements and desired capabilities that are not yet supported by HL7 tooling or education. Examples include:

• Support for capturing numeric ranges and enumeration values for static model attributes and datatype properties
• Ability to represent ballot comments within artifacts
• Definition of HL7 v3 conformance profiles

Other MIF aspects reflect methodological decisions that are recognized as desirable but have not yet been rolled out, often due to tooling and/or training issues. Examples include:

• Migration of terminology like RMIM (Refined Message Information Model), DMIM (Domain Message Information Model) and HMD (Hierarchical Message Descriptor) to DIMs (Domain Information Models) and SIMs (Serializable Information Models).
• Replacement of the fixed 3-layer RMIM-HMD-Message Type hierarchy with a variable depth SIM hierarchy
• Migration from a fixed-width identifier scheme to a character-delimited identifier scheme to avoid collisions with locally defined artifacts

Evaluation of the MIF content should therefore include consideration not only of HL7's existing practices, but the practices that the organization intends to adopt.

The MIF can be thought of as a 'companion' to the HL7 Development Framework and the Core Principles documents. The HDF defines the processes that HL7 uses to construct its artifacts and identifies what some of those artifacts are. Core Principles defines additional artifacts and describes some common constructs that require more detailed description. The MIF defines exactly what constitutes a valid artifact - what properties an artifact is allowed to have, what characteristics it must have, constraints on the cardinality and value of those properties, etc. All three must be considered together to fully understand the HL7 v3 methodology. Please note that definitions for artifact elements provided in Core Principles are more complete and detailed and supersede those found in the MIF.

In addition to the major revisions listed above, the MIF has changed on a fairly regular basis in response to new requirements from the methodology and tooling, as well as corrections to content that did not accurately reflect the methodology or intended tooling function. In 2007, the Tooling Workgroup undertook a formal process to maintain the MIF. A gForge project ( http://gforge.hl7.org/gf/project/mif-schemas) was started with accompanying trackers to capture bugs and feature requests for the MIF. It also allows publications of "releases" of the MIF schemas as they are modified over time.

Submitted change requests and defects are reviewed and resolved by the Tooling Workgroup, sometimes in coordination with the necessary domain workgroup (MnM, Publishing and/or Vocabulary). The changes resulting from approved submissions are collected into releases that are coordinated with updates to major HL7 tools. These occur with varying frequency from as little as every month to half a year or more.

Due to the dynamic nature of HL7's methodology and tooling requirements, the MIF will continue to evolve in much the same manner, even after it has completed ballot. Ballot approval will work in much the same way for the MIF as it currently does for the RIM, where harmonization changes occur multiple times per year, but the MIF itself is only balloted on a yearly basis. Whether balloting of the MIF will be annual or bi-annual has not yet been determined. However, once passed, HL7 will publish its normative editions using both the "normative" version of the MIF in effect at the time as well as the "most current release" of the MIF so that tooling vendors can make use of a more stable platform if required.

Beginning with release 2.1.4 of the MIF, transforms have been developed and included with the HL7 V3 Generator which support transforming between the new version of the MIF and the immediately preceding version. These transforms simplify the process for implementers of tooling which might internally support only one version of the MIF, but will externally need to process multiple versions.

As part of HL7's intellectual property, the MIF schemas are both copyrighted and maintained under HL7 license. That means that the full schemas are distributed under the terms of members only content. I.e. Only members of HL7 or its affiliates may access the full schemas, with special rules applying to benefactors, educational institutions and other membership categories as per HL7's GOM ( link). However, MIF also publishes a trimmed down Eclipse Public License version of the schemas for situations where applications require the use of the MIF schemas for function. For example, code generators, MIF instance validators, etc. This stripped down version excludes all of the comments, descriptions and UML mappings content but retains all structures, enumerations and other information required to validate instances.

As mentioned, HL7's original meta-model was included in MDF99. The Tooling Workgroup sponsored the creation of a UML profile based on the MIF. However, this was limited to a "proof of concept" that was limited in scope to static models and was not complete. At present, there is no official source for HL7 metadata information other than the MIF.

The MIF will continue to evolve with HL7's methodology. The dynamic model and likely the requirements model will likely be revamped as the artifacts defined by the SAIF (Services Aware Interoperability Framework) process are finalized. Some of the 'alpha' artifacts such as conformance profiles and elements to support template authoring may migrate to beta or production. Minor changes in other artifacts will continue to be made as HL7's methodology continues to change.

With the pending release of the XML Schema 1.1 specification, there is a potential for revamping the MIF schema representation to provide a more thorough validation syntax. New capabilities within Schema 1.1 may allow migration of some or all of the Schematron rules to incorporation directly within Schema. It may even permit elimination some of the "software-only" validation rules.

A more significant change may come through alignment with OMG (Object Management Group) technologies. This includes the potential of migrating from MIF to XMI, OWL or some other technology (or combination of technologies) maintained by OMG. As described below in the MIF requirements section, the formal documentation of MIF requirements was initiated as part of a joint project to help identify HL7 requirements that might be incorporated into future releases. Should HL7's needs be satisfied by off-the-shelf products, the need for a custom meta-model and validation representation might be eliminated.

As mentioned in the Background section, the MIF includes global element definitions for artifacts that might be published or released independently. Any one of these global elements might be the 'root' element in a MIF instance file. The following table provides a list of all of the global elements defined by MIF and identifies the schema in which these elements are defined. It also provides a 'status' and a description of the purpose of each element.

The 'status' indicates the level of use (and therefore the level of confidence) the HL7 Tooling Workgroup has in the MIF content of a given element. All content within the MIF has at least an "in principle" endorsement as part of the methodology, however not all endorsed aspects are presently in use. The statuses, and their corresponding meaning, are as follows:

Alpha: Indicates content that is not presently used by any tooling or manual artifact development and is therefore still theoretical. Its design may be based on existing tooling, but none of that tooling currently produces or consumes MIF. Alpha elements could change radically or be removed over time or they could be adopted by newer versions of tooling.

Beta: Indicates content that is in use by a single tool or as part of limited manual artifact creation, but has not been used by other tools and has not necessarily been broadly exercised. Beta elements are unlikely to go away, but may undergo significant change as they become more widely adopted.

Production: This content has been in use by HL7 and been represented in MIF form for a considerable period. It is usually supported by multiple tools. The content continues to evolve with changes in methodology and new requirements and features, but the core structures are stable and unlikely to change.

Testing: These elements are not really intended to be the root element of MIF instances. Instead, they exist for internal use by tools to allow validation of fragments of an artifact. They should be considered to have the same stability as Production elements.

The description of each element is a high-level description only. More rigorous definitions can be found in the HDF, Core Principles and the MIF itself.

The content of the MIF is broken up across a number of separate files to give some sense of organization and modularity. For example, the enumerations used by various MIF artifacts are maintained in one file, the simple type definitions (e.g. "short descriptive name") are maintained in a different file. Some of these 'modules' have dependencies on other modules. In a schema sense, that means the dependent schemas 'include' the contents of the schemas they are dependent on. The following diagram shows these dependencies and highlights the stability status associated with each schema file. The color coding groups the various schema files into categories based on their purpose. For example, the purple boxes deal with markup for rendering text while the yellow boxes represent schemas used to support static models.

Figure 1 - MIF Schema Hierarchy

A brief description of the content of each of the schema files can be found in the following table:

One of the purposes of the MIF schemas is to allow validation of HL7 v3 artifact instances to confirm that the artifacts respect all of the methodology rules defined by HL7. Because of this requirement, MIF schemas are defined extremely tightly. In some cases, constraints are included for interoperability and tooling reasons rather than strict methodology requirements. For example, length limits on class names and other properties are driven by a desire to ensure readability in diagrams and other renderings as well as interoperability between tools sharing artifact instances.

Because of limitations in different XML validation technologies, the validation rules are captured in three [2] different ways:

The MIF schemas follow a number of conventions [3] intended to enhance readability and the ability to generate software interfaces from the schemas. Specific conventions include:

The MIF includes constructs that appear in many places and may be a bit confusing to those not familiar with some of the underlying mechanics of HL7's methodology. This section describes and explains those constructs to allow for easier interpretation of MIF contents.

MIF instances used and published by HL7 come with a variety of different file extensions. There is no intrinsic requirement for distinct file extensions as any MIF instance is self-descriptive. All MIF files could just be labeled ".mif". However, because it is useful for quickly separating files of different types and because of a need to avoid collisions when using the v3 generator, a number of distinct file extensions have been adopted. The use of each file extension is documented in the following table:

MIF instances are represented in XML and use the namespace urn:hl7-org:v3/mif2. The original version of the MIF used the namespace urn:hl7-org:v3/mif. If in the future there is a significant re-design of the MIF, it is possible that the namespace will change again. However, all minor revisions to the MIF will retain the same namespace and will make use of the schemaVersion attribute to distinguish what version of the MIF schemas a given instance is compliant with.

As a supplement to the MIF schemas themselves, this package includes a set of documentation reflecting the methodology requirements that have driven the existing MIF structures. This documentation is a snapshot of the requirements documentation maintained on the HL7 wiki at http://wiki.hl7.org/index.php?title=Category:V3_Methodology_Requirements. While the documentation embedded in the MIF schemas does a (relatively) good job of identifying what each structure is for, how it should be used and the rules that surround validation of instances, it does not do a good job of documenting the "why" behind each element.

HL7 has recently been in discussions with the OMG around the potential application of OMG technologies such as UML and OWL to HL7 requirements. The lack of a clear rationale behind each element in the existing meta-model was a clear deficiency. The OMG and HL7 therefore undertook a joint project to capture the underlying requirements and rationale supporting each element.

The requirements documentation is organized into a number of sections dealing with different "levels" of requirements and different categories of artifacts. Each requirement is accompanied by a supporting rationale and either a description of the HL7 methodological approach(es) used to solve the problem and/or an identification of the MIF elements that satisfy the requirement.

Requirements have only been included for the MIF schemas that have reached "beta" or "production" stability levels. However, in some cases additional MIF elements that are not in active use have been captured because of the desire to see their support in OMG technologies. These have been flagged as "not currently used".

The MIF requirements can be found on the wiki here. A snapshot PDF is also provided here for those who would like to navigate a static view of the requirements or wish to review a local copy. (The rendering of the PDF is not perfect, so using the wiki might make the content slightly easier to read.)

This format contains the raw MIF schemas. This is the "source" for the remaining views. The schemas are provided in a zip file that can be downloaded and unzipped. The schemas are accompanied by supporting DTD files that are needed for validation with some tools. While the schemas can be browsed using any text editor, they will be most easily viewed using tools specifically designed to navigate schema files, managing inheritance, imports and similar functions. For example, XML Spy.

The MIF schemas can be found here. The 'trimmed' schemas can be found here

This format exposes the MIF schemas as HTML with color formatting. It is useful to see the actual content of the schemas if you do not have a tool for navigating the raw schemas. Because it is a direct rendering of the schema XML, this view exposes all information.

The rendered schemas can be found here. (Here for trimmed schemas.)

This format includes a rendered view of the schemas generated using the XML Spy tool. It includes diagrams of the schema content as well descriptive information. It provides a complete representation of the MIF content, excluding XML comments. (NOTE: It also appears to contain hyperlinks to the underlying schemas. These links are invalid, but cannot be omitted due to a bug in the tool.)

The XML Spy view can be found here. (Here for trimmed XML Spy view.)

This view is generated using a tool called DocFlex/XML that produces a Java-doc like set of HTML documentation of a set of schemas. Like the XML Spy view, this view does not include content from XML comments.

The Java doc view can be found here. (Here for trimmed Java doc view.)

Dave Carlson has developed a tool called Hypermodel for converting schema content into UML. He has kindly used this tool to produce a UML rendering of the MIF schemas. The UML view is available as an XMI 2.1 file that can be imported into the UML tool of your choice for exploration. As well, an HTML rendering has been produced using the documentation capabilities of Enterprise Architect.

Keep in mind that the UML rendering is auto-generated so the layout of classes may not be optimal. As well, the use of attribute and element groups in the schemas for re-use purposes causes the types for some UML objects to appear a bit different from how one would typically represent the content. Finally, the UML rendering only includes the first descriptive annotation and excludes XML comments, so some rules will not be exposed, nor will deprecated items be flagged.

Note: The UML generated here is not recommended for use in code generation and is not supported by HL7 at this time.

The XMI files can be retrieved here.

The HTML rendering of the UML content can be found here: here. (Here for trimmed UML HTML.)

Note: The HTML rendering requires Javascript to be enabled