Issue 2093: The spec is not clear enough on How to Handle Links (pids-rtf2) Source: (, ) Nature: Uncategorized Issue Severity: Summary: Summary: The spec is not clear enough on How to Handle Links Based on clear feedback in HL7 forums, I know there is serious concern over the fact that our Interfaces and info model show explicit support for merges (merges deactivate one dupe and leave another intact) but only implicit support for links (links leave multiple intact; In effect, they simply assert or "record" dupes). I find the last paragraph of 2.7 confusing: If PIDS implementations are to be able to "carry administrative and auditing attributes such as timestamp, user stamp, source system, and specific operation types", then it raises thevalid question: how does the implementation know when a link operation has occurred? We do not tell them anywhere in the spec as it stands. Resolution: Revised Text: Actions taken: October 16, 1998: received issue Discussion: End of Annotations:===== Return-Path: From: "Jon Farmer" To: "Issues PIDS" Subject: Fw: PIDS Issues Resolution Date: Fri, 16 Oct 1998 13:48:39 -0400 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 -----Original Message----- From: Tim Brinson To: Jon Farmer Cc: pids-rtf@omg.org Date: Thursday, October 15, 1998 12:16 PM Subject: Re: PIDS Issues Resolution Jon, I suggest you send an issue in on this (issues@omg.org), to be considered by the next RTF. Tim ------------------------------------------ Jon Farmer wrote: I want to raise another Issue, which has been raised before several times but possibly not recorded: The spec is not clear enough on How to Handle Links Based on clear feedback in HL7 forums, I know there is serious concern over the fact that our Interfaces and info model show explicit support for merges (merges deactivate one dupe and leave another intact) but only implicit support for links (links leave multiple intact; In effect, they simply assert or "record" dupes). The HL7 communities that have studied this area for years before we got started (The Patient Admin and Financial Management) know that merges and links deserve equal and explicit representation. I believe that any vendor that has implemented a single-domain MPI knows this as well. I think our ProfileAccess, IdMgr (, and now CorreltionMgr) interfaces can handle links implicitly by accepting multiple ExternalIDs from the same ID Domain and considering them Linked. I still think this would work, but in the interest of clarity (and interoperability, which is our reason for existence) I think we should clearly specify exactly where in the interfaces links are communicated. I am embarrassed whenever I have to explain "I know it looks like it's missing, but we have it covered if you look closely enough". I find the last paragraph of 2.7 confusing: If PIDS implementations are to be able to "carry administrative and auditing attributes such as timestamp, user stamp, source system, and specific operation types", then it raises thevalid question: how does the implementation know when a link operation has occurred? We do not tell them anywhere in the spec as it stands. I believe this whole issue can be remedied by modifying the PIDS Conceptual Model to show a third associative (many-many) relationship from QualifiedID to itself, called Linked; and either: a) add explicit text to 2.7 that states that client asserts a links whenever it supplies multiple qualified IDs in the same ID Domain in the following operations: ProfileAccess:update_and_clear_traits CorrelationMgr: load_profiles and find_or_register or, Better in my opinion, would be the following: b) add link_ids and unlink_ids operations that mirror the merge_ids and unmerge_ids operations. Both link_ids and unlink_ids take an input argument of PersonIDSeq ids_to_link: IdInfoSeq link_ids ( in PersonIdSeq ids_to_link) raises (InvalidIds, duplicateIds); IdInfoSeq unlink_ids( in PersonIdSeq ids_to_unlink) raises (InvalidIds, duplicateIds); I think this second approach is totally clear when presented adjacent to the merge-related ops. If we make this change then all the existing 2.7 text is intact, but it doesn't leave people and their implementations wondering how to detect a link.