Skip to end of metadata
Go to start of metadata

This project will investigate and document the implications that Merge/Link/unmerge/unlink have on the FHIR specification.

(This is not just to document the actual Operations, but also the expectations of clients with data that has been linked/merged)

The output may be content in the core FHIR specification, FHIR Implementation Guide(s) or Whitepaper(s)

A project team will form to work on this independent of the PA group, and will report into PA regularly, and for final approvals and inclusion into a ballot.

Initial project team will be:

Brian PostlethwaiteCooper ThompsonDrew Torres (who may delegate), Charles Ye

First tasks will be to:

  • document existing behaviors of existing products 
  • how this is exposed in the data
  • what are the expectations of client applications 
  • then flow onto potential operation definitions for performing these functions (lower priority)

The timeline for development of this content is anticipated during R5

Existing tracker related to this topic include: GF#19687

This specification does not specify merge functionality: if multiple patient records are found to be duplicates, they can be linked together, as described above. These links merely express the relationship between records, and in the case of a replacement link, indicate a "master" record. This specification does not mandate that FHIR servers migrate information between such records on finding such a link. Note:

  • Health information administrators may call the process "merging", but it is often implemented as "linking" at the record level
  • Servers are allowed to implement merging/record migration even though it is not mandated.

Note: We are seeking input from the implementer community on what effect linking/merging/unlinking should have on other functionality such as the GET operation, searching, reverse includes, etc.;
How should an unlink behavior be done?
How will the patient compartment interact with the merge?
This functionality and related behaviors is subject to ongoing experimentation and implementation testing, with a definition to be proposed in a future version of this specification.


  • No labels