Clovertech

MERGE Mirth

› Clovertech Forums › Read Only Archives › Cloverleaf › Cloverleaf › MERGE Mirth

  • Creator
    Topic
  • March 21, 2014 at 1:11 pm #54110
    Jared Parish
    Participant

      Good Morning All,

          Does anyone with experience supporting MERGE Mirth?

      The back story:

         We currently have MERGE PACS system and are just kicking off an upgrade.  During an upgrade they sprung on us that they want us to okay the implementation what they coined “MERGE Mirth”.  MERGE Mirth would act as their interface engine between MERGE HEMO, MERGE CATH, MERGE Radiology PACS, and iConnect. MERGE claims that rather than have multiple interface to each product, we’ll just send them one interface for each interface type (ADT, ORU, MDM).

      My concerns:

         As soon as I heard Mirth, I began having concerns.  Not necessarily because its Mirth, but because this presents another point of failure and another system that we’ll have to support (backup, monitor, etc).  Although, they claim that they’ll have alerting and support the system. This will also present a loss of control for filtering and message manipulation.  I’ve got many other concerns but really want know if anyone has MERGE Mirth and their experiences.  Will this be good for my client?

      - Jared Parish

    • Creator
      Topic
    Viewing 2 reply threads
    • Author
      Replies
      • April 1, 2014 at 2:05 am #80197
        glen goldsmith
        Participant

          There are a couple of things…….

          – Sure it reduces the amount of interfaces

          – For MERGE, all interfaces will use this — the current/old way will be legacy, and they may require it in the future.

          Caveats of having 1 interface:

          – you are correct, you will lose the ability to customize the interface to the specific application… plus if you already have.

          – you will probably pay for each custom on upgrades

          Mirth is open source — MERGE has their own version of it.  They probably fixed up alerts, as it was pretty bad.  Mirth just released version 3… I haven’t used it extensively since the 1.7 days.

          ….. as it comes down to it – it would NOT be hard for them to just route your interface data……raw.. to their application with mirth.  There *is* a middle ground!

          Instead of having 1 ADT interface going to Mirth, you have 5

          1 for Hemo, 1 for PACs, etc  Same with Orders and reports and images coming back.

        • April 1, 2014 at 12:49 pm #80198
          Jared Parish
          Participant

            Thanks for the reply Glen.  Ultimately, we told them that we didn’t want to use their Mirth interface engine.  MERGE didn’t put up a fuss about it either.  So, in the end we won’t have to spend the money for two MS server licenses and SQL licenses.  It will mean more work for me however.  ðŸ˜¡

            - Jared Parish

          • April 2, 2014 at 5:22 pm #80199
            glen goldsmith
            Participant

              A lot of vendors are starting to use it.  It’s free/cheap and it’s descent for small applications.  MModal, MERGE, Optum CAC are a few of the vendors.

              We went through this with Carefusion on our Pyxis interfaces awhile back — although it wasn’t Mirth and they put in their own engine, etc.  And they did require it.

              GE uses cloverleaf — which is nice, we (developers and the support staff) know Cloverleaf very well.  We’ve even had to correct GE on the syntax and what commands to use 😉

          • Author
            Replies
          Viewing 2 reply threads
          • The forum ‘Cloverleaf’ is closed to new topics and replies.