I was thinking, "wow, reading in data, processing it, and outputting data. Reminds me of Interface Engines in healthcare." Then I saw "HL7" on the diagram.
That's what I did for a long time. HL7 contains information such as "Admissions, Discharges, and Transfers (ADT)" which is sent from the Hospital Information System (HIS) to other department's systems (radiology, pharmacy, medical records, and possibly dozens more) and vice versa (LAB results back to HIS, for example).
HL7 interface engines unpack the HL7 data into separate segments, fields, and subfields, identify the type/subtype of message, route to various destinations based on the type and any other fields, map the data and reformat as necessary for the destination, encode back into HL7, and send it. It also needs to queue the messages as needed, re-transmit or set aside the message, or just stop sending depending on what it gets back in the form of response codes. So you can see in the diagram some of those steps. The also handle input/output either in the form of TCP/IP ports, reading/writing files (for batch processing), or pretty much any other method you can send and receive data (serial ports, in some old cases).
I'm kind of curious how (and how easy it is) to define which fields in the input for a given event goes to the output (and do certain transformations on those fields if needed).
I could see using this as a layer in between your traditional interface engine and your own services. I used to work with Cloverleaf and I ended up building my own endpoint; Cloverleaf would route all the messages I was interested in to my end point and then I'd ship them off to the appropriate application from there. The most interesting thing I did was look for messages from the Radiology system about scans (MRI, CAT Scan, X-Ray, etc.) and then notify the primary care physician for the patient ("Hey, log in here to view then new imaging data for your patient!").
Something like this would make that much, much easier. Cloverleaf would route to this Apache product, which would then route to the appropriate service. The data on traffic, etc., would be especially useful (i.e., the service that sends faxes is slow, etc.)
Nifi wraps each file with a "flowfile", which contains metadata about the flow. You can add to and change those variables as the flow goes on using the "UpdateAttribute" processor, and then route based on those attributes.
Each processor in the flow receives the full flow file, so each step along the way gets the "state" in full. This helps in case something interrupts the flow - you can resume an hour or a day later.
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.
If you haven't checked out Mirth in it's v3 format, it's not terrible. I find that alot of the hold-up with HL7 setup in regards to logic involves VPN setup and cloning/maintaining different channels that basically do identical things. We've built some tooling on top of Mirth to do this where I work and I think it's a better approach than black box integration solutions.
That being said, I'll definitely be checking this out.
That's what I did for a long time. HL7 contains information such as "Admissions, Discharges, and Transfers (ADT)" which is sent from the Hospital Information System (HIS) to other department's systems (radiology, pharmacy, medical records, and possibly dozens more) and vice versa (LAB results back to HIS, for example).
HL7 interface engines unpack the HL7 data into separate segments, fields, and subfields, identify the type/subtype of message, route to various destinations based on the type and any other fields, map the data and reformat as necessary for the destination, encode back into HL7, and send it. It also needs to queue the messages as needed, re-transmit or set aside the message, or just stop sending depending on what it gets back in the form of response codes. So you can see in the diagram some of those steps. The also handle input/output either in the form of TCP/IP ports, reading/writing files (for batch processing), or pretty much any other method you can send and receive data (serial ports, in some old cases).
I'm kind of curious how (and how easy it is) to define which fields in the input for a given event goes to the output (and do certain transformations on those fields if needed).