Why a public health dashboard took 18 months
We delivered a 22-page public health dashboard for GGD Rotterdam-Rijnmond with more than 100 measures. Building the product in Power BI took about eight months. The full project took 18 months.
The remaining work covered access to four source systems, selection of the measures, agreement on definitions, writing for the intended readers and several review cycles. Each activity was necessary before the governing board could approve the product.
Accessing and managing four source systems
The data came from a secure government statistics environment, a university research database, a municipal statistics bureau and a child health registry. Each source had a different custodian, release process and set of access conditions.
All four systems could export a table. The project still needed agreements about which data we could use and which measures we could derive. We also needed to record source versions so that a figure received in March remained traceable when the dashboard was reviewed in September.
This work required coordination with the people responsible for governance and release at each organisation. It could not be solved inside Power BI.
Selecting measures
The project began without an agreed list of indicators. We first needed to understand the system that the dashboard would describe: which factors affected each outcome, which interventions were available and which organisation was responsible for them.
An indicator is useful only if the intended reader can interpret it and connect it to a decision. A measure may be easy to calculate but provide little information about an outcome that policymakers can influence.
I worked with epidemiologists, policy advisers and care providers to map the domain before writing the queries. This produced the specification for the dashboard.
Agreeing definitions
The participating organisations already measured several of the same subjects, but they did not always use the same definitions.
For example, including multiple births changes a low-birth-weight measure because twins affect the distribution. Two organisations can therefore publish different figures for an indicator with the same label while both calculations remain internally correct.
Geographic changes create a similar problem. When districts merge, the project must decide whether to recalculate the historical series or show a break in that series.
For each measure, the organisations compared their definitions, selected one for the dashboard and documented the decision. Every calculation downstream depended on this work.
Writing labels for policymakers
The dashboard was designed for policymakers rather than clinicians. A clinically accurate term could still be unclear or misleading for that audience.
We reviewed labels by comparing their ordinary interpretation with the intended technical meaning. When those differed, we changed the label or added an explanation. This was part of the product design because a reader can misinterpret an accurate figure if its label is unclear.
Review and iteration
Stakeholders identified new questions when they saw the data arranged in a working page. Their questions led to changes in the measures, labels or layout. The revised page then allowed the next group to assess the subject in more detail.
Some requirements could only emerge after a working version existed. The team therefore planned several review cycles instead of treating every change as an error in the original specification.
A review that produces no changes may mean the product is ready. It can also mean that the reviewers have not had enough time, context or authority to assess it. Project planning should allow the team to distinguish between those situations.
Planning similar projects
Technical development accounted for about eight of the 18 months. A similar project should also allocate time for:
- data access and release agreements
- source and version management
- indicator selection
- agreement on definitions
- content design for the intended readers
- review and approval
These activities determine whether users can understand and trust the final figures. They belong in the project scope and schedule from the start.