Comments below: I am a definite beginner on lab issues, so please be patient with me...
On 8/17/05, Carlson, Larry G <[EMAIL PROTECTED]> wrote: > 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. OK. Lets start at the beginning. I have an RS232 serial connection out of the machine. I run a cable from this instrument to the serial port of a terminal? on the server? on a dedicated computer for lab systems? Would I have to get a multiport serial box etc for the computer so that all the machines have their own serial connection? I assume it would be a dedicated lab computer. Would I then have to write an interface for this computer to talk to the server? Others have recommended using the "data concentrator", and I think you are showing how to not use that. Correct? > We later moved to Cache - at the same time as we began bringing DI up. I assume that "DI" is a lab package? I could look this up, but haven't yet. This > was fortunate as VMS/Cache automatically changed some parameters (such as > PASSALL) when opening a port and we had problems with the locally written > lab interfaces as well as simple printer connections. Cache support helped > with open parameters that put us back in business, however, by then we were > moving everything we could to DI anyway. > > I did have a one interface moved to TCP/IP by using a JetDirect box before > Cache. I have Jetdirect printer servers. That's not the same thing is it? 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 don't understand TNA or LAT connections, but perhaps I don't need to. 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. Is this true? Does anyone know where I can get more information. > > I would think it would be worth the effort someday to attempt to put > together an internal interface facility (in VistA) to handle lab instrument > connections (HL7, as our directs are now, or both and more). I got the idea that this is what was already the standard way to do things (i.e. handle a HL7 message) If properly > designed the general purpose interface should allow bringing up a new > instrument to only require appropriate modification of present and some > additional lab files (a gui front end could make this even more painless) > People much brighter than I will have to decide if this is worth > investigating and with design features. It does sound like a worthwhile project. > > Speaking of gui - I have written (with help) several Delphi applications > (things like phone directory [VAcinity] - Hi Rick -, transcription watch > applications, Nuclear Cardiology stress testing data collection, etc) which > push and pull data to/from VistA, and was really sorry that Kylix support > seemed to fade away. I was really looking forward to bringing up a GTM box > with VistA and seeing if I could re-compile. I have really enjoyed writing > RPC broker events in VistA and connecting them to a gui front end and was > hoping to play in Linux too. --- all for free, of course ;-) Did the RPC Broker ever get working in Kylix? That is the achilles heel of that project I think. It sounds like you might be the best man for getting a good lab front end up and running. > > Personally I love the idea of continuing to make VistA fully functional > without the need for commercial licenses. DI has been great, however, a > completely open source package just sounds right to me which is why I have > followed World VistA progress. > > -poo If you are interested in helping my group set up a lab interface, I would be interested in having you get paid for your effort and then contribute the code to open source. Let me know. > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Joseph > Dal Molin > Sent: Wednesday, August 17, 2005 5:58 AM > To: hardhats-members@lists.sourceforge.net > Subject: Re: [Hardhats-members] Lab interfacing... > > This indeed would be a nice open source project especially since there > many point to point interfaces already written in VistA and it could be > reused by other open source health solutions. Might be something that > could be done with Jengine as the integration layer?? Although if the > cost per interface of the DI and other solution is affordable for > smaller organzations then it may not be worth the effort? > > J. > > John Leo wrote: > > Sounds like there may be a place for an open source solution to > > standardize and maintain such interfaces. > > > > Larry, are these interfaces just MUMPS routines? I assume the hardware > > interfaces are either serial or TCP/IP? Are there examples available in > > the FOIA VistA? > > > > > > Carlson, Larry G wrote: > > > >> > >> I have written (stolen too) about 20 such interfaces in the past for the > >> Seattle VA. > >> > >> 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. > > > > > > There has to be a tip point at which buying/building/licensing a > > separate box to connect just a handful of instruments is not worthwhile. > > > > And another one where there just is not the expertise available to > > roll-my-own. > > > >> 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. > >> > > > > I am going to have a task similar to Kevin's. But smaller scale and with > > nothing significant already purchased and in use. > > > > thanks, > > jlz > > > > > > > > ------------------------------------------------------- > > SF.Net email is Sponsored by the Better Software Conference & EXPO > > September 19-22, 2005 * San Francisco, CA * Development Lifecycle > Practices > > Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA > > Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf > > _______________________________________________ > > Hardhats-members mailing list > > Hardhats-members@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/hardhats-members > > > > . > > > > > ------------------------------------------------------- > SF.Net email is Sponsored by the Better Software Conference & EXPO > September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices > Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA > Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf > _______________________________________________ > Hardhats-members mailing list > Hardhats-members@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/hardhats-members > > > ------------------------------------------------------- > SF.Net email is Sponsored by the Better Software Conference & EXPO > September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices > Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA > Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf > _______________________________________________ > Hardhats-members mailing list > Hardhats-members@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/hardhats-members > ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
