found medplum not that long ago while building my ...
# general
a
found medplum not that long ago while building my own TS HL7 Engine, Gofer Engine. Sort of stalled on that in some sense, mainly just a lack of interest other than myself and not enough time to really market it much, so I was thinking... I wonder if I could instead of reinventing the whole wheel just convert some stuff to being add on "bots" for medplum instead. So far all of my use cases have been around HL7 v2. I did have to write some custom stores, queue, and event system to utilize in the core of what I was building. Had a little downtime and started watching a video explaining medplum a little bit more in depth.
r
We (Medplum team) have some experience with Mirth and it did inform some of our thinking with regards to Bots. Most of our HL7 traffic is diagnostics (OBX, ORU, etc) and ADT. What use cases are you thinking?
r
That's a great idea. We have some examples of using Bots to read HL7 messages from an SFTP server in our Demo Bots folder: https://github.com/medplum/medplum/tree/main/examples/medplum-demo-bots/src/lab-integration
a
I work in a rural hospital context, and use interface for all things automation but mainly HL7. We have these interface channels: - ADT - RDE - ORU (LAB/MIC/RAD/PCS/HIM/MON) - ORM - DFT - VXU - ZPM - RAS - SIU And then we have dozen of SFTP automation channels and some other miscelaneous SQL/JS channels for some custom business logic needs. Some of these channels have very customized functionality such as alerting when a Covid patient gets discharged with a positive outcome to help spread good chear, updating a custom plugin on our WordPress website with our custom built ER wait time projection every 15 minutes, and doing advanced order/patient matching and mapping for external facilities sending lab tests and results back out.
For Gofer Engine, https://gofer-engine.github.io/, my goal was to create a TS based engine that is super light weight and easy to use. Here is an example of a quick channel build:
Copy code
ts
import gofer from 'gofer-engine'

// pass through HL7 v2
gofer
  // received localhost:5500
  .listen('tcp', 'localhost', 5500)
  // send a ack response
  .ack()
  // save a copy to a file
  .store({ file: {} })
  .route(route =>
    // forward to hl7.emr.example.com:5500
    route.send('tcp', 'hl7.emr.example.com', 5500)
  )
  // start running this channel
  .run()
And then for the hospital I am building a custom bed board system with a web based and email integration for setting room status after cleaned by EVS so they don't have to log into the complicated EHR system, and they can just do it from a smart phone instead. For this application I receive ADT to update room status when they need cleaned and then sends back out A20 when cleaning and cleaned. The message outbound looks something like this:
Copy code
ts
import gofer, { genId } from `@gofer-engine/engine`

const [send, messengerId] = gofer.messenger(
  (route) => route.send('tcp', 'hl7.emr.example.com', 5600)
)

export const bedUpdate = (bed: string, status: 'cleaning'|'clean', user: number) => {
  const now = new Date().toISOString().split('.')[0].replace(/[^\d]/gi,'')
  const statusCode = status === 'cleaning' ? '1' : '2'
  return send(
    new Msg('MSH|^~\\&|')
      .setVersion('2.4')
      .set('MSH.7', now)
      .setJSON('MSH.9', ['ADT', 'A20'])
      .set('MSH.10', genId('ID'))
      .set('MSH.11', 'D')
      .addSegment(['EVN', null, now, null, null, user])
      .addSegment(['NPU', bed, statusCode])
  )
}
So I can just import the
bedUpdate
function and give it the key elements and it will generate the HL7 and send the message.
r
Oh this is really cool. You might be interested in learning more about our Medplum On-Prem agent (https://www.medplum.com/docs/agent)
We're in the process of creating a generic "agent", that would run as a service on a hospital on-prem machine. It would then listen for HL7 messages, and forward it to a Medplum Bot for processing (https://www.medplum.com/docs/bots). The idea is that the agent is as "dumb" as possible, with minimal config, and all the business logic lives in the cloud as bots
a
yeah... we are stricly on-prem only. Most of our interfaces never leave the front door of the hospital but are for interoperability between internal systems. PACS EHR for example.
247 Views