Integration monitoring and support services · United States
Healthcare interfaces fail quietly. A feed stops, a queue backs up, a certificate expires and nobody notices until a result is missing. We monitor your HL7, FHIR, X12 and device interfaces, alert the right person in minutes, replay failed messages safely and run the on-call rotation under an agreed SLA.
Silence, queue depth, error rate, ACK latency, certificate and VPN checks on every interface.
Page the on-call engineer by severity, follow the runbook and tell the hospital or partner.
Fix the cause, replay failed messages once and in order, and write up what changed.
The short answer
Nirmitee runs production support for healthcare interfaces. We instrument your interface engine and APIs, whether Mirth Connect, Open Integration Engine, Rhapsody, Cloverleaf, Corepoint, Epic Bridges on the hospital side or our own Interoply platform, and alert on the signals that matter: a feed gone silent, queues growing, negative acknowledgements, rising latency, expiring certificates and failing VPN tunnels. Our engineers respond under an agreed SLA, replay failed messages without creating duplicate orders or charges, keep runbooks current and send you a monthly report on how every interface is running. You get interfaces someone owns at 2 a.m.
Monitoring signals
Error counts alone miss the failures that matter. These are the signals we alert on, and why each one exists.
| Signal | What it catches | Typical threshold | What happens next |
|---|---|---|---|
| Silence (no messages) | A feed that stopped sending, often with no error anywhere | No ADT for 15 minutes in business hours, set per feed from its normal volume | Check the sender, the connection and the channel; call the site's interface team |
| Queue depth and age | Messages piling up behind a slow or failing destination | Queue growing for 10 minutes, or oldest message older than the agreed delay | Find the blocked destination, clear the cause and drain the queue in order |
| Errors and negative ACKs | Parsing failures, mapping errors and AE or AR acknowledgements | Any AR, or an error rate above the feed's baseline | Quarantine the failing messages, fix the mapping or data and replay |
| ACK and response latency | A partner or API slowing down before it fails | Latency above the agreed percentile for 10 minutes | Warn the partner and scale or throttle before timeouts start |
| Transport and certificates | Expiring TLS certificates, VPN tunnels down, SFTP login failures | Certificates 30 days before expiry; tunnel down for 2 minutes | Renew or reconnect on a planned change, not during an outage |
| Host health | Disk, memory, CPU, database size and engine process health | Disk at 60 percent as an early band; memory and CPU at 70 percent | Archive, prune or resize before the engine stalls |
| Business checks | Orders without results, results without orders, claims without acknowledgements | Rules agreed with your operations team | Route to the owning team's work queue with the message references |
Thresholds are set per interface from its own traffic pattern, then tuned in the first month so alerts stay rare and meaningful.
What we build
Take the full service or the parts you need. Each one has an owner and a report.
Engine and API metrics collected into dashboards your team can see, with OpenTelemetry traces across HL7 channels and FHIR APIs where the stack supports it.
Prometheus · Grafana · OpenTelemetry · engine APIs
Seven metrics every interface team should watch →Alerts routed by severity to PagerDuty, Opsgenie, Teams or Slack, with an on-call rotation and escalation path agreed with you, up to 24x7 coverage.
Severity levels · escalation · paging
Alerting with PagerDuty and runbooks →Failed and quarantined messages reprocessed once, in order, with idempotency on message control IDs so a replay never duplicates an order, result or charge.
MSH-10 · dead-letter queue · reprocess · audit
Message replay and dead-letter queues →Response and resolution targets per severity, written into the agreement, with monthly reporting on incidents, volumes and changes.
P1 to P4 · response targets · monthly report
Integration support SLA sample language →Patching, version upgrades, high availability, backups and restore tests for Mirth Connect, Open Integration Engine and other engines, including the move from Mirth 4.5.2.
Mirth Connect 4.6 · OIE · Java 17 · HA
Mirth Connect integration services →Mapping changes, new message types, new hospital sites and partner changes handled as tracked changes with regression tests before release.
Change control · regression suites · release notes
HL7 integration services →Buyer decisions
Who holds the pager is a real decision. These are the models we see, and where each one fits.
| Model | Best fit | Strengths | What to plan for |
|---|---|---|---|
| In-house integration team | Health systems and large platforms with steady interface volume | Deep knowledge of your systems and people | Hiring, cover for holidays and nights, and knowledge that leaves with people |
| Engine vendor support | Teams with a commercial engine license | Product defects and upgrades handled by the vendor | Vendor support covers the engine, not your channels, mappings or partners |
| Managed integration service (us) | Teams that want interfaces owned end to end | Monitoring, on-call, replay and changes under one SLA | A clear handover and access to your environments |
| Hybrid | Teams that keep daytime ownership and hand off nights and weekends | Your team stays close to the work; we cover the gaps | Shared runbooks and a clean escalation path |
| Interoply (our platform) | Products that want monitoring and replay built into the integration layer | Monitoring, replay and per-site configuration included | Fit with your hosting and data residency rules |
Whichever model you choose, write down who is paged for each interface. Unowned interfaces are the ones that fail silently.
Integration boundaries
Support works when ownership is written down. This is the split we agree before we take the pager.
Own their systems, their side of the VPN and their interface engines, such as Epic Bridges. We contact their interface teams directly and keep a current contact list.
Own the application and business decisions: what to do with a rejected order, who calls a clinic. We route those items to your queue with full context.
Own product defects in their engines. We open and chase vendor tickets with the evidence they need.
Monitoring, alerting, first response, diagnosis, replay, engine operations and the changes in our scope, within the agreed SLA.
Alerts carry message references, not patient data. We sign a BAA, use least-privilege access with audit logging and work inside our ISO 27001:2022 certified management system.
Deliverables
Everything below is yours, and stays with you if you move the work in-house.
Every interface with its partner, direction, message types, volumes, owner and contacts.
Dashboards, alert rules and thresholds as code in your repository.
Per-interface diagnosis and recovery steps, including replay procedures and partner contacts.
Severity definitions, response targets and who is called at each step.
Incidents, root causes, volumes, changes made and risks to address.
Engine versions, end-of-support dates, certificate calendar and capacity trends.
Delivery phases
Onboarding a typical estate of interfaces takes 4 to 6 weeks, and we can take urgent incidents from the first week.
Week 1
Access granted, interface inventory built, urgent risks listed
Weeks 1 to 3
Dashboards and alerts live, thresholds set from each interface's own traffic
Weeks 2 to 5
Runbooks written, our engineers shadow your current on-call
Weeks 4 to 6
On-call handed over under the SLA, first monthly report scheduled
Cost drivers
You get a fixed monthly scope and price after one scoping call. These are the factors that move it.
Support is scoped per connection, with volume and complexity considered.
Business hours, extended hours or 24x7 on-call.
Tighter response and resolution targets need more engineers on rotation.
The number of engines, clouds and on-premise servers we operate.
Expected new sites, mapping changes and partner changes each month.
A healthy estate is quicker to onboard than one with missing documentation and open incidents.
Proof
Client names are withheld. The code and write-ups linked here are public.
Our integration team has built more than 350 interfaces on Mirth Connect across admissions, orders, results, documents and charges.
Our open-source operations layer for Mirth Connect and Open Integration Engine: web administration, clinical observability and channel CI/CD.
View OpenMirth on GitHub →Public channels and transformers, including an importable MLLP listener channel, used as the baseline for our regression tests.
View the cookbook on GitHub →Our platform includes monitoring, replay and per-site configuration for HL7 v2, FHIR and X12 connectors.
See Interoply →We are ISO 27001:2022 certified and sign Business Associate Agreements for work that touches patient data.
FAQ
Integration monitoring watches the interfaces that move data between clinical systems, such as HL7 v2 feeds, FHIR APIs, X12 transactions and device data, and alerts when something goes wrong. Good monitoring watches for silence, queue growth, negative acknowledgements, latency, certificates and host health, not only error counts.
Mirth Connect, including the commercial 4.6 and later releases, Open Integration Engine, Rhapsody, Corepoint, Infor Cloverleaf and our own Interoply platform, plus FHIR servers, API gateways and custom integration services. On the hospital side we work with Epic Bridges, Oracle Health and other EHR interface teams.
When a sender stops sending, nothing errors: the engine is healthy, the queue is empty and every dashboard is green. We alert on the absence of expected messages for each feed, based on its normal volume and hours, so a stopped ADT or results feed is caught in minutes rather than when a clinician notices missing data.
We quarantine failures instead of discarding them, fix the cause, then reprocess each message once and in the original order. Receivers de-duplicate on message control IDs such as MSH-10, and we check whether an order, result or charge was already applied before replaying it.
We agree severity levels and response and resolution targets with you and write them into the agreement. A production feed down or messages queuing is the top severity; a mapping defect affecting some messages or a request for a change sits lower. Coverage can be business hours, extended hours or 24x7.
Yes. We run on-call rotations across US and India time zones, with escalation paths agreed with you. Many teams keep daytime ownership and hand nights, weekends and holidays to us.
Yes. We start with an inventory of every interface, its partner, owner and volumes, add monitoring, write runbooks and shadow the current on-call before taking the pager. Missing documentation is rebuilt from the channels and message history.
Yes. We plan and run upgrades, including the move from open-source Mirth Connect 4.5.2 to the commercial 4.6 releases or to Open Integration Engine, with Java 17, regression tests on every channel and a rollback plan.
Alerts carry interface names, counts and message references, never patient details. Engineers look up the message inside the secured environment with audited, least-privilege access, and message retention follows your policy.
Onboarding a typical estate of interfaces takes 4 to 6 weeks: access and inventory, monitoring and alerts, runbooks and shadowing, then taking the pager. Urgent incidents can be handled from the first week.
Cost depends on the number of interfaces, coverage hours, response targets, the engines and infrastructure we operate, expected change volume and the current state of the estate. We give a fixed monthly scope and price after one scoping call.
Yes. We sign Business Associate Agreements, use least-privilege access with audit logging and work inside our ISO 27001:2022 certified management system.
Next step
Tell us your engines, interfaces and the coverage you need. An engineer replies with what we would monitor first, the SLA we would propose and a fixed monthly scope.
Start with your workflow
Share the engines, the number of interfaces and the coverage you need. Please leave out patient data and credentials. Read by an engineer, answered within one business day.
