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.

Summary: The "10. Appendix - Event Descriptions" in the PIDS spec were done
before the Notification Service was adopted. The Notification Service
uses a different mechanism to specify event types. The PIDS spec should
be updated to use the Notification Service event type language.

Summary: The "8. Appendix - Use Cases" in the PIDS spec do not accurately reflect
how PIDS is to be used. This should be updated.

Summary: PIDS specification has recommended the HL7 PID segment for standard trait names. The data type for many of the traits in the PID segment (like race, martial status etc.) are CE (Coded). An important aspect of achieving interoperatibility is to make a tight connection between coded fields and the coded vocabulary items that are possible values of the field. For example, the field "Sex" might have the allowable set of values: male, female and ambagious. To achieve that goal HL7 has defined value sets for the various coded fields. In most cases the values sets are from existing standard vocabulary like LOINC, UMLS etc. I was wondering - it will be nice if PIDS specifications also recommended the values sets for the coded fields in the PID segment to be the same as recommended by the HL7 standards.