drbowen wrote on Monday, July 30, 2012:
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:
http://www.oemr.org/phpBB3/viewtopic.php?f=5&t=158#p908
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.
Appliance “Library”:
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.
Laboratory Logs:
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.
Statistical Analysis:
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:
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:
http://www.open-lims.org/home.html
I have no idea what their database structure looks like but I suspect most LISs have very similar looking tables.
Links:
http://www.oemr.org/wiki/Lab_Test_Results
http://www.oemr.org/wiki/Office_Visit_Flow_General
http://www.oemr.org/wiki/The_Laboratory
I think we really ought to move this particular discussion over to SourceForge.
Sma Bowen, MD
http://OEMR.org
Executive Director
