Healthcare Analytics Platform

An analytics interface for exploring healthcare datasets: summary views for the shape of a population, over-time views for how it moves, and detail tables for the specific records behind either.

This case study is deliberately about the interface system rather than the medical domain. The engineering (shared pieces, caching, state modelling) is the transferable part.

One dashboard is a week's work. The difficulty is the twelfth, when the product has been answering a growing list of questions about the same underlying data and each answer arrived as a request for another view.

Built the obvious way, that produces a dozen dashboards that look almost but not quite the same: twelve tooltips, twelve legends, twelve slightly different empty states, and a dozen places to fix any given bug. The inconsistency is the visible symptom; the maintenance cost is the real one.

Underneath that sits a subtler problem. The filter surface is wide enough that the same data gets sliced many ways in one session, so caching behaviour is something users feel directly, and absent data is common and meaningful, which means an empty chart is technically true and practically misleading.

Dashboards are built from a few shared pieces rather than from separate code each time. Adding a view means configuring what already exists, which is also why fixing a tooltip or an empty state fixes it everywhere at once.

Each of these solved a real problem and cost something in return. The trade-off is stated alongside the decision, because a decision without one was not really a decision.

A component library is easy to start and hard to get right. Extract too early and you encode assumptions from the only view that exists; extract too late and you are reconciling five implementations that already drifted.

The pieces here came out of the third dashboard, not the first. By then the shape was visible in real usage rather than guessed, and the thing worth stealing from this project is that timing, not the components.

The organising idea is that a dashboard should not contain a chart implementation. What each layer owns follows from that, and so does where the tests are worth writing.

With this many filter dimensions, two identical requests arrive written differently: different key order, different ways of expressing empty, keys that do not affect the result at all. A cache keyed on the raw query misses almost every time, and the user feels every miss.

Adding a dashboard became a matter of composing existing pieces with a data source, which changed the unit of work from weeks to days and kept every view consistent with the others.

The states nobody demos (no data, suppressed, partial) are handled the same way everywhere, which is where analytics interfaces usually lose their users' trust.