Stop fighting legacy GUI-based engines. Build, version, and deploy healthcare integration pipelines with YAML and TypeScript. Git-native, AI-friendly, CLI-first.
Every other part of your stack is defined as code—infrastructure, CI/CD, containers. Why are healthcare pipelines still configured in GUIs and stored in databases?
A channel is a folder with a YAML config, a TypeScript transformer, and an optional validator. Everything lives in your Git repo.
id: fhir-to-adt enabled: true listener: type: fhir fhir: port: 8082 base_path: /fhir/r4 version: R4 resources: [Patient] transformer: runtime: node entrypoint: transformer.ts destinations: - hl7-file-output
Declarative YAML: what connects to what, which protocol, which port.
import type { Patient } from "fhir/r4"; import { Message } from "node-hl7-client"; export function transform( msg: IntuMessage, ctx: IntuContext ): IntuMessage { const p = msg.body as Patient; const hl7 = new Message({ messageHeader: { msh_9_1: "ADT", msh_9_2: "A08", msh_11_1: "P", }, }); hl7.addSegment("PID"); hl7.set("PID.5.1", p.name?.[0]?.family); hl7.set("PID.5.2", p.name?.[0]?.given?.join(" ")); return { body: hl7.toString() }; }
Pure TypeScript: full npm ecosystem, type safety, IDE support.
Scaffold a project with sample channels, npm deps, and Docker config.
Add channels. Each one is a folder with YAML + TypeScript.
Run the engine. Auto-compiles TypeScript. Hot-reloads on changes.
A production-grade engine with enterprise features—all open source.
Every pipeline is plain text files. Branch, diff, review, and merge your integration logic the same way you ship application code.
Structured YAML + typed TypeScript are the formats LLMs generate best. Use AI assistants to create, modify, and debug your pipelines.
Go binary runtime with a pre-loaded Node.js worker pool. Modules are cached in V8 at startup. Transform execution is measured in microseconds.
Memory, Postgres, MySQL, SQL Server, SQLite, or S3 backends. Store messages at each pipeline stage for audit and replay. Configurable per-channel.
Configurable retry with fixed, linear, or exponential backoff per destination. Failed messages route to a DLQ for inspection.
Preprocessor, Validator, Source Filter, Transformer, per-destination Filter & Transformer, Response Transformer, Postprocessor.
OpenTelemetry traces and metrics, Prometheus endpoint, and log transports for CloudWatch, Datadog, Sumo Logic, Elasticsearch.
Redis-based coordination with channel partitioning, message deduplication, and persistent destination queues.
HashiCorp Vault, AWS Secrets Manager, GCP Secret Manager. LDAP and OIDC for dashboard authentication. RBAC and audit logging.
Sources define where messages come from. Destinations define where they go. Mix and match across protocols.
Jump straight to the most popular source connectors, or read how intu stacks up against incumbent engines.
Every stage is optional except the transformer. Per-destination filters and transformers let you customize payloads for each output independently.
Base config in intu.yaml. Override per environment with intu.dev.yaml or intu.prod.yaml. Environment variables expand with ${VAR} syntax.
Storage mode, log transports, secrets provider, cluster config, and connector settings all vary by profile. One codebase, every environment.
runtime: mode: cluster message_storage: driver: postgres mode: full logging: transports: - type: datadog datadog: api_key: ${DD_API_KEY}
Real-world healthcare integration scenarios intu was built for — from hospital EHR feeds to FHIR API gateways and DICOM imaging pipelines.
Ingest HL7 v2 messages from Epic, Cerner, and Meditech over TCP/MLLP with ACK/NACK, acknowledgement modes, and automatic reconnection.
TCP/MLLP source →Normalize legacy HL7 v2 feeds into FHIR R4 Bundles and expose a FHIR REST surface to downstream apps, analytics, and partners.
FHIR R4 source →Route LIS lab results to an EHR, analytics warehouse, and patient portal simultaneously with per-destination filtering and transforms.
HTTP destination →Parse healthcare EDI transactions and route claims, remittance, and eligibility traffic to payer and provider systems.
Getting started →Receive DICOM studies via DIMSE, extract metadata, and forward to PACS, research systems, or AI analytics pipelines.
DICOM source →We believe transparency builds trust. Read how intu stacks up—including where others still win.
The most widely deployed open-source healthcare engine. We show where Mirth still wins and where intu is better.
Read comparison →Premium enterprise integration engine. 100+ connectors and vendor SLAs vs free and open source.
Read comparison →SaaS integration platform with no-code builder. Zero-ops vs full control—which fits your team?
Read comparison →Move from legacy GUI-based engines to a modern, Git-native workflow. Go binary + Node.js worker pool, sub-millisecond transforms, and hot-reload out of the box.
Import your existing Mirth channel XML exports directly. Generates channel.yaml + transformer.ts automatically.
Same pipeline stages, same connector types, same healthcare protocols. Modern TypeScript instead of Rhino JS. Git instead of a database.
Architecture Decision Records explain the reasoning behind every major technical choice.
Common questions about licensing, deployment, formats, and migrating from Mirth Connect.
Yes. intu is 100% free and open source under the Mozilla Public License 2.0 (MPL-2.0). You can use it commercially, self-host it, and modify the source code. The core engine and all connectors are open source with no paid tiers.
intu is a code-first, Git-native healthcare integration framework. Unlike Mirth Connect's GUI-based channel builder, intu lets you define pipelines as YAML files with TypeScript transformers — fully version-controllable and AI-friendly. intu uses a modern Go + Node.js runtime versus Mirth's Java/Rhino stack.
intu is infrastructure software — it does not store PHI by default. You can deploy intu in a HIPAA-compliant environment by running it on your own infrastructure (on-prem or private cloud), enabling TLS on all connectors, and following standard HIPAA operational controls. intu does not provide a BAA directly, but your cloud provider can.
intu supports HL7 v2.x (all message types), FHIR R4, DICOM, X12 EDI (837, 835, 270/271), CDA/CCDA, and plain JSON/XML/CSV. It includes 12 source connectors (HTTP, TCP/MLLP, FHIR, Kafka, database, SFTP, email, DICOM, SOAP, IHE, file, channel) and 13 destination connectors.
intu provides a built-in Mirth channel importer via the CLI. Run intu import mirth <path-to-export.xml> against your Mirth channel XML export to generate intu YAML and TypeScript. For a full comparison and migration guidance, see intu vs Mirth Connect.
Integration as Code means defining your healthcare integration pipelines as text files (YAML configuration + TypeScript transformers) that live in your Git repository alongside your application code. This enables code review, CI/CD deployment, automated testing, and AI-assisted development of HL7 and FHIR pipelines.