Saturday, November 20, 2010

Filtered ADT Feed to an Ultrasound System

Here is some more fun that an integration analyst can have.

I was asked to put together an interface to an ultrasound system that is used in two of our OBGYN clinics. They wanted patient demographics for the patients that would be arriving for an ultrasound at these clinics.

So far, so good. Typically, one would send a filtered version of the ADT stream to this system. Except that the ADT feed that comes out of our practice management system does not contain enough information for me to do so. However, the scheduling messages that come out of the PM system do. Kind of.

They send an SIU^S12 message with a patient status of "ARRIVED" when the patient arrives for their scheduled appointment. The first thing is to find the correct clinic code in the message. The message codes the location as "OBG^Oxxx" indicating that the patient belongs to the OBGYN department and is to be seen in location Oxxx. That's non-standard usage, but I was able to figure it out.

OK. So, I can pick that message out and translate it into an ADT^A04 (Register Patient) message and send that to the ancillary.

The other trick is to build a filter that will only allow the ultrasound patients to pass. Usually, there is information in the AIG segment (General Resource) that will tell you that the ultrasound machine needs to be part of the appointment. However, this PM system doesn't schedule that way. They send a bogus provider code for the ultrasound machine (actually, two of them, one for each clinic) in the SCH-12 (Placer Contact Person) field in the scheduling message. I would not have expected to find this data in this field.

Of course, none of this was documented. I needed to look at the live message stream and the values in the messages and deduce the values to filter on. I think that I got it right, but I won't know for certain until we test.

This message won't have all of the demographic information that the ancillary wants, but it will be better than nothing.

This illustrates part of the fun that interfacing can be. The business owners know what they want to do (usually), but they don't know how to do it. My job is to understand what they want to accomplish and then figure out how to construct an interface that will accomplish those objectives.