This wiki has undergone a migration to Confluence found Here

Vocabulary Model Artifact Definition

From HL7Wiki
Jump to navigation Jump to search

Return to Artifact List

Vocabulary Model

Definition and Purpose

A package or release of a set of vocabulary artifacts drawn from - Concept Domains, Code Systems, Value Sets, Context Bindings, Code System Supplements, and Code Translations - assembled to meet a particular set of needs. A Vocabulary Model may be published at a Universal or realm level.

SAIF Matrix Location


  • Level-Independent


  • Information


Health Care Information Technology (IT) Audiences:

  • System designers and architects
  • Programmers/implementers

A vocabulary model will be needed for any SAIF project that is defining or publishing an information model. Thus it is applicable to all technology implementation audiences.


A Vocabulary Model is needed to support and document the terminology constraints of any information model and/or data types model. Therefore a Vocabulary Model must exist for any project at any level (Row) of the SAIF.

Rationale: The source for the terminology constraints for and information model is one or more "Vocabulary Model(s)" that the information model "includes."

There will be one Vocabulary Model at the "universal" level, and may be one Vocabulary Model defined for each affiliate realm.

Rationale: The "universal" model expresses the code systems, concept domains and value sets defined for universal use, including those value sets that must be used in all realms owing to there being a "universal" binding. Similarly, the realm-specific Vocabulary Model expresses the further code systems, etc. defined for realm-specific use.


  1. An expression of the purpose that determines the contents that make up this particular Vocabulary Model.
    1. Rationale A vocabulary model may include a single sub-artifact, such as a Concept domain, or it may include all of the sub-artifacts that HL7 manages. The selection criteria or requirements must be expressed in text.
  2. Contain one or more sub-artifacts from the following artifact definitions:
    1. Rationale A Vocabulary Model supports the individual terminology constraints of the attributes of a particular information model, and of the data types model that is included in that model. Therefore, it must have one or more of the above sub-artifacts to support ir define those constraints.

Relationships and traceability

  • One or more Vocabulary Models are imported as part of the definition of each information model and each data types model in the SAIF.
    • Rationale: A Vocabulary Model supports the individual terminology constraints of the attributes of a particular information model, and supports the terminology constraints of the data type components in a data types model.
  • A vocabulary model may replace or be replacedBy one or more other vocabulary models
    • Rationale: In serial publication of vocabulary models this provides the traceability between sets of vocabulary models wherein one may supercede another.
  • A vocabulary model may dependOn one or more other vocabulary models
    • Rationale: Provides a means for combining (including) content from multiple vocabulary models into a single grouping.
  • A vocabulary model may contain one or more of each of the following artifacts:
    • Rationale: Satisfy requirements

Artifact Technology

Technology as of January, 2011

  • Individual contents of a Vocabulary Model (code systems, value sets, etc.) are:
    • Maintained in tables of an Access Data Base in a "repository"
    • Updated by Java-based software driven from XML source files in the HL7-defined Vocabulary Maintenance Language (VML)
    • Selected content in Access that cannot be changed via VML is added through manual entries and queries into the Access tables (about 10% of all change entries).
    • Extracted from the Access "repository" and processed into an XML file in the Model Interchange Format (MIF) by RoseTree, a Visual Basic application that runs in the Windows environment.
    • Additional Value Set definitions and context bindings that cannot be represented in the "repository" because the underlying code system is not maintained by HL7, are managed in a supplemental MIF file that is then merged (using XSLT transforms) into the released version.
  • Distribution of Vocabulary Models:
    • All distributions are made on Gforge
    • Primary distribution: is via MIF files. (XML files in MIF format.)
    • Secondary distribution: is via the Access "repository"


  • 'Cause that's what we've got and absent funding for a replacement/upgrade, that's what we use
  • It's good enough to limp along with


Preferred strategies have been mapped out, but have not advanced for lack of resources.

Content Constraints

  1. All Vocabulary content that is maintained and Published for the universal realm SHALL be adopted through the HL7 Vocabulary and RIM Harmonization Process.
    1. Rationale: Established governance
  2. There are no further content constraints included here. The "core" definitions are documented as part of the artifact definitions for:

Content Guidelines

  1. Primary rules for submission are documented in:
  2. Guidelines for some Vocabulary artifacts are in the Wiki Style Guides Category

Publishing Representation(s)

  1. As noted above, the primary distribution is via MIF files. That are read by all commonly used HL7 tools
    1. Rationale: Hl7's preferred distribution of processable files is MIF
  2. Publication of Vocabulary content is presented in sets of HTML files generated by a single transform against the content in the vocabulary core MIF files.
    1. Rationale: HL7's preferred publication is HTML from MIF files, so we did it that way.

Publishing Constraints

None of which I am aware.

Tooling Considerations

We need a RICH GUI interface to a tool that understands the yin/yang of terminology and makes it easy to request AND understand complex relationships that they represent. To quote Jimmy Buffett:

Now here comes the big ones.
Relationships! We all got 'em, we all want 'em. What do we do with 'em?

At present we have a very rich set of relationships that can be expressed and maintained in MIF files, but the only way to take full advantage is through manual editing of MIF files. The current tools only deal with the simpler relations.