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.

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]

SAIF Matrix Location

Row(s)

• Logical (PIM)
• Implementable (PSM) (RIMBAA)

Column(s)

• Information

Audience

Designers, modelers and implementers of interoperability solutions being created under the SAIF, which solutions are required to be RIM-derived. The RIM should be accessible and understandable for domain experts seeking to verify, map or align their conceptual information models to the RIM.

Applicability

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

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.

Requirements

1. Include the set of information classes needed to 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.
5. Bind the data types of the RIM attributes to a specific "abstract" data type representation formally adopted by HL7.
   1. 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.
6. Establish a terminology binding for each "coded" attribute of the RIM to a specific Concept Domain that is drawn from and the HL7-managed Vocabulary Model.
   1. 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
7. Where a RIM class has a defined state machine, this SHALL conform to the Logical State Machine Artifact Definition
   1. Rationale SAIF consistency

Relationships and traceability

• RIM attributes SHALL be bound to a data type drawn from a single, specified, HL7-approved Abstract Data Types Model
  • Rationale: Requirement #5 above.
• RIM encoded attributes SHALL be bound to a specific Concept Domain
  • Rationale: Requirement #6 above.
• State machines for RIM classes that have such a machine, this SHALL conform to the Logical State Machine Artifact Definition
  • Rationale: Requirement #7 above.
• Conceptual Information Model elements may have traceability to the RIM
  • Rationale: Provides formal grounding of semantics at conceptual layer
• Logical information models (DIMs and SIMs) and the elements in them will SHALL be derived from the RIM and its elements
  • Rationale: Defined derivation rules.

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. As such, the RIM definition and distribution SHALL be in a file that conforms to the HL7 Model Interchange Format (MIF).

Textual representation of the RIM content will be in HTML, and graphic representation of the RIM will be UML Class Diagrams.

Rationale

• The 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.
• 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.

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. All RIM content SHALL be adopted through the HL7 Vocabulary and RIM Harmonization Process, and subsequently approved through Normative ballot.
   1. Rationale: Established governance
2. 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.

   Both the action of deprecation and the final removal must be approved in harmonization, and are subject to approval in the next Normative ballot.

   Once an element has been deprecated it SHALL NOT be used in development of further derived models.

   1. Rationale: Established governance and policy
3. 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
4. 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
5. 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: conformance
   3. Rationale: Properites to express constraints not directly represented in UML, and follow established style guides
6. 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: conductible
      2. Property: conformance
      3. Property: defaultValue
      4. Property: isDocumentCharacteristic
      5. Property: isImmutable
      6. Property: mandatoryInclusion
      7. Property: vocabDomain
   4. Rationale: Properites to express constraints not directly represented in UML, and follow established style guides
7. 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 exp[lain the current content, but rather to reflect guidelines for proposed changes.

1. 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 the 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.
2. 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.
3. New content should be presented 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.
4. New attributes should not be offered if the same information could be reasonable 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.
5. 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).
   • (See Artifact Technoilogy above for rationale.)
2. HTML representation for the ballot is MIF-based, and includes UML Class Diagrams of the content
   • (See Artifact Technoilogy above for rationale.)
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: That's how its done!!
2. Content is 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

1. Nice-to-have|Required: Some feature
   1. Rationale: Some rationale

1. Nice-to-have|Required: Some other feature
   1. Rationale: Some other rationale

Development Process Considerations

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.

Issues

• Some issue
• Some other issue