Our data is rich. Access to it is not.
The data team fields ad-hoc requests manually — slowly, inconsistently, at the cost of their actual pipeline work. Our BI tooling has grown into a maze most people cannot navigate.
57 Looker dashboards — no usable directory
Limited to 10 rows, no scrolling — no one can find anything without already knowing where it is
No source of truth for revenue
WBR numbers diverge from the Finance dashboard — teams cannot reconcile their own data
Revenue attribution is undocumented
BD vs KAM split not written down anywhere — team-level reports require reverse-engineering the data
Data team is a bottleneck
Every ad-hoc request handled manually — slowly and at the cost of their actual pipeline work
Partner and leadership questions wait days
Member populations, consult rates, revenue by insurer — requires significant manual effort across multiple people
Known data issues sit unresolved
Data quality problems and pipeline gaps have no clear owner and no fix timeline
Fix the internal problem. Build a commercial asset.
This is not just internal tooling. The same infrastructure that answers the team's questions can power client-facing dashboards — with direct revenue implications.
Team gets answers in seconds
- Plain-English questions — no Looker, no SQL, no ticket raised
- Single source of truth — the "which dashboard?" problem eliminated
- Data team freed from ad-hoc requests, focused on pipeline work
- Partner and leadership questions answered in minutes, not days
Client dashboards without custom builds
- Insurers and corporates get scoped views of their own population data
- Same engine, scoped per account — no bespoke engineering per client
- Faster time to value and a potential standalone revenue line
- Meaningful differentiator in B2B enterprise sales
All data stays within Good Doctor's own infrastructure. No healthcare or commercial data touches any external platform. No per-query cost — fixed infrastructure, unlimited use.
Five components, all self-hosted
No data leaves Good Doctor's infrastructure. No external services in the data path.
Existing. Read-only credentials scoped to approved tables. Nothing changes warehouse-side.
Ollama + Qwen2.5-Coder 14B. Purpose-built for SQL generation, leads open-weight benchmarks. Swappable via config — no lock-in.
Python API. Question → schema injected → SQL generated → validated (read-only only) → executed → result returned.
Chat UI for team Q&A. Dashboard engine: scheduled queries cached locally, instant page loads. Both served from the same box.
Ad-hoc question flow
Team member
types question
Schema injected
+ sent to Ollama
SQL generated
+ validated
Executed on
warehouse (read-only)
Results
displayed
Two steps to get there
Automate what we do today — export key tables on a schedule, run questions against flat files. A minor but immediate improvement on today's slow, manual, ad-hoc process. No infrastructure decisions, no blockers. Data is hours old and complex joins won't work. This is a bridge only, not the destination.
Dedicated Hardware
- GPU-capable machine on the office network
- Predictable, fast performance on 14B+ models
- No IT dependency — operational without waiting on server access
- If GD Servers later confirms specs: hardware becomes dev/backup
GD Servers
- Deploy on an existing GD VM — no new hardware cost
- Lives inside GD infrastructure — clean for IT governance
- Requires Julian to confirm: server specs, GPU availability, access path
- CPU-only inference is slow for 14B models — performance risk without a GPU
Recommended Phasing
Deliver value at every step. Each phase builds on the last.
| # | Phase | What it delivers |
|---|---|---|
| 1 | Quick Start | Automated snapshots replace the manual process. Team can ask questions immediately. No infrastructure decisions needed — start this week. |
| 2 | Live Query Engine | Live data, full query engine, chat interface for authorised team members. Phase 1 retired. Hardware procured or server access confirmed. |
| 3 | Client Dashboards | Scoped views per insurer or corporate client. No bespoke engineering per client. Same engine, scoped by account. Commercial upside unlocked. |
| 4 | GD Servers (if confirmed) | Migrate to GD infrastructure once Julian confirms server specs. Dedicated hardware becomes the dev and backup environment. |
recurring cost
queries, no per-use cost
data leaves GD infrastructure
What We Need to Proceed
Phase 1 starts today — no blockers. Everything below is required for Phase 2 (live queries).
| Item | Owner | Why it's needed |
|---|---|---|
| Warehouse type confirmed | Julian | Determines the DB connector — BigQuery, Postgres, and MySQL each connect differently to the query engine. |
| Schema documentation | Julian / Data team | Table names, columns, key relationships. Without this, SQL generation quality will be poor. A rough export is enough to start. |
| Read-only credentials | Julian | Scoped to approved tables only. The query engine executes SELECT only — no write operations possible by design. |
| Server specs (for GD Servers option) | Julian | CPU, RAM, GPU. Determines whether existing servers can run inference at useful speed, or dedicated hardware is the right path. |
| Hardware approval (Dedicated Hardware) | Julian | Assess one-time hardware cost (~$1,000–1,500) against the GD Servers option once server specs are confirmed. |
Phase 1 blocker: none. Manual exports from anyone with current warehouse access are sufficient to start this week.