Release 5 Ballot
AdministrationThis page is part of the FHIR Specification (v5.0.0-ballot: FHIR R5 Ballot Preview). The current version which supercedes this version is 5.0.0. For a full list of available versions, see the Directory of published versions 
| Patient Administration Work Group | Maturity Level: 0 | Trial Use | Compartments: N/A |
The Merge operation is used to request 2 patient resources be merged.
The target is the remaining patient resource (survivor), the source will be marked as inactive (or in some systems deleted)
The source-patient resource will be updated to add a new link reference to the target-patient resource (link-type=replaced-by), and also update the status to inactive (unless the resource was deleted)
The target-patient resource will be updated to add a new link reference to the source-patient resource (link-type=replaces) - and must be included in the result-patient parameter if used (if the source patient is deleted, then this link is not required).
The canonical URL for this operation definition is
http://hl7.org/fhir/OperationDefinition/Patient-merge
Formal Definition (as a OperationDefinition).
URL: [base]/Patient/$merge
This is not an idempotent operation
| In Parameters: | |||||
| Name | Cardinality | Type | Binding | Profile | Documentation |
| source-patient | 0..1 | Reference(Patient) | A direct resource reference to the source patient resource (this may include an identifier) | ||
| source-patient-identifier | 0..* | Identifier | The Identifier(s) of the source patient resource; all of these identifiers MUST be present in the located resource (in addition to the one included in the resource reference above - if included) (The purpose of this property is to ensure that the correct source patient resource is selected) | ||
| target-patient | 0..1 | Reference(Patient) | A direct resource reference to the target patient resource This is the surviving patient resource, the target for the merge | ||
| target-patient-identifier | 0..* | Identifier | The Identifier(s) of the target patient resource; all of these identifiers MUST be present in the located resource (The purpose of this property is to ensure that the correct source patient resource is selected) | ||
| result-patient | 0..1 | Patient | The details of the Patient resource that is expected to be updated to complete with and must have the same patient.id and provided identifiers included. This resource MUST have the link property included referencing the source patient resource It will be used to perform an update on the target patient resource In the absence of this parameter the servers should copy all identifiers from the source patient into the target patient, and include the link property (as shown in the example below) This is often used when properties from the source patient are desired to be included in the target resource The receiving system may also apply other internal business rules onto the merge which may make the resource different from what is provided here. | ||
| preview | 0..1 | boolean | If this is set to true then the merge will not be actually performed; an OperationOutcome will be returned in the Parameters response that will indicate that no merge has occurred and may include other diagnostic info if desired, such as the scale of the merge. e.g. Issue.details.text "Preview only Patient merge - no issues detected" e.g. Issue.diagnostics "Merge would update: 10 years of content or 120 resources" The resulting target patient resource will also be returned in the result | ||
| Out Parameters: | |||||
| Name | Cardinality | Type | Binding | Profile | Documentation |
| return | 1..1 | Parameters | The status of the response will be one of:
The Parameters resource will include:
Note: as this is the only out parameter, it is a resource, and it has the name 'return', the result of this operation is returned directly as a resource | ||
There must be at least 1 source patient/patient-identifier parameter and at least 1 target patient/patient-identifier parameter
The result-patient.id must be the same as the target patient reference (if the patient reference is provided as an input parameter)
If a client needs the server to create a new patient merged from the 2 patient resources, the client should create a new patient record and then call the merge operation to merge each old patient resource into the newly created patient resource.
A server May decide to delete the source record, but this is not defined by the standard merge operation, and if this occurs then the target patient's link property will remain unchanged.
The merge operation will have multiple stages, and some of these may take additional time for processing and thus be done asynchronously
| Stage | Description |
|---|---|
| Preview Merge | (Optional)<br/>This is a call to the operation (with preview=true) that simply checks for potential errors and warnings, without committing any changes.<br/>This might not be able to capture all possible causes of errors that could be encountered during the processing of the data patching.<br/>The returned Patient resource is a preview only and has not been committed. Hence the version number and last_modified date would be cleared/absent. |
| Initiate Merge | This stage processes the input parameters checking for errors/warnings and begins the changes to the patient resources.<br/>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.<br/>This may take a considerable period of time in some systems where the volume of records being updated is large.<br/>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) |
During the Data Processing stage the patient resource and resources referencing the source patient may be indeterminate until the merge processing operation completes.
Note: Some servers may also update the inactive source patient resource to remove most of the data to make it more clear that the resource should not be used, and the replaced-by link is the key information. Even to the extent of clearing the name and contact details etc.
Note: During the pre-merge validation stage, a system may perform other internal checks/business rules.
If the result patient resource is provided in the parameters to the operation, then it is assumed that the caller has correctly included all the required identifiers desired to be in the target patient (though must include the identifiers specified in the input parameters).
If the result patient resource is not provided (only the identifier/reference to select it), then the values provided in the request parameters (source-patient.identifier and all source-patient-identifiers) will be copied into the target resource and marked as old.
> Review Note: If the marking of old still makes sense here for ALL provided identifiers that get copied across when the result patient isn't there)
The server may also migrate other identifiers (and properties) at its discretion, and choose to mark these as old or not.
Note: If an identifier value is masked, then the server will migrate the identifier value correctly, regardless of the masking.
The merge data processing SHALL update all references that refer to the source patient to reference the target patient.
While updating resources that reference the source patient, ensure that the target patient link value isn't also accidentally updated. (don't make it point at itself)
A Provenance resource SHOULD be created that references the source and target patient resources (or just the target-resource if the source was deleted, or the source patient's old identifier) indicating that the merge has occurred. (example below)
A Provenance resource MAY be created to link all of the resources that referenced the source patient that could then provide information to a potential un-merge operation.
Note: Some resources that have been updated as a result of the merge, such as AuditEvent, Provenance, may have been digitally signed, and this change would invalidate the signature. There may be other reasons impacting the updates that should be considered, further feedback on this specific use case is required.
> Review Note: Are there other implications of these reference updates that should be identified relating to versions - (such as where a version specific reference was included)
Note: While this processing is occurring, if a client requests clinical data for either source or target patient, an OperationOutcome with an informative message MAY be included in the resulting bundle indicating this processing is ongoing.
> Review Note: Considering updating http://hl7.org/fhir/valueset-issue-type.html to extended with a new child to the transient concept to indicate that merge processing is occurring.
A GET on the old Patient resource ID (e.g. GET [base]/Patient/pat01) will return either:
> Review Note: If the system "knows" that the resource was there it would be preferable to return a stub patient 202 as described above.
> Review Note: Security implications such as those from SMART tokens could restrict access here.
When performing a SEARCH by the old Patient Resource ID return: e.g. GET [base]/Patient?_id=pat01 (often used as a substitute for direct GET when doing _include for the managing org/general practitioner)
Accessing the Patient $everything operation on the source patient resource (now marked as inactive) will return an OperationOutcome and http status of 400 Bad Request. The error message should inform that the patient has been merged and should follow the Patient link to access the $everything content.
> Review Note: Considering updating the http://hl7.org/fhir/valueset-issue-type.html to extended with a new child to the processing concept to indicate that additional content may be associated with a linked patient
Searching content (e.g. Observations) based on patient ID:
Observation?patient=Patient/pat01 would return a 200 Ok Bundle with no results (as all have been moved to Patient/pat02), an OperationOutcome may be included indicating that the patient was merged into patient xxxObservation?patient=Patient/pat02 would return all the data that is referencing pat02, and all the data that was referencing pat01 (which was updated by the merge operation to reference pat02)Use Case - Polling using search on Observations to get updates:
Observation?patient=Patient/pat02 (initial client call at start of year, gets all patient obs)Observation?patient=Patient/pat02&_lastupdated=ge2019-03 (client calls at start of march to detect any new patient obs)Observation?patient=Patient/pat02&_lastupdated=ge2019-06 (client calls at start of june to detect any new patient obs, but misses all the pat01 observations prior to June)In this case need to detect the patient merge, <u>and perform a fresh retrieval of all content</u>, 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)
The indication that a merge has been completed can be notified through several ways:
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.
Consideration should be taken to ensure that the correct data is acted on.
The downstream systems might 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.
Note: When using the identifier parameters (rather than id) you should be using the same assigner (which in the example above would be the PAS/ADT or clinical system), this may be configured in the sending notification system, such as an EMPI based on local business rules.
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.
> Review Note: Interaction with the Subscription v2 resources requires additional review and implementer feedback considering: > * What can be used as triggers for the subscription > * Patient update with new link values > * Provenance(s) as an event > * operation itself as an event (the Task resource, although that might not exist, so just a pre-defined topic) > * Will all the data that is patched over to the target patient ID be notified > * Systems might not notify that the content was changed, and rely on the merge notification to advise if required > * Also note the Client data refresh notification discussion above
Below is a summary of the Merge, Move and Link operations. They are included here as the v2 concepts of Merge, Move and Link may differ (or not) based on the establishment of the Patient, Encounter and Account as separate FHIR resources. The Merge, Move and Link operations have 3 levels: Patient Identifier, Patient Account, and Patient Visit.
The term "identifier" is used throughout this section. An identifier is associated with a set (or sets) of data. For example, an identifier (PID-3 - Patient Identifier List) may be a medical record number which has associated with it account numbers (PID-18 - Patient Account Number). Account number (PID-18 - Patient Account Number) is a type of identifier which may have associated with it visit numbers (PV1-19 - Visit Number).
This section addresses the events that occur usually for the purposes of correcting errors in person, patient, account, or visit identifiers. The types of errors that occur typically fall into three categories:
Note: HL7v2 addresses only scenarios 1 and 2 as most identifiers are assigned by the related systems, today.
Linking two or more patients does not require the actual merging of patient information; following a link trigger event, sets of affected patient data records should remain distinct. However, because of differences in database architectures, there may be system-dependent limitations or restrictions regarding the linking of one or more patients that must be negotiated.
There are multiple approaches for implementing MPIs. It is useful for the purpose of MPI mediation to support two types of linkage. Explicit linkage requires a message declaring a link has been made between multiple identifiers. Implicit linkage is performed when a receiving system infers the linkage from the presence of multiple identifiers present in PID-3-patient identifier list.
In an MPI setting, the A24 -link patient information message is preferred for transmitting an explicit link of identifiers whether they are in the same or different assigning authorities. The A37 unlink patient information message is preferred for transmitting the explicit unlinking of identifiers.
Implicit linkage of identifiers, sometimes called passive linking, has been implemented using various messages. An acknowledged method is inclusion of multiple identifiers in PID-3-patient identifier list, which the receiving system implicitly links. An MPI or application that makes such an implicit linkage can generate an A24 - link patient information message to explicitly notify another system of this action.
(This is the primary event to be considered associated with FHIR Patient merge)
A merge has been done at the patient identifier list level. That is, two PID-3 - Patient Identifier List identifiers have been merged into one.
An A40 event is used to signal a merge of records for a patient that was incorrectly filed under two different identifiers. The "incorrect source identifier" identified in the MRG segment (MRG-1 - Prior Patient Identifier List) is to be merged with the required "correct target identifier" of the same "identifier type code" component identified in the PID segment (PID-3 - Patient Identifier List). The "incorrect source identifier" would then logically never be referenced in future transactions. It is noted that some systems may still physically keep this "incorrect identifier" for audit trail purposes or other reasons associated with database index implementation requirements.
(For information only, not in scope of FHIR for now)
A merge has been done at the account identifier level. That is, two PID-18 - Patient Account Number identifiers have been merged into one.
An A41 event is used to signal a merge of records for an account that was incorrectly filed under two different account numbers. The "incorrect source patient account number" identified in the MRG segment (MRG-3 - Prior Patient Account Number) is to be merged with the "correct target patient account number" identified in the PID segment (PID-18 - Patient Account Number). The "incorrect source patient account number" would then logically never be referenced in future transactions. It is noted that some systems may still physically keep this "incorrect identifier" for audit trail purposes or other reasons associated with database index implementation requirements.
> Implementer Note: This is not merging the Patient, but merging the account, but is the same concept, should we also be including this concept as another potential operation?
(For information only, not in scope of FHIR for now)
A merge has been done at the visit identifier level. That is, two PV1-19 - Visit Number identifiers have been merged into one.
An A42 event is used to signal a merge of records for a visit that was incorrectly filed under two different visit numbers. The "incorrect source visit number" identified in the MRG segment (MRG-5 - Prior Visit Number) is to be merged with the required "correct target visit number" identified in the PV1 segment (PV1-19 - Visit Number). The "incorrect source visit number" would then logically never be referenced in future transactions. It is noted that some systems may still physically keep this "incorrect identifier" for audit trail purposes or other reasons associated with database index implementation requirements.
> Implementer Note: Would be interesting to determine if these are used in production (A41 and A42)
A move has been done at the patient identifier list level. Identifier to be moved in the PID-3 - Patient Identifier List and MRG-1 - Prior Patient Identifier List will have the same value. The "from" (incorrect source patient ID) and "to" (correct target patient ID) identifiers have different values. See A43 examples in section 5. The identifiers involved in identifying the patient to be moved (MRG-1 - Prior Patient Identifier List) may or might not have accounts, which may or might not have visits. In any case, all subordinate data sets associated with the identifier in MRG-1 - Prior Patient Identifier List are moved along with the identifier, from the "incorrect source patient ID" to the "correct target patient ID."
(For information only, not in scope of FHIR for now)
A move has been done at the account identifier level. That is, a PID-18 - Patient Account Number associated with one PID-3 - Patient Identifier List has been moved to another patient identifier list.
An A44 event is used to signal a move of records identified by the MRG-3 - Prior Patient Account Number from the "incorrect source patient identifier list" identified in the MRG segment (MRG-1 - Prior Patient Identifier List) to the "correct target patient identifier list" identified in the PID segment (PID-3 - Patient Identifier List).
(For information only, not in scope of FHIR for now)
A move has been done at the visit identifier level. That is, a PV1-19 - Visit Number or PV1-50 - Alternate Visit ID associated with one account identifier (PID-18 - Patient Account Number) has been moved to another account identifier.
An A45 event is used to signal a move of records identified by the MRG-5 - Prior Visit Number or the MRG-6 - Prior Alternate Visit ID from the "incorrect source account identifier" identified in the MRG segment (MRG-3 - Prior Patient Account Number) to the "correct target account identifier" identified in the PID segment (PID-18 - Patient Account Number).
> Review Note: Should Event A47 be covered? (this is similar to A43), Some vendor(s?) implement this and not A43
(For information only, not in scope of FHIR for now)
The A24 event is used when the first PID segment needs to be linked to the second PID segment and when both patient identifiers identify the same patient. Linking two or more patients does not require the actual merging of patient information; following a link event, the affected patient data records should remain distinct. For example, this event could be used in a hospital network environment in which there are multiple campuses and in which records need to be linked. For example, hospital A, hospital B, and hospital C would each keep their own records on a patient, but an A24 link event would be sent to a corporate-wide MPI to enable the coupling of ID information with the corporate ID number. It is used for corporate data repositories, etc. This event is not meant to link mothers and babies since a field exists (PID-21-mother’s identifier) for that purpose. See Section 3.5.3, “Patient record links,” for a discussion of issues related to implementing patient link messages and MPI issues.
This event can also be used to link two patient identifiers when a patient changes from inpatient to outpatient, or vice versa. This event can also be used to link two visits of the same patient.
The fields included when this message is sent should be the fields pertinent to communicate this event. When other important fields change, it is recommended that the A08 (update patient information) event be used in addition.
(For information only, not in scope of FHIR for now)
The A37 event unlinks two PID segments previously linked with an A24 (link patient information) event.
> Review Note: Seeking implementer feedback on safety checklist items to include
Request: Patient merge using patient identifiers and providing an explicit resulting resource:
POST /open/Patient/$merge
[some headers]
POST: [base]/Patient/$merge
<Parameters xmlns="http://hl7.org/fhir">
<parameter>
<name value="source-patient" />
<valueReference>
<reference value="Patient/01" />
<identifier>
<use value="official" />
<type>
<coding>
<system value="http://www.hospital-a/localid" />
<code value="HospitalA" />
<display value="Hospital A" />
</coding>
<text value="Hospital A" />
</type>
<system value="urn:oid:2.16.840.1.113883.3.72.5.9.1" />
<value value="1000000001" />
<assigner>
<display value="Hospital A" />
</assigner>
</identifier>
</valueReference>
</parameter>
<parameter>
<name value="target-patient" />
<valueReference>
<reference value="Patient/02" />
<identifier>
<use value="official" />
<type>
<coding>
<system value="http://www.hospital-a/localid" />
<code value="HospitalA" />
<display value="Hospital A" />
</coding>
<text value="Hospital A" />
</type>
<system value="urn:oid:2.16.840.1.113883.3.72.5.9.1" />
<value value="1000000002" />
<assigner>
<display value="Hospital A" />
</assigner>
</identifier>
</valueReference>
</parameter>
<parameter>
<name value="target-patient-identifier" />
<valueIdentifier>
<system value="http://example.org/SSN" />
<value value="804234513" />
</valueIdentifier>
</parameter>
<parameter>
<name value="result-patient" />
<resource>
<Patient xmlns="http://hl7.org/fhir">
<id value="02" />
<identifier>
<use value="official" />
<type>
<coding>
<system value="http://www.hospital-a/localid" />
<code value="MRN" />
</coding>
<text value="Hospital A MRN" />
</type>
<system value="http://www.hospital-a/localid" />
<value value="1000000002" />
<assigner>
<display value="Hospital A" />
</assigner>
</identifier>
<identifier>
<use value="old" />
<type>
<coding>
<system value="http://www.hospital-a/localid" />
<code value="MRN" />
</coding>
<text value="Hospital A MRN" />
</type>
<system value="http://www.hospital-a/localid" />
<value value="1000000001" />
<assigner>
<display value="Hospital A" />
</assigner>
</identifier>
<identifier>
<system value="http://example.org/SSN" />
<value value="804234513" />
</identifier>
<name>
<family value="LINCOLN" />
<given value="MARY" />
</name>
<name>
<use value="old" />
<family value="WASHINGTON" />
<given value="MARY" />
</name>
<gender value="female" />
<birthDate value="1954-07-04" />
<link>
<other>
<reference value="Patient/01" />
<display value="Mary Lincoln" />
</other>
<type value="replaces" />
</link>
</Patient>
</resource>
</parameter>
</Parameters>
Response: Results from the merge request above
HTTP/1.1 200 OK
[other headers]
<Patient xmlns="http://hl7.org/fhir">
<id value="02" />
<identifier>
<use value="official" />
<type>
<coding>
<system value="http://www.hospital-a/localid" />
<code value="MRN" />
</coding>
<text value="Hospital A MRN" />
</type>
<system value="http://www.hospital-a/localid" />
<value value="1000000002" />
<assigner>
<display value="Hospital A" />
</assigner>
</identifier>
<identifier>
<use value="old" />
<type>
<coding>
<system value="http://www.hospital-a/localid" />
<code value="MRN" />
</coding>
<text value="Hospital A MRN" />
</type>
<system value="http://www.hospital-a/localid" />
<value value="1000000001" />
<assigner>
<display value="Hospital A" />
</assigner>
</identifier>
<identifier>
<system value="http://example.org/SSN" />
<value value="804234513" />
</identifier>
<name>
<family value="LINCOLN" />
<given value="MARY" />
</name>
<name>
<use value="old" />
<family value="WASHINGTON" />
<given value="MARY" />
</name>
<gender value="female" />
<birthDate value="1954-07-04" />
<link>
<other>
<reference value="Patient/01" />
<display value="Mary Lincoln" />
</other>
<type value="replaces" />
</link>
</Patient>
For more information about operations, including how they are invoked, see Operations.
FHIR ®© HL7.org 2011+. FHIR R5 Ballot hl7.fhir.core#5.0.0-ballot generated on Wed, Sep 7, 2022 11:10+1000.
Links: Search |
Version History |
Contents |
Glossary |
QA |
Compare to R4 |
Compare to R5 Draft |
|
Propose a change