Linking and Unlinking of Roles in Registries

Summary

This page documents a proposed way (for role-based registries) of dealing with

1. the linking of multiple Roles into one single Role. Example: merging a Patient role with a temporary ID (a 'John Doe') with the Patient role which has a permanent ID.
2. the unlinking of a Role in multiple Roles. Example: the aforementioned link of two patient roles was erroneous and needs to be undone.

Notes:

• although the examples used are related to Patient registry the proposed solution is also applicable to all other role based registries.
• this proposal doesn't cover "merging", it only covers "linking" of Roles.

Identity of Roles, modeling aspects

One of the main issues to discuss is the meaning of Role Identity, and linking roles.

• Linking is is generally understood to be a process where multiple different Role-objects are considered to be effectively one and the same Role-object. If two Role-objects are linked, both Role-objects, as well as their Role.id attributes, can be used after the linking has taken place. A link between Roles can be undone by means of an unlink.
  • Upon receipt of a link message, the receiver should establish the link between the Role.ids. The application should act as if these are all one Role - even though they are a SET of Role objects, each with a different Id. Example: if one of the Role.ids is used in a query, results for that Role.id and all linked Role.ids should be returned in the response.
  • HL7 version 2 (from 2.7, ADT A24, with additional notes in italics) The A24 event is used when the first PID segment (Role1, Role1.id) needs to be linked to the second PID segment (Role2, Role2.id) and when both patient identifiers identify the same patient. Linking two or more patients does not require the actual merging of patient information; following a link event, the affected patient data records should remain distinct. For example, this event could be used in a hospital network environment in which there are multiple campuses and in which records need to be linked. For example, hospital A, hospital B, and hospital C would each keep their own records on a patient, but an A24 link event would be sent to a corporate-wide MPI to enable the coupling of ID information with the corporate ID number. It is used for corporate data repositories, etc.

Multiple Roles associated with one playing entity

Currently one of the main modeling constructs for associating IDs (previously associated with different roles) with a Role is by means of the so-called OtherIds modeling pattern.

• See also MnM's Identifier Pattern page.

From a pure RIM-semantics standpoint this model construct indicates that "the entity playing the aRole" also plays "the OtherIDs roles". It does not imply equivalence, or linkage of Roles nor of their IDs. The Roles only share the fact that they are played by the same entity.

The entry class is the aRole class; it's ID attribute is considered to be the primary (active) ID for the aRole role. The entity plays aRole, but also has multiple OtherIDs (a role with an id attribute). aRole is the primary role, OtherIDs (as the name indicates) contains the other IDs. The entire set of IDs is 'linked' (this is a fairly loose way of linking) via the entity.

Role.statusCode

The Role state machine has an impact on how the Role is/can be used. The default status for a Role is 'active'. The status could be set to 'terminated', which means:

• (for a Patient Role) "Person is no longer a patient of person/organization X". A patient role can be set to a terminated (completed) state a suitable amount of time after a patient is deceased or a patient has severed his/her relationship with the health care organization. The role still exists and can be revised but one would not expect new events to be associated with that patient.
• (generically) "The playing entity is no longer playing the Role". The role still exists and can be revised but one would not expect new events to be associated with that role. The criteria for 'terminating' a Role may differ on a case by case basis; e.g. the Dutch national provider registry terminates a GP/PCP Role if the playing person retires, or if their license to practice is revoked.

Identification of a Role by means of another Role

The RIM offers one to specify that one Role is "identical" (for lack of better word) to another one, by means of the IDENT RoleLink.

• From the RIM (RoleLinkType coding system, RIM 0226): IDENT: The source role provides identification for the target role. The source role must be IDENT. The player entity of the source role is constrained to be the same as the player of the target role if present. If the player is absent from the source role, then it is assumed to be the same as the player of the target role.

Example: Role1 (with a temporary patient ID) has an IDENT RoleLink with Role2 (with the permament patient ID). This means that Role1 (with Role1.id) identifies Role2 (with Role2.id). Effectively this establishes a (unidirectional) link between Role1.id and Role2.id. The RoleLink.effectiveTime.high attribute could be used to terminate the IDENT RoleLink, which terminates the linkage.

Note: Role1.statusCode could be set to 'terminated' as well.

1. The temporary Role (Role1) is still available for reference (and could be the subject of an 'active' registration event)
2. Systems that honor Role1.statusCode would not use the temporary Role1 record for new events (but would instead follow IDENT to an 'active' Role record, in our example: Role2)

Q: add a statusCode attribute to RoleLink? (harmonization proposal)

Role based registries, modeling aspects

The nature of Role based Registries

The registry functionality provided in HL7 is based on a model which contains a RegistrationProcess (REG) Act, with a subject Role.

The RegistrationProcess contains meta-information related to the registered Role (e.g. the author of the registration, the validity of the registration). Where document registries maintain a set of document metadata (as well as the document itself) throughout the document lifecycle, Role registries maintain a set of metadata (as well as the details of the Role) throughout the Role lifecycle.

Registrationprocess.statusCode contains the status of the registration.

• If 'active' the registration and its subject Role are to be considered valid-for-use; if 'obsolete' the registration and its subject Role are to be considered not valid (obsoleted, replaced by a different RegistrationProcess act and another Role). Example: a Patient registry contains Patient Registrations (a combination of the RegistrationProcess Act and the Patient Role details). Only those registrations that are 'active' will be inlcluded in the potential result set for the query.
• If 'obsolete' the registration has been replaced by another (more recent, from a more dependable source) registration. Note: the obsoletion of a registration does not have any impact on the the status of its subject Role. These two statuses are independent on each other.

Replacement of prior registrations

Role based registries support the concept of replacing existing registrations. This feature can be used to:

1. Replace an existing registration for a Role x by another registration for Role x.
   • Example: the registration of a patient received from an HIS system which replaces a prior registration of the same patient done by a Laboratory application. HIS systems are generally considered to be a more authoritative source of demographics data than Laboratory applications.
2. Using the current Patient Registry Duplicates Resolved(PRPA_IN201304UV02) interaction the existing Roles remain 'active'.
   • The current Patient Registry Duplicates Resolved(PRPA_IN201304UV02) is effectively the same as: (1) obsolete old registration associated with Role2, followed by (2) update existing registration and payload for Role1. The status of Role2 is as it was prior to the obsoletion of its associated registration.

Note: RegistrationProcess.id is an optional attribute, quite a few registries identify the applicable RegistrationProcess act by means of the Role.id attribute of the Role. If a registry doesn't use RegistrationProcess.id it can not contain multiple instances of the same Role (it's a SET of Roles, not a BAG or Roles).

New Norwegian use-case: link/unlink

There are two reasons for revisiting the way we currently deal with merging of Roles:

1. There are Norwegian use-cases for Unlinking. Our current registry material (Normative Edition 2010) is silent on that subject (linking as well as unlinking). If the statusCode of an (registration)Act is obsolete [which is what happens if we use the current Duplicates resolved interaction), we can't reactivate; there is no Act status transition from obsolete to active.
   • Therefore, unlinking (of two Roles which had ID A1 and B1 prior to the link, respectively) currently requires that we obsolete all registrations that have A1 or B1 in either Role.id or OtherIds.id, and create two entirely new registrationActs: one for A1 (in role.id), with registrationAct.statusCode = active; and one for B1 (in role.id), with registrationAct.statusCode = active. So that would be two new registrationActs, that (as a group with 2 components) replaces a group of existing registrations (i.e. all registrations related to A1 and B1).
2. Although one can establish a link (replacement) between registrations (registrationActs) there is no explicit modeling related to the fact that Roles may have been completed/obsoleted by a link; the IDENT role link feature also isn't used in the current models.

Proposed new way of dealing with link/unlink

When it comes to linking there seem to be two separate issues we need to resolve:

1. Visibility in a Role registry of a Role.id
   • In some scenarios the old role.id should no longer be 'visible'/'queryable' in a Role registry; in other scenarios both Ids should be visible [the latter is actually applicable in Norway].
   • Visibility is entirely determined by the status of a registration in the Role registry. If registrationAct.statusCode is 'active', the registration (and its payload subject) can be actively used/queried for.
2. Linkage
   • There are scenarions were a one-way linkage from the old Role to a new one is applicable [this is the Norwegian use-case]; and others where there should be a two-way linkage between both roles involved [as is the case in the IHE PIX profile].
     • This can be done using the IDENT role link: a unideriectional or bidirectional IDENT between the two roles involved.

In other words,

1. a new "Unidirectional Role Link Notification" interaction (Role1, Role2, assuming registrations for these Roles already pre-exist prior to the link) would:
   1. Update the payload model associated with the Role2 registration to include that "Role2 IDENTs Role1" (thus creating an unidirectional link from Role2.id to Role1.id)
2. a new "Bidirectional Role Link Notification" interaction (Role1, Role2, assuming registrations for these Roles already pre-exist prior to the link) would:
   1. Update the payload model associated with the Role2 registration to include that "Role2 IDENTs Role1" (thus creating a first unidirectional link from Role2.id to Role1.id)
   2. Update the payload model associated with the Role1 registration to include that "Role1 IDENTs Role2" (thus creating a second unidirectional link from Role1.id to Role2.id)

The "Unidirectional Unlink Notification" interaction would:

1. Update the payload model associated with the Role2 registration to remove the fact that "Role2 IDENTs Role1" (thus undoing the unidirectional link from Role2.id to Role1.id)

When queried for the Role with Role2.id, the registry would return a RegistrationAct with a subject (focal) Role that has Role2.id as its Id; the payload role would also have the IDENT Role1 relationship which indicates that Role2 is used to identify another Role (Role1). That way a querying application will know there is a link from Role2 to Role1.

Proposed Model changes

• Turn registrationAct.id into a mandatory attribute
  • This was already agreed upon in earlier Wrappers R2 work
• Extend the current payload models used in Role-based registries to include an "IDENT Role" relationship associated with the focal Role in the payload
• Create a set of new interactions, at least:
  • Establish link: Unidirecional/Biderectional Role Link Notification
  • Request establishment of a link: Request to Uni/Bi Link Roles; Reject Uni/Bi Request to Link Roles
  • Undo link: Unidirectional Role UnLink Notification
  • Change status of registration (to change 'visibility' of a registration): Complete Registration Act; Activate Registration Act.

Proposed RIM changes

• Create a harmonization proposal to add effectiveTime: IVL<TS> to RoleLink.
• Discussion: depending on the level of status management we wish to have on the RoleLink we may want to create a proposal to also add a statusCode to RoleLink. This is controversial and would require a solid use-case to back it up.

Proposed R-MIM Changes

The model below shows the change to the Patient topic R-MIMs. A RoleLink is added to the current R-MIMs, there are no other changes.

The IDENT RoleLink could be modeled in either direction, the direction in the above model is based on the assumption (by HL7 Norway, for their use-cases) that:

• If one queries for a temporary Patient Id, the application that processes the query will be smart enough to put the primary patient ID in the (focal class) aRole, and the temporary Patient Id in OtherIDs. In that situation "OtherIDs IDENTs aRole" - which is the direction as shown in the model.