Lab ↔ EMR Integration Program
I drove a multi-team program that connected providers' EMRs to the lab: providers self-requested a connection, Sales approved it as a client value-add, then orders flowed out and results flowed back automatically, over HL7 v2 on SFTP for the majority and REST API where it fit. My job was to align Engineering, Sales, Lab Operations, Product, and external EMR vendors behind one charter, manage the dependencies and risks between them, and move each connection through a launch-readiness gate to live.
Two bottlenecks: manual data exchange, and manual onboarding
For providers: orders and results were exchanged by email and re-keyed by hand between the lab and each clinic's EMR. That meant transcription errors, slow turnaround, and records drifting out of sync, exactly the friction that pushes a practice to a competitor.
For the lab: connecting a new EMR was a manual, Sales-gated process. Because the integration was offered as a value-add for ordering clients, every request needed internal approval before engineering provisioned it, and that intake happened over email and spreadsheets, so it was slow, inconsistent, and hard to track.
The task: stand up an end-to-end program with a self-service request and approval front door, and a reliable delivery layer that pushed orders out and pulled results back into the EMR with zero data loss.
The program charter
Before any building, I set a charter so every team was solving the same problem against the same bar. Goal, scope, and success criteria were agreed up front and used to settle trade-offs later.
Goal
One self-service path from a provider's request to live, bidirectional EMR data exchange, with zero data loss and a full audit trail.
Scope
In: request and approval front door, HL7 over SFTP and REST transport, compendium and custom panels, reliability and monitoring.
Out: EMR-side clinical workflows and billing.
Success criteria
- check_circleZero data-loss incidents
- check_circleFull, queryable audit trail
- check_circleOnboarding cut from weeks to days
- check_circleTests orderable inside the EMR
The workstreams I coordinated
The program ran as parallel workstreams, each with an owning function. I kept them aligned to the charter and to each other, so a decision in one did not quietly break another.
5+
Workstreams
5
Functions aligned
35+
People coordinated
The governance cadence
IllustrativeA steady rhythm kept the workstreams in sync and surfaced risk early, so blockers were raised in a forum that could clear them rather than discovered at launch.
Weekly delivery standup
Engineering + PM walked active connections, blockers, and the next launch candidates.
Biweekly steering committee
Sales, Engineering, and Product aligned on approvals, scope, and top risks.
Async status
Live request state in the portal and automated provider updates cut "is it done yet?" pings.
The milestone timeline
IllustrativeThe program was sequenced so each phase de-risked the next: prove the front door, standardize the majority transport, then extend to selective paths and scale.
Q1
Charter & front door
Request and approval workflow live.
Q2
Standardized HL7 mapping
Reusable HL7 over SFTP; first bidirectional connections.
Q3
API path & catalog
REST API where it fit; compendium and custom panels.
Q4
Scale & harden
More EMRs live; reliability and monitoring hardening.
The dependency map
Each connection depended on handoffs across functions and outside the company. I mapped them so an owner and a clean handoff existed for every one, and nothing waited on an unnamed party.
Sales approval gate
Gated whether a request became work. Handoff: an approval carried the EMR, mode, and contacts straight to provisioning. Owner: Sales + PM.
EMR-vendor readiness
Determined transport and timeline per connection. Handoff: shared HL7 mappings and specs. Owner: external vendors + Engineering.
Lab LIS intake & results
Received orders and generated results. Handoff: field mapping to the lab's data contract. Owner: Lab Operations + Engineering.
Compendium & catalog
Made tests orderable inside the EMR. Handoff: codes mapped and coordinated with each vendor. Owner: Sales + Lab Operations.
Risks, assumptions, issues & dependencies
IllustrativeI ran a living RAID log and worked it every cadence. The point was not to list risks, it was to name an owner and clear the blocker.
| Type | Item | Severity | How I unblocked it | Owner |
|---|---|---|---|---|
| Risk | EMR vendor readiness varied widely | Built standardized, reusable HL7 mappings so onboarding became configuration, not bespoke work. | Engineering | |
| Risk | Manual compendium upkeep risked stale codes | Set a coordinated update cadence with vendors; flagged catalog sync for automation. | Sales + Lab Ops | |
| Issue | SFTP transfer drops and malformed HL7 | Added retries, de-duplication, parse-error handling, and monitoring so nothing was silently lost. | Engineering | |
| Dep. | Sales approval gate could bottleneck intake | Defined an approval SLA and surfaced live request status in the portal. | Sales + PM | |
| Assum. | HL7 v2 is the majority-ready path | Validated through the transport decision matrix before committing it as the default. | PM |
The biweekly steering update
Every two weeks I sent leadership a one-page snapshot: where the program stood, what could derail it, and the decisions I needed from them. The point was to keep the steering committee aligned and unblock the program without a meeting. This is a sanitized version.
Schedule
On track. Phased rollout hitting milestones; new connections moving through the gate.
Scope
Stable. Holding to the charter; transport and catalog work inside agreed bounds.
Vendor readiness
Watch. Some EMR vendors lag on HL7 readiness, pacing the slowest connections.
Top 3 risks & mitigations
EMR-vendor readiness varies (Engineering). Mitigation: standardized, reusable HL7 mappings make onboarding configuration, not bespoke build.
SFTP drops / malformed HL7 (Engineering). Mitigation: retries, de-duplication, parse-error handling, and monitoring so nothing is silently lost.
Sales approval gate could bottleneck intake (Sales + PM). Mitigation: a defined approval SLA and live request status in the portal.
Decisions needed
The ask: dedicated engineering capacity to build the FHIR path and automate compendium sync.
One end-to-end flow: request → approve → provision → exchange
I framed it as a single pipeline with two halves, a self-service front door and the technical delivery behind it, so a provider went from "I want this" to live data exchange without manual handoffs falling through the cracks.
Provider requests
self-service portal
Sales approves
client value-add
Provision
HL7/SFTP or API
Orders & results
flow to/from EMR
The front door
Providers requested an integration through a self-service portal instead of email threads. Each request landed in an internal queue where Sales approved or rejected it. The gate existed because the integration was offered as a value-add for ordering clients, so each request was a commercial decision as much as a technical one. Approval handed off cleanly to provisioning, so nothing stalled in someone's inbox.
The pipe
Delivery ran as HL7 v2 messages over SFTP for the vast majority of EMRs, and REST API where the EMR supported it. Each connection was provisioned bidirectional (orders out, results back) or results-only, depending on what the practice needed and what their EMR could do.
Making custom panels orderable inside the EMR
A connection only mattered if the right tests were actually orderable on the provider's side. Inside the EMR, that menu is the compendium: the catalog of tests a practice can pick from when placing an order. Getting the compendium right was as much a part of the integration as the transport underneath it.
The compendium
The orderable test catalog surfaced inside each EMR. Mapping the lab's tests to the right compendium codes was what let a provider find and place the correct order without leaving their EMR. It was the difference between a live pipe and one nobody could actually use.
Custom panels
Frequently-ordered tests, bundled into a single orderable unit and offered at preferred pricing, one of the commercial levers Sales could offer clients. I worked with Sales to give these bundles their own dedicated compendium codes, so a bundled panel was orderable in one click inside the provider's EMR rather than as a handful of separate line items.
The operational catch: compendium codes were maintained by hand. Every price change, discontinued test, new test, or new custom panel meant a manual update that had to be coordinated with each EMR vendor before it went live, which made catalog upkeep a recurring, cross-functional effort rather than a one-time setup.
HL7 over SFTP vs. REST API
Transport wasn't winner-take-all. I chose it per EMR. I scored both options against what actually drove adoption and reliability (1 = poor, 5 = excellent) to make the default explicit: HL7/SFTP for the majority, API where it earned its keep.
| Criterion | HL7 over SFTP ✓the majority | REST APIselective |
|---|---|---|
| EMR / vendor readiness | 5 | 2 |
| Engineering / onboarding cost | 4 | 3 |
| Reliability & throughput | 4 | 4 |
| Latency (real-time vs batch) | 3 | 5 |
| Maintenance burden | 4 | 3 |
| Total | 20 | 17 |
Decision: HL7 v2 over SFTP became the default because nearly every EMR already speaks HL7. That readiness made it the fastest, most repeatable way to bring a practice live, and it carried the vast majority of connections. REST API won where the EMR offered a solid one and the practice needed lower latency than batch file drops; there it beat HL7 on freshness, but the thinner vendor support and per-integration build cost kept it from being the default. The point wasn't picking one transport; it was matching each EMR to the path that got it live reliably.
Architecture & data flow
Once a request was approved, the integration layer brokered every message between the EMR and the lab: generating HL7 v2 (ORM orders, ORU results) or API calls, mapping each EMR's fields to the lab's data contract, moving files over SFTP, and logging every hop for the audit trail.
Provider EMR
Orders placed and results received inside the provider's workflow.
Orderable via compendium codesIntegration layer
Field mapping to the lab's data contract
Transport: HL7 v2 over SFTP (majority), REST API (selective)
Reliability: retries, de-duplication, HL7 parse-error handling
Audit log: every hop logged and queryable
Lab (LIS)
Order intake and result generation in the lab system.
Orders (ORM) flow out, EMR to lab
Results (ORU) flow back, lab to EMR
The Go/No-Go checklist
No connection went live on a hunch. Each one cleared the same gate, and every item had to be green to call it a Go. It made "are we ready?" an objective decision instead of an argument.
Before & after
25+
EMR integrations live
weeks to onboard
Days
after self-service + approval
Thousands
ordering & results transactions
Verified outcome: zero data-loss incidents across thousands of ordering & results transactions, with a full, queryable audit trail for compliance.
How it got built
Request & approval workflow: Designed the provider-facing request form and the internal Sales approval queue, capturing the EMR, integration mode, and contacts up front so an approval handed engineering everything needed to provision, no back-and-forth. Providers could see where their request sat (submitted, approved, provisioning, live) in the portal and through automated email updates, which cut "is it done yet?" follow-ups.
Standardized HL7 mapping over SFTP: Built standardized, reusable HL7 v2 mappings (ORM orders, ORU results) against the lab's data contract that could be shared with EMR vendors to stand up a bidirectional or results-only integration, turning much of each onboarding into configuration rather than bespoke work. Messages moved over SFTP, the path that brought the majority of practices live.
REST API where it fit: For EMRs with a capable API, parsed the spec, aligned on auth and SLAs, and built the integration directly, for lower latency than batch file drops where the practice needed it.
Failure-state design: Built retries on dropped SFTP transfers, handling for malformed HL7, de-duplication, and monitoring, so a transient outage couldn't silently lose an order or a result.
What I'd do differently
- check_circleInvest in observability dashboards from day one. Notification-based alerting was in place, but dashboards for transfer success, retry rates, and HL7 parse failures should ship with v1 rather than relying on notifications to surface problems.
- check_circleBuild toward FHIR, not just HL7 v2. HL7 v2 over SFTP was the right pragmatic majority call on vendor readiness, but it is batch and aging. As EMRs adopt FHIR, I would invest earlier in a FHIR-based path so the program rides the industry shift instead of accumulating legacy mappings to migrate later.
- check_circleAutomate compendium and custom-panel sync. Catalog upkeep stayed manual and vendor-gated, so every price change, discontinued test, or new panel was a hand-coordinated update. A sync that pushed catalog changes to EMR vendors on a defined cadence would have removed a standing source of toil and the risk of a practice ordering against a stale code.