Unified EMR Interoperability Layer
A patient intake and referral platform that delivers captured data into any customer EMR, across 10+ systems, including Medplum.
USA
About Project
We partnered with a US-based HealthTech company, whose platform lets clinics and health systems capture patient intake and referral details, then deliver them into each customer’s system of record, the Electronic Medical Record (EMR). Customers run different EMRs, and the same EMR is set up differently from one health system to the next. The platform connects to 10+ of them, including Epic, athenahealth, NextGen, and Medplum, through one integration layer, and all of it runs from one codebase.
Project Goals & Our Role
The objective was to let the same product connect to any of the 10+ supported EMRs without a custom build per customer.
Our team owned the backend, the vendor integrations, and the cloud infrastructure.
Five objectives shaped our work:
behind one interface, so the product does not branch per vendor.
where a delivery has to finish inside seconds.
a first-class part of the design.
the queue and step-function workarounds already in place.
every delivery auditable.
Some EMRs expose modern FHIR REST APIs. Others take legacy HL7v2 files, dropped onto a network share over VPN, and some expose proprietary REST APIs. FHIR and HL7v2 both come from HL7 (the standards body for clinical data exchange), and they still behave nothing alike in production. No off-the-shelf abstraction covers all three shapes.
We wrote one abstraction per protocol, with patient transforms reused through a shared component called SimplePatientAdapter.
The platform’s API Gateway request times out at 30 seconds, and there is no asynchronous channel back to the user. Every delivery has to succeed or fail synchronously, in seconds.
We moved the request path onto simple synchronous Lambdas. Fewer moving parts make a failed delivery easier to debug and the whole thing easier to hand off.
Two health systems can run identical EMR software and still expect different configuration and credentials. Treating that variance as code would have meant a fork per customer, which is what the project set out to avoid.
A Tenant Configuration Service holds the per-client differences, so a new clinic goes live through configuration instead of a code change.
Queues and step functions had been layered in earlier. They ran, but they made both debugging and onboarding painful.
The serverless-first design below replaced them.
Once a document leaves the platform, nothing tells the user what happened on the other side. There is no interactive feedback channel back to the end user, and this project did not add one, so the platform has to be defensible through its records instead.
Every document delivery is logged in DynamoDB, traceable and de-duplicable, and that record is what supports a compliance review.
One Lambda integration per EMR vendor. Each vendor implements only what is genuinely unique to it and inherits the shared plumbing.
A shared FHIR R4 base class serves the FHIR-native systems, Medplum among them. An HL7v2 builder handles the file-drop EMRs. Thin REST clients cover the proprietary ones. Patient transforms are reused through SimplePatientAdapter.
Per-client overrides stored as data.
A single integration class serves many customers on one EMR through TCS.
AWS Lambda and API Gateway, DynamoDB, SQS, and Secrets Manager for per-tenant credentials.
Every export is logged in DynamoDB. Each new integration lands first as a reviewable scaffold pull request, before any vendor-specific implementation follows.
Project Outcome
The client’s product now connects to 10+ EMRs, including Epic, athenahealth, and Medplum, from one codebase, with no per-customer custom builds. The engagement also left behind:
A repeatable vendor-onboarding playbook that significantly lowers the cost of adding the next EMR
Multi-tenant delivery by design. New health systems onboard through configuration instead of a code fork
A simpler architecture. Synchronous Lambdas replaced the fragile workarounds, so the system is easier to debug and easier to hand off
An audit-grade delivery record supporting compliance reviews, with every document delivery traceable and de-duplicable
Technologies Used
Languages
Cloud platform & services (AWS)
Infrastructure & tooling
Data access/ORM
Healthcare platform & standards
Protocols, transport & integration
- TypeScript
- Python
- AWS Lambda
- API Gateway
- DynamoDB
- SQS
- Secrets Manager
- AWS CDK
- NX monorepo
Dynamoose (DynamoDB modeling/ODM)
- Medplum (FHIR-native backend platform)
- FHIR R4
- HL7v2
- SMART on FHIR
- HTTPS/REST
- SFTP
- HL7v2 over SFTP on VPN
We hold CREST accreditation for security services and run a dedicated cybersecurity practice for clinical products. That background shapes how we handle your data even on a backend engagement: per-tenant credentials live in AWS Secrets Manager, and every document delivery is logged in DynamoDB so it can be traced during a compliance review.
You get one team for the whole build. Backend, integrations, and cloud infrastructure sit together, so you are not coordinating three vendors to ship one feature, and the people who design a component are the ones who build it. The same setup runs through our healthcare app development services.
We provide support after launch. Our clients tend to stay with us for years, and what we hand over is built to be picked up by whoever comes next: shared components, configuration stored as data, and a repeatable path for adding the next integration.
Cases That May Be of Interest to You
Let’s turn ideas into action
VP of business development
Trusted by:
