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
 
(48 intermediate revisions by the same user not shown)
Line 1: Line 1:
−
==Summary==
+
Summary: this page contains a proposal to change the Person registry static models with regard to the linking of person records. The proposal effectively also applies to any other role based registry, it's an example of a [[Design Patterns for RIM Models]].
−
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.
 
  
−
Note: although the examples used are related to Patient registry the proposed solution is also applicable to all other role based registries.
+
*Note: This page contains the current/open proposal. Past discussions are archived on the [[Talk:Linking and Unlinking of Roles in Registries]] page.
  
−
==Role based registries, modeling aspects==
+
Note: the HL7 Norway wiki is being migrated, some images/links are still missing.
−
===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.  
+
==Proposal==
 +
This page proposes a number of changes:
 +
#See [http://www.hl7.no/hl7wiki/index.php?title=Identification_of_Patients_and_Persons#HL7_version_3_model] for documentation of the modeling principles used to link Person Records - this model is the outcome of prior discussions (see above for a link to the documentation associated with that discussion)
 +
#PA D-MIM: add identifiedBy and OtherIdentifiedPerson classes, as shown in the R-MIM model on this wiki page: [http://www.hl7.no/hl7wiki/index.php?title=PersonRegistry.LinkPersonRecords].
 +
#*Discussion PA Sept. 1011: in UV model, add optional recursive RoleLink IDENT on OtherIdentifiedperson. Helen: add recursion on IdentifiedPerson ? Rene: has the effect that scoper becomes required for all roles in the IDENT link. Helen: or make scoper of IdentifiedPerson optional ? Rene: ask MnM and PA lists. ACTION Jay to do so.
 +
#Add an R-MIM and interaction for a new LinkPersonRecords interaction with an application acknowledgement, see [http://www.hl7.no/hl7wiki/index.php?title=PersonRegistry.LinkPersonRecords]
 +
#Add an R-MIM and interaction for a new UnlinkPersonRecords interaction with an application acknowledgement, see [http://www.hl7.no/hl7wiki/index.php?title=PersonRegistry.UnlinkPersonRecords].
 +
#Add the identifiedBy and OtherIdentifiedPerson classes to the response interaction of the GetPersondemographics interaction, to expose any linkages in the response, see [http://www.hl7.no/hl7wiki/index.php?title=PersonRegistry.GetDemographics]
 +
#Discuss whether the guidance provided in the Norwegian project related to the collapsing (transitivity of) linkages in section [http://www.hl7.no/hl7wiki/index.php?title=Identification_of_Patients_and_Persons#Method_of_linking_identifiers] is universallay applicable or whether such guidance is project specific.
  
−
[[Image:Patreg 1.PNG]]
+
PA Sept 2011: request to send link to Norwegian wiki to PA list.  
  
−
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.
+
PA MOTION: (see minutes) PA agrees with direction.
−
 
 
−
Example: a Petient registry contains Patient Registrations (a combination of the RegistrationProcess Act and the Patient Role details).
 
−
 
 
−
===Linking of registrations===
 
−
 
 
−
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'').
 
−
 
 
−
 
 
−
 
 
−
 
 
−
[[Image:Patreg merge 1.PNG]]
 
−
 
 
−
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).
 
−
 
 
−
===Linking Roles===
 
−
 
 
−
[[Image:Patreg otherids.PNG]]
 
−
 
 
−
===Role equivalence===
 
−
The RIM also offers one top specify that one Role is identical(?) to another one, by means of the IDENT RoleLink.
 
−
 
 
−
[[Image:Patreg ident.PNG]]
 
−
 
 
−
*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 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.
 

Latest revision as of 23:59, 14 September 2011

Summary: this page contains a proposal to change the Person registry static models with regard to the linking of person records. The proposal effectively also applies to any other role based registry, it's an example of a Design Patterns for RIM Models. 

Note: the HL7 Norway wiki is being migrated, some images/links are still missing.

Proposal

This page proposes a number of changes:

  1. See [1] for documentation of the modeling principles used to link Person Records - this model is the outcome of prior discussions (see above for a link to the documentation associated with that discussion)
  2. PA D-MIM: add identifiedBy and OtherIdentifiedPerson classes, as shown in the R-MIM model on this wiki page: [2].
    • Discussion PA Sept. 1011: in UV model, add optional recursive RoleLink IDENT on OtherIdentifiedperson. Helen: add recursion on IdentifiedPerson ? Rene: has the effect that scoper becomes required for all roles in the IDENT link. Helen: or make scoper of IdentifiedPerson optional ? Rene: ask MnM and PA lists. ACTION Jay to do so.
  3. Add an R-MIM and interaction for a new LinkPersonRecords interaction with an application acknowledgement, see [3]
  4. Add an R-MIM and interaction for a new UnlinkPersonRecords interaction with an application acknowledgement, see [4].
  5. Add the identifiedBy and OtherIdentifiedPerson classes to the response interaction of the GetPersondemographics interaction, to expose any linkages in the response, see [5]
  6. Discuss whether the guidance provided in the Norwegian project related to the collapsing (transitivity of) linkages in section [6] is universallay applicable or whether such guidance is project specific.

PA Sept 2011: request to send link to Norwegian wiki to PA list.

PA MOTION: (see minutes) PA agrees with direction.

Retrieved from "https://wiki.hl7.org/w/index.php?title=Linking_and_Unlinking_of_Roles_in_Registries&oldid=54319"