Waiting feels free. It isn’t. How to count what delay costs you, and what you can do before March 2027.
Waiting feels free. It isn’t. Epic’s Connectors are planned for Showroom in March 2027, and most teams can’t deploy them today. But since October 30, anyone can start on the questions behind them, because the open.epic MCP (Model Context Protocol) server makes Epic’s developer documentation searchable by AI. If you’re a physician with a startup idea, or part of a health tech team, here’s how to count what delay costs you and what to do first.
Key takeaways
- The expensive mistake: waiting until March 2027 to start asking what your product would need.
- Where the money goes: documentation hours, rework from limits found late, ideas that should have stopped early, and old workarounds that keep running.
- What’s available today: the open.epic MCP server lets an AI client search API specs, playbooks, tutorials and FAQs. It isn’t a route to hospital data, and Epic’s setup page says it isn’t designated to handle PHI (protected health information).
- Who does the interpreting: your AI client. Epic says the server only retrieves content and gives no guidance, so check every answer against the source.
- What to do this week: fill in the worksheet, run your idea through the five questions and the prompt below, and write down every “not documented”.
Why I’m writing this
This article started with a short LinkedIn post I wrote about this server. I’m excited about the news: physicians see problems every day that deserve better solutions. The post passed 21,000 impressions in about a day, and people kept saving it and sending it on. Somebody out there has an idea, or works with somebody who does. So here’s the longer version, written to be saved and forwarded.
What does waiting actually cost?
It costs more than it looks like, because the bill arrives later and in pieces. We won’t put a multiplier on it, since that depends on your team. Here’s where the hours and money go, so you can count your own.
| Where it goes | How to count yours | What waiting does to it |
|---|---|---|
| Reading documentation | Engineer hours × hourly rate | The same hours, but under a deadline |
| A limit you find late | Rework hours × hourly rate | The later you find it, the more is already built |
| An idea you should have stopped | Months of build × monthly team cost | You learn it at the end, not at the start |
| Keeping the old workaround going | Manual hours a month × hourly rate × months until the new thing is live | The meter runs until it ships |
Run the numbers twice: once if you start this month, once if you start when a customer asks you in 2027. The gap between the two is your cost of waiting.
What does the open.epic MCP server do?
It lets an AI client that supports MCP search open.epic content: API specifications, interface summaries, Data Sharing Playbooks, tutorials and FAQs. MCP is an open standard for connecting AI tools to outside sources. The library is big, with more than 50 playbooks, so this is useful.
One detail is worth your attention. Epic’s announcement says you can connect a client to “search and interpret” the content. Its setup page says the server “only retrieves content” and doesn’t provide guidance. Both are accurate, and together they tell you where the interpreting happens: in your AI client.
So ask for the passage and the link, and read it yourself. And keep patient data out of it: the setup page says the server isn’t designated to handle PHI, and that you’re responsible for what you transmit.
Is it the same thing as Epic Connectors?
No, and they’re easy to mix up because both involve MCP. The docs server lets your AI read about Epic’s APIs, and it’s available now. Connectors go the other way: they let Epic’s own AI tools reach into third-party apps, with listings planned for Showroom in March 2027 and a review by each health system before anything is switched on (The Epic Edge, Oct 2026; our Open@Epic recap).
So should you build a Connector today? Usually not yet. MCP is the standard at launch, and it may change later (Fierce Healthcare, Oct 2026). Do the work that keeps its value either way: your list of APIs, your workflow map and the hospital’s answers.
What 5 questions should you answer before you build?
This is the work you can start now, and it holds its value even if the standard changes. In our judgment, AI search does the most for the first question. By the fifth, it has very little to say.
1. Does the API exist?
This is where the server earns its keep. It also speaks to a real gap: in the 2026 State of FHIR survey of 101 experts in 63 countries, 75% named lack of FHIR knowledge as a barrier, the top answer for four years running (Firely and HL7, 2026).
2. Does it do what your product needs, for your kind of user?
Reading a chart, booking an appointment and writing back to the record are different capabilities. The same API can also behave differently for a patient app, a clinician app and a backend service. The table below shows how much that varies.
3. Does it behave the same at this hospital?
Often not. Epic’s docs note that some values differ in each customer environment and that customers may need to do ID mapping before an interface can write data (Epic on FHIR). Oracle Health (Cerner) docs say an organization’s security and preferences may filter data based on its build (Oracle Health). A sandbox with sample data can’t tell you this.
4. Will the hospital let you connect?
That’s the hospital’s call, and documentation doesn’t change it. Epic says there’s no central endpoint and that customers control how and with whom they connect (open.epic). MEDITECH’s patient access FAQ also leaves app review to the organization (MEDITECH). Budget time for security and legal review, and find out early who says yes.
5. Will it hold up in the workflow?
No document answers this one. Who sees the result, and at what moment? What happens when a call fails? Who checks what your product writes into the chart? This is where clinical knowledge and integration knowledge have to meet. As one reader put it under my post, the real step forward is getting from documentation access to reliable integration.
Read, book, write back: what do the public docs say?
Here’s what each vendor’s public materials showed when we reviewed them in November 2026. It’s a starting point for your questions, not a ranking and not a statement of what’s turned on at any hospital.
| Epic | Oracle Health (Cerner) | MEDITECH | |
|---|---|---|---|
| Read a chart | Patient and clinical read APIs listed, in several FHIR versions (list) | FHIR R4 for patient, provider and system apps. Patient access may be filtered (docs) | Greenfield Workspace test environment: US Core R4, view-only, patient workflows (page) |
| Book an appointment | Appointment.$find and $book listed, STU3 (list) | Create documented for provider and system access. Patient access isn’t listed on that page (docs) | FHIR Scheduling described. Workflows for Expanse customers only (page) |
| Write a note back | DocumentReference.Create (Clinical Notes) listed (list) | Create documented for provider and system access, with different rules for each (docs) | The Greenfield page we reviewed doesn’t describe this. Ask MEDITECH |
A listed API is only the start of the conversation. Which app type can call it, which fields it accepts and whether a given hospital has enabled it all come next. If you’re choosing between launch models, this comparison of SMART on FHIR and backend systems goes deeper, and our guide to integrating an AI agent via FHIR covers read and write-back for AI.
A prompt to try with your own idea
Connect your AI client using Epic’s setup page, then paste this and fill in the brackets. Forward it to your technical co-founder if you’d rather they ran it.
Using only the open.epic documentation:
1. List each API that might support this, with its FHIR version.
2. For each one, say which app or user type it requires.
3. Quote the short passage you relied on and give me the link.
4. List anything a hospital must configure or approve.
5. If the docs don’t answer something, write “not documented”. Don’t guess.
The “not documented” lines are the useful part. That’s your list of questions for an integration engineer, or for the hospital. One commenter said he already points AI coding tools at open API docs to write API tests, a smart next step once you have a shortlist.
When the list gets long, that’s what EHR integration discovery is for: testing those answers against a real environment before anyone signs a build contract.
Waiting feels free. Now you know how to check.
Frequently Asked Questions
What does it cost to wait on Connectors and MCP?
It depends on your team, so count it: documentation hours, rework from limits found late, months spent on ideas that should have stopped, and the monthly cost of old workarounds. Compare starting now with starting when a customer asks.
Should we build an Epic Connector now?
Usually not yet, unless you’re an early adopter. Listings are planned for March 2027 and the standard may change. Use the time for work that keeps its value: your API list, workflow map and hospital answers.
What is the open.epic MCP server?
It’s a public server, announced by Epic in October 2026, that lets AI clients supporting the Model Context Protocol search open.epic content, including API specifications, Data Sharing Playbooks, tutorials and FAQs.
Does the open.epic MCP server give access to patient data?
No. It returns documentation. Epic’s setup page says it isn’t designated to handle PHI or confidential information. Reaching a hospital’s data takes a separate connection that the hospital controls.
If an API is in the documentation, will it work at my hospital?
Not automatically. Availability can depend on the app type, the software version, the hospital’s configuration and its approval. Treat a listed API as a reason to ask, then confirm with the hospital.
Can a physician founder use it without an engineer?
For early research, yes, if your AI client supports remote MCP servers. Use it to sort out which ideas are worth deeper work. Have an integration engineer check the results before you commit to a product plan or a budget.
Is the open.epic MCP server the same as Epic Connectors?
No. The server lets your AI read documentation and is available now. Connectors let Epic’s AI tools work with third-party apps, with listings planned for March 2027 and review by each health system.
Pick your idea and go through the five questions. How many could you answer today?
30 minutes, no pitch deck
This moves fast. Keeping up is our job.
We follow new EHR tooling as it ships, and a small senior team can act on it quickly. Bring your idea and we’ll go through the interoperability it needs. If that turns into a custom build, it’s built for your product and you own what we build.
Sources
- open.epic home page. Epic Systems. Source for the Oct 30, 2026 announcement, “search and interpret” and the playbook count. Reviewed Nov 3, 2026.
- open.epic MCP setup page. Epic on FHIR. Source for what the server returns, “only retrieves content”, guidance and PHI limits. Reviewed Nov 3, 2026.
- open.epic Developer Resources. Epic Systems. Source for the federated model and customer control of connections.
- Explore by Interface Type: FHIR. open.epic. Source for listed read, appointment and clinical note APIs.
- Epic on FHIR documentation. Epic on FHIR. Source for customer-specific values and ID mapping.
- FHIR R4 APIs for Oracle Health Millennium Platform. Oracle. Source for access types and data filtering by domain build.
- Create an appointment. Oracle Health Millennium Platform APIs. Source for authorization types.
- Create a document reference. Oracle Health Millennium Platform APIs. Source for authorization types and provider vs. system rules.
- Greenfield Workspace. MEDITECH. Source for the test environment, view-only US Core R4 and scheduling workflows.
- Promoting Interoperability: Patient Access APIs. MEDITECH. Source for organization review of apps.
- 2026 State of FHIR Report. Firely and HL7. 101 experts in 63 countries, fieldwork February to April 2026. Read as a directional signal, not a census.
- Epic launches Connectors to link its AI tools with third-party apps. Fierce Healthcare, Oct 2026. Source for MCP as the standard at launch, which may change later.
- Epic Opened Its AI Agents to Outside Apps. The Epic Edge, Oct 27, 2026. Source for Connector timing and health system review.
Epic, open.epic and Epic on FHIR are trademarks or registered trademarks of Epic Systems Corporation. Oracle Health and MEDITECH are trademarks of their respective owners. Itirra isn’t affiliated with or endorsed by any of them. Product scope reviewed November 2026 from public materials; an individual hospital’s setup may differ.