Difference between revisions of "Helpful EMails"
(Added a glossary link to file~) |
|||
| Line 29: | Line 29: | ||
routine. On today's systems you could just as easily Job the routine to a | routine. On today's systems you could just as easily Job the routine to a | ||
separate port (serial line?) for each instrument. The definitions for how | separate port (serial line?) for each instrument. The definitions for how | ||
| − | the instrument lays out the data are in the AUTO INSTRUMENT file 62.4. | + | the instrument lays out the data are in the AUTO INSTRUMENT [[file~|file]] 62.4. |
--Cameron Schlehuber | --Cameron Schlehuber | ||
----------------------------------------------------------------------- | ----------------------------------------------------------------------- | ||
Are you saying that the protocol for communicating with the macine is | Are you saying that the protocol for communicating with the macine is | ||
| − | stored in file 62.4? | + | stored in [[file~|file]] 62.4? |
--Kevin T | --Kevin T | ||
----------------------------------------------------------------------- | ----------------------------------------------------------------------- | ||
| Line 43: | Line 43: | ||
interface would then parse it into the ^LAH global in an acceptable pattern. | interface would then parse it into the ^LAH global in an acceptable pattern. | ||
Each interface depended on a listener connected to a device in the device | Each interface depended on a listener connected to a device in the device | ||
| − | file. Each instrument would read the barcode label on the specimen | + | [[file~|file]]. Each instrument would read the barcode label on the specimen |
container and send (by serial originally) the test results with the barcode | container and send (by serial originally) the test results with the barcode | ||
- which was unique to this patient's test request. | - which was unique to this patient's test request. | ||
With the ^LA global set appropriately, the lab techs would enter the lab | With the ^LA global set appropriately, the lab techs would enter the lab | ||
options to verify auto-instrument data and would verify each result. | options to verify auto-instrument data and would verify each result. | ||
| − | The Load/Worklist and AutoInstrument | + | The Load/Worklist and AutoInstrument [[file~|file]]s were set accordingly for each |
instrument. | instrument. | ||
| Line 87: | Line 87: | ||
on the fly (I had to pull out the routines into my namespace and take care | on the fly (I had to pull out the routines into my namespace and take care | ||
of all previously interactive pieces) then returns to Roche the patient's | of all previously interactive pieces) then returns to Roche the patient's | ||
| − | name and the accession number of the | + | name and the accession number of the [[file~|file]]d test. We are switching to the |
recently released national POC HL7 interface that will have national support | recently released national POC HL7 interface that will have national support | ||
and does a much more thorough job of confirming correct patient (clinic | and does a much more thorough job of confirming correct patient (clinic | ||
Latest revision as of 22:01, 5 July 2013
I want to interface the lab in my office into VistA. The suggestion that I was given was to get the equipment to send HL-7 messages to VistA.
Here is what we have: 1. Beckman Coulter Synchron CX5 delta http://www.beckman.com/products/instrument/genchem/cx5delta.asp This is our chemistries machine ... Our machines save RS232 ports. Would I have to manually create "drivers" for these devices? --Kevin T.
Look at the web sites: http://www.datainnovations.com/ and http://www.dawning.com/ ... Both of these companies sell PC's that consolidate data from various lab instruments and transmit it to a Hospital Information System. We use a Data Innovation Lab Instrument Manager. It is licensed by the number of drivers you need. Each instrument needs its own driver and there is a driver for the VISTA system which speaks HL-7. --Charles G Lambrecht
Those devices basically pool multiple character streams into one. Two and a half decades ago systems were not very fast so we (Wally and I) programmed a PDP-11 (the single card version smaller than the 11/03) in RT-11 assembly code to buffer the data so the 11/70 could keep up. Take a look at the ^LAB routine. On today's systems you could just as easily Job the routine to a separate port (serial line?) for each instrument. The definitions for how the instrument lays out the data are in the AUTO INSTRUMENT file 62.4. --Cameron Schlehuber
Are you saying that the protocol for communicating with the macine is stored in file 62.4? --Kevin T
At least for some machines, yes. --Cameron Schlehuber
In the past direct connect interfaces would be written to accept the data stream from each device, push it into the ^LA global. The listening interface would then parse it into the ^LAH global in an acceptable pattern. Each interface depended on a listener connected to a device in the device file. Each instrument would read the barcode label on the specimen container and send (by serial originally) the test results with the barcode - which was unique to this patient's test request. With the ^LA global set appropriately, the lab techs would enter the lab options to verify auto-instrument data and would verify each result. The Load/Worklist and AutoInstrument files were set accordingly for each instrument.
We now use Data Innovations for all but 4 of our interfaces. Paying for DI results in a stable environment that doesn't depend on having programming expertise on board. Also, writing local direct connect interfaces - although fun - is a never ending job as the labs continue to purchase new instrumentation. Nonetheless, it may be that interfaces written for similar equipment for VA labs may run with little modification in instances where avoiding annual license fees are an issue. (DI = [DataInnovations]) --Larry Carlson
Kevin, simply interfacing the devices into a Data Innovations or Dawning system would "do the trick", of course there may be so interface writing but that is not too terribly complex. At our site in the VHA we use Dawning, if collects the results from the modalities and then sends HL7 to VistA. -- Roy Gaber
The lab package comes prepared for instrument interfaces - which are just M routines (and not really all that complicated). The ones I put together (or stole, or modified stolen code) used LAT serial connections. ... I did have a one interface moved to TCP/IP by using a JetDirect box before Cache. Just had to change the Kernel open command on the M routine as the MAXM still thought it was connected serially. We are now in the process of moving the remaining direct connects to Lantronix boxes in the closet which behave much like JetDirect except a TNA type VMS connection is suppose to allow them to still use LAT-type commands on the M side. I will know more about whether this works in a few weeks. We have a Vitek, Bactec, and blood gas machines still on direct connect.
We also put together an HL7 interface with Roche glucose meters. The Roche system has an MAS HL7 interface so I only needed to write the necessary M handling routines in VistA. The meters send the patient's SSN, glucose result, date/time of test, DUZ of user, and comments. My processing routine hops on the old FASTLAB options that allow ordering and resulting of tests on the fly (I had to pull out the routines into my namespace and take care of all previously interactive pieces) then returns to Roche the patient's name and the accession number of the filed test. We are switching to the recently released national POC HL7 interface that will have national support and does a much more thorough job of confirming correct patient (clinic appointment for the day etc). Nonetheless, the project demonstrated that an HL7 lab interface is not too difficult. BTW I presume John McCormack's group's POC interface is available as part of VistA now. --Carlson, Larry G
