This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

Difference between revisions of "Linking and Unlinking of Roles in Registries"

From HL7Wiki
Jump to navigation Jump to search
Line 1: Line 1:
 
==Summary==
 
==Summary==
 
This page documents a proposed way (for role-based registries) of dealing with  
 
This page documents a proposed way (for role-based registries) of dealing with  
−
#the merging/linking (see below for a discussion of these two terms) 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.
+
#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.
−
#the unmerging/unlinking of a Role in multiple Roles. Example: the aforementioned merge/link of two patient roles was erroneous and needs to be undone.
+
#the unlinking of a Role in multiple Roles. Example: the aforementioned merge/link 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.
 
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==
 
==Identity of Roles, modeling aspects==
−
One of the main issues to discuss is the meaning of [[Object_identity#Object_Identity_for_Roles|Role Identity]], ''merging roles'' and ''linking roles''.
+
One of the main issues to discuss is the meaning of [[Object_identity#Object_Identity_for_Roles|Role Identity]], and ''linking roles''.
−
*'''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 preferred record" (in terms of richness, identification scheme used, etc.) of the two. If two Role-objects are merged, one of the Roles (and its Role.id attribute) is meant to "survive" the merge, the other Role (and its Role.id) can no longer be used after the merge. After the merge it will appear as if the second Role (and its 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 (including the Role.id) with the details of the surviving Role (inclusive of its Role.id). After the replacement the old Role and Role.id will be purged from the system. 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.
 
−
**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.
 
*'''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.
 
**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.
Line 50: Line 47:
 
#Replace an existing registration for a Role x by another registration for Role x.  
 
#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.
 
#*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.
−
#Merge roles (e.g. Patient Registry Duplicates Resolved(PRPA_IN201304UV02)). One doesn't actually merge roles; the existing Roles remain 'active'.
+
#Using the current Patient Registry Duplicates Resolved(PRPA_IN201304UV02) interaction the existing Roles remain 'active'.  
−
#*Example: Role1 (''the top one in the figure below'') is to be merged with Role2, with Role1 as the 'surviving/merged' role. The ID attributes (and perhaps some of the associated demographics details) are used (after the merge) in Role1 (the topmost registration and its payload Role1 are updated to reflect the merged information). The non-surviving Role2 is modeled (''as the bottommost act and role'') as an 'obsoleted' registration act.
 
 
#*A merge (in the context of 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.  
 
#*A merge (in the context of 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.  
  
Line 58: Line 54:
 
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).
 
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: unmerge/unlink==
+
==New Norwegian use-case: link/unlink==
 
There are two reasons for revisiting the way we currently deal with merging of Roles:
 
There are two reasons for revisiting the way we currently deal with merging of Roles:
−
#There are Norwegian use-cases for UNmerging/Unlinking. Our current registry material (Normative Edition 2010) is silent on that subject. 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.
+
#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/unmerging (of two Roles which had ID A1 and B1 prior to the merge/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).
+
#*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).
 
#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 merge/link; the IDENT role link feature also isn't used in the current models.
 
#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 merge/link; the IDENT role link feature also isn't used in the current models.
  
 
==Proposed new way of dealing with merge and link==
 
==Proposed new way of dealing with merge and link==
−
When it comes to merging/linking there seem to be two separate issues we need to resolve:
+
When it comes to linking there seem to be two separate issues we need to resolve:
 
#Visibility in a Role registry of a Role.id
 
#Visibility in a Role registry of a Role.id
−
#*When merged, the old role.id should no longer be 'visible'/'queryable' in a Role registry. When a role is linked to another Role, both should be visible.
+
#*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.
 
#*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.
 
#Linkage
 
#Linkage
−
#*A merge is a one way linkage from the old Role to a new one; a link is a two-way linkage between both roles involved
+
#*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 merge is an IDENT from OldRole to SurvivingRole; a link is a bidirectional IDENT between the two roles involved.
+
#**This can be done using the IDENT role link: a unideriectional or bidirectional IDENT between the two roles involved.
  
 
In other words,  
 
In other words,  
−
#a new "Role Merge Notification" interaction (Role1, Role2, assuming registrations for these Roles already pre-exist prior to the merge) would:
+
#a new "Unidirectional Role Link Notification" interaction (Role1, Role2, assuming registrations for these Roles already pre-exist prior to the link) would:
−
##Set registrationAct.statusCode to completed or obsolete for the registration associated with Role1 (thus rendering the id of Role1 invisible)
+
##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)
−
##*The use of the completed act status has the advantage that one can change the status back to active should this be necessary at a later point in time (e.g. as part of an unmerge activity). An obsolete status can't be transitioned into any other status.
+
#a new "Bidirectional Role Link Notification" interaction (Role1, Role2, assuming registrations for these Roles already pre-exist prior to the link) would:
−
##Update the payload model associated with the Role2 registration to include that "Role1 IDENTs Role2" (thus creating a unidirectional link from Role2.id to Role1.id)
+
##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)
−
#and a new "Role Link Notification" interaction (Role1, Role2, assuming registrations for these Roles already pre-exist prior to the link) would:
+
##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)
−
##Update the payload model associated with the Role2 registration to include that "Role1 IDENTs Role2" (thus creating a first unidirectional link from Role1.id to Role2.id)
 
−
##Update the payload model associated with the Role1 registration to include that "Role2 IDENTs Role1" (thus creating a second unidirectional link from Role2.id to Role1.id)
 
  
−
The unlink interaction would:
+
The "Unidirectional Unlink Notification" interaction would:
−
#Update the payload model associated with the Role2 registration to remove the fact that "Role1 IDENTs Role2" (thus undoing the unidirectional link from Role1.id to Role2.id)
+
#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)
−
#Update the payload model associated with the Role1 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===
 
===Proposed Model changes===
Line 91: Line 86:
 
*Extend the current payload models used in Role-based registries to include an "IDENT Role" relationship to the focal Role in the payload
 
*Extend the current payload models used in Role-based registries to include an "IDENT Role" relationship to the focal Role in the payload
 
*Create a set of new interactions, at least:
 
*Create a set of new interactions, at least:
−
**Role Merge Notification
+
**Unidirecional/Biderectional Role Link Notification
−
**Request to Merge Roles; Reject Request to Merge Roles
+
**Request to Uni/Bi Link Roles; Reject Uni/Bi Request to Link Roles
−
**Role Link Notification
+
**Unidirectional Role UnLink Notification
−
**Request to Link Roles; Reject Request to Link Roles
 
−
**Role UnLink Notification
 
−
**Request to UnLink Roles; Reject Request to UnLink Roles
 

Revision as of 10:26, 10 July 2010

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 merge/link 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, 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.

Patreg otherids.PNG

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.

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.

Patreg ident.PNG

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.

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.

Patreg 1.PNG

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'.
    • A merge (in the context of 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.

Patreg merge 1.PNG

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 merge/link; the IDENT role link feature also isn't used in the current models.

Proposed new way of dealing with merge and link

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 to the focal Role in the payload
  • Create a set of new interactions, at least:
    • Unidirecional/Biderectional Role Link Notification
    • Request to Uni/Bi Link Roles; Reject Uni/Bi Request to Link Roles
    • Unidirectional Role UnLink Notification
Retrieved from "https://wiki.hl7.org/w/index.php?title=Linking_and_Unlinking_of_Roles_in_Registries&oldid=39071"