How a healthcare network opened up its data without opening up PHI

Self-service healthcare analytics — clinic managers exploring visit volumes, utilization and turnaround times themselves, against views that never contain an identifiable patient.

A practice manager at a growing healthcare network waited three days to find out how many patients hadn't shown up at her clinic the week before.

Nothing in that answer identifies a patient. It is a count. It contains no name, no medical record number, no date of birth, no diagnosis — nothing that any privacy regulation was written to protect. And yet the request went into the same queue, behind the same technical team, governed by the same caution as a request for a patient's chart.

This is the quiet cost of healthcare data governance done at the wrong resolution. The controls are correct; they're just applied to a far wider set of questions than they need to be. Most of what operational staff want to know is about the organization — how it's running, where it's straining — not about anyone in it. Treating both kinds of question identically is what makes a healthcare network data-rich and answer-poor.

This is what one network did about it.

Two kinds of question

The distinction that unlocked the project isn't technical. It's a distinction between the questions people ask.

Kind one

About a person

What is this patient taking? What did their last result show? What's in their history?

• Requires identity to be meaningful
• Answered inside clinical systems
• Access controls exist precisely for these
• Should stay exactly as hard as they are

Kind two

About the organization

How many visits did this clinic take? How long are results taking? Where is capacity tight?

• Identity is irrelevant to the answer
• Answerable from aggregates alone
• No privacy rule is protecting a count
• These are nearly all of self-service demand

Almost every question the operations side of a healthcare network needs answered is the second kind. Almost every access policy is written for the first. That mismatch — not SQL literacy, not tooling — is what produced the queue.

The work was the views, not the AI

The network's first move wasn't installing anything. It was building a layer of de-identified operational views: the shape of the organization's activity, with every identifiable person removed by construction.

What the views carry

• Visit and appointment counts by site, service and period
• No-show and cancellation rates
• Lab turnaround times by test type
• Appointment lead times and capacity utilization
• Staffing and demand, aggregated

What never enters them

• Names, medical record numbers, dates of birth
• Addresses and contact details
• Diagnoses, medications, clinical detail
• Free-text notes of any kind
• Any row resolving to one identifiable person

This is the whole project, and it is unglamorous data modelling rather than anything to do with artificial intelligence. But it changes the nature of the risk: once the self-service layer is granted access to those views and nothing else, opening it broadly stops being a judgement call. There is nothing sensitive behind the door to reason about.

It also, usefully, makes the AI work better. Views built for humans carry business-legible column names and a fixed grain, and generated SQL is measurably more reliable against them than against raw clinical tables with cryptic naming.

The controls that hold the line

Read-only, by database privilege

The workspace connects under a role with write permissions revoked, granted SELECT on the operational views alone. No question a user asks, and no SQL the model produces, can reach a source system or alter a record.

Row-level access by site and role

Each person's identity is set on the database session, and row-level security decides what returns. A practice manager sees their clinic; a regional lead sees their region. Enforced by the database, so it holds whatever query gets generated.

An audit trail that is a record, not a reconstruction

Every question, the SQL it produced, who asked, when, and what returned — logged and exportable. Access logging is a standing healthcare requirement, and far easier to satisfy as a property of the workspace than as an after-the-fact investigation.

What leaves the environment

[State precisely: deployment model, whether schema metadata leaves the environment, whether any PHI can reach a model provider, and whether a BAA is in place. This is the first question a compliance officer asks, and a vague answer undermines everything above it.]

The general argument for putting these controls in the database rather than the application is in our engineering post on production text-to-SQL; we turned it into vendor questions in the buyer's checklist.

What the teams ask now

The question that started it

"Show the number of patient visits by clinic for the past 30 days."

DBx Studio generates the query, runs it read-only against the permitted views, and returns the result with a visual summary beside it. The SQL stays visible, so the analytics team can check the logic behind anything that will inform a decision — and save the good ones as named templates that anyone can re-run.

Where this goes wrong

The approach is not difficult, but it fails in predictable ways. Each of these is worth checking before a pilot rather than after one.

Skipping the views and writing a policy instead

Granting self-service access to clinical tables and relying on a rule that says don't look. Every new user reopens the access question, and the compliance conversation never ends. Build the views; the architecture should make the policy unnecessary.

Entitlements that live in institutional memory

Row-level security needs a rule to encode. If who-sees-what is something three people know and nobody has written down, that is the first project, not a detail of this one.

Involving compliance after the pilot

In healthcare this is the difference between a six-week rollout and a six-month one. Their requirements are almost always satisfiable and always cheaper to design for than to retrofit.

Nobody reviewing the queries that matter

Every tool in this category is sometimes wrong, and a wrong operational number is plausible and well-formatted. Without someone reviewing the queries behind consequential decisions, errors accumulate quietly. A named, verified query library is what makes that manageable.

Letting the views drift

Source systems change. Views built once and never maintained go quietly stale, and stale views are worse than no views, because people trust them. Whoever owns the view layer owns it permanently.

The takeaway

The case for restricting healthcare data access is real. It just gets applied to a far wider set of questions than it was written for — including a great many that are simply counts. Separate the question about a person from the question about the organization, put a view between them, and self-service stops being a compliance risk. It becomes what it should always have been: the fastest way for the people running clinics to see how the clinics are running.

See it against your own schema

The most informative pilot is a narrow one: build the de-identified operational views for a single service line, bring ten questions your managers ask every week, and count how many come back right.

Query it. Analyze it. Visualize it. — all with DBx.