Object Equivalence, determination of

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

The identity of a RIM class (its identifying characteristic) is mostly contained in its Id attribute (II data type). It is a safe assumption that Act.id and Participation.id will have an identifier that is 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.
• 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.
  • 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.

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.

Below an example constraint model (CIM or LIM)

The image below shows two different object trees (m1, m2). If the receiver is somehow aware that both messages comply with the constraint model shown above it has the ability to identify the non-identified object by means of its context and the known constraint. The 0..1 cardinality on the participation, and the fact that the objects associated with the participation, allows the receiver to deduce that the two non-identified objects in the two messages are one and the same object.