No announcement yet.

Let's talk MIRTH

  • Filter
  • Time
  • Show
Clear All
new posts

  • Let's talk MIRTH

    We are using mirth as the integration engine for our HIE clients implementing a patient chart aggregation portal. We average about 40 source channels per instance of mirth.

    We have experienced some rather annoying and costly problems with throughput and space issues over the past few months and we would like to connect with others to discuss strategies for improving these processes.

    In addition, we hear that some very cool alerting is possible, but we have not figured it out yet.

    Any ideas?

    Basic stuff we use includes:

    redhat Linux
    mirth connect

  • #2
    You should make sure your pruning settings are optimized:
    - Same pruning interval on all your channels
    - Enable batch pruning
    - Set pruning block size to a large number.
    - If you don't need to store messages, disable it on the channel
    - Make sure you are running the latest version of MC
    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!


    • #3
      Thank you. I'll get these things verified.


      • #4
        Originally posted by dans View Post
        You should make sure your pruning settings are optimized:
        - Set pruning block size to a large number.
        I have 163 deployed channels running on 2.1.1 with an Oracle DB. About 50 of them doing message logging. Retention is set to 14 days. Given those parameters, what would you define as a "large number" for the block size?