Epic Patient Outreach: The Org Is the Gate

Epic documents this as a step-by-step process, and it's worth reading literally rather than skimming.

You register an app on the developer portal. Epic issues you two client ids, one production and one non-production. You mark the app ready for sandbox, and Epic's docs say it becomes testable within about an hour. You build against sandbox data.

When you're done, you go back, finalize the app's details, check a compliance box, and mark it ready for production.

Here is the sentence that determines your schedule: the app cannot be used in any community member environments, production or non-production, until it has been marked ready for production. A community member is Epic's term for a customer health system. Marking your app ready for production doesn't connect it to anyone. It only makes it eligible to be connected.

The actual connection is initiated from the other side. Someone at the health system, specifically a person whose Epic account carries the security point to purchase apps, has to request a download of your app using your production client id.

Epic has a reputation for being the expensive one, and on the developer side that reputation is mostly wrong.

The self-service path is free. Registering on Epic's developer site, building against the sandbox, and using the standard FHIR APIs, USCDI and several hundred others, costs nothing, and the documentation is open. A separate program, Vendor Services, sells individualized assistance rather than access. Epic doesn't publish its terms on the open part of the site, so treat any figure you find elsewhere as unverified and ask Epic directly. It's optional, and plenty of integrations ship without it.

So when you're estimating an Epic project, put the licence line at zero and spend the anxiety somewhere more useful. What costs you is calendar time inside the health system, and that bill arrives whether or not you pay Epic anything.

One caveat worth stating plainly rather than discovering later: the free path clearly covers reading. Whether writing to the schedule, meaning actually booking an appointment, falls inside it or needs something enabled on the health system's side varies, and it's worth confirming with Epic directly before promising a customer a date. Assume the read side is free and the write side is a question.

This surprises people who expect an app-store model. Epic states plainly that it does not endorse, certify, or verify the integrity, safety, performance, or practices of the developers who use Epic on FHIR or their software.

There's no approval queue you're sitting in. There's no reviewer to escalate to. If your project is stalled, it's stalled inside a customer's organization, and the only people who can unstick it work there.

Practically, that means your integration plan needs a named internal sponsor at the health system before you write any code: someone who can find the person with that security point and get the download requested. Every Epic project that ships has one. Most Epic projects that don't ship were technically finished months before they died.

Epic recommends a distinct client secret per community member, and separately for production versus non-production.

That recommendation has an architectural consequence that's easy to miss at design time. Your credential store isn't one secret per environment. It's one secret per customer per environment, which means the schema you sketch on day one should already have an organization dimension in it. Retrofitting that after your third customer is unpleasant, and it's the kind of unpleasant that involves rotating live credentials.

Budget for it early. It costs almost nothing to design in and it's genuinely painful to add later.

Patient outreach, reminders, recall, filling a cancelled slot, needs two things: a way to know the schedule changed, and a way to reach the patient.

Epic's FHIR surface gives you the read side. Appointment, Slot, and Schedule are all documented resources, and Epic's own scheduling documentation covers prototype services for booking via FHIR. The read side is genuinely fine.

The reach side is where scope creep lives. Epic health systems typically already have MyChart, and MyChart already sends appointment reminders. If you propose an outreach system that duplicates MyChart notifications, you'll lose that conversation, and you should, because the patient doesn't want two reminders from the same clinic.

The outreach that actually gets approved at Epic sites is the outreach MyChart doesn't do: reaching patients who never activated a portal account, working a cancellation list by phone or text within the hour, chasing recall on patients who haven't booked at all and therefore have no appointment to be reminded about. Frame the project as covering the gap and it clears internal review far faster than one framed as a better reminder system.

The sensible first slice usually isn't scheduling at all. Authentication, patients, encounters, and documents are the read-heavy surfaces that establish the connection is working and produce visible value quickly, without touching appointment writes.

That's not a limitation to regret. Writing to a health system's schedule is the highest-consequence thing an integration can do, and the internal review it triggers is proportionate. Getting a read-only integration live first means you've already cleared credentialing, security review, and the download request. The second conversation is much shorter than the first.

Because the organization is the gate, the first conversation with a health system is worth treating as a technical discovery call rather than a sales one. Four questions save months.

• Who holds the security point to purchase apps? If nobody in the room knows, that's your first task and it isn't a technical one.
• What Epic version are you on, and what's your upgrade cadence? Resource availability and search parameter support both track the version. An organization mid-upgrade may be a poor first customer regardless of enthusiasm.
• Has this organization done a third-party FHIR integration before? A yes means the security review, the BAA, and the download request are known quantities with known owners. A no means you're the pilot, and pilots absorb the cost of inventing the process.
• What does MyChart already send patients today? This determines whether your project is additive or competitive, and it's better to learn it before you've built anything.

None of these are about FHIR. That's the point.

• This describes the public developer process, not a production deployment. The specific FHIR resources and search parameters a given health system exposes vary by their Epic version and by what they've chosen to turn on. Confirm against that organization's own capability statement before you commit to a design.
• Timelines vary enormously. A health system with an existing integration practice and a motivated sponsor can move in weeks. One without either can take much longer, and no amount of engineering will shorten it.
• Vendor Services pricing isn't public. Treat any number you hear secondhand as unverified until Epic confirms it for your project.
• The write side needs its own confirmation. Booking against the schedule may need something enabled beyond the standard self-service path. Don't promise a booking timeline before you've asked.