Receive hl7 lab results

mdsupport wrote on Monday, July 15, 2013:

This patch is useful during hl7 transition or someone chooses only to receive results. In both cases inbound lab results do not have OpenEMR’s order reference information.

The patch will try to locate one (and only one) existing procedure order by matching patient name, dob and lab on the day specimen was collected. Original error message is enhanced to show hl7 content so order may be created manually if necessary.

The patch also enables use of the server directories for ‘download’ protocol to handle providers pushing the hl7 result files to emr server using alternate mechanisms.

sunsetsystems wrote on Monday, July 15, 2013:

I made some code comments. It’s great to see this stuff gathering support.

By the way, something that will be needed eventually is logic to handle a results-only interface by creating missing orders on-the-fly.

Thanks!

Rod
http://www.sunsetsystems.com/

mdsupport wrote on Monday, July 15, 2013:

Updated patch.

mdsupport wrote on Wednesday, July 17, 2013:

Does anyone know why ‘date_report’ field is not a datetime? It is usual for some labs to send several updates during the same day. So the time is included in HL7 standard and needs to be recorded as sent by provider.

weesnerkim wrote on Wednesday, July 17, 2013:

I am glad to see it gaining support also. I also have lab results import code for HL7 and CDA/CCD/HL7-v3. I do the same, search for a match and if nothing is close I create a procedure order. It also imports prescription information from CDA files such as the .xml downloads from Quest labs.
I haven’t been on the forum for awhile because setting up a HIE exchange for my area has kept me busy. I have both CONNECT-4 (NwHIN Direct Project Secure Health Transport) and MIRTH running along with OpenEMR and a patient portal.
My plan is to contribute this code soon as I get active in the forum again.

Kim

tmccormi wrote on Wednesday, July 17, 2013:

Kim,
We (MI2 and OEMR) are very interested in helping you move forward with sharing this code. What can we do to help out? There is a Direct Connect-a-thon going on right this very minute… http://wiki.directproject.org/July+2013+Connect-A-Thon

I have both CONNECT-4 (NwHIN Direct Project Secure Health Transport) and MIRTH running along with OpenEMR and a patient portal.
My plan is to contribute this code soon as I get active in the forum again.

Tony

mdsupport wrote on Thursday, July 18, 2013:

It would be great if some Mirth packages are shared. As tempting it may be, hl7 needs a robust, proven and versatile middleware. We can lend some time on our Mirth setup as well.

weesnerkim wrote on Thursday, July 18, 2013:

Thanks MD Support, I look forward to it. The way it sounds you have a mirth server as well.
Tony, Connect-a-thon is cool, wish I had more time to participate, HIE is such a hot item I have not had the time. Let me know what I need to do, git a branch??, from where??, version??, so I can get current with everyone. I will add my goodies, lots of great HIE and 5010-X12 also.

Kim

tmccormi wrote on Thursday, July 18, 2013:

Kim,
Feel free to contact me directly for help with github and getting in sync with 4.1.2 I can help and I’m motivated by various needs above and beyond just OpenEMR.

tony @ mi-squared.com

sunsetsystems wrote on Thursday, July 18, 2013:

Let me just note that my lab interface work intentionally bypasses middleware such as Mirth. The intent is to keep things simple, not require complex additional components, and to interface as directly as possible with the lab.

There may be other reasons to inject middleware, but parsing HL7 is not one of them and we don’t want to impose it on everyone.

Rod
http://www.sunsetsystems.com/

weesnerkim wrote on Friday, July 19, 2013:

Rod
I could not agree with you more, my CDA parser handles Observation results and substance administration direct into OpenEMR. I create orders for results that don’t match up and use the prescription import table created for allscripts results for Rx’s.
Mirth is not important, CONNECT is, all the big boys using NwHIN

mdsupport wrote on Monday, July 22, 2013:

Rod, Kim:
Since you have dealt with results-only interface (filler does not have placer order number), which field is being used to store OBR*3-Filler Order Number?
Without such a reference, processing multiple results transmission is proving to be problem.

sunsetsystems wrote on Monday, July 22, 2013:

Looks like that is not being stored. Current code requires placer order number is present. Obviously code for handling a results-only interface without existing orders will need to care about that.

Rod
http://www.sunsetsystems.com/

weesnerkim wrote on Monday, July 22, 2013:

Rod
Currently I assume all input to the OpenEMR CDA parser has been pre-filtered to belong to one of my doctors and one of my patients. All processing from there keys on specimen_num, ala search for specimen_num match for updates to prelim reports or create procedure orders for all unmatched. Orders are created for each test CBC, LIPID PANEL, etc.
Prescriptions are handled like Kevins import_allscripts_rx code except I break apart the SIG into components, 100mg 1 Tablet PO b.i.d. (this logic took awhile) and I manually put them in the medications list.
As far as OBR*3-Filler Order Number, assuming you are talking about HL7-v2.x, I just disregard. HL7-v3 XML-CDA is a payload and what I have seen is the number is hyphened onto the specimen number such as Quest EN31906E-057935.
Does this help? I may not exactly understand the question.

Kim

mdsupport wrote on Monday, July 22, 2013:

Kim, in HL7v2.x OBR allows / pair. Not sure about HL7v3 since there is no backward compatibility. But as Rod said, in results-only interface it would be another key in deciding if partial results were provided earlier by the vendor or a given packet should result in a new procedure_order.

weesnerkim wrote on Tuesday, July 23, 2013:

Rod & MD Support
I agree that we need more keys. In dealing mostly with Quest generated CDA’s the specimen - number combo has worked in handling partial result updating for now. The largest problem so far has been with codes and code systems, LOINC, SNOMED, CPT, Quest, and matching up observation BATTERY(test,CBC,LIPID,order) with results(WBC,LDL,HDL). Each lab having full code_type table configurations is a problem, not to mention observation results can change code systems inline.
Test can be ordered using SNOMED and results using LOINC or custom, or both.
I have some suggestions I will write up and share, gotta go for now.

Kim