What Read-Only Means in Practice: A Plain-English Guide for CIOs Approving Analytics Connectors

“Read-only” is the load-bearing phrase in every analytics connector pitch. A CIO who approves a read-only integration is approving something fundamentally different from one that could write to the chart. Here's what “read-only” should mean in practice — and what to ask the vendor to make sure their promise matches their architecture.

The credential-scope test

Read-only is enforced at the credential level, not the application level. A SQL credential with SELECT permission and no INSERT/UPDATE/DELETE. A FHIR OAuth client registered for read scopes only. A REST API token bound to GET endpoints.

Ask the vendor: “What permission set does the credential actually have on the source EHR?” If the answer is anything other than “read-only by grant,” you don't have a read-only integration. You have a vendor promise.

The Epic-specific version

Inside Epic, “read-only” can refer to several different surfaces:

• FHIR R4 with read scopes — the OAuth client is registered for patient/*.read or system/*.read scopes and cannot acquire write tokens.
• Clarity SQL with a read-only role — Microsoft SQL Server role membership grants SELECT only against the Clarity schema.
• Cogito / Caboodle read access — analytics platforms reading the data warehouse, not the production OLTP schema.

Any of these is a legitimate read-only integration. The combination of FHIR + Clarity (which Vizier uses) covers most analytics use cases without ever touching the live operational schema. See the Epic-to-Vizier guide.

The Cerner / Oracle Health version

Cerner's analogous surfaces:

• CCL service account with read-only schema membership.
• HealtheIntent OAuth client registered for read scopes.
• FHIR R4 endpoints on Millennium with read scopes.

The questions IT should ask every analytics vendor

1. Show me the IAM policy on the credential you use. Is SELECT the only permission granted?
2. If the credential is compromised, what's the maximum blast radius? Can it modify a chart? An order? A bill?
3. How do I revoke this credential in production? What's the runbook?
4. Show me the audit log. Every query Vizier issues should be logged with timestamp, account, source IP, and result row count.
5. What about the vendor side? Once data leaves Epic, who else at the vendor can see it? Is there an internal audit log on the vendor side too?

The non-technical question that matters

Beyond the credential model, ask: “If we cancel this contract in six months, what happens to the data?” A read-only connector that doesn't take an exit clause seriously isn't actually read-only in spirit — the vendor still holds copies. Vizier's standard contract includes a 30-day deletion warranty after cancellation, with audit confirmation.

Why this matters in 2026

Two pressures are converging. CIOs are more comfortable approving read-only API access than they were five years ago — the model is well-understood. They are also more skeptical of vendors that wave the “HIPAA compliant” badge without showing the underlying controls. The gap between “read-only” as a marketing claim and “read-only” as an enforceable credential is the gap that distinguishes mature analytics vendors from immature ones.

See Vizier's security page for the controls, and the HIPAA audit most vendors quietly fail for the underlying audit framework.