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

Relationships and traceability

• Some relationship
  • Rationale: Reason for relationship

• Some other relationship
  • Rationale: Reason for other relationship

Artifact Technology

Text here

Rationale

• Some reason
• Some other reason

Alternatives

Some technology

• Some pro or con
• Some other pro or con

Content Constraints

1. Some rule
   1. Rationale: Some reason

1. Some other rule
   1. Rationale: Some other reason

Content Guidelines

1. Some rule
   1. Rationale: Some reason

1. Some other rule
   1. Rationale: Some other reason

Publishing Representation(s)

1. Some text
   1. Rationale: Some rationale

1. Some other text
   1. Rationale: Some other rationale

Publishing Constraints

1. Some rule
   1. Rationale: Some reason

1. Some other rule
   1. Rationale: Some other reason

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

1. Some text
   1. Rationale: Some rationale

1. Some other text
   1. Rationale: Some other rationale

Issues

• Some issue
• Some other issue