A dashboard can make a digital health rollout look more certain than it is.
Counts rise, charts turn green and activity is summarised into a single adoption number. But a service can have registered users without meaningful engagement, trained staff without a workable onboarding route, and alerts without a reliable response process.
The purpose of live-service data is not to decorate a status report. It is to help a team see where reality differs from the operating model and decide what to do next.
Separate the stages of adoption
I built and iterated Power BI and operational reporting around onboarding, retention, engagement and alert response. One of the most useful choices was to avoid treating adoption as a binary state.
Someone might be:
- identified as potentially suitable;
- confirmed as clinically suitable;
- not yet contactable;
- contacted but undecided;
- interested but blocked by access;
- onboarded but not submitting regularly;
- engaged over time;
- disengaged and in need of follow-up.
Each stage suggests a different intervention. Combining them into one total hides the point where the journey is failing.
Look for operational signals
Useful reporting helped us ask practical questions. Which teams had a strong candidate list but low contact rates? Where were people onboarding but dropping away? Which users were consistently engaged? Were alerts being reviewed in the way the service expected? Was a technical issue concentrated in one environment or visible across sites?
The answers informed contact priorities, implementation conversations and product work. They also exposed gaps in the process itself - for example, where ownership was unclear or data exports depended on a fragile manual step.
The most valuable metric was often not the largest number. It was the number that pointed to an action.
Pair quantitative and qualitative evidence
Service data can locate a pattern, but it cannot always explain it.
Low engagement might reflect technical performance, a change in someone’s circumstances, an unclear expectation, anxiety about the tool or a contact route that never worked. Interviews and frontline conversations add the context needed to choose a proportionate response.
In one long-term user interview, someone who had submitted consistently for almost a year described serious app-loading delays. Their persistence made aggregate engagement look healthy, but the conversation revealed product friction and a need for better access to their own data.
Neither the metric nor the interview was sufficient alone. Together they produced a much more useful picture.
Report honestly
Data-led delivery sometimes means saying that the numbers do not support the preferred narrative. That is especially important in early implementations, where small samples and rapidly changing processes can make confident conclusions tempting.
I try to distinguish operational evidence from evaluation evidence. A two-week navigator test can show that a new approach is workable and worth developing; it cannot prove a general outcome for every service. A rise in registered users can show delivery momentum; it cannot prove sustained clinical benefit.
Honest reporting protects trust. It also gives product and delivery teams permission to learn rather than defend the first plan.
Build dashboards around decisions
The best live-service dashboard is designed backwards from the decisions a team needs to make. It should show enough of the journey to locate friction, provide a route to the underlying detail and make ownership visible.
In digital health, reporting is part of the service. Used well, it helps teams focus limited capacity, notice risk earlier and improve the experience around the product. Used poorly, it can turn a complicated human journey into a reassuring chart and hide the work still left to do.