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.

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.

The business identity of a RIM class (its identifying characteristic) is contained in its Id attribute (for Acts, Entities and -managed- Participations).

• 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. 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 object trees comply with the constraint model shown above it has the ability to merge these object trees into the net1 object net. If the constraint isn't known the resulting object net would be net2. The 0..1 cardinality on the participation allows the receiver to deduce that the two non-identified objects in the two object trees are one and the same object.