DEMYSTIFYING HL/7 MERGES AND MOVES
By Clyde Smith, Executive Consultant
When implementing HL/7 interfaces, one of the biggest challenges is to automate the changing
of Patient Identifiers that is sometimes required. These may occur because the patient may not
be able to be identified or is incorrectly identified at the time of admission. Sometimes it
occurs because the admission clerks do not properly search for existing patients before
creating a new one. While the concept of automating these required changes may be desirable,
improper automation can leave you with two applications that are no longer synchronized. I
want to share some information on HL/7 merges and moves that should be considered before
attempts are made to automate them. In order to understand some of the issues, it should be
stated that HL/7 assumes that the following hierarchy of identifiers exists:
- Master Patient Index ID
- Patient ID or Medical Record
- Alternate Patient ID (There can be multiple Alt Pt ID’s per
person)
- Account ID (There can be multiple Accounts per Person)
-Visit ID (There can be multiple Visits per Account)
-Alternate Visit ID (There can be multiple
Alternate Visit ID’s per Account)
HL/7 supports several merge/move trigger events. Here is a list with some notes about how
they are intended to be used:
- A18 – Merge Patient Information
o This event is only retained for backward compatibility. It was a very
non-specific event and the use of this event frequently left several patient
identifiers unchanged that should have changed or modified. It worked at the Patient
ID level only.
- A40 – Merge Patient – Patient Identifier List
o This event is designed to merge all of the records for a patient that are
incorrectly filed under two identifiers into one identifier. In addition, this event
contains an option to rename or renumber account ID’s and/or Visit ID’s if
the merge would leave you with non unique account numbers or visit numbers due to your
numbering scheme. All data subordinate to the Patient Identifier should be moved by
this transaction.
- A41 – Merge Account - Patient Account Number
o This event is designed to merge all of the records for an account that are
incorrectly filed under two or more account identifiers into one account identifier.
Like the A40, this event contains an option to rename or renumber Visit ID’s if
the merge would result in non unique visit numbers. All data subordinate to the Account
Number should be moved by this transaction.
- A42 – Merge Visit – Visit Number
o This event is designed to allow two existing visits to be merged into one. This
may be required in systems and organizations that record separate visit numbers for
ER visits and the associated inpatient stays where the visits must become one for
billing purposes. All data subordinate to the Visit Number should be moved by this
transaction.
- A43 – Move Patient Information – Patient Identifier List
o This event works like the A40 except that instead of merging two sets of records
into one, it is designed to move all subordinate data sets associated with the Patient
Identifier from the incorrect source patient ID to the correct target patient ID. All
data subordinate to the Patient identifier should be moved by this transaction.
- A44 – Move Account Information – Patient Account Number
o This event is designed to move an account from the incorrect Patient Id to the
correct Patient ID when an account was erroneously placed under the wrong or a net new
patient. All data subordinate to the Account Number should be moved by this
transaction.
- A45 – Move Visit Information – Visit Number
o This event is designed to move a visit number from one account to another when a
visit has incorrectly been placed on the wrong account. All data subordinate to the
Visit Number should be moved by this transaction.
While HL/7 is called a standard, it is important to note that the interpretation of
this standard tends to vary among the vendors and providers that utilize the standard.
I think it is extremely fair to say that not every vendor implements the trigger events
exactly as we would expect. The likelihood of two vendors interpreting this rather
complex portion of the standard in the same way is very low. Because these events can
have a tremendous impact on the integrity of some of the key data elements in your
Patient Care systems, I cannot caution you enough how important it is to properly and
thoroughly test the functionality of these transactions before allowing them to operate
in your production environment. If you are considering implementing merges in your
environment, and need some help in determining the best way to plan, test, and
implement automated merging, please feel free to contact
csmith@getvitalized.com for assistance.