Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.


In this case need to detect the patient merge, and perform a fresh retrieval of all content, there is no way for the server to return any error codes in this use case, and may also need to consider notification mechanisms too.

Creating/Updating content (e.g. Observations) that reference the old Patient ID: (feedback on this required)

  • 422 Unprocessible Entity with an OperationOutcome indicating that the patient referenced was merged into patient xxx
  • 412 Pre-condition failed with an OperationOutcome indicating that the patient referenced was merged into patient xxx (if the client provided an IfMatch header)
  • 400 Bad Request with an OperationOutcome indicating that the patient reference did not resolve (existing behavior if the patient resource was deleted)

Merge Notification Mechanisms

The indication that a merge has been completed can be notified through several ways:

  • Using FHIR Messaging to invoke the same operation
  • An integration engine sending HL7v2 A40 merge message (A18 may also be applicable in backward compatibility modes)
  • Directly calling the $merge operation on the dependent systems (requires the system to have both patient resources)
  • Client data refresh notification (to be defined, could be triggered by merge, security changes, system migrations, consent changes, etc...)
  • Using Subscriptions to detect the merge operation has occurred
  • Polling the Merge Provenance resource
  • (other non standard notification channels)

These notifications can be sent to other downstream systems, partners, or other applications (including EMPIs). An EMPI could expose the merge operation, and therefore be a notification sender.


The downstream systems may not have all identifiers that the notifying system has, the notifier may be configured to know what "types" of identifiers should be propagated to which systems.

When using the identifier parameters (rather than id) you should be using the same assigner (which in the example above would be the PAS or clinical system), this may be configured in the sending notification system, such as an EMPI based on local business rules.

Impact on Subscriptions

Subscriptions on merges are most likely to be used by applications connecting directly to the system. Many use cases could consider using FHIR Messaging (or other messaging e.g. v2 messages) to communicate the merge occurred.


  • What can be used as triggers for the subscription
    • Patient update with new link valuesThe Task doing the Merge operation?
    • Provenance(s) as an event
    • operation itself as an event (what does this even mean? persist the parameters object?the Task resource, although that may not exist, so just a pre-defined topic)
    • AuditEvent as a trigger?
  • Will all the data that is patched over to the target patient ID be notified

Additional work needs to be done on this as the Subscription v2 resource matures, we should check with FHIR Infrastructure and other implementers working on the new content (Michael Donnelly,   Jenni Syed)

Mapping HL7v2 Merge to FHIR

There are several flavours of merging in V2 and Irma Jongeneel/Alex de Leon is going to provide the rough details so that we can explain how to convert into FHIR....

Other Notes

In the case where there aren't 2 records in the clinical system, then a simple update could be used.


Further consideration on the identifier assigning authority needs to be done.

In HL7 v2HL7v2, the trigger message only reports the results of the operation, and has PID and merged from PID

The HL7v3 in particular looks like they link content, and send a duplicates resolved message interaction.

Q & A

Question: Should support for a simple query parameter form of the operation be permitted? (using the form used in search url|value for identifiers, and the resource references will just include the reference value (no identifiers)

Cooper Thompson 9/15/2019 3:51 PM - this wouldn't be idempotent, so I would think this really should be a POST, even if it could be a GET.Answer: As this operation is not idempotent it is only defined for POST.

------ up to here ------ 

Question: How should privacy related meta tags be handled? When reconciling 2 patient resources to be merged, any security or privacy related tags should be included in the resulting target resource with the most sensitive values surviving.