Short answer: If your company holds protected health information on behalf of health plans, provider groups, or other clients, you can give those clients self-service dashboards and ad-hoc reports under your own brand, as long as four things are true. Every query is filtered by tenant at the server, not in the report. Each client sees a curated data model, not raw tables. The features that would let a client user see behind the curtain are switched off. And the platform runs under a Business Associate Agreement on infrastructure that serves only you. This post walks through each, using a real deployment that replaced pre-built spreadsheet exports for more than 400 client organizations.
The problem: spreadsheets out, questions in
Most healthcare data services companies start the same way. Clients need to see the results of the work you do on their data, so someone builds a nightly job that produces a set of spreadsheets per client and posts them to a portal. It works. Then the questions start: can we get this by month, can we filter to one facility, can we add the field your analysts use, can we see it as a chart. Each request becomes a ticket, a developer change, and a new file in the nightly job. The portal fills up with variations, the clients keep asking, and a growing share of your engineering time goes to reporting instead of the product.
The obvious next step is dashboards. The obvious tool is whichever BI product your team already knows. And that is where the project usually stalls, because general-purpose BI tools were built for analysts inside one company, not for hundreds of outside organizations that must never see each other's data. The per-seat pricing doesn't fit thousands of occasional client users. The branding is the vendor's. Row-level security exists but is configured per report and per user. And the vendor may not sign a Business Associate Agreement, or only at a price that ends the conversation.
A worked example
The deployment below is a DashboardFox customer we can describe but not name: a healthcare data services company that analyzes clinical and claims data on behalf of health plans and provider organizations, with more than 400 client organizations, many of them heavy users of the reporting.
Their previous solution generated pre-built spreadsheets that clients downloaded from a portal. It answered the standard questions and nothing else. They were evaluating Power BI for dashboards when they reviewed DashboardFox, and they chose it for three reasons that had nothing to do with charts: it passed their security review, it could be deployed on a server dedicated to them under a signed BAA, and it let their clients build their own reports without exposing the underlying data model.
Today each client logs into a portal on the company's own domain, with the company's logo, colors, and terminology. They see dashboards, which the spreadsheet portal never had. They open a curated data model and build their own reports with a drag-and-drop composer, schedule them by email, or export them. And no client can see another client's rows, because the filter is applied by the server to every query based on who is logged in.
The four things that make it safe
1. Tenant isolation at the query level
The mechanism that makes multi-client reporting work is row-level security tied to a tenant identifier. In DashboardFox this is done with data tags: each user carries a profile tag such as a client ID, and a data security policy tells the server to append the matching condition to every query that user runs against tables carrying that tag. The user never sees the filter, cannot remove it, and cannot reach the underlying dataset through another route. A client who builds a brand-new ad-hoc report from scratch still gets only their own rows, because the constraint lives below the report.
This is different from the approach several tools take, where each dashboard is filtered per user or per copy, and the vendor's own documentation warns not to rely on that filtering for security. For PHI across hundreds of tenants, the filter has to be a server-side policy, or it is not a control.
2. A curated data model instead of raw tables
Self-service does not mean giving clients your schema. DashboardFox sits a semantic layer, called an App, between the database and the report builder. You decide which tables and views are in it, how they join, which fields appear and under what names, and which fields are hidden. A client building a report in the Composer picks from "Member," "Visit Date," "Facility," and "Diagnosis Category," not from column names, and never from tables you did not expose. The App is where minimum-necessary gets enforced: a client can explore freely inside a model that contains only what they are entitled to see.
Field-level security adds a second layer. Within an exposed table, individual fields can be hidden from particular groups, so an identifier that internal analysts need can be invisible to client users.
3. Hiding what clients should not see
White-label is usually described as logos and colors, and it is that: custom domain, logo, palette, login page, email templates, and a phrase manager that renames product terms to the ones your industry uses. But the part that matters for client-facing PHI reporting is what white-label lets you remove. In this deployment, the client-facing branding policy hides:
- The vendor's support links and help content, so clients contact you, not us
- The ability to view the SQL behind a report, which would reveal table and column names
- Report library metadata such as author, creation date, and modification time, which can leak internal names and workflow
- Administrative and configuration features that have no place in a client's hands
Branding policies apply per group, so internal analysts and client users can share one platform with different experiences. The default should be to expose the smallest feature set that lets a client answer their own questions, and to add features only when a client asks for one you are comfortable with.
4. Dedicated infrastructure under a BAA
Everything above is application design. The fourth requirement is where the application runs. This customer's environment is a dedicated server and a dedicated PostgreSQL database that serve their organization alone, provisioned by us, in a US region that is a HIPAA/HITECH-attested facility. They evaluated on-premise first and chose the dedicated cloud because it gave the same single-tenant isolation without waiting for internal server provisioning. We operate it as their business associate under a signed BAA, with BAAs in place with our own hosting and backup providers before any PHI was provisioned, database audit logs retained for six years, and the arrangement backed by a standalone $5 million cyber liability policy.
The BAA question deserves a direct answer from any vendor you evaluate: will they sign one, on which plan, and is your data on shared or dedicated infrastructure? Our comparison of which BI tools sign a BAA covers the major vendors.
What changed for the business
| Before | After |
|---|---|
| Pre-built spreadsheets generated per client and downloaded from a portal | Clients log into a branded portal and run reports on demand |
| Every new question became a development ticket | Clients build ad-hoc reports themselves from a curated model |
| No dashboards or visualizations | Dashboards and charts, which the company had been evaluating Power BI to provide |
| Delivery was a file; freshness was whenever the job ran | Live queries against the source data, with scheduled email delivery for clients who still want a file |
| Isolation was "each client gets their own files" | Isolation is a server-enforced policy on every query, by tenant ID |
| Per-seat BI pricing would have charged for every client user | Flat pricing for a dedicated environment, unlimited active users within capacity |
A checklist for your own deployment
| Decision | What to settle before you build |
|---|---|
| Tenant key | Which field identifies a client in every table you will expose? It must exist, be reliable, and be stamped on the user's profile. |
| Data model scope | Which tables, views, joins, and fields belong in the client-facing App? Start small; add on request. |
| Internal vs. client groups | One group per client, plus internal groups with wider access and a different branding policy. |
| Feature exposure | Which Composer and library features clients may use. Hide SQL view, metadata, admin, and vendor support links by default. |
| Delivery | Which clients want scheduled email or export, and through whose mail server. Use your own SMTP so PHI never transits shared mail infrastructure. |
| Environment | Dedicated server and database, BAA executed, sub-processor BAAs confirmed, audit retention set to six years. |
| Onboarding | A repeatable script: create group, assign profile tag, assign App role, apply branding policy, test with a client-role account before go-live. |
How DashboardFox is built for this
DashboardFox is our product, and this use case is one it was designed around. Row-level security with data tags, field-level security, the App semantic layer, the Composer, per-group branding policies, custom domains, phrase management, and scheduled delivery are included on every plan. Client-facing deployments with PHI run on Enterprise Dedicated Cloud, from $1,499 per month billed annually, where we sign a Business Associate Agreement with the Compliance Tier. Self-hosted is available for organizations that must keep everything in-house, in which case no BAA from us is needed because we never have access to the data.
Compare deployment options → · What to require from a cloud BI vendor for PHI → · Security review kit → · Talk to an engineer about client reporting →
Frequently asked questions
Can clients build their own reports without seeing other clients' data?
Yes, if row-level security is a server-side policy tied to a tenant identifier on the user's profile. Every query the client runs, including brand-new ad-hoc reports, carries the filter, and nothing in the report builder can remove it.
Do we have to copy PHI into the BI tool?
Not with DashboardFox. It queries your database in place and stores only report definitions and metadata. Your PHI stays where it already is, under controls you already audit.
What should we hide from client users?
At minimum: the vendor's support and help links, the ability to view a report's SQL, report library metadata such as author and timestamps, and any administrative features. Expose the smallest feature set that lets a client answer their own questions.
Is a dedicated environment required for client-facing PHI reporting?
HIPAA does not require it, but it simplifies the risk analysis and most security reviewers prefer it. DashboardFox signs a BAA only on its dedicated Enterprise tier for that reason.
How is this priced compared to per-seat BI tools?
Per-seat tools charge for every client user who logs in, which makes hundreds of client organizations expensive fast. DashboardFox Enterprise Dedicated Cloud is a flat annual fee for a dedicated server, with unlimited monthly active users within server capacity and fair use.
The deployment described is a real DashboardFox customer that has asked not to be named. Details have been generalized; nothing in this post identifies the organization or its clients. This post is not legal advice.