Case Study - A Pre-Op Tool That Opens From Inside the Patient’s Epic Chart
A SMART on FHIR app that launches from a patient’s chart in Epic with that patient already loaded — and flags the medications most likely to cancel their surgery — with a second EMR connected through the same clinical layer.
- Client
- Beacon Health
- Year
- Service
- EHR Integration (SMART on FHIR)
We built the Epic launch so a clinic nurse opens Beacon from the chart they already have open, with the patient’s procedures and medications already there — and the drugs that most often cancel surgery flagged before anyone has to go looking.
The challenge
Day-of-surgery cancellations are costly for a surgery center and hard on the patient, and a share of them trace back to medications nobody caught in time — GLP-1 drugs, anticoagulants, NSAIDs and SGLT2 inhibitors among them. Beacon prepares patients for surgery, so it needs each patient's procedure and medication list. That information lives in the practice's EHR, and the people who would move it — clinic nurses — have no time to copy a chart into another system.
My role
I set the EMR strategy — which systems to integrate first and how — and designed and built the Epic integration: the launch from the chart, the clinician's identity, the data Beacon reads, and the medication screening applied to it. I also connected a second EMR, athenaOne, through the same clinical layer.
Leadership decisions
Decision 1
Launch from the patient’s chart, not from a separate login.
Instead of: A standalone app where staff sign in and search for the patient again.
A nurse who has to leave the chart, open another tool and find the same patient will stop doing it by the second week. So Beacon is a SMART on FHIR app launched from inside Epic: the chart supplies the patient in context, Beacon reads that patient's demographics, procedures and active medications, and the nurse lands on a screen that's already filled in. It was also built for the reality of Epic's embedded browser, which doesn't keep cookies across the hand-off — so the session state lives on the server instead.
Decision 2
Screen for cancellation risk at the moment the data arrives.
Instead of: Importing the medication list and leaving staff to read it.
The reason to pull the medication list at all is clinical: certain drug classes commonly cancel surgery if they aren't managed beforehand. So every imported medication is classified on arrival, and GLP-1s, anticoagulants, NSAIDs and SGLT2 inhibitors are flagged — turning a list someone has to scan into a short list of what needs attention before the procedure.
Decision 3
Make the clinical layer shared, and only the connection EMR-specific.
Instead of: A separate pipeline for each EMR — or starting with the systems whose access depends on a partnership.
Each EMR authenticates differently, but they speak FHIR. So sign-in is built per vendor, while reading the record, classifying medications and saving the patient are shared. And the order was deliberate: start with EMRs whose APIs developers can reach directly, and use working integrations as leverage with vendors whose access depends on a partnership. athenaOne was then connected reusing the same parsing and medication screening.
The solution
From a patient's chart in Epic, a nurse clicks to open Beacon. Beacon discovers the hospital's authorization endpoints, completes the SMART on FHIR sign-in, verifies who the clinician is, and reads that patient's demographics, procedures and active medication orders. The clinician is matched to their existing Beacon account by email, or one is created for them. The patient is saved to Beacon with surgery-cancelling medications already flagged.
The integration starts where the nurse already is — in the chart — and does the first clinical read for them.
Impact
- One flow, end to end. Sign-in, clinician identity, the patient in context and the medication read work as a single launch from the Epic chart.
- No re-keying. The patient's demographics, procedures and medications arrive from the chart rather than from a nurse's typing.
- Cancellation risk surfaced up front. The medication classes most associated with day-of-surgery cancellations are flagged the moment a patient is imported.
- A second EMR on the same foundation. athenaOne was connected using the same clinical layer, rather than a second build.
Under the hood — the technical detail
The Epic integration is a SMART on FHIR EHR launch: the app requires the launch and issuer parameters Epic supplies, discovers endpoints from the issuer's SMART configuration, and exchanges the authorization code server-side. The identity token is verified against the issuer's published keys, and the practitioner is resolved from the fhirUser claim. Epic released neither name nor email in the identity token, so identity falls back to reading the FHIR Practitioner resource — a finding that made manual account linking an explicit requirement. Practitioner mappings are keyed by issuer as well as practitioner ID, so identifiers can't collide across Epic organizations. Tokens stay on the server, and because Epic's embedded browser drops cookies across the launch boundary, OAuth state and the session hand-off are held server-side with short expiries.
Beacon reads Patient, Procedure and active MedicationRequest resources for the patient in context. The athenaOne connection uses a backend client-credentials flow scoped to the practice and reads Patient, MedicationRequest, Condition, AllergyIntolerance and ServiceRequest, mapping service requests to procedures and reusing the same parsers and medication classifier. Write-back to the EHR was designed as a later phase.
- SMART on FHIR (EHR launch)
- Epic
- athenaOne
- FHIR R4
- Perioperative medication screening