sunsetsystems wrote on Wednesday, March 09, 2005:
So, in the "old" developer forum there were messages from Andres and Dr. Bowen indicating they were working on HL7 interfacing to labs.
It appears I may need to get into this area also, and would like to hear about the current status of these projects. Please post here, or drop me a note. Thanks!
rod at sunsetsystems dot com
drbowen wrote on Wednesday, March 09, 2005:
Hi Rod,
I would say that I “want” to work on HL7 interfaces but haven’t started anything more than the thought process.
Part of the problem is that the laboratory vendors don’t want any of their proprietary software either released as GPL’d software nor do they want their own code “tainted” with the GPL licensing.
My thought process was that if the client medical office has a secure connection (likely VPN) with the lab vendor then the client medical office could have a run-time program listening to the VPN connection. The lab company would delivery data using the HL7 format. As the messages were being delivered the listening run-time program would upload the HL7 messages to the OpenEMR database.
The OpenEMR php code would then display the messages inside a particular patients chart using the pid.
This would allow a one way connection to display data.
A two way connection where the client medical office can upload orders to the vendor lab will likely not be possible unless the vendor will be to allow us to look at some of there code (very unlikely) or GPL the client end code for use in OpenEMR (also unlikely).
My approach would be to set up a table in EMR that allows the HL7 messages to stored intact using either a longtext or possibly a blob. This will be a very long table with lots of records and may need to be indexed to improve data retrieval speed.
Only the metadata need be displayed in the EMR and then specific messges could be parsed with HL7 parser as needed.
Certain values might be better stored in separate columns to allow graphing (with jpgraph for example). This would allow easier monitoring of key lab values such as creatinine, hemoglobin A1c, hemoglobin and others. This will be a key feature for the future of medical practice.
We like Python for its speed, easy maintainability, and rapid prototyping. Once a module is worked out and funtioning well it can be rewritten in C for improved speed and good run-time performance.
I look forward to hearing your thoughts.
Sam Bowen, MD
sunsetsystems wrote on Wednesday, March 09, 2005:
OK thanks. My client will want to use MPL, Quest and Lab One, so I expect to be talking with these guys eventually. My thoughts will follow. 
I don’t see that we need any of their proprietary code; surely interfacing specifications would be sufficient…
– Rod
andres_paglayan wrote on Thursday, March 10, 2005:
Hi there,
I am currently working on the HL7 interface with Ticore,
the approach is based on the PHP PEAR HL7 module for parsing but uses custom hl7 fields definitions from Tricore themselves,
by changing the inc to any other lab definitions you’ll be able to import any lab report,
Ticore will provide a file on a FTP server, the script connects and download it,
I am taking this week very easy since I just got a new son,
andres_paglayan wrote on Monday, April 04, 2005:
just a little note,
I am still working in the HL7 parser, and got the point where you can define different labs, but still need to input that data in the chart, so coming soon.
but I had to swith to other priority now,
The clinic director wants sort of ‘permanent forms’
these will be tables that contains information meant to be tabulated and in the paper-like practice these are forms where you go every encounter to the same page to check and add info, such as children vaccination, flow chart, problem list, etc.
feed-back welcome,
drbowen wrote on Monday, April 04, 2005:
Rod Roark has already added a problem list.
I call these things "flow sheets". A similar example would be to track Protime and INR tests for managing Coumadin.
Some of the data such as growth charts should be pulled from the vital sign table. It would be nice to enable graphing with jpgraph. Given a particular table and column have jpgraph do the work. Such as form_vitalsigns.weight_lbs.
The vital signs table, unfortunately has three different columns for weight. In my opinion, this should be consolidated into one column called "weight". It would be a simple matter to be able to select "pounds", "kilos", or "ounces" from a drop down box for the default input for that particular patient.
The table might actually store "grams". A user selects "pounds" for input. The php would take the entered number and calculate grams and store the result. Output could then be returned in "pounds".
Pediatric offices could then graph patients in "grams" or ounces until - say - age 2 and then the default for that patient would be switched to the appropriate "pounds" or "kilos".
Having only one column for weight would greatly simplify graphing the weight. This is especially important in pediatrics where Growth Charts are such an important part of the care.
Graphs of height, weight, and head circumference could then more easily be compared to normal growth curves.
Reducing the number of columns of "weight" from 3 to 1 would improve normalization of the table and reduce headaches for practices that see children.
Sam Bowen, MD
andres_paglayan wrote on Friday, July 01, 2005:
Back to the keyboard,
for the HL& retrieving tool I am about to set the following tables, but wanted some agreement before. Don’t worry about the field names, I’ll beautify them.
File supported is result transaction type, ORU, since it’s downloading a file from an FTP server there is no hl7 ack/nak talking.
lab_headers (table) this holds relevant info on MSH, PID, PVI, ORC and OBR segments.
and matches what is regularly printed in the lab header paper report. This information is sent by the lab, and does not necessary matches OpenEMR schema,
lab_head_id
Patient name
patient_id
DOB
Sex
Alias
Patientaccountnumber
Ssn
Status
Physician
DateCollected
DOS
Print
Requisiton
Patient _phone
lab_reference
laboratory
Hl7fileID
Timestamp
lab_results (table) holds the information of the OBX segment, refers to a header.
lab_result_id
lab_head_id
Test
Note
In range
Out of range
Units
Reference range
Flags
Site code
Timestamp
lab_hl7_file(table) holds the original file retrieved, just in case, it may contain more than one lab report.
Hl7fileID
Content
Received
lab_transaction (table) this one, is the one that matters for the work flow,
it holds the status of one particular lab report, and to which patient record has to be assigned. I think this has to be manually done, I see something like this: a flag appears on the screen, it says new labs received, the assistant clicks there, sees a list of the lab headers with a mark on those with abnormal values, runs a pop up to assign the lab to a patient. But at this point something else has to be done, but not sure what, send and email to the doctor?
Fields on lab_transaction.
Date
Pid
User
Groupname
Authorized
lab_head_id
Received (date)
Assigned (date)
Notified (date)
Notes (free text input)
Status (current status for extended functions, but it can be pulled from received, assigned, notified)
timestamp
sunsetsystems wrote on Friday, July 01, 2005:
Not sure I follow all this, but it looks like very good stuff. Regarding the work flow:
The lab should have some way that we can give them our patient ID, and then feed it back to us when the results come back. It would be pretty silly to have to match up the results with the patient manually.
We need a notification or "reminder" system. The closest thing we have to that right now is the "authorizations" list that appears at the bottom of the screen when a doctor log in, and perhaps that could be polished up and made more general. Giving it the option of sending email would also be reasonable.
– Rod <rod at sunsetsystems dot com>
andres_paglayan wrote on Friday, July 01, 2005:
yes, when I said manually, I meant look up the database and pick a patient to assign the lab to, in the sense of not trusting the data from the lab report to match a patient in the database and autmaticaly push the result right there.
for the notification or reminder, I thought of a red label at the top of the screen for any new labs not yet assigned and a yellow one for the specific doctor logged in.
markleeds wrote on Friday, July 01, 2005:
Do we need an email field for the doctors to send out reminders? The patients and pharmacies already have one.
ALTER TABLE users
ADD `email` varchar(255) NOT NULL default ‘’;
andres_paglayan wrote on Friday, July 01, 2005:
makes sense,