Difference between revisions of "Linking and Unlinking of Roles in Registries"
Rene spronk (talk | contribs) (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...) |
Rene spronk (talk | contribs) |
||
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. | ||
− | + | 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
- 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.
- the unmerging of a Role in multiple Roles. Example: the aforementioned merge of two patient roles was erroneous and needs to be undone.
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
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.