AccAnalysisAccAnalysis
Revenue Cycle & Financial Operations

The reports clients kept asking for, available before they ask

Healthcare clients had no secure way to see their own collection performance, so every question became an email and a manual export. We built a multi-tenant analytics portal with tenant-level isolation and full audit logging.

At a glance
Status
Delivered
Region
United States
Engagement model
Dedicated team

Status: Delivered. Described from our own delivery records. Client identity, brand and commercial terms are withheld. Figures, where given, cover the period stated and nothing beyond it.

The organisation

Context

A revenue-cycle operation serving healthcare provider organisations. Its clients wanted to see performance, payment and recovery data about their own accounts.

There was no mechanism for that, so the demand landed on an internal analytics team as a stream of individual requests — several a day, answered same-day at best, each one a manual export.

The brief

The problem

  • Client visibility depended entirely on someone building a spreadsheet on request.
  • The turnaround was a day at best, which made the data too old for some decisions.
  • A dedicated analytics team's capacity was being consumed by repeat requests rather than analysis.
  • Data covering multiple healthcare clients sat in one estate, so any self-service access had to guarantee isolation before it could be offered at all.
  • Regulated data meant access needed to be evidenced, not just controlled.
The work

What we built

A multi-tenant analytics portal

Eleven interactive data pages covering collection performance, payment data and account-level reporting.

Tenant-level data isolation

Enforced at the platform layer, so a client can only ever resolve their own data, with role-based access control within each tenant.

One-click exports to spreadsheet

Because the honest reality is that some users will always want the data in their own hands.

Full audit logging

Of access and activity, with session security appropriate to regulated healthcare data, deployed on a private network.

Method

How we delivered it

  1. 1

    Define the questions first

    The twenty or so things clients were actually emailing to ask, which became the page structure.

  2. 2

    Model the data

    So each metric has one definition and traces back to source.

  3. 3

    Build isolation and access control before the pages

    Since retrofitting tenancy is the failure mode here.

  4. 4

    Page by page

    Reviewed with internal account teams who knew what clients meant.

  5. 5

    Pilot with a small group of clients

    Then extend.

Sequence

How it was phased

PhaseDurationWhat happens
1Requirements from real requests
2 wks

The recurring questions, turned into a page map

2Data modelling
3–4 wks

Metric definitions, lineage, warehouse layer

3Tenancy & access control
2–3 wks

Isolation, RBAC, session security, audit logging

4Portal build
5–7 wks

Eleven interactive data pages, exports

5Pilot & extension
3–4 wks

Small client group, then wider release

Indicative phasing for work of this shape. Actual duration varies with data quality, access and decision speed.

Hand-over

What the client keeps

  • The portal and its source
  • The data model and metric dictionary
  • Tenancy and access configuration
  • Audit-log structure
  • Deployment documentation
Stack
PythonSQLPower BIPrivate network deploymentRole-based access control
Keep reading

Related

Related case studies

Tell us what your current system can't do, and we'll tell you what it would take to change that.