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.

The third design, the one documented in the Supplement, combines the best of the prior two approaches. It goes back to Merge because of its inclusion in transaction 8. It specifies that the results of a Merge must be present in the results of a Stored Query. This allows registry implementers to update the database tables representing registry metadata to reflect the patient identifier merge or keep a separate table and rewrite the metadata before it is returned in a Stored Query. Since there is no UnMerge action documented, either approach will fit the profile.

Closed Issues reflecting Link Design

The following are the documented Closed Issues from the second design utilizing Link. There are kept here for possible public review and to support any future discussion of Link.

1. What XDS actors would be responsible for managing Patient ID Linking?

The Document Registry manages all aspects. The only requirement levied on the Document Consumer is to ignore apparent inconsistencies in the Patient ID attribute of returned metadata. An exception is the handling of SQL queries (ITI-16) where Equivalent Patient IDs are managed by the Document Consumer.

1. How does Patient ID linking affect the Stored Query transaction?

• A Stored Query request that includes the Patient ID as a parameter may return metadata referencing other Patient Ids. The Document Consumer is to assume this occurs because of Patient ID Linking.