Versions Compared


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


Preview Merge


This is a call to the operation (with preview=true) that simply checks for potential errors and warnings, without committing any changes.

This may not be able to capture all possible causes of errors that could be encountered during the processing of the data patching.

The returned Patient resource is a preview only and has not been committed. Hence the version number and last_modified date would be different.

Initiate Merge

This stage processes the input parameters checking for errors/warnings and begins the changes to the patient resources.

If the system is able to complete the processing of all reference data to the target patient, then it may be complete and no task is required. Otherwise a Task for tracking would be created and monitor the progress of the merge.

Data Processing

The rest operation may have returned, and processing is ongoing to patch any other resource that references the source patient to reference the target patient.

This may take a considerable period of time in some systems where the volume of records being updated is large.

The source Patient record will be marked as inactive, and add the link property to the target patient (except where systems delete the record)

Completed (or failed)All data processing is complete, and the Task is marked as completed (maybe with errors)


Answer: A server MAY provide an additional outcome in any search bundle with the informative information.------ up to here ------ 

Question: What should happen to the source patient post merge? Should it be deleted, marked as inactive, hidden from searches? What impact on subscriptions and lists?Question: Should there be a pre-merge or dry run merge operation to check the scale of the operation, this could be useful to check the scale. If the results were to be reported, it can be an estimate, and doesn't really need to be broken down into resource types, its just to help advise age of the record. This preview parameter satisfies this need.

Answer: There are 2 options here, delete the patient completely, or mark it as inactive with the link to the active patient (and optionally clear all other data values to ensure that it is not accidentally used - and is quite obvious it's not for use)

Question: Should a search no the old MRN identifier return both the old patient and target patient resources, or just the target patient resource? How do we filter out the old resource? Rely on the inactive flag?Question: Should the merge itself mark the source as inactive? Suggest that this is a good idea

Answer: If the resource was physically deleted, then it won't be returned. If the data was cleared from the source patient to prevent accidental use, then it won't be returned, Otherwise the inactive flag should be checked.

Question: Should other resources, such as Patient Accounts, be merged too? Or is that a supplementary exercise? Could they be tagged with Task resources for review?

Other considerations could be claims to be withdrawn, communications in process to be cancelled.

Answer: This is not currently planned to be addressed by FHIR with a specific operation, and may be done through regular FHIR restful updates at this stage.

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

Question: Should anything happen with SMART App Launch tokens that have the Patient ID in them? If they were revoked, that would be the cleanest, as apps need to handle this and would just challenge for a new token, which would get the new value

Answer: Suggest expiring the token, but will refer to the broader group on Zulip.

Question: If the 2 patient resources had links to each other, should those be removed?