I have recent hired a ASCP certified medical technologist and in addition to my existing hematology analyzer am adding a chemistry analyzer and an immunoassay analyzer. This brings up the need to have an integrated Laboratory Infomation System (LIS). I have been discussing this with Tony McCormick of MI-Squared and Sena Palanasami of Visolve. This was brought last week on the OEMR Ad Hoc committee meeting that happens every Tuesday at 12:30 PM Eastern. I wanted to post what I am thinking here to be able to get input from the community during the design process, I think this will help solve the Meaningful Use Phase II Laboratory discrete data and CPOE requirements.
There is a thread that was started on the OEMR forum that I am moving here since it is more straight development:
Kevin, you are quite correct. The analyzers always have to have an API built to allow the analyzers to import data into the mysql tables in a way that they can be viewed by the end users (laboratorians, clinicians, lab reviewers). While this may be an incomplete list, lhe main modules are:
CPOE: Computerized Physician Order Entry.
MI-Squared has been working on a LabCorp order entry for some time. According to tony is about 80% finished. Since multiple end users use various reference laboratories there is a need for more than one interface. Our office uses LabCorp so this is fortunate for me. What I am hoping is that the LabCorp interface may by modified to select "Send labs out to LabCorp" or "Order In-house laboratories" so that we can take advantage of this already almost completed interface. This does bring up the problem that the LabCorp interface requires a a secure connection to LabCorp, as does Quest, CPL and the host of other private reference labs. Some one has to build and maintain these connectors. This gets into the proprietary solutions being offered by MI-Squared, Visolve and and others.
The local laboratory, in my case, BPUC, will need a solution that can be incorporated into the OpenEMR code base that is not encumbered by proprietary solutions. So the CPOE will need to able to operate without a proprietary solution, at least for the local instance. Rod's orginal laboratory entry is extremely versatile but the problem is the that it is extremely versatile. So much so that normal users have no idea how to get started using it and each local lab will have a highly individual version of the LIS. The proposed LIS module will create a standard interface that will be much easier for us end users to learn how to use so that it doesn't take much work to actually get the lab order entry working.
In this process I am hoping that this section in OpenEMR gets renamed form "procedures" to "CPOE" or "Order Entry". The term "procedures" is correct in the "insurance" dialect but means something else to a physician. In the physician dialect a procedure is poking something into a patient such a catheter, an endocsope, cutting with a scapel, performing an x-ray or other diagnostic procedure.
Each appliance has a "Host communication protocol" and as referenced by Art above have a large array of protocols. Many diagnostic machines such ECG machines do use proprietary protocols that are carefully guarded by the manufacturer. In the laboratory this is not usually the case because all of the laboratory analyzer manufactururers assume that the laboratory will by using an LIS with which their machine will need to communicate.
Older machines use the old ASTM protocol. As an example, I am using a Coulter Ac-T Diff II. This analyzer "prints" the messages to either a printer or to a serial port. If printing to the serial port it needs to be connected to a PC that is listening on the serial port and knows what to do with the incoming data. The techincal specification from Coulter uses messages that uses a pipe separator that at least superficially look like HL7 messages to me. This behavior is typical of the smaller simpler machines (My Ac-T Diff II, a dipstick reader, my A1c analyzer). For my application there will likley be 3 of these interfaces.
Newer usually more sophisticated anmalyzers have two way interfaces. The sample is collected by the laboratorian, labled with a bar code, entered into the LIS, and an order is pushed from the LIS to the analyzer. The sample is placed into the analyzer which reads the bar code and performs the requested set of tests on the sample. These analyzers are larger, have better CPUs, more memory etc., and cost a lot more money. Typically multi-channel chemistry analyzers and imuno assay machines. Usually the newer machines are using HL7 messages though the specific version of HL7 may be a little older and or modified by the manufacturer to a non-standard version. It is certainly possible to build only a one-way interface initially. For my application there will be two of these interfaces.
Almost always, a new analyzer needs its own interface written. Oftentimes of the analyzer manufacturers will pay for the development of the interface because it is in their best interest to promote the use of the analyzer. As each analyzer is created we will build an increasingly large libary of this type of API. Whether or not we could create a Class to build these interfaces is well over my head but because of the large number of required interfaces, this is worth some thought.
A series of "logs" which may need to addition of additional tables. Main laboratory log where every sample is collected with an individual sample identification number (Thw assession number), patient identification, datetime of collection, collecting phlebotomist, the analyst performing the test, the analyzer used which may be a waivered test (no analyzer per se), datetime of completion, who the result was reported too, datetime the clinician was notified, whether a sample was referred to a reference lab (such as LabCorp), and when the results were reported by the reference lab.
There are logs for each analyzer which include the serial number of the analyzer, when the analyzer was put into service and taken out of service (may be placed in and out of service multiple times for maintenance), initial and susequent calibration, running of controls, initial correlation studies, patient results. There are special views for the controls, calibration and proficiency testing. In the results log these are recorded as "patient results" but these are special samples that need their own flags. (normal patient, calibration, controls, correlation study (lab and reference lab pairs), proficiency testing)
Reagent logs. Tracking dateime of ordering, inventory, lot numbers, expiration dates, cost per unit, date placed into service. alarms for expired items or use of the item on the analyzer past its expiration. The controls are a special type of reagent that are either real human or recontituted samples that are critical to monitor the expiration dates.
Analysts: Yes, we have a work flow for the analysts, keeping track of documents, training, performance reviews, hourly rate, hours worked, etc.
We have about 10 different types of logs that we use. Once the LIS is written there is likley substantial overlap between these logs and the total number of required additional tables is likely to be small. I have scanned the logs into single page pdfs and will upload these to the wiki.
Most of (or perhaps all) of the analyzers need exactly the same type of statistical analyses. These analyses are used on the initial corelation study when setting an analyzer up, to monitor the controls to detect malfunction of the machine, and more rarely to set up the "normal values" for the individual laboratory.
Reporting depends on the end user role. I as a clinician will wan to be able see the most recent results but also be able to quickly compare curent values with historic values. Being able to plot each individual lab value will be a big plus.
Laboratorian: The laboratorian will need easy access to statistical analyses of each separate analyzer. Reporting for monitoring by CMS and CLIA. There are specific reports that may be used only for the review process. The laboratorians may nee dto have different access levels. Phlebotomists and analysts are likely going to need reduced privileges compared to the laboratory director.
Generate reports to other physicians to be able to send lab results by paper, email, fax. All reports must have the name, addrss, and laboratory directory attached. Any reference labs reports usually have additional formatting requirements to match the normal appearance of the companies usual paper reoprts.
We need a laboratory review tool where we can see the labs, enter comments, and then generate a letter to the patient that includes the lab values, comments, and send it out by mail, email, or fax.
Job Cost Analysis:
Job Cost Analysis is a special reporting engine the pulls data from the analyzer logs, reagent logs, Analyst logs to compile a report that reports the components being considered, variable detail in the report, calculation of amortization cost of the analyzer, reagent cost, personnel cost, laboratory director cost, floor space cost, utilities, etc.
Recycle or Reuse Code:
I have not looked in a while but there have been other LISs built. There is an open source Apache, MySQL, PHP project here that looks like it has some promise in terms of similar architecture so that we might be able to possibly collaborate, borrow or re-use:
I have no idea what their database structure looks like but I suspect most LISs have very similar looking tables.
I think we really ought to move this particular discussion over to SourceForge.
Sma Bowen, MD
I'd like to get some details ASAP as to what Tony's group is doing with order entry. I also have a lab interested in that and would like to avoid duplication of effort. Tony, do you have (or can you put) your current (non-proprietary) stuff on github?
I have a zip file of code that I paid (am still paying) ZHH to write for us. It's been languishing here in MI2 land waiting for me and my staff to have time to do QA and testing. I gave a copy to Ensoftek to help us out, but they have been just as swamped and have not made any progress either.
I will happily post the code for anyone that wants to try and finish it or use it is some way. In order for it to be used with LabCorp (for whom it is intended, first) it still has to go through extensive testing and approval with them via the MI2 LEN server connectors we have with LabCorp.
Here's the rub, ZHH did not tell us where this was branched from in the release and it's been quite a while since they stopped working on it ( 6 month or so). It may be weird to just post it on a github, but I'll try anyway.
Rod -- short term or as an option, I'd be happy to send you the ZIP file too, just like I did Ensoftek.
I might make sense to post it to the hub and we'll be able to diff it to the latest release and figure out the integration from there….
Hi Tony, sure you can send me the zip or post it on github and I'll see if I can make sense of it. It will help a lot if you can tell us what files they changed, and include any documentation.
Note: That branch is NOT merged.. I unzipped the code over the current release, replacing anything that was there. No idea if it will work that way…
82d833d Lab Orders Interface - by ZHH for MI2
I have been talking to FML/CPL (http://www.cpllabs-midatlantic.com/home.aspx) here in Virginia. They are willing to do the interface to connect to openemr. They need a point man to discuss interface issues that is beyond my knowledge. Is there anyone here who will be willing to spend time to work with them to make this work and then make it available to the community without fees and such. Let me know by the end of the week. I think this is a great opportunity for our community and one step closer to our ultimate goal.
I am interested in this project and have other aspects of the lab informatics that I am working on. Please send me an email and we can arrange a time to discuss - firstname.lastname@example.org
Much better strategy is to figure the approximate time that this code was last part of the main codebase. For example, if it was 6 months ago, then just pick a commit at that time and do the following:
git checkout master
git checkout -b make_lab_commit
git reset -hard <sha1 of commit you located above>
Now bring in your code/patch.
git add .
git commit -a -m "Lab orders interface, take 1"
(copy the sha1 number of the commit you just added)
git co master
git co -b lab-orders-interface_1
git cherry-pick <the sha1 number you got from above log command>
Even better would be for ZHH to tell me what they based it on…
Tony, do you have the entire original code tree that includes these changes? That would help to identify when they were done.
I spent a bit of time today looking at this, ignoring for now what it should be diffed against. It's kind of hard to follow without knowing more about what the intent of the design is. But it seems they've thrown away all the code for the manual lab order entry system, as well as the procedure_order and procedure_type tables, and replaced them with something else where orders are stored as LBF data.
I can see adding an alternative order entry system, but not throwing away the old one that resulted from a great deal of collaboration and discussion, especially without getting consensus on it. I've got clients using that stuff. So this code is going to need some significant refactoring, and I'd like some explanation of its design.
Been a little swamped lately to read the forum stuff. Tony directed my attention to this. I should have responded earlier. Apologize for that.
Tony contracted us over a year ago to develop some parts of his LEN which included configuring mirth and developing an order entry system. At that time it was not meant to be released but was to be part of the LEN( i may be wrong about the intent.) In any case the project was developed according to specs provided by MI Squared and the way it was designed was approved by MI Squared. I am forwarding the entire documentation to Tony. The documentation will show that everything was approved and directed by them. They will also show you why it was designed the way it was. Tony may release those to you guys: it is his call.
Regarding his statement
that I paid (am still paying)
that I paid (am still paying)
I am sure he means that he is paying us in installments for the work that was done long ago and that we are not still charging him.
The code was based on the official release version of 4.1 before the patches.
Meanwhile we are developing a module in Zend for the labs which will use all the tables that are currently on there. I had discussed this with Brady during one of those weekly meetings and also in some earlier posts where in we had hoped that this will be a way to show how we can include the Zend model into OpenEMR. Of course, it is the community's choice to accept it or not. We however, wanted a much better and intuitive UI and have to develop this for our clients.
Hope this clarifies things.
Hello Mac, I replied to your email but haven't heard from you. I need your phone number to give to CPL or do you prefer to use your email. I thought Brady and Sunsetsystem would have an input as to how best to do this
Not sure why but didn't get the email. Yes let's talk with Rod and Brady. Give me a call when you have some time at 401-345-4665.
Mac and voipbound - of course I'm interested but suggest that CPL use this forum to discuss interfacing and other technical issues, especially as there are multiple developers with interests in this area.
agreed, let's use this as an opportunity to get a community / vendor project coordinated. voipbound, let's get the lab contact person to setup an account here and on github. we'll obviously have conversations with them offline but we'll present findings, issues and code here. let's set up s new thread dedicated to their integration project.
I do not think their IT department will get on the forum. I got that impression as I was talking to their head honcho. It will be best if they have a point person who is knowledgeable with the innards of openemr. Mac, you can be that person. I got your phone number. Let me know if it's ok to give him your number and we can get this going…
I do not think their IT department will get on the forum.
I do not think their IT department will get on the forum.
Might not be too far-fetched for just the person doing the programming to get on here. Tell them we have cookies. :)
let them know we don't byte. worst case we can proxy their feedback, but it would good to have firsthand vendor participation in the forum. let's discuss sometime soon.
Dear Mac, voipbound,
Would you send please me your contact info?
drbowen @ bowenmd.com
You need my info or my contact man at CPL? I will direct him to the here but I really think one point of contact is best. CPL is doing this for free! I need to provide a contact person by this Friday!
You can give them my contact number and we'll go from there.
I was looking for your personal contact info?
Log in to post a comment.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.