Reference Information Model Artifact Definition

Return to Artifact List

Reference Information Model (RIM)

Definition and Purpose

The HL7 Reference Information Model (RIM) is single artifact that is the foundation from which all V3 and SAIF logical and implementable information models SHALL be derived. It serves to unify the information content of HL7 V3 standards, affording more consistent representation of models and simpler implementation of models from multiple topics. The RIM is a class model that includes the state machines, associations and attributes of those classes.

SAIF Matrix Location

Row(s)

• Logical (PIM)

Column(s)

• Information

Audience

Health care Information Technology (IT) Audiences:

• Standards developers and standards development organizations
• System designers and architects
• Programmers/implementers

Designers, modelers and implementers of v3 solutions being created under HL7 SAIF, which are required to be RIM-derived.

The RIM should be accessible and understandable for domain experts seeking to verify, map or align their analysis information models to the RIM.

Applicability

As a single, foundation, "reference" source for SAIF, the RIM is required for use by all v3 projects, but it does not need to be "created" by those projects.

Requirements, Relationships and Content

1. Include the set of information classes that fully represent the information needed to support interoperability in the clinical and administrative functions of health care.
   1. Rationale As the foundation of HL7 SAIF, it must be able to represent the full spectrum of likely HL7 applicability.
2. Include selected information classes that represent the computational and contractual information needed to implement health care interoperability.
   1. Rationale Must support the necessary communication artifacts (wrappers and the like) needed to establish information interoperability.
3. Maintain a degree of abstraction in the RIM model such that there is, ideally, only one way to represent a data structure using RIM classes.
   1. Rationale Large models with myriad associations lead to ambiguity in selecting the preferred representation of a particular concept. A controlled abstract model eliminates or greatly reduces such ambiguity.
4. Manage the abstraction in the RIM model using controlled terminologies (code systems) that are formally approved as an integral part of the RIM.
   1. Rationale Controlling terminologies determine the meaning of the concrete expression RIM abstractions, and must, themselves be part of the RIM.

Relationships and traceability

• Bind the data types of the RIM attributes to a specific "abstract" data type representation formally adopted by HL7.
  • Rationale The data structures that derive from the RIM will draw much of their "type" information from data types assigned to RIM attributes. Thus these attributes have a data type representation that is fully as consistent and tightly managed as the RIM itself.
• Establish a terminology binding for each "coded" attribute of the RIM to a specific Concept Domain that is drawn from an HL7-managed Vocabulary Model.
  • Rationale Over 40 per-cent of RIM attributes carry encoded values. The expected terminology binding for those attributes must be carefully defined and managed by HL7
• Where a RIM class has a defined state machine, this SHALL conform to the Logical State Machine Artifact Definition

Artifact types that may or must relate to this artifact types:

• Analysis Information Model
• Domain Information Model
• Serializable Information Model
• Loose Information Model
• Simplified Information Model
• Semantic Profile

Content

• Model data - Defining data (including name, version, responsible party, and description) captured at the model level.
  • HL7-defined properties - Properties that formally extend the definition of a model beyond the UML specifications.
• Association - UML element expressing relationships between classes with UML-specified characteristics such as descriptions, name, association ends, cardinalities, navigability, etc.
  • HL7-defined properties - Properties that formally extend the definition of an association beyond the UML specifications.
• Class - UML element with UML-specified characteristics such as descriptions, name, etc.
  • Attribute - UML element with UML-specified characteristics such as descriptions, name, cardinality, etc.
    • Data type - Type assignment from HL7 data types specification.
    • HL7-defined properties - Properties that formally extend the definition of an attribute beyond the UML specifications.
  • HL7-defined properties - Properties that formally extend the definition of a class beyond the UML specifications.
  • State Machine optional - Identifies the states and transitions for a class
• Subject area - (Non-normative) Element to collect classes into logical groupings.

Artifact Technology

The RIM is a UML Class model with extensions needed to document more specific content properties than are encompassed in UML and to define and manage terminology bindings.

Rationale

UML provides the key constructs of classes, attributes, associations & state machines and has the extensibility necessary to support the remaining requirements.

Alternatives

None. The MIF was defined for this purpose, and the RIM has been maintained in this fashion for several years.

Content Constraints

The following constraints are based on long-established HL7 policies and practices. The rationale, therefore, is to maintain consistency with the established RIMs and published HL7 standards.

1. Once a RIM element (class, attribute, state, controlling code) has been included in a version of the RIM released for ballot, and that element has been used in a normative specification, the element cannot be removed from the RIM except by a process of Deprecation and delayed removal.
   1. Once an element has been deprecated it SHALL NOT be used in development of further derived models.

   2. Rationale: Established policy
2. RIM UML content must include the following elements:

   1. Classes
   2. Associations (including generalizations, but excluding compositions and association classes)
   3. Attributes
   4. State machines for selected classes
   5. Definitive text for every element

   1. Rationale: Provide a RIM that is lean and understandable using standard modeling paradigm

1. RIM Classes:
   1. Class names SHALL be "upper-camel-case" with no spaces and only alphabetic characters
   2. Classes may have the following HL7-defined properties.

      The properties are only listed here. Their formal definition and rules are in the RIM Normative specification.

      1. Property: classCode
      2. Property: stateAttribute
   3. Rationale: Properites to express constraints not directly represented in UML, and follow established style guides

1. Associations:
   1. Association ends will include names and cardinalities (limited to 0..1, 0..*, 1..1 and 1..*). Association end names SHALL be "lower-camel-case" with no spaces and only alphabetic characters
   2. Association ends must have the following HL7-defined property.

      The property is only listed here. Its formal definition and rules are in the RIM Normative specification.

      1. Property: allowedUpdateMode
      2. Property: availableUpdateModes
      3. Property: conformance
      4. Property: mandatoryInclusion
   3. Rationale: Properites to express constraints not directly represented in UML, and follow established style guides

1. RIM attributes:
   1. Attributes shall include names, cardinalities (limited to 0..1, 0..*, 1..1 and 1..*) and a data type drawn from a single, specified, HL7-approved Abstract Data Types Model. Attribute names SHALL be "lower-camel-case" with no spaces and only alphabetic characters and will follow a convention to identify the approximate data type (coded, boolean, name, etc.)
   2. Coded attributes must include the "vocabDomain" property. (see below)
   3. Attribute may have the following HL7-defined properties.

      The properties are only listed here. Their formal definition and rules are in the RIM Normative specification.

      1. Property: allowedUpdateMode
      2. Property: availableUpdateModes
      3. Property: conductible
      4. Property: conformance
      5. Property: defaultValue
      6. Property: isDocumentCharacteristic
      7. Property: isImmutable
      8. Property: mandatoryInclusion
      9. Property: vocabularyAssertion
   4. Rationale: Properites to express constraints not directly represented in UML, and follow established style guides

1. Additional MIF-defined annotations such as rationale, usage not4es, etc. may be included in the documentation of any RIM element.
   1. Rationale: Allow a rich set of annotations to make RIM content more readily understood.

Content Guidelines

Since the RIM is a formal specification that has been approved internationally and is in active use within the HL7 International communities, these guidelines are not designed to explain the current content, but rather to reflect guidelines for proposed changes.

1. New content or changes to existing content should be designed for universal use in HL7 International.
   1. Rationale: The RIM is a consensus model that is required for use in all HL7 realms.
2. New content should be added only when there is no reasonable way to represent the same content with existing RIM structures.
   1. Rationale: See requirement #3 and the objective of having only one way to express a given concept in the RIM.
3. New attributes should not be added if the same information can be more appropriately represented as an "observation."
   1. Rationale: See requirement #3 and the objective of having only one way to express a given concept in the RIM.
4. The definition of new RIM elements should not overlap with existing elements and the names for new elements (including controlling codes) should have universal applicability (as opposed to realm-specific).
   1. Rationale: Retain the abstract nature of the RIM and its ability to satisfy a broad range of needs.

Publishing Representation(s)

1. The primary distribution of the RIM is in the form of a file formatted according to the HL7 Model Interchange Format (MIF).
   • Provides the computable representation needed by implementers
2. HTML representation for the ballot is MIF-based, and includes UML Class Diagrams of the content
   • The RIM is balloted in its HTML representation, which uses the MIF representation as its source. The HTML format is familiar to most HL7 participants.
   • UML graphic representation is universal and familiar.
3. Near-term (2011-12) distribution of the RIM in an Access data base format is used to support selected tools, notably the HL7 RMIM Designer (in Visio) and vocabulary management software.
   • Rationale: Support existing tool base.

Publishing Constraints

1. Content is provided in two MIF files and a number of graphic files:
   • RIM "core" MIF containing the "technical content" (classes, attributes, etc.)
   • RIM "publication" MIF containing the balloting rules and definitions for the core properties and principles for the RIM. This also "structures" the presentation of the technical and graphic content.
   • RIM graphics in GIF and PDF (for very large diagram) formats
   1. Rationale: Formats required by publishing process
2. Content publication is dependent upon of the joint publication of RIM with the Abstract Data Types and Vocabulary Model to which the RIM is bound.
   1. Rationale: These models are mutually inter-dependent

Tooling Considerations

The current RIM-tooling was first used 15 years ago. Although its technology is archaic, it is robust and replacement is not simple. Some of the features of the current RIM tools include:

1. 2011 Technology Base:
   • Fundamental storage is in the Access data base known as a RIM Repository

   • Content management of the Access content is handled by DLLs from the RoseTree family maintained in Visual Basic 6.
     • Source code is on SVN

   • Model content is documented and updated in Rational Modeler (199x release) with HL7 properties defined. The content is then read and "synched" with the RIM repository using RoseTree invocations of the APIs provided by Rational Modeler, and a set of Access VBA software in HL7 "Access tools".

   • Extraction of RIM content and its expression in the primary MIF format is done as:
     1. Content is assembled in the RoseTree application (and manually reviewed, if needed)

     2. RoseTree expresses the full content in an idiosyncratic XML format

     3. The V3 Generator is used to convert the "RIM-XML" content into a correct MIF representation.

   • Complete RIM archival content (all releases back through 0.86 in 1997) is retained in an Access data base archive.

   • Migration of data to-from the archive is managed by a set of HL7 "Access tools" encoded in VBA in an Access data base. They permit the retrieval of older versions into a current repository.

   • Trained users: Although at one time Karen vanHentenryck was trained in the RIM update process, only G. Beeler has used this process in recent years. Although this may sound risky, the risk is ameliorated by the avialable of full content in MIF (excepting only the graphics).
2. Nice-to-have - A RIM model management based on a UML tool
   • Clearly it would be desirable to manage the RIM content from a UML model tool that could read and write MIF either directly or through MIF to XMI transforms. Notes:
     • This is an easier task for the RIM than it would be for the generalized Static Model Designer because RIM content is not "constrained" by the RIM, does not need access to code systems, and has a very low rate of change.

     • A UML modeler would not need to read the RIM MIF provided that a means of robustly verifying that the modeler representation of the RIM and the MIF representation are identical. (The current RIM maintenance process uses this strategy to maintain alignment between the RIM repository and the Rose Modeler files.)

     • The archived RIM content should be extracted and converted to MIF format to provide a MIF archive of past RIMs, albeit absent the graphics, which would have to be archived separately in GIF and PDF files.

     • HL7 has the technical resources to make this conversion, but not the manpower resources to undertake it.

Artifact Exchange and Version Management

The primary distribution of the RIM is in the form of a file formatted according to the HL7 Model Interchange Format (MIF).

RationaleThe RIM is a core technology for HL7 endeavors. As such it is a necessary element of most HL7 design tools, and must be available in a processable, MIF format.

Development Process Considerations

There is one and only one RIM artifact (though it will be versioned)

The complete development process for the RIM is documented in HL7 Vocabulary and RIM Harmonization Process, and subsequent GOM-defined Normative ballots.

The process for updating the RIM that results from these processes is considered in Tooling Considerations above.

Governance Process Considerations

The HL7 Reference Information Model is managed under the ANSI "continuous maintenance" process, currently (April, 2011) as HL7 Version 3 Standard: Reference Information Model, Release 4 [HL7 V3 RIM, R4]

1. All changes to RIM content SHALL be adopted through the HL7 Vocabulary and RIM Harmonization Process, and subsequently approved through Normative ballot.
   1. Rationale: Established governance
2. For elements of the RIM, both the action of deprecation and the final removal must be approved in harmonization, and are subject to review in the next Normative ballot.
   1. Rationale: Established governance
3. New content or changes to existing content should be widely reviewed within the affected HL7 Work Groups and with both Modeling and Methodology and Vocabulary before a change proposal is submitted for harmonization.
   1. Rationale: The RIM is a consensus model that supports the entire HL7 community. Therefore changes should have as broad a consensus as possible before they are brought forward.
4. Proposals for new or changed content should include a strong, readily understood use case that provides the requirements for that proposal.
   1. Rationale: Necessary to justify and gain the approval from the harmonization meeting.
5. Each project SHALL be designed to derive from the release and version of the RIM that is current at the time that the project deliverables become a standard.
   1. Rationale:
6. As such, the RIM definition and distribution SHALL be in a file that conforms to the HL7 Model Interchange Format (MIF).
   1. Rationale:

Issues

• Need approval and adoption of a "Deprecation" rule set that is more clear than I have