Why Filter HL7 Messages?

May 7th, 2007 by Dave Shaver

Votes | Average: 0 out of 5 (No Ratings Yet)

Loading ...

Posted in Healthcare Integration, HL7 Messaging, HL7 Standard

Sometimes it is necessary to have messages “filtered” on an HL7 Standard interface. Filtering reduces the number of messages that are sent on an interface due to business or technical requirements. For example:

A clinical application might have a performance problem with 30,000 ADT messages arriving on an interface each day - if the number could be reduced, the performance issue might be resolved.
A department might want to reduce the “excess patient noise” in the target application. For example:

Neonatal Intensive Care (NICU) application only had six beds, there is no need to have patient demographic information loaded into the NICU application for an adult patient checking in for dialysis or an outpatient lab test.
Likewise, the Radiology department might only want to see inpatients, emergency patients, and those outpatients checking in for mammogram.

In order to filter, the business rules for the filtering must be understood by both the technical (IT) and clinical staff. Ultimately these rules are translated into HL7 messaging segment or field values.

Continuing the examples from above, here is some example business logic to create filters:

The NICU filter could be built by only sending patients to the NICU application that are in the NICU nursing unit (PV1-3-1 = “NI”) or if their hospital service indicates NICU state (PV1-10 = “NICU”).
The Radiology filter could be built by selecting patients that have the correct patient class (PV1-2 = “I” or PV1-2 = “E”) or the correct admitting location (PV1-14 = “BCTR”).

Ultimately, the filtering is done in either the sending application, the receiving application, or an interface engine that sits between the two applications.