Mechanism for using Clinical Statement Pattern in Design

Background

This document describes the requirements for asserting how models relate to the clinical statement pattern, and the technical solution for how this is done. The technical solution includes how the links are maintained in the Model Interchange Format (MIF), and how these are expressed in the documentation.

The Clinical Statement Pattern

The Clinical Statement Pattern was created by HL7 in response to the observation that different committees were designing different RIM derived structures to define the same clinical meaning. The Clinical Statement Model is the structure that all committees creating clinical content have agreed should be used to represent that common content. As a model it is intended to represent only commonly used structures, and will be extended by committees where there is a specific requirement for more detail.

Requirements for asserting model relationships

Derivation type

• It must be possible to assert that a node in the derived model is a restriction of the node in the parent document
• It must be possible to assert that a node in the derived model is an extension of the node in the parent document
• It must be possible to assert that a node in the derived model is a combination of restriction and extension of the node in the parent model

Relationship maintainence

• The relationships to the parent model will be maintained as part of the derived model, and so any change to these relationships will result in a change to the version on the derived model. Note that a consequence of this is that if the clinical statement model evolves, such that the derived model can be asserted to be a better constraint on the new parent model, adding this information will be done to a new version of the parent model.

Unmbiguous mapping

No node in the derived model should be associated with more than one node in the parent model. Thus if there are two different actRelationships in the parent model that could correspond to an actRelationship in the derived model, an association to only one of them must be asserted.

Issues

• should there be a facility to maintain relationship assertions externally from the parent and derived models, such that asserting a relationship does not have to change the version information of either model (since there is no change to the set of valid instances of either)?
• should this document be written explicity in terms of teh clinical statement pattern, or should it be generalised to address any parent model and derived model? I err towards making it general, and using the clinical statement pattern as the example - but it is not all written in that way at the moment