Linking and Unlinking of Roles in Registries

Summary

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

1. the merging 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 unmerging of a Role in multiple Roles. Example: the aforementioned merge of two patient roles was erroneous and needs to be undone.

Note: although the examples used are related to Patient registry the proposed solution is also applicable to all other role based registries.

Identity of Roles, modeling aspects

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

• Fusion is a process whereby two identical Role-objects are fused into one single Role-object.
  • Example: if, because of serialization requirements, a receiver has an in-memory object structure which contains the same object twice, these can be fused into one object.
• Merging is generally understood to be a process where multiple different Role-objects are considered to be effectively one and the same Role-object, and where one of these Roles is judged to be "the best record" (in terms of richness, identification scheme used, etc.) of the role. If two Role-objects are merged, on of the Role.id attributes is meant to "survive" the merge, the other Role.id can no longer be used after the merge. After the merge it will appear as if the second Role.id never existed at all. Merging is a one -way process, there is no unmerge.
  • One could also think of this as a "Replace": upon receipt of a merge message, the receiver is requested to replace all mention/use/references to the old Role (Role.id) with the details of the surviving Role (Role.id). After the replacement the old Role and Role.id will be purged from the system.
  • HL7 version 2 (from 2.7, A40) A merge has been done at the patient identifier list level. That is, two PID-3 - Patient Identifier List identifiers have been merged into one. An A40 event is used to signal a merge of records for a patient that was incorrectly filed under two different identifiers. The "incorrect source identifier" identified in the MRG segment (MRG-1 - Prior Patient Identifier List) is to be merged with the required "correct target identifier" of the same "identifier type code" component identified in the PID segment (PID-3 - Patient Identifier List). The "incorrect source identifier" would then logically never be referenced in future transactions. It is noted that some systems may still physically keep this "incorrect identifier" for audit trail purposes or other reasons associated with database index implementation requirements.
• 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 Roles, 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, A24) The A24 event is used when the first PID segment needs to be linked to the second PID segment 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

The current mechanism for associating IDs (previously associated with different roles) with a Role is by means of the so-called OtherIds modeling pattern.

Example: 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' via the entity.

Identification of a Role by means of another Role

The RIM also offers one top 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): 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 link between Role1.id and Role2.id. The RoleLink.effectiveTime.high attribute could be used to terminate the IDENT RoleLink, which terminates the linkage.

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.

Linking of registrations

Role based registries support the concept of merging roles (e.g. Patient Registry Duplicates Resolved(PRPA_IN201304UV02)). One doesn't actually merge roles; the existing Roles remain 'active'. The ID attributes (and perhaps some of the associated demographics details) are used (after the merge) in one single Role (the top one in the figure below). The non-surviving Role is modeled (as the bottommost act and role) as an 'obsoleted' registration act.

RegistrationProcess.id is optional, 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).

Example use-case

This section documents a use-case from the Norwegian Patient Registry project. The use-case is referenced in the remaining sections of this proposal.

If the central registry has two patient records: -regsitrationact 1, Role.id A1, registrationAct.statusCode active -registrationAct 2, Role.id B1, registrationAct.statusCode active

OPTION 1 - We merge these using duplicates resolved, we get (registrationAct 1 replaces registrationAct2): -regsitrationact 1, Role.id A1, OtherId B1, registrationAct.statusCode active -registrationAct 2, Role.id B1, registrationAct.statusCode obsolete

OPTION 2 - We merge these using duplicates resolved, we get (new registrationAct 3 replaces registrationAct2; registrationAct 3 also replaces registrationAct1): -regsitrationact 1, Role.id A1, registrationAct.statusCode obsolete -registrationAct 2, Role.id B1, registrationAct.statusCode obsolete -registrationAct 3, Role.id A1, OtherIDs B1, registrationAct.statusCode obsolete

Is option 1, or option 2, the proper way to do things? Both would probably work..

There are Norwegian use-cases for UNmerging/Unlinking. Our current registry material is silent on that subject. If the statusCode of an (registration)Act is obselete, we can't reactivate. Therefore, unlinking A1 and B1 (in the above example) requires that we obsolete all registrations that have A1 or B1 in either Role.id or OtherIds.id, and create two entirely new registrationActs: -registrationAct 98, Role.id A1, registrationAct.statusCode active -registrationAct 99, Role.id B1, 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).

Maybe we need just one interaction: "replaceRegistration". That's effectively what both Duplicatesresolved and Unmerge accomplish.