Now Providing Healthcare Electronic Data Interchange (EDI) Services
This is a little bit of a different post than we would usually publish, but we wanted to bring to your attention some new health care related services we've been providing that we'd like to highlight, the first one being Electronic Data Interchange (EDI) Services. This is the first of two posts planned to outline these new services.
Some time in 2016 we were first asked by a valued client to help out with an HL7 interface with one of their partners. At the time, the only thing known about how these sorts of technologies work is that HL7 is a text based protocol with various delimiters. In usual fashion we dug in and started figuring it out. Over a year later and systems built both from scratch as well as using Mirth Connect we've become quite comfortable working with the technologies and want you to know that we're available to help tame your next EDI integration beast.
First, the old fashioned way
The first project we worked on was to be an SFTP based interface with some very specific business requirements that would require a lot of data and logical processing to build the HL7 messages. At the time I had investigated Mirth Connect knowing it was a well regarded platform for a system such as this, however in order to avoid working with both the new concepts of EDI (HL7, etc) and a new, complex tool such as Mirth, it was decided to build a set of PHP scripts knowing that once we nailed down the HL7 formatting, the rest would be straight forward. After finding an existing HL7 library for PHP and making a few needed adjustments we had the HL7 piece covered and it was on to developing the business requirements. As expected, this was all straight forward and all said and done, we have a stable, fully customizable system. While some may snicker at this combination, we can do any database and or other processing as needed for the business requirements with this solution just as we would any other CLI script.
Next up, Mirth Connect
So the next request was for a TCP sockets based solution, but one with much more straight forward business requirements. Since our previous system doesn't support the TCP connections we figured it was time to build on top of Mirth when possible to be more industry standard. After a few days of working through their documentation we had a generally functional environment setup for sending and receiving transmissions. A few more days and we had the integration built and ready for testing. I was very impressed with the functionality in Mirth, it is a great system with many, many options out of the box to work with. When the drop in pieces don't work, you can also drill down to the JavaScript level and customize things to suit. Honestly one of the biggest challenges is finding exactly what you need within all the options. While they have fairly good documentation it lacks in real world examples for the more complex options. Because of this significant time was spent fiddling with things to see if it was the right way for us.
All that matters though is that we ended up with a solid, industry standard solution that met the business needs.
Circling back
Once I felt more comfortable with Mirth, I spent a little time working through what it would take to implement the first, custom solution using Mirth. While it was not something we completed and implemented, after having a better understanding of the tools available I found it would definitely be possible. Though I think we would have struggled much more to complete the first project if it were our first foray into Mirth. Starting out with something simpler was a great way to get started with the product.
Conclusion
All said and done, Mirth was a success for us and we will continue building on the platform whenever possible. Have any comments on this post or a project we could work on for you, please reach out to us here!