Uses of a Reference Information Model (RIM) in Health Informatics

Use of the RIM by HL7

The HL7 RIM is a critical component of the V3 development process. It is the root of all information models and structures developed as part of the V3 development process.

The HL7 V3 standard development process is a model-driven methodology in which a network of inter-related models are developed that depict the static and behavioral aspects of the requirements and design of HL7 standards, as well as the underlying semantics and business rules that govern them.

The RIM provides a static view of the information needs of HL7 V3 standards. It includes class and state-machine diagrams and is accompanied by story boards, interaction models, data type models, terminology models, and other types of models to provide a complete view of the requirements and design of HL7 standards. The classes, attributes, state-machines, and relationships in the RIM are used to derive domain-specific information models that are then transformed through a series of constraining refinement processes to eventually yield a static model of the information content of an HL7 standard.

The HL7 V3 standard development process defines the rules governing the derivation of domain information models from the RIM and the refinement of those models into HL7 standard specifications. The rules require that all information structures in derived models be traceable back to the RIM and that their semantic and related business rules not conflict with those specified in the RIM. The RIM therefore is the ultimate source for all information content in HL7 V3 standards.

The RIM is used by HL7 affiliates to extend HL7 V3 standards to meet local needs. Through a process known as localization, V3 standard specifications are extended using the RIM as the source for new information content. This new information is derived from the RIM and refined in the same manner used to create the original specification.

Uses of the RIM Outside of HL7

The RIM is primarily for use by HL7 and its international affiliates. However, others outside of HL7 have also found the RIM useful. Although HL7 maintains a copyright on the expression of this standard, HL7 does not seek to license or otherwise control the use of information structures or programs that implement this specification.

Some adopters use the V3 standards development process and the RIM to develop HL7-like message specifications in their own environments. Other organizations are known to use the RIM as a source of input to their enterprise information architectures, as a starting place for systems analysis and design, as internal application objects, or even as the basic model for enterprise integration databases.These adopters include vendors, large integrated delivery networks, and government agencies. These same adopters are extremely active in HL7 and provide practical input to the RIM and other aspects of V3 the development process.

The RIM is only one model of health care information needs. The abstract style of the RIM and the ability to extend the RIM through vocabulary specifications make the RIM applicable to any conceivable healthcare system information interchange scenario. In fact, it is conceptually applicable to any information domain involving entities playing roles and participating in acts.

The universal applicability of the RIM makes it particularly useful for an organization like HL7 that has to consider the needs of a large and diverse membership. The style of the RIM makes it extremely stable, which is another important characteristic for HL7. The HL7 standards development process calls for the creation of domain specific models derived from the RIM and the incremental refinement of those models into design models that are specific to the problem area. These problem area specific design models narrow the abstractness of the RIM and include constraints on attribute values and class relationships that are use case specific. External organizations considering using the HL7 RIM are advised to adopt a similar process of deriving design models as a transformation of the RIM.

RIM Abstraction and UML Properties

The RIM uses a very abstract modeling style. At the core of the RIM are its back-bone classes, their specializations (sub-types), and the "structural" attributes that encode definitions for further enumerated sub-types that have no additional attributes and associations and are therefore not diagramed as part of the RIM structure. An understanding of these classes and attributes is essential to understanding the RIM. This section describes how the abstractions are represented in UML and controlled through the application of controlling vocabulary that is part of this specification.

RIM as an abstract model

The "back-bone" of the RIM, which is used to express the clinical and administrative content of health care, is comprised of six classes:

• Act which represents the actions that are executed and must be documented as health care is managed and provided.
• Participation which expresses the context for an act in terms such as who performed it, for whom it was done, where it was done, etc.
• Entity which represents the physical things and beings that are of interest to, and take part in health care.
• Role which establishes the roles that entities play as they participate in health care acts.
• ActRelationship which represents the binding of one act to another, such as the relationship between an order for an observation and the observation event as it occurs.
• RoleLink which represents relationships between individual roles.

Three of these classes - Act, Entity and Role - are further represented by a set of specialized classes, where the set of sub-types are not fully enumerated in the class model . In the HL7 representation, a sub-type is only added to the RIM class model if it requires one or more attributes or associations that are not inherited from its parents. Classes that represent distinct concepts, but which need no further attributes or associations are represented solely as a unique code in the controlling vocabulary. Therefore, these three classes include the following coded attributes, which serve to further define the concept being modeled:

• classCode (in Act, Entity and Role) represents the exact class or concept intended, whether or not that class is represented as a class in the RIM hierarchy
• moodCode (in Act) and determinerCode (in Entity) an attribute that distinguishes whether the class represents an instance or a kind of Act or Entity. If the class is a specialization of Act then moodCode further delineates the instance as an occurrence or an intent.
• code (in Act, Entity and Role) provides for further classification within a particular classCode value, such as a particular type of observation within the Observation class.

The other three RIM back-bone classes - Participation, ActRelationship and RoleLink - are not represented by enumerated generalization-specialization hierarchies. Nevertheless, these classes represent a variety of concepts, such as different forms of participation or different kinds of relationships between acts. These distinctions are represented by a typeCode attribute that is asserted for each of these classes.

Introduction & Scope

Scope of Clinical Statement Pattern Domain

The model described in this section is a 'pattern' designed to be used within multiple HL7 Version 3 domain models. This pattern is intended to facilitate the consistent design of communications that convey clinical information to meet specific use cases. In most cases the pattern will be refined for use within the model using the Clinical Statement.

It is not intended that the 'pattern' itself is ever used in a communication, accordingly the information in this document is necessarily at a high level with a minimum of constraints applied. The pattern does not represent a Record Architecture or a physical structure for storing data on an EHR database, although it does cover many of the types of clinical information that should be part of an Electronic Health Record.

The Clinical Statement model is deliberately broad and encompassing. As a result, it would be possible to represent a particular statement in more than one way. The primary objective of the Clinical Statement topics is to constrain the Clinical Statement model when used to communicate certain types of information in an effort to enhance interoperability and shareable semantics.

The formal definition of a Clinical Statement for the care of patients (persons, animals and other entities) is:

• An expression of a discrete item of clinical, clinically-related or public health information that is recorded because of its relevance to the care of a patient or other entities. Clinical or public health information can be expressed with different levels of granularity and therefore the extent and detail conveyed in a single statement may vary. To be regarded as a Clinical Statement, a concept must be associated with a patient or other entity in a manner which makes clear:
• Its temporal context
• Its relationship to the entity or entities
• In the case of an observation, its mood and presence, absence or value
• In the case of a procedure, its mood and status



This clarity may be achieved by:

• Explicit representation; or
• Implicit application of defaults ONLY where explicitly modeled rules state the appropriate defaults.

Use of the model

The Clinical Statement Pattern represents a standard, high-level structure for the inclusion of clinical information in communications intended to support specific business functions. Although not intended to be implemented 'as is' (except by direct use of the supplied CMET A_SupportingClinicalStatement), the Clinical Statement Pattern can be constrained to meet the requirements of many specific communications regarding clinical information. The process of modification will involve either pattern constraint or extension (or sometimes both) in order to achieve the needs of a particular domain. There is one main CMET based on the pattern: COCT_MT530000 (A_SupportingClinicalStatement universal)

COCT_MT530000 (HL7 V3)

COCT_MT530000 (UML)

Options for pattern constraint

Options for pattern constraint include:

• The generic 'Clinical Statement' class attributes may be constrained to reflect the precise nature of the data to be conveyed. For example:

  • Optional attributes may be removed if not appropriate to the business case

  • Attributes themselves may be constrained:

    • multiplicities may be constrained to narrower number sets, e.g. (0..*) may be constrained to (1..*)

    • attribute value sets may be constrained to smaller attribute value sets, e.g. 'mood code' limited to 'Event'

  • Datatypes for an attribute may be constrained, e.g. 'ANY to CD'

• Associations may be constrained to remove the potential for complexity, e.g. the limitation of an implementation to three levels of nesting

• Classes may be constrained:

  • Classes may be removed if not required

  • Classes may be constrained to specific subclasses, e.g. 'Observation Class' constrained to 'Battery Class'

  • Classes may be 'cloned' in order to document specific constraints on attributes or associations

  • Classes with specific constraints applied may be 'unrolled' from the Clinical Statement Choice box in order to constrain their use to a specific structure (in that case, the constrained version of the class may no longer be assumed to be present in the generalized Clinical Statement Choice Box)

Pattern Use

As stated above in the Scope of Clinical Statement, the purpose of the pattern is to allow consistent design of clinical models. In use, the pattern is similar to a D-MIM. It is never used directly but is a model that other models or parts thereof are derived from.

The concept of a "pattern" is not properly defined in HL7, but the difference between CSP and other models is mainly one of coverage. A model derived from a D-MIM can only have content that is in that D-MIM. With CSP your model can be fully derived from the pattern, or only that part of your model considered "clinical".

If a model has areas that are similar to Clinical Statement, then the intention is that those be modelled consistently with CSP. This should be a full conformance, with no extra attributes or cardinalities.

CSP is not meant to replace the RIM. CSP exists to illustrate good practices of modelling. It is not meant to exclude anything from the RIM, but does only include RIM features that have been encountered in the clinical domains. The RIM has multiple ways of doing the same thing and some concepts and combinations of concepts appear unnecessary for clinical data. CSP evolves however, and additional RIM attributes and classes can be added, at the appropriate points of the model where they are shown to be necessary, via a change control process. No RIM attribute is forbidden in principle, but many are only appropriate in some circumstances. It is allowing these known good combinations and downplaying others that CSP is about.

Although the typical way to use CSP is similar to a D-MIM, other methods are possible. In particular CSP can be used as a CMET, and plugged into your model directly. Also, CSP as whole can be used as the source for an HL7 template, or more likely a CSP-derived model can be used to create a more specialized HL7 template.

Checking a Model Against the Pattern

The process of checking a model for conformance to CSP can be summarised as follows:

• Decide which part(s) of your model M need to be conformant with CSP (Other parts of these usage notes show how to identify those areas)

• For every class in the model, check that it is a valid constraint of the equivalent CSP model class. Follow the rules documented in the HL7 standard "Refinement, Constraint and Localization" guide

• Every attribute (property) of every class, must be checked against the CSP model attribute, to see that it is the same, or is more strict a condition. Hence an instance confirming to M would also be a valid instance conforming to CSP. Attributes are checked for conformance in regard of cardinality, HL7 conformance (required, optional etc), allowable datatypes and vocabularies or code systems

• One technique for achieving this task is to make a spreadsheet with two columns. One has all the classes and attributes in M, the other is the equivalent class and attribute from CSP. Misalignments can be documented and considered in this way. (see diagram below for an example)

• Where a model includes a CMET and that CMET is to be checked, the process is repeated, treating that CMET as a model in its own right. In other words, if a model uses 3 CMETs, check that those CMETs are independently CSP compatible, as well as checking the model that uses them is CSP compatible. Then the complete composite model will be CSP compatible. Another way to consider this issue is that when checking conformance you can treat the CMET as "transparent", and it is as if the CMET contents were cut and paste directly onto the model that uses them. The CMET boundary is not a boundary when checking conformance - checking continues into the body of the CMET. This also implies that a CMET does not need to appear in CSP itself, in order to be used by a CSP conformant model. If the CMET is itself conformant, it is already allowed to be used in a CSP conformant model.

Domain Information Model

The model can be divided into 4 related parts:

• Clinical Statement Act Choice Box
• Relationships between Clinical Statements
• Participations surrounding the Acts
• Acts and relationships outside the Choice Box

Clinical Statement Act Choice Box

This part of the model is used to convey the detailed clinical information that is being sent in support of the specific business need. As well as providing a mechanism for conveying the components of this information, it supports grouping of these components and provides mechanisms to explicitly link statements where there is a specific relationship.

Where a Clinical Statement has previously been conveyed in a communication and is consequently known within an information system, the Clinical Statement may be included either by reference or by repeating the full statement. Where the full statement is repeated, all attributes and context (whether explicit or inherited) shall be identical.

Clinical Statement has the choice box structure to allow any clinically relevant selection, duplication, constraining and ordering of Acts to be included in the communication.

All items in the clinical data will be able to be coded via either an HL7 code, an external registered coding system, or a locally derived / developed coding system. Through use of the OID structure, the appropriate coding system will be identified.

Relationships between Clinical Statements

The model provides three mechanisms that allow Clinical Statements to be linked by the Act Relationship Class:

• Containment
• Direct relationship
• Reference

These links may be achieved by one of three act relationships in the pattern described below:

• component
• sourceOf2/targetOf
• sourceOf1

These are all refinements of the same general structure and share the following facilities:

• inversionInd; when 'true' reverses the direction of the relationship e.g. 'Cause of' becomes 'Caused by'
• negationInd; when 'true' allows the sender to specifically state that the relationship does not apply e.g. An observation was not caused by a medication

Participations surrounding the Acts

Clinical statements can have various participations. Participations propagated from the focal or source Act can be overridden within the Clinical Statement. These participations include:

• recordTarget
• subject
• author
• consumable
• informant
• performer
• product
• location
• dataEnterer
• verifier
• responsibleParty

Acts and relationships outside the Choice Box

Clinical statement pattern define various acts and relationships outside of the central Choice Box. These elements include:

• ControlActEvent: Each message has a Control Act wrapper to represent the trigger event to which this message relates.
• referenceRange: The referenceRange relationship has a source of Observation, and a target that is another Clinical Statement.
• conditions: The precondition class, derived from the ActRelationship class, is used along with the Criterion class to express a condition that must hold true before some other activity occurs.