Hey what's wrong with Mirth? I've long since moved on but I was one of the original engineers building Mirth. I wrote a lot of the HL7 parsing logic and the tcp transports.
User interview protip: if you actually want to know what's wrong with your product, never tell people that it's your product.
At my last startup, we did user tests every week, and my cofounder was very careful never to let on which test items were made by us. We didn't have our name on the door or on the buzzer. Nothing with our logo was visible between the entryway and the user interview room. And when he started showing products, he'd always start with somebody else's.
It was great. We got some incredibly honest feedback (sometimes brutally so) on what we were building. It helped us kill a lot of bad directions early. Most people just don't want to tell you that your baby is ugly, but they'll happily dish if they think it's somebody else's.
Any tips for when the user definitely know it's your product? I can't think of anything besides starting with butchering some aspect of it. Then again that might trigger some empathetic response, and end with even less actionable feedback.
I think people can't un-know something, so I'd try very hard to get test subjects in a way where they don't think the people they are talking to are the ones who make the product.
For example, you could set up a fake market research org, and have them say they are "conducting a study on [your market] and are looking for users of products like [competitor 1], [competitor 2], and [your product]". Then for the user testing sessions you could rent a conference room from somebody like Regus, or even rent a user testing lab. Then during the tests, make sure to start with general questions and test (or show screens from) the other products before you get to testing yours.
I'm not sure if those specifics will work in your environment, but I hope you see what I mean.
To me, it's the fact that Mirth nickel-and-dimes users for "premium" features and has pretty poor documentation to push people towards support plans. It's an open source platform "kind of", which rubs some folks the wrong way.
However, the functionality of the engine itself is top notch. We've had some Mirth servers running for a year at this point without incident. It handles alot of things around the nuances of HL7 nonchalantly, which has usually been my hang-up with non-healthcare specific toolsets like Mule or Camel.
Last time I used Mirth (going on 3 years ago now), it was a pretty good engine wrapped up in terrible UI/UX. The core logic and some of the built-in transformation (particularly the HL7v2 parser, actually!) was good, but any time you had to interact with Mirth through the dashboard (say, for example, building a channel) it was incredibly painful -- especially if you had to chain multiple channels in a row. No way to see the flow of data, and lots of fumbling interactions with a clunky JWS interface.
