We're in the final testing of a lab results interface with a local hospital. They will send us results messages and we will place those results into the Patient's chart so that our Doctors can view the results in our EHR. Their lab system will not accept order messages from us, so we are faxing the orders to them and they are manually entering the orders. The results come back to us as an ORU^R01 message.
Late in the testing, we discovered that some results were not displaying correctly. The values were correct. The NextGen EHR will display results that are Low, High or Abnormal in a different color to make it easier for the provider to recognize. This is meta-data in that it describes the results. This information is carried in the message in the OBX-8 Abnormal Flags field.
The sending lab system is using non-standard codes in this field. Technically, the values for OBX-8 are in the User Defined Table 0078, which means that they can use whatever they want in there. Many years ago, they defined their own abnormal flags.
The values in HL7 Table 0078 are below.
Value -- Description Comment
L -- Below low normal
H -- Above high normal
LL -- Below lower panic limits
HH -- Above upper panic limits
< -- Below absolute low-off instrument scale
> -- Above absolute high-off instrument scale
N -- Normal (applies to non-numeric results)
A -- Abnormal (applies to non-numeric results)
AA -- Very abnormal (applies to non-numeric units, analogous to panic limits for numeric units)
null -- No range defined, or normal ranges don't apply
U -- Significant change up
D -- Significant change down
B -- Better--use when direction not relevant
W -- Worse--use when direction not relevant
S -- Susceptible. Indicates for microbiology susceptibilities only.
R -- Resistant. Indicates for microbiology susceptibilities only.
I -- Intermediate. Indicates for microbiology susceptibilities only.
MS -- Moderately susceptible. Indicates for microbiology susceptibilities only.
VS -- Very susceptible. Indicates for microbiology susceptibilities only.
The sending system told us that they would not change the codes that they use.
I was already using a Rhapsody Mapper to make changes to the incoming result message before I sent it to NextGen. So, I needed to translate their Abnormal Results codes into the ones that NextGen uses. There are a limited number of codes to translate, and the code sets are fairly static. I have done this sort of code translation using interface engines before. It is very common. The technique varies. Cloverleaf has a separate component that is used to translate codes.
I have use database tables to translate codes in Rhapsody before. We recently upgraded to Rhapsody version 4.0, and it supports Translate Tables in a way that does not require using a database. I had not used this technique before, so I got to learn something new. You create the translate table using the IDE and can maintain it using either the IDE or from the web based Management Console. Once I had the table created, I needed to add a single line of code to the Mapper to translate the code.
I made the change to the test route and replayed several results messages to verify that Low, High and Abnormal results are displayed in the correct color in the EHR.
Because I had not used this technique before, the change took about half a day to develop, code and test.
The Management Console will allow us to view the codes that failed to translate. That is, when we get a message that contains a code that is not in the translate table, we will be able to see that and possibly add the new code to the translation table. I don't expect this to happen, because it sounds like they have been using their non-standard codes for many years.
The sending lab system will have to adopt the Abnormal Flags values from Table 0078 to achieve Meaningful Use, as both of the Implementation Guides (Lab to EHR and Public Health) have specified the use of the values that are in the standard.
Showing posts with label HIT informatics interface. Show all posts
Showing posts with label HIT informatics interface. Show all posts
Sunday, January 9, 2011
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.
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.
Subscribe to:
Posts (Atom)