Types of Updates

This page is initially being constructed to facilitate discussion within Patient Care around requirements for ActRelationships in the Condition/Concern model. However, the discussion is generic in nature and will likely be escalated to MnM as a hot-topic and/or "Lore" discussion.

Types of identifiers

When examining the relationships between classes, it is important to understand the concept of different Types of Identifiers. Historically, it has not been possible to differentiate between identifiers (e.g. Business Identifier, Version Identifier) in the II datatype. However, an MnM resolution at the May, 2006 WGM recommending the introduction of an II.useCode property should differentiate this.

Types of update relationships

There are three major types of update relationships:

1. Update

An 'update' relationship is one where a particular 'version' of an object references a previous version of the same object prior to a state transition. The presence of the relationship allows the receiver of the instance to trace back through previous versions of the instance to see the history of an object as it has changed over time. Each view is frequently accompanied by a 'subjectOf' relationship indicating the ControlAct reponsible for bringing that particular version of the object into being (showing the author, reason, time and other information associated with the state transition).

Within an update relationship, both source and target should have the same Business Identifier but will have distinct Version Identifiers. There must be a maximum of one update relationship from a given version of the object. I.e. One version can only result in a state transition from one other version.

2. Replace

A 'replace' relationship is a relationship between two independent objects. The objects must have the same mood and generally have the same classCode. The target of the replace relationship is an object which is now obsolete and the source of the relationship is the new object instance which has taken its place. The source and target of a 'replace' relationship have distinct Business Identifiers. If Version Identifiers are present, the Version Identifier of the target will be the 'last' version in the chain of the previous object (because 'Obsolete' is a terminal state).

A given object may replace multiple other objects (as a 'join') and may be replaced by multiple objects (as a 'split').

3. Link

This relationship allows two objects to be linked as referring to the same general concept, but remain as distinct objects, each with their own independent state. This is commonly used in circumstances where it would be inappropriate for one user to create a new instance that replaced both of the previous instances with a new record. For example, where both are maintained by separate organizations who have not given permission to modify the state of each other's objects.

In this circumstance, multiple objects can be linked. Linking is bi-directional. A link from A to B implies a link from B to A.

Discussion

It is quite possible for a given class to support all three types of 'update' relationships. Other classes might limit to only one or two of the relationships. In addition, the permissions required to perform one type of update might vary. For example, it may be possible for the author of an object to update it, but other users would be restricted to replacing the object, and those outside the organization would be limited to linking. As such, all three mechanisms require support within the HL7 model.