EMR Interoperability Case Study

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:

Unify EMR integration

behind one interface, so the product does not branch per vendor.

Meet the platform’s real-time constraint,

where a delivery has to finish inside seconds.

Make per-tenant configuration

a first-class part of the design.

Replace

the queue and step-function workarounds already in place.

Make

every delivery auditable.

Challenges & Solutions

No common language across EMRs

Solution

We wrote one abstraction per protocol, with patient transforms reused through a shared component called SimplePatientAdapter.

A hard 30-second ceiling

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.

Solution

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.

The same EMR, configured differently everywhere

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.

Solution

A Tenant Configuration Service holds the per-client differences, so a new clinic goes live through configuration instead of a code change.

Queue and step-function workarounds already in place

Queues and step functions had been layered in earlier. They ran, but they made both debugging and onboarding painful.

Solution

The serverless-first design below replaced them.

Fire-and-forget delivery

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.

Solution

Every document delivery is logged in DynamoDB, traceable and de-duplicable, and that record is what supports a compliance review.

Build Your Project With US

Learn how your project can benefit from our expertise

Let's talk

What We Built

An NX monorepo with a strategy pattern

One Lambda integration per EMR vendor. Each vendor implements only what is genuinely unique to it and inherits the shared plumbing.

Protocol-specific abstractions

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.

A Tenant Configuration Service (TCS)

Per-client overrides stored as data.

Multi-tenant by design

A single integration class serves many customers on one EMR through TCS.

Serverless-first infrastructure

AWS Lambda and API Gateway, DynamoDB, SQS, and Secrets Manager for per-tenant credentials.

An audit trail by default

Every export is logged in DynamoDB. Each new integration lands first as a reviewable scaffold pull request, before any vendor-specific implementation follows.

Provided Services

Backend Development

API and EMR Integration

Cloud and Serverless Infrastructure (AWS)

Our Work Approach

Our team turned vendor onboarding into a repeatable playbook with four steps. Configuration lives as data, never as a branch in code, and the work was senior-led.

Step 1

Classify the protocol

FHIR REST, HL7v2 file drop, or proprietary API.

Step 2

Select the base class

The protocol classification determines where the integration starts.

Step 3

Ship a foundation PR

A scaffold pull request lands first, with no vendor logic in it, which keeps the change small and reviewable.

Step 4

Implement the methods

Vendor-specific behavior fills in the scaffold, one reviewable change at a time.

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

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

Why TechMagic

Certified security specialists with a focus on healthcare security

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.

All-in-one development

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.

Ongoing support

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.

Let's talk