Connecting Epic to a Third-Party Analytics Platform: The IT Conversation That Actually Works

Why most pitches fail

The pattern is consistent. A quality director, CFO, or service-line lead identifies an analytics platform that solves a real problem. They schedule time with the CIO. The pitch goes something like, “We need to connect this tool to Epic so we can run our own MIPS reports / readmission analytics / denial analysis. The vendor says it's easy. Can we get it done?”

The CIO has heard this a dozen times. They have a stock answer that protects the organization without saying yes or no: “Let me look into it. We'll need to involve security, the Epic team, and procurement.” Three months later the request is still in the queue, and the requester has either given up or built a manual workaround using SlicerDicer exports.

The CIO is not being obstructionist. They are processing the request through a security and stability lens that the requester is not addressing. To get past that lens, you need to walk in with answers to four specific questions, in the language IT uses.

The four questions IT actually evaluates

Every Epic integration request gets scored against these, whether or not the CIO articulates them out loud:

1. Authentication model. How does the external platform identify itself to Epic, and can that credential be revoked instantly if needed?
2. Read vs. write scope. Does this thing only read data, or could it write back to the chart, modify orders, or affect clinical decision support?
3. PHI flow and residency. Where does PHI go after it leaves Epic, who else touches it, and which jurisdiction stores it?
4. Failure mode. If this connection breaks, does Epic stay up? Does the vendor lock us into a multi-year contract before we know whether it works?

If your pitch covers all four in the first meeting, you move from the “evaluation” queue to the “technical review” queue. That's the goal.

Authentication: which Epic surface, which credential

Epic exposes several integration surfaces, each with its own authentication model. The right one depends on what data you need.

• FHIR R4 — the modern API for clinical data (problems, medications, encounters, results, observations). Authenticated via OAuth 2.0 client credentials registered through Epic's App Orchard (now “Showroom”) program. This is the path most net-new vendor integrations follow today.
• Clarity — Epic's relational reporting database (SQL Server). A read-only SQL credential, allowlisted to a specific IP range, gives a connector access to historical encounter, billing, and operational data. Most large IDNs already maintain Clarity for internal reporting; granting one additional read-only credential is a small operational lift.
• Caboodle — Epic's data warehouse, optimized for analytics workloads. Same authentication model as Clarity (SQL credential) but better suited to large-scale historical queries.
• Reporting Workbench / SlicerDicer — user-facing report exports. No external credential — the user runs the report and exports a CSV. Useful for proof-of-value before you ask for a permanent connector.

When the CIO asks “how does the vendor authenticate?” the answer they want is one of those four, not “through their software.” If the vendor cannot tell you which surface they consume and which credential type they need, you have a vendor problem, not an Epic problem.

Read-only is the only acceptable answer

The single fastest way to move a request through IT is to be able to say, in writing: “The connector has read-only scope. It cannot write to the chart, modify orders, change clinical decision support rules, or trigger any user-facing workflow inside Epic.”

This sentence accomplishes two things. First, it removes the worst-case patient-safety scenarios from IT's mental model. Second, it limits the SOC 2 / HITRUST scope of the integration to data access controls — which are well understood and auditable — rather than clinical write paths, which are not.

A FHIR client registered for read scopes only, or a SQL credential with SELECT permission and no INSERT/UPDATE/DELETE, is a structurally safer integration than a vendor saying “don't worry, we won't write to it.” The grant of permission is the boundary, not the vendor's promise.

PHI flow and residency: where does the data live after it leaves Epic?

CIOs will ask a version of: “After Epic sends data to your platform, where does it go, and who else touches it?” The right answer has four parts.

1. Encrypted in transit (TLS 1.3) from Epic to the vendor's ingest endpoint.
2. Encrypted at rest (AES-256) in the vendor's data store.
3. Stored in a specific cloud region you can name (e.g., AWS us-east-1, Azure UK South).
4. Not shared with sub-processors except those listed in a published sub-processor schedule, with BAAs in place.

If the vendor cannot answer all four, the integration will not pass security review at any health system above the small-practice tier.

Failure mode: what happens if it breaks?

The CIO's implicit risk model is: “If this thing fails, what's my downside?” The answer they want is “the analytics layer goes dark, Epic keeps running, and we can revoke the credential in 60 seconds.”

That answer requires three properties of the integration. First, the connector reads from Epic but does not push state back into Epic. Second, the credential is scoped narrowly enough that revocation is a one-click operation in the Epic admin console. Third, the contract has an exit clause that does not penalize the customer if the connector is removed.

Long contract commitments before pilot completion are the single most common reason CIOs decline new integrations. A flat-fee monthly subscription with a 30-day cancellation right is a far easier ask than an annual commitment with provisioning fees.

The proof-of-value path that almost always works

The pattern that gets Epic integrations approved fastest:

1. Start with a manual export. Pull a SlicerDicer or Reporting Workbench export, upload it to the analytics platform, and demonstrate the answer to the question that motivated the project. This requires zero IT involvement.
2. Show the proof to IT. “This took twenty minutes with a CSV. We want to make it automatic with a read-only Clarity credential or a FHIR client. Here are the security answers.”
3. Move to a scheduled feed. If the FHIR / Clarity request needs more time to clear, an interim step is to schedule a Reporting Workbench export to SFTP nightly. This requires no new credentials and gives you 95% of the value.
4. Graduate to direct connector. Once the team trusts the output, the read-only API connector is a final upgrade for refresh cadence and reduced manual operations.

The Vizier-specific version

Vizier supports all three integration patterns into Epic — direct connector via FHIR R4 + Clarity, scheduled Reporting Workbench feed to SFTP, and manual SlicerDicer / CSV upload. We publish the security answers above before the security review meeting, not after. BAA executed in one business day. Read-only scope baked into the credential type, not promised in marketing copy.

If you're trying to get Vizier (or any analytics platform) connected to Epic and the IT meeting hasn't happened yet, the four questions above are the meeting prep.

Related

• Epic-to-Vizier: three integration paths in detail →
• All Vizier EHR connectors →
• Vizier security & HIPAA →