4 ms·

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. Tha

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).

impostervt 11y ago
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.
ubertaco 11y ago
Yep, this reminded me of a not-crappy version of Mirth Connect.
- markolschesky 11y ago
  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.
- eclipxe 11y ago
  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.
  - markolschesky 11y ago
    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.
  - wpietri 11y ago
    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.
    - rparrish 11y ago
      Great advice. Makes too much sense.
    - mlonkibjuyhv 11y ago
      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.
cmiles74 11y ago
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.)
sixothree 11y ago
Though a good interface engine would expose a greater understanding of the HL7 messages in the front end interface. Does the NiFi designer have the ability to do something like this, the ability to create abstractions in the front end?
- izzle49 11y ago
  yes seems like it, by extending abstract processor, there is a developer guide right at the bottom on the left. https://nifi.apache.org/docs.html https://nifi.apache.org/docs.html

impostervt 11y ago

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.

ubertaco 11y ago

Yep, this reminded me of a not-crappy version of Mirth Connect.

markolschesky 11y ago
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.
eclipxe 11y ago
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.
- markolschesky 11y ago
  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.
- wpietri 11y ago
  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.
  - rparrish 11y ago
    Great advice. Makes too much sense.
  - mlonkibjuyhv 11y ago
    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.

cmiles74 11y ago

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.)

sixothree 11y ago

Though a good interface engine would expose a greater understanding of the HL7 messages in the front end interface. Does the NiFi designer have the ability to do something like this, the ability to create abstractions in the front end?

izzle49 11y ago
yes seems like it, by extending abstract processor, there is a developer guide right at the bottom on the left. https://nifi.apache.org/docs.html https://nifi.apache.org/docs.html