EHR integration best practices, and what Epic integration really takes

EHR integration best practices come down to six habits: start from the workflow, prove access in the vendor's sandbox before the build depends on it, match patients across systems, write back only with a person approving, build for failure from the first release, and decide who runs the integration after launch. Epic adds a route decision and a health system's approvals on top. Digital Scientists runs PointClickCare and Netsmart (GEHRIMED) integrations in production on platforms we operate. Our Epic work so far is in Epic's sandbox, and this post says what that means.

What are the EHR integration best practices that matter?

The practices that matter are the ones that keep a clinician from opening an empty chart. An EHR integration is the connection between an electronic health record and another system: your product, an AI model, a billing tool or a care team console. The first data pull is rarely the hard part. Access approvals, mismatched patient IDs, slow vendor APIs and a feed that stops at 2 a.m. are.

Here is the short list we work from on every EHR integration:

• Start from the workflow. Name the decision the data supports and who makes it, then pull only the fields that decision needs.
• Prove access early. Get credentials, a sandbox and real sample data in week one. If a connection won't work, hear it then.
• Match patients deliberately. The same person shows up under different IDs in different systems. Treat matching as its own piece of work.
• Write back carefully. Validate every field, and have a clinician approve clinical changes before they reach the chart.
• Assume it will break. Retries, monitoring, audit logs and PHI controls ship in the first release, not after the first outage.
• Name the owner after launch. Vendors change their APIs. Someone has to absorb that, every time.

Why start with the workflow instead of the API?

Because the API tells you what's available, not what's needed. Start from the API and you pull everything the vendor exposes, then build screens nobody uses. Start from the workflow and the integration has a job.

CommuniCare's MDS platform is a good example. MDS coordinators in skilled nursing facilities needed to know when a resident's condition changed enough to affect an assessment. So we read assessment data, clinical notes, medications and lab results from PointClickCare, scan for 200+ clinical events that change an MDS assessment, and surface recommendations inside the PointClickCare workflow. No separate login and no duplicate data entry. Every recommendation links to its source documentation, and the coordinator validates it before acting.

We built that platform from April 2024 and then handed it to CommuniCare's own team. It has recovered $10M+ to date, with $24M+ in forecast PDPM revenue. See the CommuniCare MDS case study.

How do you prove EHR access before the build depends on it?

Run a week-one check: get access, pull real data and prove each connection before anyone writes the features that sit on top of it. Everyone thinks an integration is easy. We've seen simple ones take four months, and the code was rarely the reason.

The week-one check covers four things. Access: credentials, a sandbox, the vendor's partner or developer program, and who on your side signs off. Partner approvals often set the calendar, so we start them on day one. Real data: a sample under a BAA, because field names in a spec and values in production are rarely the same thing. The gaps: what the API exposes, what lives only in reports or exports, and where a person is the integration today, retyping between screens. A plan: the channel for each system, the build order and the risks.

Pick the channel the vendor actually supports, not the one in the sales deck. FHIR, HL7 v2, vendor APIs, webhooks and secure file feeds each carry different data, and most organizations run several. Our post on interoperability in healthcare covers how those channels fit together.

What does Epic integration really take?

Epic integration takes a route decision, the health system's approvals and a sandbox test before any production work. The route depends on who you're selling to. Here is where we stand: we've pulled patient data from Epic's FHIR sandbox, and we don't have an Epic production interface or a Showroom listing on record. Anyone who tells you Epic is quick hasn't waited on a health system's approvals.

A SMART on FHIR app launches from inside the EHR, receives the patient and user in context, and gets a scoped token, so the clinician never logs in twice. For one health system, building to the interface its Epic team already runs is often faster than a marketplace route. We pick the route in the Blueprint, test in the sandbox, and put the approvals on the plan from day one so they don't move your launch date.

How should you handle patient matching across EHRs?

Treat it as engineering, not cleanup. The same patient appears under slightly different names and IDs in each system, and every downstream feature inherits the errors.

On CommuniCare's platforms we pull PointClickCare and Netsmart (GEHRIMED) data, and we built the crosswalk that matches the same patient across both EHRs. Along the way we found patients carrying more than one Medicare ID and cleaned them up. The risk adjustment work on the same foundation reached $10M+ in RAF improvement at 90%+ accuracy across 7 states, 245 providers and 20K+ patients. The model was the easy part. Getting six data sources to agree on who each patient is took the real engineering.

When should you write back to the EHR?

Write back when the workflow needs it and the vendor permits it, and not before the read side is stable. Writing back is where integration projects slip. It needs the vendor's write permission, usually a separate sign-off from the provider's IT and compliance teams, validation on every field so bad data never lands in the chart, and a clinician who reviews clinical changes first.

Some EHRs only allow reads. Then design the workflow around that instead of pretending otherwise. On the MDS platform, recommendations surface inside PointClickCare and coordinators review each one before anything changes in the record.

How do you keep an EHR integration reliable after go-live?

Build for the failures you already know are coming. EHR integrations fail quietly: a token expires, a vendor renames a field, a feed stops overnight and nobody notices until a clinician opens an empty chart.

• Slow or down vendor APIs. Retries with backoff and queues that hold work until the EHR is back, so no record is lost.
• Expiring credentials. Automatic refresh, with an alert before expiry.
• Changed or empty fields. Validation on every record. Bad data is set aside for review, not written.
• Feeds that stop. Monitoring on volume and freshness. A missing file counts as a failure.
• PHI. An audit log of every read and write, encryption in transit and at rest, and access limited by role.

Each integration ships with a runbook, so whoever is on call knows what normal looks like. We sign a BAA with every covered entity, and our security plan is mapped to NIST CSF 2.0. On the platforms we build, we take L2 and L3 support and absorb vendor changes, while your team or IT provider takes first-line questions. When you want to own it, we hand it over on a build-operate-transfer plan.

Where should an EHR integration project start?

Most start with a Blueprint that maps the data you need, what each EHR exposes, who has to approve access and where the risk sits. If one integration is the risky part, pull it forward and prove it against the vendor's sandbox before the full build. These are common starting points, not rules.

We can integrate with any system that has an API, a standard interface or a reliable export. What we won't do is call a sandbox test a production integration. If you're weighing an Epic route or a PointClickCare build, talk it over with us.

Frequently asked questions