Cameleering
CameleerCameleering / Cameleer / Packs / Healthcare
Healthcare integration ยท the health pack
An open-source healthcare integration engine: HL7, FHIR and DICOM in one binary
Receive HL7 v2 over MLLP and acknowledge after delivery, talk to FHIR servers, route medical images over DIMSE and DICOMweb, and de-identify them with the PS3.15 profile. Every interface is an Apache Camel YAML route kept in Git and tested in CI, run by one native binary that fits on a hospital gateway. Apache-2.0, no licence fees, no lock-in.
Status: the health pack is released in 0.6.0 (2026-11-12), as the image cameleering/cameleer:health (or :0.6.0-health) and the cargo feature health. HL7, MLLP and FHIR were in the default image up to 0.5.1; DICOM is new. What it does not do yet.
What is in the pack
| standard | components, formats and languages | what you do with it |
|---|---|---|
| HL7 v2 | mllp, the hl7 data format, the hl7terser language | receive and send ADT, ORM, ORU and other messages over MLLP with automatic AA, AE or AR acknowledgements; read fields by path (PID-3-1); parse ER7 into a structured value and back; TLS |
| FHIR | fhir, the fhirJson and fhirXml data formats | create, read, update, delete, search, history, transactions and operations on a FHIR server (R4, R4B, R5, DSTU3); convert resources between JSON and XML |
| DICOM | dicom, dicomweb, the dicom and dicomJson formats, the dicom language and ${dicom.*} | C-ECHO, C-STORE, C-FIND, C-MOVE and C-GET as SCU and SCP; STOW-RS, QIDO-RS and WADO-RS as client and server; route and edit on tags; DICOM JSON for indexing |
| De-identification | dicomDeidentify | the PS3.15 Annex E basic profile and its options except the pixel options; replacement UIDs, pseudonyms and date shifts under one key; an audit record per instance |
Plus everything else in Cameleer: Kafka, AMQP, databases, files and SFTP, HTTP and REST, cloud services, Apache Camel's routing and error-handling patterns, and MCP tools for AI agents. The DICOM Conformance Statement (PS3.2 form) lists every DICOM service and policy.
What healthcare teams build with it
HL7 to the EHR
ADT and lab messages in over MLLP, the patient id read with a terser path, posted to the EHR, and acknowledged only after delivery, so the sender resends on failure.
An imaging gateway
Modality to PACS or a cloud DICOMweb store over DIMSE and STOW-RS, filtered on tags, with store-and-forward when the uplink is down.
AI inference routing
De-identify the series a model needs, send it to the inference service, and post the finding back as a FHIR DiagnosticReport that points at the original study.
De-identification for research
A folder in, a folder out: pseudonyms that stay consistent across batches and sites, shifted dates, and an audit record per instance.
HL7 v2 to FHIR
Read segments with the terser, build the resource, post it with the fhir producer, and drop duplicates on the message control id.
Provable processing
Since 0.6.0: in a confidential VM, show a data owner hardware evidence of the routes and configuration that handle its data, including the de-identification options.
Get it
Docker
docker run --rm -p 2575:2575 -v "$PWD:/routes:ro" \ cameleering/cameleer:health run /routes/adt.camel.yaml
The :health image is also tagged :0.6.0-health and :0.6-health and is also published as ghcr.io/cameleering/cameleer:health, for linux/amd64 and linux/arm64.
Cargo, or your own Rust program
cargo install cameleer-main --features health
A Rust program depends on cameleer-health and calls ctx.add_pack(&cameleer_health::HEALTH). From the next release, release archives come with SHA-256 sums, a CycloneDX SBOM and a Sigstore signature (how to verify); 0.6.0 ships as the image and the crates.
- route:
id: adt-to-fhir
from:
uri: "mllp://0.0.0.0:{{env:MLLP_PORT:2575}}"
steps:
- setHeader:
name: PatientId
hl7terser: PID-3-1
- log: "ADT ${header.CamelMllpTriggerEvent} for patient ${header.PatientId}"
- to: "log:adt"
Tested against the tools hospitals use
| against | what was checked |
|---|---|
| DCMTK 3.6.7 | DIMSE as SCU and SCP, with and without TLS |
| Orthanc 1.12.2 | as a PACS; its DICOMweb plugin 1.16 as server and as client |
| python-hl7 0.4.5 | MLLP in both directions, AA and AR acknowledgements |
| HAPI FHIR 8.12.0 | create, read (JSON and XML), update, search, history, delete |
| 33 pydicom test files | read and written back byte for byte |
Live tier of 2026-11-11 (CAMEL_HEALTH_INTEROP=1, 10 of 10), plus the hermetic suite that runs on every change. How each test works: INTEROP.
Coming from Mirth Connect or another interface engine?
The full comparison, with the open-source forks, the commercial engines and sources for every fact: Mirth Connect alternatives.
Why teams look at Cameleer
- Apache-2.0 open source. Mirth Connect moved to a commercial licence from version 4.6.
- Interfaces as code: YAML routes in Git, reviewed and tested in CI with
cameleer validateandcameleer test. - One small native binary instead of a JVM and a database: starts in milliseconds and runs on a gateway.
- HL7, FHIR and DICOM in the same engine as Kafka, databases, cloud services and AI tools.
What it does not have
- No visual channel editor and no message browser.
- No importer for Mirth channels, and Mirth's JavaScript transformers do not run; transformations are Camel steps (Simple, jq, terser paths).
- Not tested against dcm4che or real modalities yet.
What it does not do yet
- Not a PACS, a viewer or an EHR. It moves, transforms and de-identifies data between them.
- Cloud healthcare services not tested yet: Azure Health Data Services, the Google Cloud Healthcare API, AWS HealthImaging (which also needs SigV4 signing).
- DICOM not supported yet: Storage Commitment, MPPS, UPS-RS, WADO frames and rendered images, transcoding compressed pixel data and the pixel de-identification options.
- Audit format: hash-chained records, not yet IHE ATNA messages.
- No throughput numbers yet against Mirth, dcm4che, DCMTK or Orthanc.
- Compliance: Cameleer provides controls (TLS, de-identification, audit, attestation); it is not HIPAA certified or FDA cleared.
Need something that is not here? We will build it with you.
The health pack grows from what people running real hospital, lab and imaging interfaces ask for. If a message type, a FHIR operation, a DICOM service, a cloud store or a profile stands between you and a working interface, open an issue with your workflow, the systems involved and what you use today. We read every request, reply on the issue, and work on it with you until it ships.
Please never attach data that identifies a patient.
Common questions
Is there an open-source healthcare integration engine for HL7, FHIR and DICOM?
Cameleer's health pack is one, under the Apache-2.0 licence: HL7 v2 over MLLP with acknowledgements, the hl7 data format and terser paths, the fhir component and FHIR JSON and XML, DICOM over DIMSE and DICOMweb, and PS3.15 de-identification. Integrations are Apache Camel YAML routes run by one native binary.
Is Cameleer an alternative to Mirth Connect?
For teams that keep integrations as code, yes: channels become routes in YAML files kept in Git, tested in CI, with Apache Camel's error handling and routing patterns, under the Apache-2.0 licence. It has no visual channel editor, no message browser and no importer for Mirth channels, and it does not run Mirth's JavaScript transformers.
Which image or build has the healthcare components?
The health pack, since 0.6.0: the image cameleering/cameleer:health, or cargo install cameleer-main --features health. The default image and the full build do not include it. Up to 0.5.1, mllp, hl7 and fhir were in the default image; DICOM is new in the pack.
How was it tested?
The health pack's live tests pass 10 of 10 against DCMTK 3.6.7, Orthanc 1.12.2 with its DICOMweb plugin, python-hl7 0.4.5 (MLLP both ways, AA and AR acknowledgements) and the HAPI FHIR 8.12.0 server (create, read, update, search, history, delete, JSON and XML). 33 public pydicom test files are read and written back byte for byte.
Is Cameleer HIPAA compliant?
Compliance belongs to a deployment, not to a library. Cameleer gives you controls: TLS and mutual TLS on MLLP, DIMSE and HTTP, PS3.15 de-identification with audit records, a hash-chained audit log, and, since 0.6.0, attestation in a confidential VM. It is not certified, cleared or audited for HIPAA or by the FDA.
Can I ask for a feature the health pack does not have?
Yes. Open a feature request on GitHub with your workflow, the systems involved and what you use today. Requests are read and answered on the issue, and worked on with the person who asked.