EHR Sidecar App: Build One Inside Epic, Cerner & athena (2026)

An EHR sidecar is a separate application that runs next to the electronic health record. It handles a workflow the EHR does badly, and it hands the result back to the EHR, which stays the legal record of care.

Most articles stop at that definition. This guide goes further, and it is written from the work our EHR integration team does on Epic, Oracle Health and athenahealth. It covers the decision to build a sidecar at all, a reference architecture, what the Epic, Oracle Health and athenahealth write APIs allow, the failures that hurt teams in production, and a test plan you can run before you sign a hospital contract.

The short answer

Build a sidecar when three things are true:

1. The workflow needs an interface or logic the EHR cannot give you, such as a patient dashboard, an AI drafting step, or a cross-system work queue.
2. The clinician can tolerate one extra surface, usually a panel launched from the chart.
3. You can name exactly what must go back into the EHR, in what form, and who signs it.

If you cannot answer the third point, you do not have a sidecar design yet. You have a separate app with an integration risk.

What an EHR sidecar is, and what it is not

A sidecar sits beside the EHR. It reads context from the EHR, does its own work, and writes a defined result back. The EHR keeps the authoritative clinical facts: orders, signed notes, results, medications. The sidecar can keep working copies of data, but it must not become a second long-term chart.

The idea is older than FHIR. In the 2000s, the HL7 CCOW standard let separate viewer applications follow the same patient as the EHR, so a clinician who switched patients in one window saw the same patient in the other. Research groups later used "sidecar" for systems such as i2b2, which hold a copy of EHR data and serve queries in parallel to the EHR. The SMART on FHIR team described running the same apps against either the live EHR or such a sidecar (Mandel et al., JAMIA).

Today, a sidecar usually means one of three shapes:

A sidecar is not an EHR replacement. It is also not a reporting copy of the database. If nothing flows back to the chart and no clinician acts on it inside the visit, you are building analytics. Design for that instead.

Sidecar, build inside the EHR, or replace: how to decide

Health systems ask this question before vendors do. Answer it in your proposal.

A real example shows the trade. UCSF built a patient-reported outcomes dashboard for rheumatoid arthritis as a sidecar on Salesforce, launched from the EHR, and put it into production in August 2021. The investigators wrote that building it inside Epic at the time would not have given them the customization they wanted (trial record NCT06655077). They also published a roadmap of what the build took: design, approvals, testing and long-term maintenance (Digital Health, 2024).

The same project carries the second lesson. The dashboard was then tested in a stepped-wedge, cluster-randomized trial with 554 enrolled patients. A UCSF investigator summary reports no change in the quantitative outcomes measured over the 18-month trial (Rethinking Clinical Trials summary). The sidecar worked as software. That alone did not move the measured outcomes. Plan adoption and outcome measures as part of the build, not after it.

Reference architecture

The diagram below is the architecture we use as a starting point. Each box has one owner and one job.

What each part owns:

• Launch layer. Validates the SMART launch: issuer, state parameter, granted scopes, patient and encounter context. It refuses to start if the context is missing. It never guesses an encounter.
• Back end for front end (BFF). Holds tokens on the server, never in the browser. Writes an audit line for every read and write: who, which patient, which resource, when.
• Workflow engine. Owns the life of each task: draft, reviewed, approved, sent, confirmed. It decides what to do when the EHR is slow, down, or returns an unclear answer.
• EHR adapters. One per vendor. They hide vendor differences from the rest of the code: different note formats, status rules and error shapes.
• Working store. Holds drafts and task state. Set a retention period. Once the EHR confirms a write, the EHR copy is the truth.

The rule that keeps this safe: the sidecar may draft anything, but only a confirmed write to the EHR counts as done.

What the EHR write APIs allow: the part most guides skip

Reading data from an EHR over FHIR is now routine. Writing back is where projects slip. The question to ask is not "does the vendor support DocumentReference create?" but "can this app, at this customer, create this kind of note, in this status, for this user, and will it show up where the clinician expects?"

Here is what the public documentation establishes, and what it leaves open.

Two buyer requests look the same and are not:

• "Put our AI note into the chart." A final document filed to the encounter may be enough.
• "Let the doctor edit and sign our AI draft in the EHR." That needs a draft status and a signing flow. Epic supports this with a preliminary note. Oracle's provider-access create does not, because it accepts only final. There you sign in the sidecar, use system access, or use the vendor's own document workflow.

Settle which one the buyer means before you size the work. We cover the per-vendor details of note write-back in FHIR DocumentReference for clinical notes on Epic, Oracle and athenahealth.

Security and HIPAA: what the architecture must show

Using FHIR does not make an app HIPAA compliant. FHIR is a data format and API standard. Compliance comes from the safeguards around it. For a sidecar, a hospital security review will look for:

• A signed business associate agreement before any real patient data flows.
• Scopes limited to what the workflow needs. Request patient/DocumentReference.c only if you write notes, not broad write scopes "for later".
• Tokens kept on the server, short-lived, and refreshed only within the session the user started.
• An audit trail the hospital can query by patient and by user.
• A data retention rule for the working store, and a documented way to delete drafts.
• Encryption in transit and at rest, and a risk analysis on file.

Failure modes, and the tests that catch them

Most sidecar incidents are not crashes. They are quiet errors: a note on the wrong encounter, a duplicate note, a draft lost when a token expired. Write these as acceptance tests and run them on synthetic data in the vendor sandbox before any pilot.

T05 deserves extra attention. A timeout does not mean the write failed. Search for the document by a stable identifier you set on create before you send it again.

For each test, keep the request and response with credentials and patient data removed, the expected result, the actual result, the environment, and the date.

A worked example: an AI documentation sidecar

Here is how the pieces fit for the most common sidecar request we see in 2026, an AI drafting tool for visit notes.

1. The clinician opens the patient in the EHR and launches the app from the chart. The app receives patient, encounter and user context through SMART.
2. The app reads the data it needs to draft: problems, medications, recent notes. It reads only what the scopes allow.
3. The AI step produces a draft. The draft lives in the sidecar's working store, labeled as unreviewed.
4. The clinician edits and approves the draft in the sidecar. Nothing reaches the chart without this step.
5. The adapter files the note in the form this customer supports: a final document over FHIR, or a document over an HL7 v2 interface.
6. The workflow engine confirms the note exists in the EHR, then marks the task done and clears the draft per the retention rule.

Step 5 is where the customer-specific answer from the write API table decides the design. Step 4 is where the clinical safety lives. Do not let a product deadline remove it. Our AI scribe EHR integration page covers the vendor paths for this flow.

Rollout plan

Expect the customer approval steps, not your code, to set the timeline. Our Epic FHIR integration guide walks through those approval steps for Epic.

Feasibility worksheet: questions to settle before you quote

• Which EHR product and version does the customer run?
• How does the app launch: from the chart, from a CDS card, or standalone?
• Which data does it read, and which scopes does that need?
• What exactly does it write: resource, note type, status, and who signs?
• Does the customer's configuration allow that write for a third-party app?
• What happens to the clinician's work if the write fails?
• Who at the hospital owns the app after go-live?
• Which outcome will prove the sidecar was worth it, and how will you measure it?

Build your sidecar with Nirmitee

We build EHR integrations and sidecar applications for US digital health teams across Epic, Oracle Health and athenahealth. If you are scoping a sidecar, start with the feasibility worksheet above. Then book a write-back feasibility review with our Epic integration team: we confirm what your target EHR and customer allow before you commit engineering time. For the Epic marketplace route, read our Epic Showroom approval guide.