Going Live with a Provider App: Hospital Install, Connection Hub and Cost
So we’ve built Vital Check, launched it from Epic’s test launcher, ran it inside Hyperspace, and it reads and writes to Epic’s FHIR server. All of that was in Epic Sandbox.
This lesson is about how to get it in front of real clinicians. The process is usually more tedious than building the app, because there are a lot of steps and you can’t start until a hospital has agreed to use your app.
Why there’s no automatic distribution
Back in Lesson 2, the registration form for VitalCheck had no Automatic Client Distribution section.
The reason is that installing your client ID into a hospital’s Epic instance is what lets someone there use your app. For a patient app, Epic does this for you across its customer base. For a provider app, there is no automatic path. Every hospital that wants your app has to go into their own Epic instance and configure your client ID themselves.
So going live is a sequence of hospitals, one at a time.
Build your first real FHIR app in 15 days
500+ builders have done it. Live kick-off, structured modules, Demo Day. $27.
Join the challengeStep 1: mark the app ready for production
Before you approach anyone, finalise the app on fhir.epic.com. Check every detail: the endpoint URLs, the scopes, and the client secret if you’re using a confidential client.
The moment you mark it Ready for Production, the record freezes. You can’t edit it afterwards. If something is wrong, you create a brand new app with a new client ID and start again. So check it properly and then mark it ready for production.
Step 2: find a hospital that wants it
You need to have a hospital that commits to integrating your app on their Epic system.
If you don’t already have one, this is the sales work: emails, calls, conferences, finding someone at the hospital who will pay attention. There’s really no way around it.
A common misunderstanding is that Epic has to approve your app before you go to a hospital. It doesn’t. That decision is made by the hospital. If they want your app, they can install it and use it, and Epic isn’t a gatekeeper in that decision.
Epic staff are usually around, though. Most hospitals have Epic consultants and analysts on site who configure the system, and they’ll be involved in the technical steps that follow. But they don’t decide whether your app gets used. The hospital does.
For decision makers: budget for the sales cycle before the integration work. The first hospital is the hardest to sign.
Step 3: the open.epic API Subscription Agreement
Once a hospital wants your app, the first thing they do is sign the open.epic API Subscription Agreement with Epic.
If they’ve installed any third-party app before, this is already done. If it’s their first time, they get their Epic technical coordinator involved and sign it. Once it’s signed, they can install any app from outside Epic’s own catalogue.
Step 4: send your client IDs and launch details
There’s no automatic distribution, so the hospital needs your client IDs some other way. Usually that’s email.
Send them:
- your non-production client ID
- your production client ID
- your launch URI
- any launch tokens your app needs (from the configuration in Lesson 5)
Someone at the hospital holds a role Epic calls the Purchased App Security Point. They log into their own Epic portal and configure your app inside their instance. Hospitals run more than one environment, so they’ll add your non-production client ID to their non-production instance first, and the production client ID to production once they’re ready.
If your app launches from inside a patient chart, the way VitalCheck does, that’s a separate piece of configuration on their side. It usually involves someone working in a terminal, but the Epic technical staff at the hospital will know what to do. Your job is to give them the launch URI and the details they ask for.
Step 5: activate from your side
When the hospital activates your app in their non-production instance, their name appears on fhir.epic.com under Review and Manage Downloads.
You then activate the app for non-production on your side. When they move it to production, you activate it for production too.
At this point you can ask for access to that hospital’s non-production Epic instance. You’ll need sign-off from someone like the CTO or the CMIO, because this environment is what they use to train their clinical staff. It’s full of dummy patients and there’s no PHI in it.
It’s worth asking. It lets you see your app in the hospital’s actual Epic installation, with all their configuration, before any real clinician opens it.
Once that looks right, they promote it to production, you activate for production, and your app is live at that hospital.
Then you repeat the whole thing for the next hospital.
The first two or three are the hard ones
Once your app is live at one or two hospitals, the next ones get easier. A hospital that sees your app already running somewhere else trusts that the install works, and the process moves faster. The first two or three contracts are where most of the effort goes.
Knowing the process helps as much as the live reference. By the second hospital you know who to contact and what they need from you. We’ve seen a lot of teams lose months on their first integration because they didn’t know who to talk to or what the steps were, which is the reason this lesson exists.
List on Connection Hub
After your first customer goes live, you can list your app on Epic’s Connection Hub.
You fill out a listing with what the app does and add screenshots. It works like an ad page: hospitals browse it to find apps, and when you’re selling, you can point to the listing. All it tells them is that at least one Epic customer has implemented your app, and that’s the condition for being listed.
What it costs
The APIs. All calls through the standard FHIR APIs are free, same as the patient side.
Vendor Services membership. On the provider side, a Vendor Services membership is worth having. It’s around $1,900 a year. If you want Epic to review and list your apps on Connection Hub, that’s around $500 per app on top.
Private APIs. If the standard FHIR APIs don’t cover what your app needs, you’ll use Epic’s private APIs. Many of these are metered per call, and they’re priced in tiers. A call can cost a fraction of a cent or a bit over a dollar depending on the tier. The tier is set by what the API does, so writing medications back costs more than reading data that isn’t available through FHIR, and the volume of calls doesn’t change which tier you’re in.
Engineering. Building a provider integration has ranged from about $25,000 to $100,000 in the projects we’ve seen.
Going Live. The hospital tests your app in their sandbox, gives feedback, and you iterate. Then they promote it to production. A lot of that is waiting for their team to validate and sign off. Including this cycle, a first production go-live for an Epic provider app has usually landed between $50,000 and $80,000.
| Item | Cost |
|---|---|
| Standard FHIR API calls | Free |
| Vendor Services membership | About $1,900 per year |
| Connection Hub review and listing | About $500 per app |
| Private API calls | Metered by tier, under a cent to a little over $1 per call |
| Engineering effort | $25,000 to $100,000 |
| First go-live, including hospital testing and sign-off | $50,000 to $80,000 |
Most of this is people’s time. Epic’s own charges are small, apart from some of the higher-tier private APIs. What drives the cost of a first Epic integration is the engineering and the waiting.
For decision makers: the figures above are for a first integration. The second and third hospitals cost much less, because the app is built and the team knows the process.
What’s next
That’s the full path for a provider app: build it, test it in the launcher and in Hyperspace, find a hospital, get your client IDs installed, activate, and go live. Then list it on Connection Hub and repeat.
Module 4 covers the backend pattern, where no user is logged in at all and your system talks to Epic directly. If you’re in the middle of a hospital install and something in this process doesn’t match what you’re seeing, post it in the comments.
