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

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 objects are being used.

The following also applies at the universal leve:

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

Equivalence can only really be determined if one knows the value II.scope. HL7 v3 implementers (RIMBAA implementers) that use Datatypes R1 should pre-adopt II.scope, i.e. support that concept in their application even if the wire format doesn't. In most circumstances (though not universally so, see below) the value of II.scope can be determined by looking at II.root. See section below for details.

On occasion Entities may be identified through Entity.code instead of Entity.id. If the concept codes in a coding system identifies a single object (e.g. then this is known as appellation (according to ISO 704). In most circumstances (though not universally so, see below) the value of C?.codingSystem (an OID) can be used to determine if it acts as an identifier. See section below for details.

There are implementations where Role identifiers are 'pushed into' the entity; the role object itself doesn't have a populated id. One can reasonably assume the role.id to be the same as the entity.id.

If the Role.id of at least one Role object has an unknown II.scope, then two Role objects can only be said to be identical if: scoping entities are identical AND playing entities are identical AND code/classCode of the Role objects are the same, THEN one could reasonably conclude that two Role objects are the same.

All RIMBAA applications, in order to decide if two roles are the equivalent will have to build some kind of "role identity management component".

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.

II.root and II.scope

It is tempting to look at the root OID, and if it is equal to (for example) the OID of the US SSN identification scheme (a widely used identifier for all sorts of roles), to state that the II.scope is therefore equal to BUSN.

At the universal level this however isn't true. For the above example it depends on the scoper of the Role: if the scoper is the US Governement (who assigns SSNs), then the II.scope will be OBJ (the US Governement uniquely identifies one single citizen by means of an SSN). If the scoper is a hospital, the use of SSN is as a BUSN identifier. There are also circumstances where (e.g. for Acts) one systems OBJ scoped II is another systems VER scoped II.

Whilst one may not be able to deduce the value of II.scope from II.root at the universal level it is very likely that one is able to do so within a single project/context. Within a specific context one will be aware if (for example) the scoper of a role identified with an SSN will ever be the US Government. If not, then the SSN root OID implies that the scope of the identifier is BUSN.

Entity.code and appellations

It is tempting to look at the OID of the coding system, and if it is equal to (for example) the OID of the ISO Country coding system, to state that the code is an appellation (i.e. that the code is an identifier with scope OBJ).

At the universal level this however isn't true. For example, the ISO country codes might be used to "identify" both Country entities (geographic region) as well as Nation entities (political organization). However, the geographic entity object of type X is not equivalent to the nation entity object of type X.

Whilst one may not be able to deduce whether or not a code is an appellation at the universal level it is very likely that one is able to do so within a single project/context. Within a specific context one will be aware that (for example) Country entities are never used. In that case the codeSystem OID for the ISO Country coding system implies that the code always has the appellation characteristic.