The EHR, the lab, the billing system and the patient app each hold part of the record, in their own format, under their own identifiers.
Four systems, one patient, no single record
A health system or a digital health product rarely fails on its own features. It fails at the boundaries: the appointment that never reached the EHR, the lab result that arrived as a PDF, the patient who exists three times because three systems assigned three identifiers.
Most of that boundary work is standards work. FHIR and HL7 v2 are well specified, but every EHR implements them slightly differently, every site has its own local codes and custom segments, and access to a production Epic environment is a process, not a download. We do that work so your product team can build the product.
Results arriving as PDFs
Duplicate patients
Incomplete FHIR support
Unannounced interface changes
Late security reviews
Systems we connect to
FHIR R4 through Epic on FHIR; HL7 v2 feeds; SMART launch from Hyperspace and MyChart.
Any EHR with a FHIR endpoint or an HL7 v2 interface, built to that vendor’s implementation guide and the site’s specification.
Orders out and results in over HL7 v2 ORM/ORU or FHIR DiagnosticReport.
Medication orders and dispense records exchanged with pharmacy systems over HL7 v2 or FHIR MedicationRequest.
Charges (DFT), eligibility and claims.
Document and record exchange with regional exchanges where the health system participates.
What is different afterwards
Records match across systems on MRN and demographics before anything is written.
Results and documents arrive coded and routed, so they can be searched, trended and acted on.
Every message and every FHIR call is logged with who, what and when, which is what your compliance team will ask for.
How a project runs
Which systems, which messages or resources, which identifiers. Output: an interface inventory and a field-level map.
A written spec per feed: message types, segments or resources, codes, error handling and who is notified when a message fails.
Built against the vendor sandbox (Epic non-production, a FHIR test server) or a message library from the site.
Every feed is run against sample messages from the site and checked field by field with their interface analyst.
Feeds are switched on one at a time with monitoring on message volume, latency and rejects.
Dashboards and alerts for every interface, and a runbook so your team owns it after we leave.
Questions we get on the first call
Yes. Where we handle PHI we work under a Business Associate Agreement, and we build to the minimum-necessary principle: the integration sees only the resources and fields the workflow needs.
TLS for every connection including MLLP where the site supports it, encryption at rest in your cloud account, no PHI in logs, and access limited to named service accounts. Test environments use synthetic or de-identified data.
Feeds are built to run as queued, horizontally scalable consumers, so volume is a hosting decision rather than a code limit. We size against your peak hour, not your daily average.
Outbound messages queue and retry with backoff; inbound rejects go to a dead-letter queue with the original message and the reason, and someone is alerted. Nothing is silently dropped.
You do. Code, infrastructure definitions and the test message library are handed over, with a runbook. We can stay on for monitoring and changes on a support agreement, or step away.
We can take an app through Epic on FHIR registration and work with a health system’s Epic team on enablement, but the health system decides what an app may access. We do not have a shortcut around that, and we would be wary of anyone who says they do.
Four ways to
work with us
A defined project
A defined integration or product, priced and scheduled up front, delivered with the test suite and infrastructure code you keep.
Engineers on your team
Engineers who join your team, your code and your daily meetings for as long as the roadmap needs them.
Ongoing support
We keep the integrations you run working: monitoring, vendor updates, new connections and month-end support.
Taking over existing systems
A system or integration nobody wants to touch: we review it, make it stable, then build on it.
What clients say
Tell us which systems
you run.
An engineer replies within one business day, with questions rather than a pitch.
