Versions Compared

Key

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

...

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

HL7v2 Merges, Move and Linking

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 and Account as separate FHIR resources. The Merge, Move and Link operations  have 3 levels: Patient Identifier, Patient Account, and Patient Visit. 

Definitions:  Merge, move, and change identifier events

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:

  • Duplicate identifier created
    The registrar fails to identify an existing person, patient, account, or visit and creates a new, "duplicate" record instead of using the existing record. A "merge" operation is used to fix this type of error.
  • Incorrect identifier selected
    The registrar mistakenly selects the wrong person, patient, or account and creates or attaches a patient, account, or visit underneath the incorrect person, patient, or account. A "move" operation is used to fix this type of error.
  • Incorrect identifier assigned
    The registrar accidentally types in the wrong new identifier for a person, patient, account, or visit. This type of mistake usually occurs when identifiers are manually assigned (not system generated).  A "change identifier" operation is used to fix this type of error.

Note that we are addressing only scenarios 1 and 2 as most identifiers are assigned by the related systems, today.

Patient record links

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.

Merge Events

ADT/ACK - Merge Patient - Patient Identifier List (Event A40)

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.

ADT/ACK - Merge Account - Patient Account Number (Event A41)

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.

ADT/ACK - Merge Visit - Visit Number (Event A42)

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.

Move Events

ADT/ACK - Move Patient Information - Patient Identifier List (Event A43)

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 may not have accounts, which may or may 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."

ADT/ACK - Move Account Information - Patient Account Number (Event A44)

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).

ADT/ACK - Move Visit Information - Visit Number (Event A45)

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).

Link Events

ADT/ACK - link patient information (event A24)

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.

ADT/ACK - unlink patient information (event A37)

The A37 event unlinks two PID segments previously linked with an A24 (link patient information) event.

Other Notes

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

...