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

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

Guidance, to be added to Core Principles

The rules for determining when matching identifiers can lead to certainty about equivalence of the objects being compared are unclear.

The following guidance was developed during an MnM meeting in Sydney (20110111, Q3), 
this guidance will be added to a future version of the Core Principles document.

Role equivalence

Role identifiers can be considered to refer to identical role objects IFF:

• There are II values on each of the roles that are equivalent according to the II equivalence definition
• Both IIs declare the scope property
• Both scope properties are one of OBJ, VER or VIEW (they need not be the same on both instances)

In all other circumstances, object equivalence cannot be safely assumed without specific knowledge of the implementation environment, no matter how many other attributes are compared. (It may still be possible to achieve "high probability matches" with less information.)

Example: Clinic uses Social Security Number as their "public" patient identifiers plus an internal object identifier. Patient comes to clinic for several years, then leaves for several years and the role gets flagged as "terminated". They then come back to the clinic and a new role is created for the patient, still using the same SSN as the "public identifier, but with a new internal object identifier. Eventually they leave again and the status becomes terminated again. The SSN cannot be used to point to a single role object instance, even when paired with classCode, code, status, scoper, etc.

Playing Entities of Roles with equivalent Role identifiers can be considered to be equivalent.

Entity equivalence

The same rules for determining equivalency apply as for roles (equivalent IIs each with declared scopes other than BUSN).

In addition, in some cases an entity may be uniquely identified by the code. This may occur for entities with determinerCode of INSTANCE (e.g. countries) as well as those with determinerCode of KIND (e.g. drugs). This equivalence cannot be safely asserted without specific knowledge of the implementation environment.

For example, the ISO country codes might be used to "identify" both country codes (geographic region) and nation codes (political organization). However, the geographic entity object of type X is not equivalent to the nation entity object of type X.

Note: If an Entity II does not have a declared scope, in most circumstances it will be reasonable to presume it is of type "OBJ" and can be treated accordingly.

Act equivalence

The same rules for determining equivalency apply on Acts as for Roles (equivalent IIs each with declared scopes other than BUSN).

Note: If an Act II does not have a declared scope, in most circumstances it will be reasonable to presume it is of type "OBJ" and can be treated accordingly.

Participation and RoleLink equivalence

The scope property for IIs on Participations and RoleLinks must never be BUSN or VIEW. As such, the IIs can always be presumed to be comparable. The sole equivalence requirement is that the objects have equivalent IIs.

Additional guidance for software implementers (to be updated)

The wording in the above section applies at the universal level without one being aware of the context/setting of where the HL7 v3 instances are being used.

xxxxxxxxxxxxxxx

The identity of the Role depends on the identity of the playing and scoping entities; those identities may not be known.

• If the playing entities are both present but not equivalent, the roles being played by these entities are (by definition) not equivalent.
• If the scoping entities are both present but not equivalent, the roles being scoped by these entities are (by definition) not equivalent.

• • There are implementations where Role identifiers are 'pushed into' the entity.

• • 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 reasonably conclude that two Roles are the same.

As a consequence of the role identity issue described above, 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.

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. If a codes identifies a single object then this is known as appellation (according to ISO 704). 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.

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.