Announcement

Collapse
No announcement yet.

Need Suggestions for moving to mirth

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Need Suggestions for moving to mirth

    We currently use a home-grown HL7 interface engine tied tightly to our own LIS software. We would like to look into using Mirth as a replacement, but the problem with that would be all of the "rules" we have built into our engine for how it communicates in the LIS database. Our Home-grown engine handles a lot more than just parsing HL7 messages to the point where it inserts items into specific tables based on an order code (OBR.4) in the HL7 messages and then runs internal rules based on a number of conditions. It's basically 10yrs of custom coding for interfacing to multiple vendors wrapped into one service.

    One of our main reasons for looking into mirth is the multi-threading, which we currently do not have in our engine. Also our current engine is client/server based, so each client has their own engine specifically configured for their interfacing needs.

    Just seems like a big undertaking and I'm having trouble wrapping my head around all that will be needed to accomplish everything we currently do and more.

    Any suggestions are appreciated!

  • #2
    Seems like a interesting project!
    Suggestions:
    - I would start with one of the simpler interfaces and move that to Mirth first. That way you can learn the basics before getting into the more advanced areas.
    - Read up on javascript and e4x.
    - If your existing code is written in java, you could potentially reuse that code by packing it into a jar, putting it in the lib-custom folder, and calling it from your Mirth channel.
    - Post specific question on the forum with code or your channel export attached
    - Consider getting Mirth training: http://www.mirthcorp.com/services/training
    - Channel development help is also available either with support: http://www.mirthcorp.com/services/support or direct channel development: http://www.mirthcorp.com/services/custom-engineering
    Daniel Svanstedt
    Software Engineer
    Mirth Corporation

    Want professional services, support, and enterprise or virtual appliances? It's all available from the Mirth Corporation:
    Mirth Support | Mirth Training | Mirth Appliances | Online Training | Developer Q&A

    Don't forget, Mirth Support gives you access to all of our online training videos, and silver support gives you access to developer Q&As!

    Comment


    • #3
      Originally posted by dans View Post
      Seems like a interesting project!
      Suggestions:
      - I would start with one of the simpler interfaces and move that to Mirth first. That way you can learn the basics before getting into the more advanced areas.
      - Read up on javascript and e4x.
      - If your existing code is written in java, you could potentially reuse that code by packing it into a jar, putting it in the lib-custom folder, and calling it from your Mirth channel.
      - Post specific question on the forum with code or your channel export attached
      - Consider getting Mirth training: http://www.mirthcorp.com/services/training
      - Channel development help is also available either with support: http://www.mirthcorp.com/services/support or direct channel development: http://www.mirthcorp.com/services/custom-engineering
      I've been working with mirth for the last 8 months or so, so at this time I'm getting fairly well versed in mirth. I was more looking for suggestions as to others may have transitioned to Mirth. What they found was the best way to accomplish the transition, etc.

      Comment


      • #4
        Here's a thought. Consider leaving the home-grown HL7 interface engine in place for the time being as a front end communications processor for the LIS. Get Mirth up and running and then take all the inbound feeds to the LIS and have them point inbound to Mirth where there is a channel for each feed that simply passes the transactions through and the outbound Mirth connection connects to the inbound of the LIS. Do the same for all the LIS outbound, feed each one into a Mirth channel which simply passes the transactions through to the destination system.

        Once that is in place you can transition the interface work for each LIS inbound and outbound feed (if you want to risk fixing something that ain't broke) and you can start doing new interface work using Mirth.

        Just a plan to consider; hope it makes sense in relation to what you are trying to do. We all applaud you for planning ahead rather than just plunging right in. Good luck!

        Comment


        • #5
          Transition to Mirth

          We first started testing some small simple connections. Once we decided we loved mirth, we took the simplest interface, and had mirth take over. Now that mirth is up and running, we're moving more work to it, one channel/project at a time (some new connections, some old).

          How? I guess we just plan a time to turn off the old interface engine, say 6pm, and have mirth turn on at 6pm. Send some test messages through, and we're off. (Then we update our documentation, so folks know whats new).

          Ambulatory interfaces are easier if you can pause the interface for a few minutes. In a 24/7 ADT feed or something, you can announce a downtime, or do it at a time when volume is lowest.

          Comment

          Working...
          X