Epic integrations, FHIR APIs and TEFCA connectivity
Cohash builds and governs the integration layer around Epic for health systems. We catalog HL7 v2 interfaces, build FHIR R4 and SMART on FHIR integrations through Epic's developer program, review OAuth scopes for every third-party app, and support TEFCA exchange through your QHIN. We work alongside Epic and your analysts, with identity, interface monitoring and EHR data feeds to analytics in the same plan.
- 01Interface and app inventory
- 02App intake and scope review
- 03Build and test FHIR integrations
- 04TEFCA and payer API exchange
- 05Monitor and hand over
The story
Told without the client's name or anything that could identify them.
A health system's integration team had HL7 v2 interfaces that backed up overnight, third-party apps connected to Epic by individual departments, and no register of the scopes those apps held. Payers were preparing CMS-0057-F prior authorization APIs, and nobody owned the TEFCA exchange purposes the organization had signed up for. We started with a catalog of every feed, FHIR client, SMART app and HIE connection, with an owner and failure procedure for each. From there we set up one app intake path with scope review, built new FHIR R4 integrations against Epic's sandbox, and added queue and error alerts that reach on-call staff.
why it was urgentThe first TEFCA QHINs were designated in December 2023, and Epic Nexus is on the RCE's list. Under CMS-0057-F, impacted payers generally have to offer Provider Access and Prior Authorization APIs from 1 January 2027, which gives providers new FHIR endpoints to call. In the meantime, app and AI vendors keep asking for FHIR access.
- openDepartments connect third-party apps to Epic and nobody keeps a register of granted scopes.
- recurringHL7 interfaces back up overnight and clinicians notice missing results before IT does.
- blockedNobody owns the TEFCA exchange purposes your organization has signed up for.
- openAnalytics teams wait for EHR extracts that one analyst builds by hand.
- recurringPayers are about to offer prior authorization APIs and nobody has planned the Epic side.
The estate, before and after
Before: point-to-point HL7 feeds and unreviewed app access
Departments connected third-party apps to Epic with scopes nobody tracked, and HL7 v2 interfaces backed up without alerts. Analytics waited on extracts built by hand, and HIE exchange had no clear owner.
Read the diagram as text
- Third-party apps → Epic: untracked scopes
- Epic → HL7 v2 interfaces: ADT · orders · results
- HL7 v2 interfaces → Lab and ancillary systems: HL7 messages
- Epic → Manual extracts: ad hoc extract
- Manual extracts → Analytics: files
- Epic → HIE connections: exchange
After: governed Epic FHIR APIs, TEFCA and monitored interfaces
Apps reach Epic's FHIR R4 APIs only through one intake path with scope review. TEFCA exchange runs through the QHIN with confirmed purposes, payer FHIR APIs are planned into clinical and revenue cycle work, and interfaces send queue and error alerts to on-call staff.
Read the diagram as text
- SMART on FHIR apps → App intake and scope review: registration request
- App intake and scope review → Epic FHIR R4 APIs: approved scopes
- App intake and scope review → Interface and app catalog: register client
- Payer FHIR APIs → Epic FHIR R4 APIs: payer data to clinicians
- QHIN for TEFCA → Epic FHIR R4 APIs: TEFCA exchange
- HL7 v2 interfaces → Interface monitoring: queue metrics
- Epic FHIR R4 APIs → Analytics: EHR data feeds
How we run it, phase by phase.
5 phases take you from Point-to-point HL7 feeds and ad hoc app access to Governed Epic FHIR APIs and TEFCA exchange. Each one ends with something you can check before the next starts. As you scroll, the blocks show the estate moving across.
- phase 01
Interface and app inventory
Every HL7 v2 feed, FHIR client, SMART on FHIR app, file extract and HIE connection goes in the catalog. For each we note the owner, message types and scopes, and what to do when it breaks.
- phase 02
App intake and scope review
We set up a single intake path: security and privacy review, a scope checklist per app type, a register of every registered client. Scopes that existing apps never touched get revoked.
- phase 03
Build and test FHIR integrations
Build against Epic's sandbox and FHIR R4 resources first, test with real message samples and clinical users, then move through production registration.
- phase 04
TEFCA and payer API exchange
Confirm the exchange purposes you support through your QHIN, then plan how payers' Provider Access and Prior Authorization APIs get to clinicians and revenue cycle staff.
- phase 05
Monitor and hand over
Add queue depth and error alerts on interfaces routed to on-call staff, and write runbooks for the failures that recur.
What the client got
What changed for the client once the work was done. Described, not scored: we don't publish client figures.
- result 01
Every interface and app has an owner
We catalogued every HL7 v2 feed, FHIR client, SMART on FHIR app, file extract and HIE connection, each with an owner, message types, scopes and a failure procedure.
- result 02
Third-party apps get scopes through one intake
New apps now pass security and privacy review against a scope checklist for their type. We also revoked the scopes existing apps had but never used.
- result 03
Interface failures reach IT before clinicians notice
On-call staff get the queue depth and error alerts. Any failure that recurs has a runbook.
- result 04
TEFCA and payer APIs have a plan and an owner
We confirmed which exchange purposes go through the QHIN and planned how payers' Provider Access and Prior Authorization APIs reach clinicians and revenue cycle staff.
- result 05
New FHIR integrations follow a tested path
We built new integrations in Epic's sandbox against FHIR R4 resources. Real message samples and clinical users tested them, and only then did they go through production registration.
Risks we plan for
-
Over-broad FHIR scopes
Apps approved with more scopes than they need expose patient data that was never in scope for their use case. We review every scope against the app's job.
-
PHI in test environments
Copying production data into development is a familiar HIPAA problem. We default to de-identified or synthetic data, and every exception has a person's name on it.
-
Interfaces with no owner
Feeds built by departed analysts fail quietly. Each interface needs a named owner, an alert threshold and a runbook.
-
Splitting work badly with the vendor
If Cohash and Epic services overlap, you pay twice and support doesn't know who to call. So the split between Epic, your analysts and us is written down on day one.
Where AI helps, and where it needs guardrails
Epic's own AI covers clinicians (Art), patients (Emmie) and revenue cycle (Penny), and Epic describes Agent Factory for building and monitoring agents. Outside AI tools usually arrive as FHIR clients or MCP servers wrapping FHIR. We treat each one like any app: its own client registration, minimum scopes, patient-context limits and audit logs, reviewed by security and privacy before go-live.
forward deployed engineers →What you're left with
We write these for your setup, and they're working documents. Your team should be able to keep things running from them long after we've gone.
- inventory01
Interface and app catalog with owner, scopes and failure procedure
yours to keep - document02
FHIR app intake process with a scope checklist per app type
yours to keep - design03
FHIR and SMART on FHIR integration designs with registration steps
yours to keep - code04
TEFCA exchange purpose and payer API readiness review
yours to keep - runbook05
Interface monitoring alerts and runbooks
yours to keep
Platforms and services on this move
Certified engineers, wherever you need them.
Some clients want a project team, some want a couple of engineers on theirs. Either works. Onsite, nearshore or offshore, with handovers across time zones that keep things moving.
Onsite
Engineers at your sites in the US
Nearshore
Overlapping hours with US teams
Offshore
Overnight progress on your backlog
All time zones
Coverage handed over across time zones
01Do you implement Epic?
No. Epic and your own analysts lead the implementation. We work on what surrounds it: integrations, FHIR apps, data feeds, identity and support. We can also place analysts and integration staff.
02Which FHIR version should new integrations target?
Epic on FHIR lists R4, STU3 and DSTU2, and new work normally targets R4. Support for individual resources and scopes varies, so we check every resource your app needs against Epic's documentation before building.
03Do we need to do anything for TEFCA if Epic is our QHIN connection?
Usually, yes. You still decide which exchange purposes to support, how requests get answered, and how consent and patient matching work. We go through those settings and the workflows behind them with your team.
04How do we let AI tools use Epic data safely?
Register them like any other FHIR client, with the narrowest scopes that work, patient-context limits and audit logging. Security and privacy review each one before production.
Often on the same roadmap
On-premises Active Directory to cloud-first Microsoft Entra ID
We shrink on-premises Active Directory one application at a time, moving groups, users and app authentication to Microsoft Entra ID as each app is ready.
read the case studyAD FS federation to Entra ID authentication
Converting federated domains from AD FS to Entra ID cloud authentication, moving relying parties app by app and retiring the AD FS farm.
read the case study
Apache Airflow 2 to Airflow 3
Upgrading self-managed Apache Airflow 2, now past end of life, to Airflow 3, and fixing removed features, auth and scheduling changes before DAGs move.
read the case study0376fd21 - 01ASTP/ONC: Trusted Exchange Framework and Common Agreement (TEFCA)healthit.gov ↗
- 02The Sequoia Project (RCE): Designated QHINsrce.sequoiaproject.org ↗
- 03Epic on FHIR: developer resource (R4, STU3, DSTU2)fhir.epic.com ↗
- 04Epic on FHIR: OAuth 2.0 and SMART on FHIR launchfhir.epic.com ↗
- 05CMS: Interoperability and Prior Authorization Final Rule (CMS-0057-F) fact sheetcms.gov ↗
- 06Epic: Real results, right now, how Epic AI is reducing costs (10 Mar 2026)epic.com ↗
Planning this move?
A 30-minute working session with a senior engineer. No slides.
- The platform and the version you're on
- Where you need to get to, and by when
- What's custom: rules, plugins, integrations
- Any audit finding or deadline driving it