RMIM Designer Documentation (Vocabulary MIF)

Introduction

Release 4.4.0 of the HL7 RMIM Designer (in Visio) was the first release to use a vocabulary "core MIF" file as its source for Vocabulary content. The "core MIF" files (with names like DEFN=UV=VO=822-20090227.coremif) have been released along with the Design Repository in every design repository release since September 2008.

Note: It is recommended that this tool only be used on machines with at least 1 GB of memory, because the in-memory vocabulary content is large.

In the past, you the designer presented a "drop-down" that displayed a tree view of vocabulary content that was actually in mixed-mode - it combined concept domains, value sets and code systems into a single hierarchical display. This comkbined display was replaced because it was introducing confusion (and errors) and because it was constraining the ability to create a "clean", correct vocabulary model.

The new release opens a new "modal" window pane that displays vocabulary content as three independent tree views - one each for concept domains, code systems and value sets.

Features of the selection pane are:

Independent tree views for the three types of vocabulary content;
Tree views may be tiled side-by-side (default) or displayed singly on a "Tab" control;
When opened, tree views are constrained to the relevant sub-set of content (such as ActClass when selecting a class code for an Act clone);
When opened, the "selected" constraint in the pane is set to the previous constraint from the source model;
Search capability to find content in the vocabulary (uses a case-insensitive search on descriptive text, names and identifiers of vocabulary content);
Text descriptions for an element selected in a tree view may be called up for display;
"Current" selection box shows what is the current (most-recent) selection;
"Help" display summarizes the function of each button on the pane;
In addition to mouse control, "Enter" key and "Esc" key will close the pane and either return a constraint (or nothing for "Esc")

These features and their use are discussed in the following sections.

Jump to top of page

Loading RIM and Vocabulary Content

Model Selection Window

The Model Selection window was modified to allow selection of both a Design Repository file ("mdb" file) and a Vocabulary MIF file (either "coremif" or "mif" file extension.) Since September of 2008, all RIM Repository distribution have included a vocabulary "core"mif file (with names like DEFN=UV=VO=822-20090227.coremif) as part of the distribution. In both RoseTree and the new RMIM Designer releases, the associated vocabulary "coremif" file will be loaded unless the user over-rides that selection.

The simplest way to use the latest RMIM Designers is to place a copy of the design repository from the Design Repository Project on Gforge along with its associated vocabulary file in some convenient directory, perhaps the Visio solutions HL7 directory, and then start the RMIM Designer in the usual fashion.

The first pane to appear will be the Model Selection pane (right-above). This pane now includes tweo selectioln boxes. One for the Repository file and the other for the "Vocab MIF" file. You do not need to select the latter file. If it has not been selected, the RMIM Designer will look for the correct file to associate with the repository and will use that, if one is found. (It will seek your permission before using the found file.) If it cannot find a file, it will prompt you to select one. It is not possible to run the RMIM Designer without a vocabulary mif file available.

Jump to top of page

Selecting Vocabulary Constraints

Clone Editor - Properties Pane

Vocabulary constraints for RIM attributes are established in one of two ways in the RMIM designer. Both methods are done within the HL7 Class Refinement Editor as seen at right and below. This editor has two panels selected by a tab control

The Properties tab is where the typeCode, classCode, moodCode, etc. are selected. The vocabulary constraints for doing this are circled in the first of the three panes at the right. The process of constraining these properties is initiated by either clicking on the associated "Browse" button, or by double-clicking on the text box that displays the constraint.

The remaining vocabulary constraints are established in the Attributes tab, as seen in the second of the panes to the right. For each coded attribute, there are three "controls" a selection box for the kind of constraint, the text field that displays the constraint, and a "Browse" button. The vocabulary selector/browser can be started by either clicking the associated "Browse" button, or by double-clicking the text field.

NOTE: Although the constraint type box may be changed by clicking on it, its value will always be correctly set by choosing a constraint in the browser, and thus this control is best treated as a display-only control.

Finally, in selected cases it may be reasonable to set a "fixed" or "default" value constraint on an attribute. (This can only be done with attributes whose data type is CS in the RIM, or has been constrained to CV in the static model design. When such constraints are established, a second row of vocabulary constraints that includes a code value and a code browser button are added to the Attributes tab display, as in the third pane at right.

Jump to top of page

Clone Editor - Arttributes Pane

Proper Constraints by Attribute Kind

The HL7 methodology specifies varying constraint expressions for the different kinds of attributes found in the HL7 Reference Information Model (RIM) and in static models derived from the RIM. Moreover, the appropriate form of constraint is different for a "universal" (UV) design or constraint than it would be for an implementation-level constraint. Simply stated, at the "UV" level constraints (with the exception of structural attributes) should be abstractions or generalizations that permit realms, projects and implementers to refine these further in order to meet the requirements of their particular design.

The following sub-sections provide an informative overview of these principles to help guide model designers. The formal "rules" are embedded in other documents.

Structural Attribute Constraints - classCode, typeCode, moodCode, and determinerCode

The so-called "structural attributes" are those attributes in the RIM that encode design content that might otherwise have been part of the model structure. For example, a class code represents an sub-type enumeration that might have been represented as a physical class in the RIM, but was not because while it had unique meaning, it did not require unique attributes or associations.

There are a total of eight structural attributes in the RIM - the classCode attributes for each of the Act, Role and Entity classes; the typeCode attributes for the ActRelationship, Participation and RoleLink classes; the moodCode attribute for the Act class; and the determinerCode attribute for the Entity class. The constraints for these attributes are unique in that they:

are bound to the Code System that supports them, including a value set binding to "all codes" for the RIM concept domain constraint;
are selected from the Properties tab of the Clone Editor rather than the attributes tab;
are usually displayed in the model as code values, with symbols to indicate a fixed value or a hierarchy;
usually do not have value set constraints, except for enumerated "x_" value sets; and
commonly replace their RIM Concept Domain Constraint with either a code or value set.

Governing Principles

In November 2007, M&M and Vocabulary committee agreed on the following principles for defining these constraints and for managing the vocabulary content for these attributes:

For each coded concept in the appropriate code system, define a value set that has that code as its "head code" and includes that code and all of that code's specialized descendants in the value set. Thus a constraint that appears to be a code constraint is actually short hand for a constraint to a predefined value set.
Provide enumerated value sets, where needed, to accomodate constraints that do not align with a logical hierarchy of the code system; and
Limit the concept domains for these attributes to a single concept domain that represents the RIM constraint and is bound in the universal realm to the appropriate code system - usually "all codes" of the supporting code system.

Selecting Structural Constraints

Thus when selecting constraints for these attributes users should:

Expect code constraints to be the dominant constraint in universal designs;
Occasionally use an enumerated value set; and
Never use a concept domain constraint other than the one asserted in the RIM.

Jump to top of page

Clone Editor - Attributes Pane for Fixed/Default

Other Attributes with CS Data Type in RIM

In addition to the eight structural attributes there are another thirty or so RIM attributes whose data type is CS. By the data type definition, these attributes are constrained in the RIM to values drawn from a single code system that can only be extended through harmonization or ballot. The principles for vocabulary content management (stated above) apply to these attributes as well.

However these decisions have a slightly different impact since the representation of these constraints in the RMIM iconography does not dominantly depend on a code value. Tius means that in most cases, the user will wish to select a value set as the primary constraint, rather than a code.

Selecting Other CS Constraints

Thus when selecting constraints for these attributes users should:

Value set constraints to be the dominant constraint in universal designs; and
Never use a concept domain constraint other than the one asserted in the RIM.

Other Attributes Constrained to Data Type CV

Occasionally, universal designs may involve an attribute that has been constrained to the CV data type, and for which there exists a universal binding of some concept domain to a particular value set (and code system). In those cases, it may be reasonable to assert a fixed or default code value as a constraint.

All Other Attributes

As a general rule all other attributes in universal designs should be constrained to a Concept Domain. Absent a universal context binding, all such attributes should retain the generality provided by a concept domain constraint.

Jump to top of page