Open Source & Demos

Code editor, results chart and an HL7 v2 to FHIR pipeline

These projects are open source. Anyone can read the code and run it. They use synthetic test data only. There is no real patient data.

They show how we work: a clear structure, tests, and documentation that a new team member can follow.

Live demos: coming soon

We are building live demos that you can try in your browser. They will use synthetic data only.

HL7 v2 to FHIR pipeline with OIE and Mirth Connect

The problem

Many hospital systems still send HL7 v2 messages. This is an older text format with fields separated by the | sign. Newer apps and cloud platforms expect FHIR R4, a modern web standard that uses JSON. Connecting the two usually takes a lot of manual mapping work.

What it does

  • Open Integration Engine (OIE) receives HL7 v2 patient messages (ADT). The same channel also works on Mirth Connect 4.5.2.
  • It reads the patient details from each message.
  • A small Node.js service turns these details into a FHIR R4 Patient record.
  • Everything runs in Docker containers, so it starts the same way on any computer.

What it shows

  • A clear, reusable pattern for HL7 v2 to FHIR projects.
  • Synthetic test messages only. There is no real patient data.
  • Step-by-step guides, so a team can follow it and extend it.

View the project on GitHub | Read the full article

SMART on FHIR starter kit with an HL7 check

The problem

A healthcare app is harder to build than a normal web app. It must open from the hospital’s EHR, sign in safely, ask for the right permissions, and read patient data correctly. Few open examples show this whole flow from start to end.

What it does

  • A SMART on FHIR web app. It opens from an EHR or a public test sandbox, signs in with OAuth2, and shows a patient summary: details, recent visits, medications, and lab results.
  • A standalone mode for demos, with no sign-in needed.
  • An Open Integration Engine (OIE) channel that checks each HL7 v2 message first. A message without a message ID or a patient ID is rejected, so bad data does not reach other systems.

What it shows

  • The full SMART on FHIR sign-in and data flow.
  • Validation first: bad messages are stopped at the door.
  • Private server settings are kept out of the shared code.

View the project on GitHub | Read the full article

Want something similar for your organization?

Tell us about your systems. We usually reply within one business day.

Request a quote