Vocabulary Model Artifact Definition

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

Row(s)

• Level-Independent

Column(s)

• Information

Audience

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.

Applicability

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.

Requirements, Relationships and Content

1. The Vocabulary Model is intended to assist in packaging and managing the myriad component artifacts needed to satisfy the constraints on encoded elements in a particular set of information models and/or data types models.
   1. Rationale Encoded information model and data types model elements have a mandatory binding to one or more terminology artifacts that are contained in a vocabulary model. In turn those information models and data types models have a required relationship to the Vocabulary Model that contains the needed artifacts.
2. A statement 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.

Relationships and traceability

• 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:

  • Concept Domains
  • Code Systems
  • Value Sets
  • Context Bindings
  • Code System Supplements and
  • Code Translations

  Rationale: Satisfy requirements

Artifact types that may or must relate to this artifact types - Vocabulary Models are imported as part of the definition of each information model and each data types model in the SAIF therefore the following artifacts MUST relate to a Vocabulary model:

• Conceptual Information Model
• Conceptual Data Types Model
• Abstract Data Types
• Reference Information Model
• Domain Information Model
• Serializable Information Model
• Loose Information Model
• Simplified Information Model
• Data Types Implementation Technology Specification
• Semantic Profile

  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.

Content

Each of the following is a SAIF Artifact in its own right, but is packaged as a sub-artifact of a Vocabulary Model

• Concept Domains
• Code Systems
• Value Sets
• Context Bindings
• Code System Supplements and
• Code Translations

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 or define those constraints.

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 "design 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 "design repository"

Rationale

• '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

Alternatives

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

Content Constraints

There are no content constraints included here. The "core" definitions and constraints are documented as part of the artifact definitions for:

• Concept Domains

• Code Systems

• Value Sets

• Context Bindings

• Code System Supplements and

• Code Translations

Content Guidelines

1. The primary rules for change proposal submission include many guidelines or style guides. They are documented in:
   • Instructions in the Harmonization Proposal Submission Template
2. Guidelines for some Vocabulary artifacts can also be found 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.

Governance Process Considerations

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. Primary rules for submission are documented in:
   • Instructions in the Harmonization Proposal Submission Template

   • Rules and principles of the HL7 Vocabulary and RIM Harmonization Process