Object Equivalence, determination of

20110111 MnM Q4: This page provides input into updating section 4.2 (Identifying Objects) of the Core Principles document.

Overview

The Object Identity (a.k.a. Business Identity, identity throughout the business cycle) of an object uniquely identifies the object. Two objects (e.g. as present in two different messages) with the same Object Identity are one and the same object.

Identity and Equality

Note: when it comes to the identity of objects: two objects can be identical (same identity), or equal (same value). Objects that are equal need not be identical. An object may have an attribute that contains an identifying characteristic, i.e. two objects are identical if they have the same identifying characteristic.

Scope of Identifier

An identifier (the identifying characteristic, if expressed as an II data type in HL7) can be of different types (have different characteristics). The Datatpes R2 specification documents the II.scope (CS datatype) attribute, which is defined as Specifies the scope in which the identifier applies to the object with which it is associated..

• The CodeSystem used is "IdentifierScope", with OID: 2.16.840.1.113883.5.1116. Values are:
  • BUSN: Business Identifier. An identifier whose scope is defined by business practices associated with the object. In contrast to the other scope identifiers, the scope of the use of the id is not necessarily restricted to a single object, but may be reused for other objects closely associated with the object due to business practice.
  • OBJ: Object Identifier. The identifier associated with a particular object. It remains consistent as the object undergoes state transitions.
  • VER: Version Identifier. An identifier that references a particular object as it existed at a given point in time. The identifier SHALL change 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 (though the control act may never be instantiated). NOTE: Applications that do not support versioning of objects must ignore and not persist these ids to avoid confusion resulting from leaving the same identifier on an object that undergoes changes.
  • VW: View Specific Identifier. An identifier for a particular snapshot of a version of the object. This identifies a view of the business object at a particular point in time, and as such identifies a set of data items that can be digitally signed and/or attested. This is in contrast to the Version Identifier which identifies the object at a specific time, but not the amount of information being asserted about the object. This identifier would be changed when a transformation of the information is performed (eg to add code translations, to provide a simplified textual rendering, or to provide additional information about the object as it existed at the specific point in time).

Note: Grahame recommends that v3 implementers (RIMBAA implementers) 
that use Datatypes R1 should pre-adopt II.scope.

The identity of a RIM class (its identifying characteristic) is mostly contained in its Id attribute (II data type).

• For Acts and Participations it is a safe assumption that the identifier used will have been used to identify one single Act instance (OBJ, VER, VIEW).
• For Roles the situation is a bit of a muddle, because one may not know if the Role.id is a unique identifier of this single role instance (OBJ, VER, VIEW), or whether it is an identifier used for a set of role instances (BUSN). The identity of the Role depends on the identity of the playing and scoping entities; those identities may not be known. See section below for details.
• When it comes to the identitifier of Entities it is a safe assumption that the identifier used will have been used to identify one single Entity instance (OBJ, VER, VIEW).
  • There are implementations where Role identifiers are 'pushed into' the entity.
  • For certain Entities the identifying characteristic may actually be present in the code instead of the id attribute (e.g. for Countries). See section below for details.
• A significant number of objects in a RIM-based object tree (e.g a message) don't have a populated id attribute. Example: most participations and non-focal observations. In specific circumstances the Object Identity can be determined by the context (the set of related objects) of the object in question. See section below for details.

Object Identity for Roles

For Roles the situation is a bit of a muddle, because one doesn't know if the Role.id is a unique identifier of this single role instance, or whether it is an identifier used for a set of role instances. An example of the latter is a national identifier (e.g. SSN in the USA) to identify multiple roles. In those cases the identity of the role is based on the tuple (Role.id, 'Scoper') where 'Scoper' could be the Entity.id or the Entity.name of the scoping entity.

• This is especially relevant in the process of deciding when to 'merge' objects into an object net.
  • If the Role.id of at least one Role has an unknown II.scope, then two Roles can only be said to be identical if: scoping entities are the identical AND playing entities are identical AND code/classCode of the Role are the same, THEN one could conclude that two Roles are the same.
  • If both Roles have a Role.id has a II.scope that indicates a object identifier (OBJ, VER, VIEW) then they are identical.

• Example #1: Dr. Smith is a part-time employee of two different hospitals, A and B. Within each organization he performs a different role (different role.code values). Each role has different contact details, address etc. However: both hospitals (the scopers of the respective roles) both know Dr. Smith using one and the same ID: his 'national healthcare provide identity', 607802. Given that the roles are different, but the Role.id values are the same (607802), one has to use the scoper.Id (A or B) in combination with the Role.id to uniquely identify a role instance.
• Example #2: a RIMBAA application persists an Observation with subject Patient 123 with scoping entity 'hospital A'.
  1. If it subsequently receives an object tree with Demographics update for Patient 123 with scoping entity 'hospital A' - in that case the patient objects are one and the same.
  2. If it subsequently receives an object tree with Procedure with subject Patient 123 with scoping entity 'hospital B' - the objects won't be merged - they're not the same.
  3. If it subsequently receives an object tree with Demographics update for Patient 123 without a scoping entity being present' - the objects won't be merged, the scoper of the new object is unknown and therefore can't be merged automatically with any other Role object.

As a consequence of the role identity issue described above (this is an open methodology issue), all RIMBAA applications, in order to decide if two roles are the same (one and the same object, just different versions of it) will have to build some kind of "role identity management component". Roles may or may not have an id, scopers may or may not be present, scopers may not have an id, the id may be specified via an IDENT role, the entity may have an ID whereas the Role it plays has not, the ID of the entity may have to be gleaned of another role played by the entity.. identity crisis, indeed.

Object Identity for Entities

The Core Principles document (CP) provides guidance as to whether something is a code or an identifier. There are circumstances where there is little difference between the two, in which case one could use either (see section X.Y of the CP document).

Example: Countries. ISO has defined a code system for country codes, to identify the "type of country" (e.g. US for USA, NL for Netherlands etc.). This coding system is used in the entity.code attribute - to identify a country.

If a codes identifies a single object then this is known as appellation (according to ISO 704).

• 2010-05-20 Rene talked to Ted Klein: he states that this has been exhaustively discussed in Vocab. Whether or not a code uniquely identifies and object is determined by its business context, it is not a property of a coding system. The example he provided is a coding system for "insurance policy types" created by insurance company XYZ. When using these codes in a policy act associated with a patient, then the code does not identify the object. When these codes are used internally within the insurance company (e.g. to communicate definitions of policies) then they do uniquely identify the object.

The OID of the coding system could be used, for a subset of coding systems (e.g. country codes), to determine if (the coding system as a whole) always have the appellation characteristic. In other words: there are some coding systems where it's safe to assume that there are no known business contexts where the code does not also act as an object identifier.

Reference objects

Models may contain 'Act References', 'Role References'. These objects are rather minimalistic in nature, they contain an ID, no code attribute, and a generic classCode/moodCode.

In this situation the ID really has to be a single Act instance (OBJ, VER, VIEW). If the ID is a business identifier the reference object won't be very useful.

Contextual Object id

A significant number of objects in a RIM-based object tree (e.g a message) don't have a populated id attribute. Example: most participations and non-focal observations. In specific circumstances the Object Identity can be determined by the context (the set of related objects) of the object in question.