Point Of Care (Lab-POC)

[Aseel Alali]

Dears,

Reading the "LABORATORY POINT OF CARE (POC) INTERFACE INSTALLATION AND USER GUIDE" document I have many questions to ask starting by:

1. Does POC interface has an end users manual (for healthcare providers) , or no need for that, can you please tell me how the work flow goes on from their side ?
2. The document states that:" The POC results are automatically entered into the patient record without a separate step of tech verification."
   my question is : Does that mean all results are automatically sent from processing device at the POC directly to CPRS via HL7 messages without any manual interaction ?
   and if so, what about lab devices at POc that doesn't communicate HL7 ? can their results be entered manually?
3. The document also states that: " The support for a maximum of five separate POC interfaces is provided. Multiple POC instruments can be interfaces on a single vendor’s POC system. "
   my question is : would the interpretation of this statement be: POC interface support max. 5 lab devices per POC location, or else ?
   
4. Other than (Lab Point of Care Setup) option is there any menus related to this interface a user should be aware about?

Thanks a lot in advance, your group is much more than helpful exploring the world of VistA.

[Wasim]

Dear Nancy,

FYKI,

[Kevin Toppenberg]

See below.

On Tuesday, May 26, 2015 at 7:48:23 AM UTC-4, Aseel Alali wrote:

Dears,

Reading the "LABORATORY POINT OF CARE (POC) INTERFACE INSTALLATION AND USER GUIDE" document I have many questions to ask starting by:

1. Does POC interface has an end users manual (for healthcare providers) , or no need for that, can you please tell me how the work flow goes on from their side ?

The POC interface is designed such that lab results automatically are filed into VistA.  So end users would not be involved.

 

1. The document states that:" The POC results are automatically entered into the patient record without a separate step of tech verification."
   my question is : Does that mean all results are automatically sent from processing device at the POC directly to CPRS via HL7 messages without any manual interaction ?

Yes, the lab messages are directly filed into VistA via HL7 messaging.  

 

1. 
   and if so, what about lab devices at POc that doesn't communicate HL7 ? can their results be entered manually?

For devices that don't have an HL7 output function, currently there is no method for data entry (see below)

 

1. The document also states that: " The support for a maximum of five separate POC interfaces is provided. Multiple POC instruments can be interfaces on a single vendor’s POC system. "
   my question is : would the interpretation of this statement be: POC interface support max. 5 lab devices per POC location, or else ?

I'm not sure about this.

 

1. 
   
2. Other than (Lab Point of Care Setup) option is there any menus related to this interface a user should be aware about?

Thanks a lot in advance, your group is much more than helpful exploring the world of VistA.

First a word about POC.  The original intent of VistA lab setup was for use in a hospital.  Thus, if the lab is going to provide testing services for porcelain levels, it would define the test during setup and then run the test.  Thus all sorts of information values are needed for each test: specimen, lab name, workload code, etc, etc.    Then, they needed a way for labs to be sent to outside labs, when they are not performed locally.  So there is functionality for that.  And when the reference lab sends back results via HL7, then the lab result is filed automatically.  The POC system, to my understanding, is an extension of the reference lab system.  It treats the POC (point of care) lab as an outside lab, and expects results to come back via HL7.

The problem with this system, is that every lab has to be defined before a result can be accepted.  I have created 2 lab interfaces for my office, and we get lab results on our patients, even if we did not order the lab (we want it this way, so we can get lab results from ER visits etc.).  And as a result we get all sorts of lab tests that I might not have even heard of before.   In the traditional VA hospital lab setup, it was not that big a deal to take 20 minutes to get a lab set up when the hospital is considering offering a new test.   But it IS a big deal when I am constantly flooded with new labs that I have to quickly get registered in between seeing patients in the office. 

Another problem, is that I could not figure out how to manage the errors that the VA lab system generated.  There would be some problem with the incoming lab, and I would search and search and search and just could not figure out what the error was trying to tell me, or what I needed to do to fix it.  And this raises another issue.  Inevitably, the HL7 messages as provided by the outside lab are not going to be in the exact format that the VistA lab system wants.  So there will have to be a transformation of the HL7 message.  Mirth is one possible transformation engine that is quite powerful.  I ended up not using it because Mirth doesn't have access to the VistA database, so it is limited in what it can do.  

I spent nearly a year working on this problem, and finally decided that I just couldn't get the POC system to work for me.  So I wrote my own import system as follows

--Our outside lab runs client software that delivers text files for each HL7 message to a shared folder

--My mumps software runs a scheduled task that polls for these files

--The HL7 message is run through my custom transformation engine.  This engine first parses the HL7 message into a mumps array tree structure for all the parts.  It then checks for handlers for each part.  If a handler exists, then that handler is called with the relevant data part, and the handler will transform the value.  Because the handlers are part of VistA, I can look up workload codes, for example, for the incoming lab descriptors, and get the message into a usable format

--I then call my custom lab filer which stores the data into the VistA database.

--During the above process, if there are problems with the filing process, than an alert is generated.  During the user processing the alert, the user is provided with a menu structure for registering the lab right then and there.

It has worked fairly well for me, in a private practice where we also get paper copies of the labs.  However, I would want someone more knowledgeable than I to go through the system carefully before I would use it in a hospital system.

Downfalls of the system are as follows:

-- The microbiology system is not used.  My system puts urine culture results in as a "chemistry" result.

-- The pathology system is also not used.  All results are also put into the chemistry part of lab results.

-- It is also very difficult at times to determine if two labs are the same.  For example, the other day I got a result for "Thrombin clotting time."  I wasn't sure if this was the exact same thing as "Thrombin time" that was already defined in my system.  So I ended up making two different labs.  Perhaps this is not the best example, but there are many immunoglobin tests that I am not intimately familiar with, so I just end up making a new lab entry for them.  Perhaps some of them should be combined but are not.

Hope this helps.

Kevin

 

[Aseel Alali]

Dear Kevin,

Thanks a lot for your replies, as you also mentioned things I was skeptical about.

I will be greedy and ask you more, let's assume that the first part of defining POC tests and all the corresponding information is there, and all IP addresses required for the connection between VistA lab and POC system is functional and configured.

1. how does the the system connect a specific lab test to a specific VistA patient
   I mean I know message containing results coming from POC device has a PID segment with those data, but from where did the device itself acquired it?
   is it from the common workflow of CPRS lab order-Print Barcode for the specific order of the specific patient?
   this is a gap for me.
2. if I want to put a scenario on what kind of communication messages POC and VistA pass to each other would this be the right way/order :

• Handshake:  (interchangeable)

From         To                 Message

VistA          POC             ACK (Acknowledgment messages)

POC          VistA             ACK (accept Acknowledgment messages)

in both MSH segment is responsible of defining sending/ receiving applications and facilities, the types of accepting ACK and application ACK

• a sample is ran into the POC device, for those lab tests previously configured to the Work/Load Profile.
• results of those tests are sent
  

From        To                   Message

POC         VistA               ORU (Observational Results Unsolicited).

and here it's either accepted, rejected or flagged for abnormal results (depending on each segment's content).

Thanks again Kevin it's really appreciated,
and I hope your efforts in your importing system could function later on in a VistA production environment,

as it shows from your words what a struggle fixing the POC errors was and what a magnificent alternative you participated in.

Regards,

Aseel

[Kevin Toppenberg]

See below...

On Sunday, June 7, 2015 at 6:07:12 AM UTC-4, Aseel Alali wrote:

Dear Kevin,

Thanks a lot for your replies, as you also mentioned things I was skeptical about.

I will be greedy and ask you more, let's assume that the first part of defining POC tests and all the corresponding information is there, and all IP addresses required for the connection between VistA lab and POC system is functional and configured.

1. how does the the system connect a specific lab test to a specific VistA patient
   I mean I know message containing results coming from POC device has a PID segment with those data, but from where did the device itself acquired it?
   is it from the common workflow of CPRS lab order-Print Barcode for the specific order of the specific patient?
   this is a gap for me.

I am guessing that you are talking something like a office INR meter.  And I think your question is how to associate the value that the machine generates and a particular patient.   And actually, I don't know the answer.  If I had to solve this in my office, I would probably write a custom application that loads the data from the machine, and then prompts the user to select the patient that the data is for.   In my hospital, I think they have glucometers that have built in bar-code readers, and before a nurse can check a patient's sugar level, they scan their wrist bar code.  Or something like that.

Does anyone else know how to associate POC data with a particular patient?

 

1. if I want to put a scenario on what kind of communication messages POC and VistA pass to each other would this be the right way/order :

• Handshake:  (interchangeable)

From         To                 Message

VistA          POC             ACK (Acknowledgment messages)

POC          VistA             ACK (accept Acknowledgment messages)

in both MSH segment is responsible of defining sending/ receiving applications and facilities, the types of accepting ACK and application ACK

• a sample is ran into the POC device, for those lab tests previously configured to the Work/Load Profile.
• results of those tests are sent
  

From        To                   Message

POC         VistA               ORU (Observational Results Unsolicited).

and here it's either accepted, rejected or flagged for abnormal results (depending on each segment's content).

I am not quite following you here.  Are you saying that you would have VistA send an HL7 message to the POC machine to act as an order?  And that message would contain patient identifiers?  And then the machine could send that information back with the resulting value?  If so, that would be great.  But I think it would depend on the individual equipment as to what they will accept.  

 

Thanks again Kevin it's really appreciated,
and I hope your efforts in your importing system could function later on in a VistA production environment,

as it shows from your words what a struggle fixing the POC errors was and what a magnificent alternative you participated in.

Regards,

Aseel

One of the issues with my system is that it is "good enough" for me.  But for it to be put into a production system, I would need to be every more careful.  And the next thing I would know, would be that my system is just as complex as the existing VistA lab system -- and likely just as cryptic to an outsider.  Lab is just a complicated subject to do properly.

Best wishes,

Kevin

[The BoMan]

Just remember to Link the POC GLUCOSE or whatever POC test you're using (file 60 to 64). We used 82115.000 (for the NLT code in file 64). Make certain you have the collection sample and topography (file 62 and 61) setup correctly. . Aso, make sure your generic user (auto-verify entry from file 200 are in and have necessary keys, etc...) You can use a Generic provider if you )wish (and your site agrees p and has a policy in place. But, the POC interface works great.

1. Other than (Lab Point of Care Setup) option is there any menus related to this interface a user should be aware about?r