XDS Merge Patient Identifiers Supplement - Discussion

Cross-Enterprise Document Sharing (XDS) Patient Identity Merge

Status: Trial Implementation

Current Supplement: http://www.ihe.net/Technical_Framework/upload/IHE_ITI_TF_Supplement_XDS_Patient_Merge_TI_2007_08_15.pdf

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.

First Design 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.

Second Design 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.

Third Design 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.
2. 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.
3. How does Patient ID linking affect the Query transaction?
   • The Query transaction (raw SQL) does not process Patient ID Linking. If the Document Consumer wishes to use the Query transaction in an environment where Patient ID Linking is used then it must receive the Patient Identity Feed and manage Patient ID Linking itself.
4. What about Patient ID Merge?
   • Merge is much harder to implement than Link within the Document Registry if the result of the merge is to be documented in metadata. Un-Merge is even harder to implement. As a result, XDS and the Document Registry will rely only on Link Patient ID and Merge will be left out of the specification. An example of the complexity of implementing Merge is to consider the interaction between Link/Unlink requests and Document Replacement/Update/Translation. The committee has considered this approach in the past and can discuss/document the details if needed.
5. Should UnLink be required along with Link?
   • Given that Link can be implemented as a separate table in the registry which is referenced in the processing of Stored Query requests, UnLink can be just as easy to implement, a table update.
6. Are new transactions needed to support Link Patient ID in XDS?
   • No. But, changes are required in functionality in the following actor/transaction pairs: Document Registry/ Patient Identity Feed; Document Registry/ Stored Query; and Document Consumer/Stored Query. There are implications for the quality of data available via the Query transaction.
7. What added functionality is required in these actors?
   • Document Registry: Stored Query: Link/UnLink Patient ID messages (Patient Identity Feed transaction) must be captured and the link information maintained. Stored Query transaction implementation must translate the Patient ID present in some queries into a list of Patient Ids for the internal query.
   • Document Registry: Register: the existence of Equivalent Patient IDs affects the process of metadata validation.
   • Document Consumer: Stored Query: Ignore multiple/differing Patient Ids in Stored Query results. If using SQL Query transaction, receive and manage Patient Identity Feed and issue SQL queries that reference all the necessary Patient Ids.
8. What impact is there for the work on Cross-Affinity Domain profiles?
   • For Stored Queries incoming from the Bridge: as long as one historically valid Patient ID is referenced the Equivalent Patient ID functionality in the Registry will work as expected. SQL would not be practical for Cross-Affinity Domain queries.
   • For Stored Queries being sent to the Bridge: it may be necessary to include all Equivalent Patient Ids and the associated demographics in the query.
9. Should Merge Patient ID (and UnMerge) messages be accepted but be interpreted as Link/UnLink? #*NO
10. Does the stated transitive property documented in Use Case 1 follow the intent of HL7 and message A24?
    • Only known experience comes from Japan. PAM implies it does (see section 3.30.6.6.1 Trigger Event)
11. The solution presented here to the ‘linking/merging of Patient IDs’ does not allow the Document Consumer actor to determine what IDs were linked/merged by querying the registry. It can only be determined by accepting and interpreting the Patient Identity

Feed. This is acceptable.

1. How can UnLink be handled? For instance, if two Patient IDs are linked then a document attributed to one of the Patient IDs is added to a folder attributed to the other and then an UnLink is received. Should the document be removed from the folder? Something similar can happen with submission sets.
2. UnLink is not yet specified.
3. Need to study use cases of UnLink by message vs by admin procedure.
4. Make sure it is clear that we are only linking Affinity Domain patient IDs.
5. Need note discussing consequences of managing local patient ids and how this flows to linking AD patient IDs.
6. Merge/Link/Unlink must all result in an audit message.
7. Can an UnLink Patient ID request be processed if there were no matching Link Patient ID request preceeding it?
   • No. If a single Patient ID is found to represent multiple patients, there is not enough information in the XDS Registry actor to allow for separation. This will require manual/external intervention.
   • But, if/when this manual intervention occurs, should it be documented in metadata? How?