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
(New page: ==Summary== *This page documents a proposed way (for role-based registries) of dealing with *#the merging of multiple Roles into one single Role. Example: merging a Patient role with a te...)
 
Line 4: Line 4:
 
*#the unmerging of a Role in multiple Roles. Example: the aforementioned merge of two patient roles was erroneous and needs to be undone.
 
*#the unmerging of a Role in multiple Roles. Example: the aforementioned merge of two patient roles was erroneous and needs to be undone.
  
Note that although the examples used are related to Patient registry the proposed solution is also applicable to all other role based registries.
+
Notes:
 +
#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 status of the registration is managed though a RegistrationProcess Act (which has a subject Role). 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).
 +
#although the examples used are related to Patient registry the proposed solution is also applicable to all other role based registries.
  
 
==Example use-case==
 
==Example use-case==
Line 27: Line 29:
 
-registrationAct 98, Role.id A1, registrationAct.statusCode active
 
-registrationAct 98, Role.id A1, registrationAct.statusCode active
 
-registrationAct 99, Role.id B1, 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.

Revision as of 14:56, 23 June 2010

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.

Notes:

  1. 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 status of the registration is managed though a RegistrationProcess Act (which has a subject Role). 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).
  2. although the examples used are related to Patient registry the proposed solution is also applicable to all other role based registries.

Example use-case

This section documents a use-case from the Norwegian Patient Registry project. The use-case is referenced

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.