Most digital health products do not live in the hospital. They live in the clinic, in the patient's pocket, and on a connected device at home. That makes Epic Ambulatory, the outpatient side of Epic, the module most healthtech apps actually need to integrate with. If your product touches a clinic visit, a patient portal, a telehealth session, or remote monitoring, this is the part of Epic you are connecting to.
This guide explains Epic Ambulatory for the people building outpatient and patient-facing products: what it covers, how remote monitoring and telehealth connect, and the integration patterns that work. For the full module-by-module view, our Epic integration services is the hub this guide links back to.
What is Epic Ambulatory?
Epic Ambulatory, often called EpicCare Ambulatory, is the module clinicians use for outpatient care: clinic visits, documentation, orders, results, and the in-basket workflows that run a practice. It is paired with MyChart, Epic's patient portal, and it is the surface where outpatient care meets the patient's own tools, the portal, telehealth, and connected devices.
For a healthtech team, Ambulatory matters because it is where the highest-volume, most patient-facing workflows live. A remote monitoring program, a telehealth add-on, a patient engagement app, a chronic-care tool, almost all of them touch the ambulatory record rather than the inpatient one. Understanding this module is the difference between an integration that fits the clinic's day and one that fights it.
What Epic Ambulatory Covers?
The module's scope is broad, but it clusters into a few areas.
Clinic visits are the core: visit documentation, orders and results, and the in-basket workflows clinicians live in.
MyChart is the patient's window, covering scheduling, messaging, results, records, bill pay, and forms.
Telehealth covers video visits, e-visits, and remote follow-up, increasingly a standard part of outpatient care rather than an add-on. Each of these is a place where an external product can extend what the clinic offers.
Bringing remote monitoring into Epic
Remote patient monitoring is one of the most common ambulatory integrations, and one of the easiest to get wrong.
The data path is straightforward in shape: a patient device, a blood pressure cuff, glucose meter, or scale, sends readings to a gateway or app that aggregates them, the data is standardized into FHIR or HL7, and it is filed into the Epic Ambulatory chart. The hard part is not the plumbing. It is deciding what reaches the clinician. A feed that dumps every reading into the chart buries the care team; a well-designed RPM integration surfaces the readings that matter and the trends worth acting on, and leaves the rest in the background. We have built remote monitoring solutions, so this signal-versus-noise problem is one we have worked through before.
Connecting apps to Epic Ambulatory
There are three durable patterns for connecting an outpatient app to Epic.
The embedded app runs inside the visit, launched from the chart with SMART on FHIR, so the clinician sees it in context with the patient already loaded. Patient apps work between visits, using FHIR patient access and MyChart linkage for engagement, RPM, and self-service.
Data sync runs behind the scenes, pulling data through backend FHIR services for population analytics and care coordination. Our Epic FHIR integration guide covers the launch and authentication details, and our guide to third-party Epic integration maps how each pattern reaches production.
Telehealth and the outpatient experience
Telehealth integration is less about video and more about workflow. The video call is the easy part; the value is in scheduling the visit, documenting it in the ambulatory record, capturing orders during the call, and making sure the encounter is billable and complete. An outpatient telehealth integration that handles the call but not the surrounding workflow leaves the clinic doing double entry, which is exactly what they were trying to avoid. The same logic applies to patient-facing tools generally: the integration earns its keep by removing clicks from the clinician's day, not adding them.
The gotchas worth knowing
Ambulatory integrations have their own realities:
- Workflow fit beats features. An outpatient tool that adds clicks gets abandoned, no matter how capable it is.
- RPM signal versus noise. Filing every device reading buries clinicians; surface what matters.
- MyChart is the patient surface. Patient-facing integrations usually have to account for how MyChart already works.
- Per-customer enablement. Like all Epic integrations, each health system enables your app in its own environment with its own base URL.
- PHI and consent. Patient-facing data flows raise consent and access-control questions that need answering up front.
MyChart and the patient relationship
For patient-facing products, MyChart is both an ally and a constraint. It is where patients already go to schedule, message, view results, and pay bills, so a new app has to decide whether it complements MyChart or competes with it. The integrations that work tend to complement: they use FHIR patient access and MyChart linkage to extend what the portal does rather than asking patients to adopt a parallel system they will forget about. Understanding what MyChart already covers keeps a product focused on the gap it genuinely fills, which is usually a specific condition, program, or moment in the patient journey rather than general portal functionality.
Population health from ambulatory data
Outpatient care is where most chronic disease is managed, which makes ambulatory data the foundation of population health. Care gaps, screening compliance, and chronic-condition cohorts are built largely from outpatient encounters, orders, and results. A backend data-sync integration that pulls this data, through FHIR or the reporting layers covered in our Clarity and Caboodle guides, lets a population-health tool see the panel clearly. The same care about definitions applies: a program that miscounts who is overdue for a screening loses the trust of the clinicians it is meant to help.
Designing for the clinic's day
The hardest constraint in ambulatory integration is not technical; it is time. An outpatient clinician sees patients on a tight schedule, and every extra click compounds across a day. The most successful ambulatory integrations are the ones that disappear into the workflow: an embedded app that loads with the patient already in context, a result that files itself, a remote-monitoring alert that appears only when it matters. We design ambulatory products with that economy of attention in mind, because a tool that respects the clinician's time gets used, and one that does not gets quietly turned off no matter how strong its underlying capability.
How we approach Epic Ambulatory work
Healthcare is the only industry we work in, and we have built 100+ AI-enabled healthcare products, including remote patient monitoring and telehealth platforms, plus EHR integrations for 30+ healthtech startups. We have shipped the kind of patient-facing, outpatient products that connect to the ambulatory record, so the workflow-fit problem is one we design for rather than discover late.
Our work is HIPAA-compliant by default, with SOC 2 and ISO 27001 behind it, which is what a health system's review expects before a patient-facing app goes live. The pattern we see is that ambulatory integrations succeed when the clinician's workflow and the patient's experience are designed together, not treated as separate problems.
Per-customer reality and going live
However elegant the design, an ambulatory integration still has to clear the same path as any Epic integration: each health system enables your app in its own environment, with its own base URL, after its own review. A patient-facing app also has to think about how patients are identified and linked to the right record, and how consent is captured and respected.
None of this is a reason to slow down, but it is a reason to plan for the partnership and security work alongside the build rather than after it. The teams that ship ambulatory products smoothly treat the technical integration and the go-live process, security review, customer enablement, and patient onboarding, as one project, so the launch is a formality rather than a scramble. Our guide to third-party Epic integration walks through that path in detail.
Where to start
Define where your product sits: inside the visit, between visits, or behind the scenes. That single decision points you to the right pattern, embedded SMART app, patient-facing FHIR access, or backend data sync, and shapes the whole integration. With the pattern chosen, map the specific clinic or patient workflow your product changes, name the clicks you are removing, and design the integration around that.
The outpatient tools that succeed are the ones that make a clinician's day lighter and a patient's care simpler, and that outcome is decided in scoping, long before the first line of code.
If you want help scoping or building an outpatient or patient-facing Epic integration, see our Epic integration services, or reach out to talk through your product, the workflow it changes, and the fastest path to a working integration that fits the clinic and the patient alike without adding to anyone's workload.
