Types of Updates

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 identifier types. Historically, it has not been possible to differentiate between identifiers in the II datatype. However, an MnM resolution at the May, 2006 WGM recommending the introduction of an II.useCode property should differentiate this.

• Business Identifier: This is a commonly used identifier associated with a particular object. It is often a publicly exposed identifier which is known to providers and may be printed on reports or forms. It remains consistent as a class undergoes state transitions, including suspend, resume, revise, abort and complete. It is the truest identifier of the "object", given the MnM paradigm that an object persists across state transitions.

• Version Identifier: This is a type of identifier introduced in some jurisdictions to allow referencing a particular business object as it existed at a given point in time. They can be considered identifiers of a static snapshot of the object. This type of identifier changes with each state transition on the object. I.e. The version identifier of an object prior to a 'suspend' state transition is distinct from the identifier of the object after the state transition. Each version identifier can be tied to exactly one ControlAct event which brought that version into being.

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