Services
Interoperability & Interfaces
Interfaces are where healthcare projects go to stall. We design, build, test, and monitor the connections between your EHR, devices, LIS/RIS, and partners — in the standards those systems actually speak.
The problem
-
The interface backlog is measured in quarters, and every new clinical initiative lands on the same two engineers.
-
Vendors quote a standard integration, then the site visit reveals Z-segments, custom code sets, and an interface spec from 2011.
-
FHIR is on the roadmap, but the systems that matter still speak HL7v2 over MLLP — and both worlds have to work at once.
How we work
- 01
Interface discovery
We read the actual message samples, not just the spec — mapping segments, code sets, and the exceptions nobody documented.
- 02
Design & mapping
A mapping document both sides sign before we build: source fields, transformations, error behavior, and who owns each edge case.
- 03
Build & test
Interfaces built on your engine or ours, with message-level regression tests and a test harness your team keeps.
- 04
Cutover & monitoring
Parallel-run validation, a rollback plan, and monitoring that pages on queue depth and error rates — not on angry phone calls.
What you get
- Signed interface specifications and mapping documents
- Interfaces live in production with regression test coverage
- Message-level monitoring and alerting on every feed
- Runbooks for common failure modes and reprocessing
- A migration path from legacy HL7v2 interfaces toward FHIR where it pays off
Standards & technologies
- HL7v2
- FHIR R4
- DICOM
- MLLP
- IHE
- SMART on FHIR
- CDA
- X12
- Mirth Connect
- HAPI FHIR
Common questions
Which EHRs have you worked with?
Our engineers have integrated against the major EHR platforms (Epic, Oracle Health, MEDITECH-class systems) at previous posts. Every engagement starts from your EHR’s actual interface capabilities, not assumptions.
Do we need an interface engine?
Usually there’s already one in the building. We build on what you have when it’s healthy, and recommend a change only when the engine is the actual bottleneck.
HL7v2 or FHIR?
The unsatisfying, correct answer: both, chosen per interface. Device and departmental feeds often stay v2 for years; patient-facing and app integrations are FHIR-first. We wrote up how we decide — see Insights.
Who supports the interfaces after go-live?
Your team, ours, or both — every interface ships with runbooks either way, and our managed services practice can take the pager.
Have an interface that has to happen?
Bring us an integration problem, a device fleet, or a product idea — we will come back with an approach, not a slide deck.