Channel development, version migration, production monitoring, and deployment automation for health systems and digital health companies.
HIPAA compliant . BAA available
3x
Message standards per typical deployment - HL7v2, FHIR, X12
90%
Of operational visibility suppressed by Mirth's default ERROR log level
5
Business days to a prioritized assessment of your environment
30d
Days of post-deployment support included on every channel build
Channels built by an engineer who has since left. No automated deployment. Logging at ERROR level - no visibility into transformer failures. An upgrade from 3.x to 4.x deferred, again. We address these across five scoped engagement types, each priced to a specific problem.
See the engagement modelsBuilt manually in the GUI by someone who's gone. No version control, no documentation, no one who can safely modify them.
Root log level ships at ERROR. Transformer exceptions, HTTP errors, and routing decisions never surface until a clinician calls.
Changes promoted by hand from the Administrator GUI. The deploy endpoint returns success even when nothing deployed.
A Java 8 -> 17 change, a database migration, and channel-by-channel review. Not a version bump - and out of commercial support.
A full-time Mirth engineer is overkill; emergency consultants bill 2-3x and only show up after something breaks.
Each engagement is scoped to a specific problem and priced accordingly. Click any model to see scope, format, and investment.
Every channel ships with version-controlled XML, retry logic, and a dead-letter queue. Filter by standard to see typical channel types.
| Interface | Standard | Transformation | Protocol |
|---|---|---|---|
| ADT feed - Admit / Discharge / Transfer | HL7v2 | A01 / A04 / A08 route and filter | TCP / MLLP |
| Lab orders and results | HL7v2 | ORM / ORU map and enrich | TCP / MLLP |
| HL7v2 to FHIR R4 transformation | FHIR R4 | HL7v2 to FHIR Bundle | HTTP / REST |
| Eligibility and claims | X12 | 270/271, 837/835 parse and validate | SFTP / API |
| Medical device data ingestion | Device / Proprietary | Proprietary to HL7v2 / FHIR | TCP / serial / file |
| REST API to HL7v2 translation | JSON | JSON to HL7v2 | HTTP to MLLP |
| FHIR subscription routing | FHIR R4 | Event routing | Webhook |
Mirth ships with the root log level at ERROR - transformer failures, HTTP errors, and routing decisions never surface. Managed Operations replaces that blind spot with live monitoring and alerting, so you hear about a failing channel before your clinical team does.
Channel Health Monitor
Messages today
1,320,202
across 5 active channels
Avg transform latency
42 ms
p95 under 110ms
Failed & auto-retried
319
0 lost . all in dead-letter queue
Aggregate throughput . last 60s
0 msg/sIllustrative monitor reflecting the alerting and dead-letter patterns included with Managed Operations.
Most teams need 20-40 hours a month, not a full-time role. This directional estimate compares common support models.
Current support model
Estimated saving vs current model
$15,600/yr
The 4.x migration touches the Java runtime, the database, and every channel. We run both versions in parallel until you're confident, then cut over with a documented rollback.
Plan a MigrationRuntime and library compatibility
Schema migration
Per-channel validation
Engine migration
Our Mirth work is written up on the engineering blog. These cover specific production issues we found and fixed, not conceptual overviews.
Still unsure which engagement fits? The assessment is built for exactly that.
Assessments can start within one week of signing. Channel development and migration engagements require a scoping conversation first, with typical kickoff in 2-3 weeks.
Tell us what you are running and where the pressure is. We will respond with a specific recommendation for your situation.
