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.
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.
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.
The "back-bone" of the RIM, which is used to express the clinical and administrative content of health care, is comprised of six classes:
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:
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.
This collection of classes and their associations represent the "normative" content of the HL7 RIM. The content of this subject area has been balloted within HL7 as a normative document.
FoundationClasses contains subject areas:
A collection of classes including the Act class and its specializations. These relate to the actions and events that constitute health care services.
Acts contains subject areas:
Acts contains classes:
A collection of classes related to the Entity class, its specializations and related qualifying classes. The classes represent health care stakeholders and other things of interest to health care.
Entities contains classes:
A collection of classes related to the Role class and its specializations. These classes focus on the roles participants may play in health care.
Roles contains classes:
A collection of classes related to the definition of document-based communication in HL7, as represented by the Clinical Document Architecture standards.
StructuredDocuments contains classes:
A collection of classes related to the technical definition and control of message-based communication in HL7.
MessageCommunicationsControl contains subject areas:
This subject area contains those RIM elements involved in the control, communication and acknowledgement of messages.
MessageControl contains classes:
This subject area contains those classes necessary to formulate, communicate and respond to query messages.
QueryControl contains classes:
This subject area contains those classes that provide foundation elements for the HL7 communications infrastructure.
CoreInfrastructure contains classes:
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:
This clarity may be achieved by:
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)
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)
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.
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.
The model can be divided into 4 related parts:
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.
The model provides three mechanisms that allow Clinical Statements to be linked by the Act Relationship Class:
These links may be achieved by one of three act relationships in the pattern described below:
These are all refinements of the same general structure and share the following facilities:
Clinical statements can have various participations. Participations propagated from the focal or source Act can be overridden within the Clinical Statement. These participations include:
Clinical statement pattern define various acts and relationships outside of the central Choice Box. These elements include: