IBM Data Science Professional Certificate study materials
IBM Data Science Professional Certificate study resources

The Dashboard That Said Occupancy Fell

IBM Data Science Professional Certificate · Put your knowledge to work in context.

All case studies

The Dashboard That Said Occupancy Fell

A hospital operations team has shipped a bed-capacity dashboard. The tiles are: a 14-slice pie chart of discharge dispositions; a dual-axis line chart with average length of stay (0–12 days, left axis) and monthly admissions (1,200–1,500, right axis) drawn as two lines that happen to cross in July; a bar chart of occupancy by ward whose y-axis starts at 85%; and a red/green heatmap of ward-day utilisation. The CEO looked at it and said 'occupancy fell in March, what happened?'. In fact one ward's interface engine was down for three days in March and sent no bed events, which the pipeline wrote as 0 occupied beds. The pie chart's 'Other' slice is 41%. The team has one sprint before a regulator visit and wants to know what to fix first.

1. Identify the misleading encodings tile by tile and state the replacement for each.

Read the worked answer

14-slice pie. Human angle judgement degrades past roughly five slices, and 41% in 'Other' means the chart is dominated by a category that answers nothing. Replacement: a sorted horizontal bar chart of the top 8 dispositions with counts, and break 'Other' out in a second panel or table if the regulator cares about its composition - the fact that it is 41% is itself the finding.

Dual-axis line chart. Two axes with different units and independently chosen scales have no mathematical relationship; the July crossing is an artefact of axis scaling, and readers will read it as causation or as a milestone. Replacement: two stacked panels sharing a single x-axis, or index both series to a common base month if comparison is genuinely the point.

Bar chart starting at 85%. For occupancy, the interesting variation is small, which is precisely why a truncated axis is tempting - but it magnifies a two-point move into a visual collapse. Replacement: full 0–100% axis with a target or capacity line, or if resolution is needed, a dot plot with explicit axis labels and a note that the scale is zoomed.

Red/green heatmap. Hue alone carries the message, and roughly 8% of men have red-green colour vision deficiency; a regulator audience may include them. Replacement: a sequential colour ramp (light to dark) plus a secondary encoding, such as printed values or a diverging ramp centred on a meaningful midpoint like the target occupancy rate.

2. The March dip is a data outage, not a real drop. How should the pipeline and the display handle the missing days, and which is worse: showing 0 or showing a gap?

Read the worked answer

Showing 0 is worse, and materially so. Zero is a measurement; a missing feed is the absence of a measurement. Writing 0 asserts that the ward was empty, which is false, and in a capacity context it also understates demand - someone could reasonably conclude the ward had spare beds. The gap is the honest representation of what is known.

Pipeline. Distinguish 'no events received' from 'occupancy was zero'. If the interface engine sends nothing, the row should not be written, or should be written with a NULL and an ingest_status flag. Add a freshness check: if a ward normally emits N events per hour and emits none while peer wards are reporting, raise an alert rather than backfilling a default. Treating sparse absence as zero is a general-purpose bug that will recur in every feed.

Display. Render the affected days as a break in the line with a shaded band and a short annotation - 'no data, 3 days' - and keep the y-axis on the same scale so the gap is not visually distorted. Attach an inclusion note to the tile: which wards, which dates, how many ward-days excluded. Do not interpolate across the gap without labelling it: a smooth line through missing data is a fabricated measurement.

Worth the sprint: the outage handling and the pie chart. A wrong number reaches a regulator; an ugly chart merely annoys. Fix the encoding after the correctness.

3. The team has one sprint. Propose a prioritised fix list and the design rule you would impose so this does not recur.

Read the worked answer

Prioritisation by consequence, not by aesthetics:

  1. Correctness first - stop writing 0 for missing ward-days, backfill the March band as 'no data', add an ingest-freshness alert, and re-verify every downstream tile that aggregated over March. Any historical total that included the zeros is wrong and needs restating.
  2. Then the tile that changes decisions - replace the truncated-axis bar with a full-scale view plus target line. Occupancy drives staffing; a misread here costs money or safety.
  3. Then the pie - the 41% 'Other' means the dashboard currently cannot answer the disposition question at all, so a bar chart plus a breakdown is a functional improvement, not a cosmetic one.
  4. Accessibility and dual-axis last - swap the red/green ramp for a sequential one with printed values, and split the dual axis into two panels. Both are quick and low-risk.

The rule to impose. Every tile must state the question it answers in its title as a finding or a metric with a definition, not a topic ('Ward occupancy, % of staffed beds, daily, excludes days with no feed'). And every tile must be reproducible from a documented aggregation, so a reviewer can ask 'what went into this number' and get an answer without reading the SQL. A dashboard whose numbers cannot be traced to a definition is a rumour with a colour scheme.