“Embedded data for Epic” usually means one of two things, and the more common one is a SMART on FHIR application running inside the Epic chart rather than data loaded into Epic records. An embedded SMART app launches from within the EHR and receives launch context — the patient currently open, the encounter, and the signed-in user — handed over as part of the OAuth2 exchange. That context is the entire difference between an embedded app and a standalone web application calling the same API: the embedded app already knows who it is looking at, so the clinician never re-enters or re-searches anything, and the app inherits the user’s session rather than authenticating separately. Building one means implementing the SMART EHR launch flow, requesting the right scopes, registering the app in the health system’s Epic environment, and rendering inside a constrained iframe. The registration step, not the code, is usually the long pole.
Two Things People Mean by “Embedded Data in Epic”
Let me resolve the ambiguity up front, since the phrase genuinely points in two directions and most content picks one without saying so. It can mean a SMART app rendered inside the chart — a third-party tool the clinician sees and uses without leaving Epic. Or it can mean writing data into Epic’s own records. This post covers the first reading in depth, because it’s the more common developer intent behind the search. If you specifically mean the second — actually writing data back into the record — I’ve covered that governance-heavy process separately in how Epic write-back integration actually works.
What a SMART on FHIR App Inside Epic Actually Is
An embedded SMART app is a real application — often just a web app under the hood — that renders inside the Epic chart rather than in its own separate window a clinician has to switch to. It shows up in real clinical workflows as a panel or tab a provider clicks into without leaving the patient’s record: a risk-scoring tool, a specialty-specific calculator, a third-party clinical content viewer. The defining trait is that it’s launched by the EHR itself, with context already attached, rather than opened independently.
EHR Launch vs. Standalone Launch
This is the core mechanic, and it’s worth walking through concretely. In an EHR launch, the clinician is already inside Epic, working in a patient’s chart, and clicks to open your embedded app. Epic hands your app an iss parameter (identifying the FHIR server) and a launch context handle. Your app exchanges that handle, through the OAuth2 flow, for the actual patient, encounter and user identity — which means by the time your interface renders, it already knows exactly who and what it’s looking at.
A standalone launch is the opposite scenario — a user opens your app from outside Epic entirely, with no existing session to inherit. That flow typically prompts the user to select a patient during authorization instead, since there’s no EHR context handed over automatically.
For an app meant to live inside the clinical workflow, the EHR launch is the pattern that actually matters, and it’s the reason embedded apps feel seamless to clinicians in a way a separately-opened tool never quite does.
Scopes and What Your App Is Allowed to See
Launch context and data access are separate concerns, and your app has to request both explicitly. Launch scopes (like launch itself) get you the context handle; data scopes determine what clinical information you’re actually authorized to read once you have it. Request only what the workflow genuinely needs — the same minimum-necessary discipline that governs Epic’s write-scope approvals applies here too, and asking for a broader data footprint than your feature requires slows down review without buying you anything.
Registering the App in Epic
This is the practical bottleneck most competing content skips past. Before your app can be embedded in a real health system’s Epic instance, it has to be registered — first against a sandbox for development and testing, and separately against that specific health system’s actual environment for anything real. The sandbox registration is straightforward and self-service. The real-environment registration is not: it runs through that health system’s own Epic governance process, on their timeline, and it’s the same organizational gate that shows up everywhere in Epic integration work, not a code problem you can engineer your way past.
Rendering Constraints Inside the Chart
Worth planning for as a real design constraint, not an afterthought: an embedded app typically renders inside a constrained iframe, with limited screen real estate compared to a full browser window, session handling that has to play nicely with the parent Epic session rather than fighting it, and browser-support expectations set by whatever Epic’s own client environment uses. A UI designed first as a standalone full-page app and then squeezed into an embedded panel later is usually the wrong order to design in — plan for the iframe constraints from the start.
The Other Meaning: Getting Data Into Epic Records
Briefly, for the reader who actually meant this: writing data into Epic’s own records is a governance-gated process, not a rendering question, and it’s a different problem from everything above. I cover exactly what Epic lets you write, how scopes for writes get authorized, and what a health system’s governance review actually asks in the dedicated write-back post — that’s the deeper resource if this is the reading you actually needed.
Next Steps
An embedded SMART app is one of the more genuinely useful things you can build against Epic, because it puts your product directly into a clinician’s existing workflow instead of asking them to leave it. The engineering is learnable from public documentation; the registration and governance sequencing is where real projects gain or lose weeks. If you’re scoping one, our Epic integration team can help you sequence the sandbox and real-environment registration correctly from the start — or explore healthcare app development more broadly if you’re still shaping the concept. Talk to us when you’re ready.