sion errors and possible privacy violations (see AHIMA’s Breach
Management Toolkit for more details on handling a breach).
audit trail is maintained for legal purposes, but only the updated
information is presented to the end user.
There are times when the incorrect information is of such a type
that it is vital to correct it immediately in order to ensure patient
safety. This could include information about a rare blood disease,
a life-threatening allergy to a common medication, or other information that would impact a physician’s treatment approach,
particularly in an emergency situation. Therefore, CEs considering participation in an HIE should inquire about the escalation
process the HIE uses for these types of data corrections.
The HIE may act as the gatekeeper of the amendment process by providing an amendment request form for the patient
to complete and then forwarding that amendment request to
the originating provider. Alternatively, the HIE may provide the
originating provider’s contact information to the patient in order for the patient to contact the provider and follow the provider’s amendment request process. CEs should ask a few questions of the HIE such as:
Will the HIE provide the patient with information about
any other providers who have accessed the patient’s data
and possibly viewed the incorrect information?
How can the patient be assured that the incorrect information has not been disseminated further than the originating provider’s record and the HIE?
It would be reasonable to outline the maximum acceptable
timeline in the participation agreement in order to ensure HIE
accountability. The CE will also need to ensure that the audit
trail will provide sufficient information about the other HIE
participants who viewed the incorrect information in order to
ensure the updated information is provided in a timely manner.
Routine Testing Scenarios and the Testing Process
Managing amendments in the HIE environment requires understanding how to correct and/or amend patient information systematically. Communication between a CE’s EHR and an HIE is usually
through Health Level Seven (HL7) messages such as observation
results (ORUs) and medical document management (MDM) as
well as clinical document architecture (CDA) documents. Therefore, it is imperative to understand how these messages and documents can be updated when the need for an amendment arises.
ORUs are typically sent in response to an order and contain
test results (e.g., lab, imaging). The ORU^R01 for unsolicited
observation messages and ORU^R03 unsolicited update are the
most common ORU messages.
3, 4 If there is a correction to an
ORU message, the ORU^03 message is sent and the receiving
system should replace the current patient information/order/
test info with the updated information. A status of “C” can be
used when sending the corrected message and the date/time
changes when the ORU gets updated; thus, the latest message
becomes the “official record” at that time.
The MDM message transmits new or updated documents
(e.g., progress note, operative report) as well as status informa-
tion and may or may not be in response to an order. The most
commonly used type of MDM message is the MDM^T02 (i.e.,
original document notification and content) which is similar
to an ORU message. Other MDM message types include the
MDM^T05 for Document Addendum Notification and the
MDM^T06 for Document Addendum Notification with Con-
tent. For example, a specification may require a MDM^T10
(i.e., document replacement notification and content) rather
than an MDM^T06 (Document Addendum Notification with
Content) for amendments so participants will need to be able
to send messages based on the specification and understand
what message type and format is being used for amended in-
formation. In some cases, only the “F” final status is used (no
“C” corrected status).
HL7 messages have many segments. One of the required
message segments is for patient identification (PID). The PID
includes the patient identifier, name, date of birth (DOB), sex,
race, address, and other identifying information. Many updates
and corrections involve name changes or DOB corrections, so
the PID segment is often the segment being updated. The ob-
servation (OBX) segment contains document information and
contents in the case of MDMs and clinical observation results in
the case of ORUs. The format (e.g., plain text, formatted text, or
encoded PDFs) is dictated by the receiving system. The contents
of the OBX segment is another possible area where corrections/
amendments may occur.
Evaluation of CDA conformance should also be a part of the
testing process. CDA is a document markup standard used to
exchange clinical documents. The CDA specification is very
broad; templates are used to limit or “constrain” to specific
use cases. Most templates are open and allow for customiza-
tion of content. The CDA header enables clinical document
management and exchange. The CDA standard allows for the
function of amending or replacing records via the CDA head-
er but CEs must make sure the end system (e.g., the HIE) can
handle these functions as well. The CDA header can be used
to identify document revisions and addenda as well. Typi-
cally, if there is an error in a CDA document, such as incor-
rect medications, the originator will resend the entire docu-
ment which, once sent, becomes the official new record. CDA
documents can be distributed via email, HL7 messaging, or
Direct messaging, among other options. Documentation for
amendments that were not accepted can be included as part
of a CDA document or sent as an embedded document in an
ORU or MDM message.
There are a number of steps to managing amendments or
making corrections of patient information with regards to
health information exchange. In general, participants do not
correct the already-processed HL7 message or CDA document. Providers correct the information in the EHR or source
system, which sends a new message with the corrected information and it is up to the receiving system to update its information based on the new information in the HL7 message or
CDA document. Each part of the interface or exchange process
must be tested. For example, for ORU or MDM messages, each
segment, status, and acknowledgment used should be a part
of the testing plan.