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.

The business identity of a RIM class 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.
• 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 circunstances 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.

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 circunstances the Object Identity can be determined by the context (the set of related objects) of the object in question.