rdejournett wrote on Thursday, January 22, 2015:
Hi, I am an HL7 developer and I am wondering what the current state of this project is with respect to import or export of HL7 data, and if there was anything I could do to assist.
Ie - is there a user interface for import of data such as a bridging tool for lab ORUs?
Are other types of HL7 messages wanted or needed and not present? Or not very current?
Thanks!
teryhill wrote on Thursday, January 22, 2015:
I know there is a need for the ability to do a demographics interface (insurance, patient information, encounter information, etc) so openemr can communicate with other systems.
Terry
sunsetsystems wrote on Thursday, January 22, 2015:
We have a pressing need to export QRDA Category I and Category III reports to satisfy MU2. This is XML stuff based on CDA and thus HL7. We’re having a tough time digesting the spec and finding examples. Got any insight/experience in that area?
rdejournett wrote on Thursday, January 22, 2015:
Ignore.
rdejournett wrote on Thursday, January 22, 2015:
Rod, just a bit, most of my experience is implementing traditional interfaces HL7 2.x and a bit of CDA/CCD. The spec is here http://www.hl7.org/implement/standards/product_brief.cfm?product_id=286
Looks like a mouthful. Have you been able to extract the QRDA required information? Is it a display/ ETL issue?
rdejournett wrote on Thursday, January 22, 2015:
Sounds like a bidirectional ADT interface. I looked at the user documentation and did not see anything describing HL7 interfaces. THere are two large issues: Creating the backend services needed, and creating the UI infrastructure for things like monitoring status of interfaces.
I use Mirth Connect extensively and I would recommend it for this project, it is also open source with a similar business model. We could use it to generate HL7 interfaces and use it for interface maintenance and support. The idea is that it would take a HL7 data stream and directly import it into the OpenEMR database (performing validation and checking of course). That would be for inbound ADT such as an A04 or A28 (new patient).
For Outbound ADT I would create a new entry point or trigger such as a HL7ADT table with entries PatientID Status DateTime, entries on this table would be scanned by a Mirth channel (interface) and if there are any rows the HL7 would be sent.
mdsupport wrote on Thursday, January 22, 2015:
There are two major challenges with HL7 used in this project:
There is no central library functions to process hl7 segments. So CCR and Lab orders have different approach/logic to process hl7 data. This makes it harder to leverage existing code for new fuctionality.
Hard coded functions will need a complete rewrite for HL7v3 - a major effort since current code parses raw text…
HL7 will become increasingly important and complex in MU2 and beyond. Can you suggest any engine to bring in robustness and flexibility to this process?
mdsupport wrote on Thursday, January 22, 2015:
Mirth integration will be a great contribution to this project. We can help in that process.
sunsetsystems wrote on Thursday, January 22, 2015:
I don’t think we are willing to require Mirth and the complexities and overhead of a Java engine for the average OpenEMR installation. OpenEMR is a PHP project.
Non-Mirth HL7 solutions should continue to be considered. We do that already for X12 claims with a single easily-understood PHP module (see library/gen_x12_837.inc.php), “hard coded” though it may be. Similarly, see the lab data export and import modules interface/orders/gen_hl7_order.inc.php and receive_hl7_results.inc.php.
A PHP alternative to Mirth would be a better fit.
mdsupport wrote on Thursday, January 22, 2015:
It is not an either/or choice. There are and will continue to be users who run complete package from their laptop. They should be able to use PHP coded functionality. On the other hand if someone is willing to add another box or go through additional install steps, they would leverage benefits of a highly flexible infrastructure. This is no different than adding WordPress to the mix. If someone doesn’t know it and doesn’t have urgent need for it, they are able to use vanilla OpenEMR just fine.
So rather than asking Rob Dejournett to polish up PHP, it is better to leverage his Mirth expertise to add an open gateway to the current project. We already use it and have been very happy with the performance.
teryhill wrote on Thursday, January 22, 2015:
I have mirth running on my development box (windows 2008 server R2) with openemr and have accomplished moving data from openemr to a 3rd party app in a XML format.
Terry
rdejournett wrote on Thursday, January 22, 2015:
Okay sounds good. So what is the biggest need? Demographics? Scheduling? Labs?
sunsetsystems wrote on Thursday, January 22, 2015:
If someone wants to make connectors for special needs that’s fine. But again, requiring Mirth for “normal” use of OpenEMR is not.
Rob, I’m curious… are you familiar with Mirth internals? Is it modular and well organized, or more like your average spaghetti bowl? Just wondering if we can learn anything from it as we move forward with HL7 stuff. Good design principles transcend language.
As an aside, there’s a PHP PEAR module Net_HL7, but that seems to be unmaintained.
rdejournett wrote on Thursday, January 22, 2015:
Rod, I do not, but the source is available. I think if the project were not to use an existing interface engine then code would have to be written to handle troubleshooting and maintenance of HL7 data streams. The advantages of Mirth are that it is free & open source, and already there is a bunch of work to create the necessary infrastructure for viewing and replaying messages. Without this, interface engines become very difficult to maintain and troubleshoot.
For example, Allscripts PM uses AIE, their homebrew solution. The GUI contains configurable items but all the troubleshooting data are in SQL tables. As a result, it’s impossible for any practice staff user to figure out, and for support personnel they must have good understanding of the table schema and good enough SQL background. (and of course now you are twiddling directly in the database with a minimally trained person)
Another company I worked for used iguana (interfaceware) for another home brew, but the traffic needs were pretty light (it’s a radiology app, so they get a few orders and some ADT from different vendors). This is a possibility too, but what I saw there was every time they added a vendor it got more and more difficult to write code.
The good thing about using an interface engine like Mirth (or Egate or Rhapsody or Cloverleaf), is that it’s modular and scalable. We can write one interface to connect to Cerner, another to connect to Epic, and a third to write to Allscripts PM or EHR.
Anyway that’s my two cents from being in that field. It may be possible to import directly parts of the mirth app directly into your project, but probably this would be painful, since they use Java.
Working with PHP is fine but you’d need to consider things like 1) how do you know the service is running. 2) What happened to message X, did it even come through? 3) Can we replay message Y, but just that one. These things are trivial with a good interface engine like Mirth.
Lastly in settings that have critical data coming in like labs, having them fail is not really an option. Failures typically are due to demographic mismataches or a mis-sync in lab compendiums. In a situation where there is no outbound ORM feed, the former arises, but also if the source of truth from the lab system is different, it’s a moot point anyway. (Ie if the patient has to re-register at the lab). Anyway. In those cases, especially with the demographics issue, if that occurs, one thing to think about would be code to handle patient bridging like Allscripts EEHR does (most interface engines do not support this concept, even Epic just says there is a failure because XYZ and here is the message, do what you want with it).
I’m hoping this info is useful! Good discussion. I will download the Ubuntu appliance and see if can get bidirectional ADT working.
rdejournett wrote on Thursday, January 22, 2015:
Terry, thanks. Would you be willing to share your channels?
sunsetsystems wrote on Thursday, January 22, 2015:
Thanks Rob, that is indeed good feedback. I can relate to the issues you raise with incoming lab results, having written code for that.
ADT = Automated Data Transfer?
teryhill wrote on Thursday, January 22, 2015:
Admit Discharge Transfer
mdsupport wrote on Thursday, January 22, 2015:
Rob, ADT testing will need partner(s) on other end that are ready with testing facilities. How about Immunization Registry as a PoC? California allows test messages.
rdejournett wrote on Friday, January 23, 2015:
Right, pretty much everything would need an external partner. I have a GE CPS test installation I can use for this, GE is basically the same model, they can accept ADT /DFT messages. Is the biggest need for outbound ADT/SIU (registration/scheduling)? I’ll also do immunizations (will start that first), VXUs are really easy. Terry provided me his Mirth channel which is a good starting point. Thanks.
mdsupport wrote on Friday, January 23, 2015:
We have had no luck in getting facilities to do ADTs although it is a MU requirement for them and all major vendors have it available as a module. May be it is just our area/partners. Considering this package is used by mostly solo and small offices, we are likely to be very low on roll out schedule for facilities.
As for the installation, you have several key decisions to make. Would you hard link - put Mirth structures in OpenEMR database or keep it self contained (Mirth Appliance)? Looking ahead, there will be questions about replicating business workflow logic in Mirth or calling EMR installation as a web service etc… My suggestion would be to use PoC approach for wider community to see the benefits.
Thank you for your initiative.