Three empty cells, three different jobs
A researcher opens a batch of assay results. Three rows have an empty measurement cell. One measurement is still running. Another was never performed because there was insufficient material. The third produced a value, but the import could not interpret its unit. A neat table gives all three the same dash.
Now the researcher has to leave the table to find out what to do. Waiting is reasonable for the first row. It will never resolve the second. The third needs someone to inspect the source record. The visual simplification has removed the information needed to move the work forward.
This is a representative design case, not a report of a client deployment. Consider a research product used to review a batch before exporting selected measurements for analysis. Its central design problem is deciding what each imperfect record allows the researcher to do next. The proposed states and release rules below would need agreement with the people responsible for the actual assay and workflow.
Give absence a reason
A blank field should not silently become zero. Nor should every absence acquire the label “error.” A measurement that was not planned for a particular sample may be entirely consistent with the study design.
There is an established vocabulary for some of these distinctions. HL7 FHIR R5's DataAbsentReason value set separates temporary unknowns, procedures not performed, values that are not applicable, and information withheld for security or privacy reasons. Those codes show why a single missing-value label can be inadequate. They do not prescribe the interface or require every research product to adopt FHIR.
For our batch table, display the specific reason where the value would normally appear: “Awaiting measurement,” “Not performed,” or “Unit unresolved.” Keep additional detail one step away. A short reason makes scanning possible; a details panel can explain the source, when the condition was recorded, and who can resolve it.
If the source supplies no reason, say “Reason unavailable.” Inferring that a blank means “not collected” would make the interface sound more certain than its data. This distinction also matters when exporting: an empty numeric field should travel with its recorded reason, rather than relying on a tooltip that disappears outside the application.
A failed check is a separate fact
The unit problem deserves a closer look. There may be a perfectly readable number in the source file. The application has a value, yet it cannot safely interpret that value under its current rules. Replacing it with “missing” loses useful evidence.
Keep the original value and unit available in the record details. In the main table, explain that the measurement is excluded from the proposed analysis export until its unit is resolved. Offer “Inspect source” to a reviewer with the relevant access. Avoid suggesting a unit merely because it is the most common one in the batch.
Availability, validation, and review should be separate properties in the product's model. A present measurement can fail a check. A valid measurement can still await review. A reviewed record may legitimately contain no measurement. Combining these into one status field produces ambiguous labels and makes later filtering difficult.
The interface does not need to display every property as a badge. For the current task, it can lead with the condition preventing progress and expose the other dimensions in details. The underlying distinctions remain available for search, export, and explanation.
Show what the warning changes
A warning is useful when the researcher can connect it to a consequence. “Data issue” leaves too much to guess. “Unit unresolved; excluded from analysis export” identifies both the problem and its immediate effect.
Suppose this illustrative batch contains twelve expected measurements. Nine are ready for the intended export, one is pending, one was not performed, and one has an unresolved unit. A summary could state: “9 of 12 expected measurements ready.” Below it, name the three exceptions. Counting only the nine populated rows would make the batch appear complete by changing the denominator without explanation.
The product should distinguish inspecting a partial batch from releasing it for a particular use. A research team might allow an explicitly partial export for exploratory work while requiring a completed review for a shared report. Another workflow may require the entire batch to remain blocked because its checks depend on all measurements. The interface should apply the agreed rule and explain it near the action.
Where partial export is permitted, show the included and excluded records before confirmation and preserve that selection in the exported record. Do not let a filter quietly become an exclusion policy. “Visible rows” and “eligible measurements” can describe different sets.
Corrections need a visible before and after
After the researcher exports the nine ready measurements, a source result is corrected. Updating the displayed number alone creates a problem: the current table and the saved export now disagree, with no obvious explanation.
FHIR R5's ObservationStatus vocabulary distinguishes preliminary observations from final ones and includes a corrected state for an error corrected after finalization. This is a useful reminder that completion does not make later correction impossible. It does not define how this research product should notify users or revise exports.
In the proposed interface, the current result carries a visible “Corrected” label. Opening it shows the previous value, replacement value, correction reason, and recorded attribution. Where the system knows that a saved export included the earlier version, it links to that export and identifies it as needing impact review. If downstream usage is not tracked, the product should acknowledge that limitation instead of implying that every affected analysis has been found.
Keep the saved export intact. A researcher can create a revised export after reviewing the change. Silently refreshing the old one would make it harder to explain which measurements a colleague actually used.
Late arrivals should not move the table under someone
The pending measurement may arrive while the researcher is reviewing another row. In this design, an update notice offers to refresh the batch and states that one result has arrived. It preserves the current selection and position while the researcher finishes the task.
A continuously updating operational display may need different behavior. For a review screen, however, automatic reordering can move the record the person was about to select. The team should decide whether the view is a live feed or a review snapshot and communicate that choice. A timestamp and a specific update notice are more informative than a generic loading spinner.
Use visible words for these states, even when color helps scanning. W3C's explanation of WCAG 2.2's Use of Color criterion says color must not be the only visual means of conveying information or prompting a response. “Pending” and “Corrected” need to remain distinguishable without recognizing an amber or blue tint. That addresses one accessibility requirement; keyboard operation and programmatic status announcements still need their own implementation checks.
Try the review with deliberately awkward records
Before adding more dashboards, test the batch screen with the twelve-record example. Ask a researcher to identify what is ready, explain each exception, and produce the permitted export. Then introduce the late measurement and the correction. Ask them to find which saved export contains the earlier value.
Watch for specific mistakes: treating “not performed” as still pending, assuming a present number passed validation, overlooking an exclusion, or believing a corrected value was always the value on record. These are proposed acceptance exercises, not measured outcomes. They test whether the design communicates the distinctions it claims to preserve.
A small product may handle this with a table, a details panel, and an explicit export summary. More elaborate queues become useful when exceptions have different owners or remain unresolved across shifts. Start with the information people need to finish the review. The interface has done its job when an imperfect record still tells them what happened, what remains uncertain, and which action is available.
Sources consulted
HL7 FHIR R5 — DataAbsentReason