XDS Merge Patient Identifiers Supplement - Discussion

History

The current Supplement represents the third design of an answer to the question of how to handle Merge Patient Identifier (A40) messages from the Patient Identity Feed. First some terminology. The Merge message provides two patient identifiers: MRG-1, the identifier that is going away (being merged into the other) which we call the subsumed patient identifier in this Supplement. The other patient identifier, PID-3, is the identifier that will continue to be used which we call the remaining patient identifier.

The first design attempted to record in registry metadata detailed results of the merge. This used the existing Document Replace mechanism (RPLC Association type) to replace all XDSDocumentEntry objects belonging to the subsumed patient identifier with new XDSDocumentEntry objects which carried the remaining patient identifier. The subsumed and remaining versions of the XDSDocumentEntry referenced the same URI in the Repository. Actually, the two copies of the object were identical except for the XDSDocumentEntry.PatientId attribute. This design went well until we considered the impact on Document Replace, Transformation, Addendum submissions. The process of replacing an entire tree of metadata representing the life cycle of the document with new metadata representing the new patient identifier was too complicated. The two uses of Document Replace brought too many conflicts. Although abandoned, the good part of this design was that it had no impact on queries, at least on the simplest queries where the lineage of a document was not of concern. The replacement contained the remaining patient identifier which made query easy.

The second design abandoned any attempt at metadata updating and focused on supporting the linking of patient identifiers outside of metadata. Since we did not want to impose a rewriting of metadata in the response to a query, we decided to use the Link/Unlink messages in the Patient Identity Feed to trigger this action. This seemed consistent with the semantics we could easily specify for registry. A link message would update a table of linked patient identifiers. Any implementation of Stored Query requires that parameters of the query be extracted from the request and inserted into some sort of query template custom built for the registry implementation. Using link, we asserted that it would be easy for an implementer to add a step to this process, replace patient identifiers with lists of equivalent patient identifiers. A big negative would be that a Document Consumer would see the original patient identifiers in metadata, a result of the definition of link. This approach was abandoned for several reasons: effect on Document Consumers, Merge is part of transaction 8 which is already specified as part of XDS while Link is part of another transaction which is not currently associated with XDS, if we used Link then the community would expect Unlink which as a huge semantic conflict with folders which we have not yet solved. The following steps demonstrate the problem:

• Submit Document for Patient ID A
• Submit Folder for Patient ID B
• Link Patient ID A and Patient ID B
• Add Document (Patient ID A) to Folder (Patient ID B) - this is legal because of the Link
• Unlink Patient ID A and Patient ID B - the above Folder/Document linkage is now illegal by the rules of XDS.

Although the processing of Link can be handled automatically, Unlink may require manual intervention.