- This topic has 5 replies, 5 voices, and was last updated 12 years, 4 months ago by
.
-
Topic
-
-
Replies
-
-
-
-
I agree with the last comment, and Mirth has been discussed here. It is portable, lean and “agile”, customizable, not guaranteed of much else. I work with Mirth as both feed from an external EHR, and destination for a portable app. Up to you to master api’s/scripting and create your own magic. If you’re not shy with Java, for example, and want to try portable app. dev to, Mirth can be useful, even fun. It is “free”, in terms of $, but not in terms of your potential efforts required. Design Uncertainty is generally higher, for obvious reasons.
Cloverleaf has all the magic built in, plus lots of customization capability. I think among the best in my experience. Stability and reliability (if configured well) are main benefits. Must admit I used Cloverleaf as the backend to a Mirth engine, feeding a FileMaker portable app.. So, there you go 🙂
-
We use both in our organization although we use Mirth in a very limited capacity. Mirth has a lot of strengths but the main flaw we saw with it is that it does not have true fail over capability. If the server goes down you can bring all your channels (interfaces) up on a different node but the transactions that were in route at the time it went down are stuck in the primary server’s DB. We didn’t see a way around this. I admit, we didn’t look very hard as we are only using Mirth to communicate with our systems outside our hospital’s network.
I’ve also found that the lack of an equivalent to Cloverleaf’s variant makes you have to do a lot of Java coding to figure out which group the segment is in that you’re trying to do your data mapping on. Without a variant how do you know which NTE segment you’re trying to modify? I do love the way you can just export an interface to XML from your test environment and import it into your production environment.
-
-
- The forum ‘Cloverleaf’ is closed to new topics and replies.
