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!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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?
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?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
There would probably need to be a bit of database work within the open emr, unless there was a field such as last update date/time. I am looking at the patietn_data table and don't see such a field, but I do see some date fields. Basically we'd need to know what type of message to send and where to send it. For example the typical new patient ADT is an A04, so when a new entry in the patient_data table was created, we need somewhere to say 'create an Hl7 message for this patient', such as an HL7 table with the id, date, and message type.
As for the HL7 itself, probably it would be best to do the work in Mirth, that way the core application is insulated from any requirements. For example Epic doesn't really like A04s without a CSN, they want an A28. Some don't want version 2.5.1 of HL7, they want version 2.2 or 2.3.
My biggest question - is there a training database somewhere with some (fake) patient data? I'd need that or to figure out the app enough to do registration, scheduling, create vaccination orders, that sort of thing.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
For training purposes, you can either use demo farm established by Brady which get refreshed on a schedule OR download an VM appliance.
As you get specific questions, several members on this forum will be extremely helpful.
Please consider using outbound interface first. If you use direct database reads, you will bypass the logging mechanism in emr but mirth could probably log that action in its database if needed.
Most tables will have 'date' field, it is usually date created. Application also includes a phpmyadmin installation (Admin -> More -> Database).
For testing purposes, use Admin -> Layout -> Demographics to maintain screen layout. You can either use one of the unused 'custom' fields for user to mark for HL7 output and change it from 'unused' to 'optional' OR you can add a new field for this purpose. Try it in any of the public demos.
For production use, we could probably put in little code in the application that will directly call Mirth as a jsonp / web service providing patient id and facility as the keys which can in turn do the HL7 export action in real time. Inbound processing logic will take some thought as no office will want another system creating an entry in the background.
Last edit: MD Support 2015-01-25
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Terry and I are working on outbound ADT as a proof of concept, about half done. I'll share when we're more fleshed out.
Regarding 3.x - yes it's completely different. I haven't seen any U.S. implementations yet (but the world is big and I am small). Mostly we are going towards CCD generation and exchange. 2.x is mostly for real-time exchange of interfaced systems such as labs, documentation, etc. CCDs are great for patient portals and the like. (probably most of you know this but anyway.).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Excellent Please think about C-CDA as that is the new MU2 direction
Tony McCormick, CTO
www.mi-squared.com
Support: 866-735-0897, Direct: 713-574-6709
My Calendar: http://bit.ly/XznvDo
... we have to slow down a bit to be able to speed up a lot... (me)
Terry and I are working on outbound ADT as a proof of concept, about half
done. I'll share when we're more fleshed out.
Regarding 3.x - yes it's completely different. I haven't seen any U.S.
implementations yet (but the world is big and I am small). Mostly we are
going towards CCD generation and exchange. 2.x is mostly for real-time
exchange of interfaced systems such as labs, documentation, etc. CCDs are
great for patient portals and the like. (probably most of you know this but
anyway.).
--
Please be aware that e-mail communication can be intercepted in
transmission or misdirected. Please consider communicating any sensitive
information by telephone. The information contained in this message may be
privileged and confidential. If you are NOT the intended recipient, please
notify the sender immediately with a copy to hipaa-security@mrsb-ltd.com and
destroy this message.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am done with a proof of concept system which will send person updates or add persons based on a trigger added to the patient_data table. Here are the files needed for it to run. Once the new SQL is added to the database, create c:\mirth, c:\mirth\in and c:\mirth\out, deploy the two channels in mirth, and do a patient update (ie change the name). Or add a new patient. You should get an ADT outbound in the c:\mirth\out directory.
This POC is missing visit level info, dx info, and any insurance beyond primary.
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!
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
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.
Mirth integration will be a great contribution to this project. We can help in that process.
Okay sounds good. So what is the biggest need? Demographics? Scheduling? Labs?
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?
Rod
http://www.sunsetsystems.com/
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?
Ignore.
Last edit: Rob Dejournett 2015-01-22
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?
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.
Rod
http://www.sunsetsystems.com/
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.
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
Terry, thanks. Would you be willing to share your channels?
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.
Rod
http://www.sunsetsystems.com/
Last edit: Rod Roark 2015-01-22
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.
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?
Rod
http://www.sunsetsystems.com/
Admit Discharge Transfer
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.
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.
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.
There would probably need to be a bit of database work within the open emr, unless there was a field such as last update date/time. I am looking at the patietn_data table and don't see such a field, but I do see some date fields. Basically we'd need to know what type of message to send and where to send it. For example the typical new patient ADT is an A04, so when a new entry in the patient_data table was created, we need somewhere to say 'create an Hl7 message for this patient', such as an HL7 table with the id, date, and message type.
As for the HL7 itself, probably it would be best to do the work in Mirth, that way the core application is insulated from any requirements. For example Epic doesn't really like A04s without a CSN, they want an A28. Some don't want version 2.5.1 of HL7, they want version 2.2 or 2.3.
My biggest question - is there a training database somewhere with some (fake) patient data? I'd need that or to figure out the app enough to do registration, scheduling, create vaccination orders, that sort of thing.
Last edit: MD Support 2015-01-25
Terry and I are working on outbound ADT as a proof of concept, about half done. I'll share when we're more fleshed out.
Regarding 3.x - yes it's completely different. I haven't seen any U.S. implementations yet (but the world is big and I am small). Mostly we are going towards CCD generation and exchange. 2.x is mostly for real-time exchange of interfaced systems such as labs, documentation, etc. CCDs are great for patient portals and the like. (probably most of you know this but anyway.).
Excellent Please think about C-CDA as that is the new MU2 direction
Tony McCormick, CTO
www.mi-squared.com
Support: 866-735-0897, Direct: 713-574-6709
My Calendar: http://bit.ly/XznvDo
... we have to slow down a bit to be able to speed up a lot... (me)
On Tue, Jan 27, 2015 at 9:52 AM, Rob Dejournett rdejournett@users.sf.net
wrote:
--
Please be aware that e-mail communication can be intercepted in
transmission or misdirected. Please consider communicating any sensitive
information by telephone. The information contained in this message may be
privileged and confidential. If you are NOT the intended recipient, please
notify the sender immediately with a copy to hipaa-security@mrsb-ltd.com and
destroy this message.
I am done with a proof of concept system which will send person updates or add persons based on a trigger added to the patient_data table. Here are the files needed for it to run. Once the new SQL is added to the database, create c:\mirth, c:\mirth\in and c:\mirth\out, deploy the two channels in mirth, and do a patient update (ie change the name). Or add a new patient. You should get an ADT outbound in the c:\mirth\out directory.
This POC is missing visit level info, dx info, and any insurance beyond primary.