On-prem agent

[codyebberson]

For non-HTTP communication such as HL7, DICOM, or ASTM, Medplum requires an agent to run and convert to HTTP API calls.

Medplum has done this as custom projects on multiple occasions, but currently does not have an official general purpose agent.

Other projects such as Mirth can play this role. Mirth is widely deployed and battle tested. Mirth natively supports HL7 and DICOM. Mirth supports ASTM via paid plugin on Mirth Platinum.

However, we do hear objections from customers about why they do not want to use Mirth:

• Difficult to setup / administer
• Requires VPN to remote push messages
• Requires outdated version of Java
• Too heavy / bloated
• ASTM plugin too expensive
• SSL features require commercial license

The idea for exploration is a Medplum agent that provides this edge connection capability.

Desired features:

• Minimal local configuration. Set an API key and go.
• Auto updates
• Remote push without VPN
• Remote health checks
• Remotely managed. Access the device remotely through the Medplum UI or alternative.

The minimal version would simply be an HL7 MLLP to HL7 over HTTPS adapter. However, that would have many of the same disadvantages as Mirth, because it would not support remote push. (A suboptimal implementation could be achieved with polling, but that has a bunch of problems)

The more comprehensive version would include a bidirectional network protocol such as XMPP or Matrix. Other IoT network protocols could be considered (AMQP, MQTT) but would require an additional layer on top.

The advantage of a bidirectional network protocol would be a natural story for remote management, remote health checks, and server initiated messages. I.e., the ability to "push" a message to a remote device.

The disadvantage is increased complexity and the necessity of running a server to manage the centralized communication. There are popular and battle tested servers for XMPP (ejabberd, OpenFire, Prosody) and Matrix (Synapse). We would need to recognize the long term commitment to managing such a service.

[rahul1]

Curious how this interacts with our current subscription/bot paradigm. How would we use Bots and Subscriptions to handle / send XMPP messages? Would we make a new subscription channel type? And in the other direction, would we have some kind of representation of an XMPP connection that we could subscribe to?

[codyebberson]

Good question.

Let's set aside Subscriptions for a second.

I think the Bot/id/$execute model might be a better starting place? Some kind of routing mechanism that connects the edge device to a Bot. Then the Bot would receive the HL7 message as a BotEvent<Hl7Message>.

We'd probably treat XMPP as a network protocol, and probably as an auth mechanism. There is an established XMPP extension for OpenID, which we might be able to leverage out of the box: https://wiki.xmpp.org/web/JabberID_and_OpenID_combination_:_XEP-0154_User-Profile_export

So receiving a message would be similar to receiving an HTTP request with an associated user, Content-Type, and payload.

XMPP + Subscription would be a special case for FHIR-to-FHIR interfaces that don't use HTTP, or environments where the HTTP endpoint is not publicly accessible so the agent + XMPP is more like the network tunnel. There is value there. In that case, yes, a new custom "channel" for the XMPP protocol.

[reshmakh]

The minimal version would simply be an HL7 MLLP to HL7 over HTTPS adapter. However, that would have many of the same disadvantages as Mirth, because it would not support remote push. (A suboptimal implementation could be achieved with polling, but that has a bunch of problems)

I think the way to think about this is by environment. If there is remote access to the host that the agent lives on, then the simple adapter, like above seems sufficient and probably the right amount of surface area. For the true edge hosts (those running in a lab or warehouse etc.) this will be problematic, but for managed hosts simple seems appropriate.

[codyebberson]

The main question is "do you need to push data in?" If yes, "HL7 over HTTPS" will not be sufficient.

[codyebberson]

Notes on "HL7 over XMPP" from the Direct project:
https://wiki.directproject.org/XMPP_Implementation_Capability_Worksheet

[codyebberson]

Notes on "XMPP for bioinformatics":

"XMPP for cloud computing in bioinformatics supporting discovery and invocation of asynchronous web services"
https://www.ncbi.nlm.nih.gov/pmc/articles/PMC2755485/

[codyebberson]

Considerations for building a standalone binary:

• Experimental support in Node.js 20: https://nodejs.org/api/single-executable-applications.html
• Need to bundle all dependencies
• For Windows, need a signing key

[reshmakh]

Related to signing key for Windows the instructions for the workflow on signing binaries.

This is one of the cert programs, digicert. Are there preferences for a specific code signing program?

[Neustradamus]

To follow