After reviewing the customer information, a limitation in the software that was likely the cause of the customer complaint.The meditrac driver and the poccelerator middleware displayed the correct behavior.The fields within the hl7 protocol are called "observation fields" and are sequentially numbered as obx1, obx2, obx3.Etc.The meditrac driver interprets these values and translates them to transmit through poccelerator.The standard protocol for field obx-4 is a quantitative result, while obx-8 is for a qualitative result (n/p).The device also uses obx-11, called the 'result status field' for marking a result as invalid or as a means to flag it for review.In this specific situation, the device put a "n" in obx-8 and a "x" in obx-11.Poccelerator currently does not accept a dedicated field for flags, and therefore does not accept a value in the obx-11 field, where the customer dedicated their flag.And upon pushing to the lis, the poccelerator fills this field with a ¿f¿ by default.So, if the instrument has a result in either obx-4 or 8, it should transmit.On the on contrary, only if the instrument withholds the result it will not transmit.For the aforementioned reasons, both the meditrac driver and poccelerator are behaving as intended.
|
A customer running a f2400 instrument for clostridium difficile alleged that a result incorrectly appeared as "negative" in poccelerator and the lis, despite the instrument printing the c.Diff result as "invalid".The result was verified and transmitted to the physician.The data logs show the raw result from the instrument as an "n" for negative.However, because the control that runs in parallel reported as "invalid", the whole test could only be reported out as "invalid" by the system.The customer expected the invalid result and/or a flag to have transmitted from the system to poccelerator.There is no report of injury due to this event.
|