Why Trace the Data to the Screen?
A dosing recommendation can be displayed incorrectly even when the underlying model calculation is unchanged. The wrong laboratory result might be selected, a valid value might be converted with the wrong unit factor, or the screen might show an outdated dose or misleading timestamp. These are data-pipeline and interface problems: they concern whether the system carries the intended information through retrieval, transformation, and presentation.
This verification has a different question from analytical validation of model predictions. Here, the question is whether a known test input is handled and displayed according to specified rules. A passing test does not establish that the model’s predictions are clinically accurate. It establishes that the tested data flow and user-interface behavior match their requirements for the cases examined.
A useful test follows one request from its source data to the final screen. For each stage, the test needs a clear expected result—not merely a screenshot that “looks right.” The expected result should be derived independently from the system under test, using the documented data definitions and calculation or display rules. The examples below use hypothetical records and rules; they do not describe a real patient or establish a clinical dosing policy.
Specify the Path and the Rules
Represent the tested path as a sequence: retrieve candidate records, determine which records are eligible, transform selected values into the required representation, pass those values to the recommendation service, and render the result. The recommendation service is treated here as a specified component with known test outputs. This tutorial checks the transfer and presentation of those outputs; it does not assess whether the service’s predictions are correct.
In this expression, \(S\) is the source-record set, \(T\) is selection and transformation, \(R\) is the recommendation service or its controlled test response, and \(U\) is the user-interface rendering. A real implementation may contain more stages, such as terminology mapping or a data cache. The test specification should name the stages relevant to the behavior being checked.
Before testing, state the rules that determine the expected path. These often include the patient and encounter identifiers, which result statuses are eligible, the meaning of each timestamp, unit-conversion factors, rounding and display conventions, and how missing or stale values are handled. Timestamp semantics deserve particular care: a specimen’s collection time does not establish when its result became available to the system.
A simple justification follows from the composition of the stages. If the specified transformation is \(T\), but the implementation applies \(T'\), then the downstream service and interface receive \(R(T'(S))\), not \(R(T(S))\). The final screen can match by coincidence for a particular \(S\), so checking only the screen cannot establish that \(T'=T\). Comparing the selected record and transformed value with their expected values directly tests more of the path and helps locate a failure.
Worked Examples
Worked Example: Selecting an Eligible Laboratory Result
A hypothetical dosing request is made at 12:00 on 14 May. The documented rule is to select the most recently collected finalized result that was available to the system by the request time. The source contains these records:
- 13 May, collected 17:00; finalized and available 18:05; value 80 µmol/L.
- 14 May, collected 08:15; finalized and available 09:02; value 72 µmol/L.
- 14 May, collected 10:40; finalized and available 12:18; value 88 µmol/L.
The third record is not eligible: although it was collected before the request, it was not available until 12:18, after the 12:00 request. The first two are available by the request time, and the 08:15 collection is the later of those eligible collections. Therefore, the expected selected result is 72 µmol/L, collected at 08:15 and available at 09:02.
Suppose the interface specification requires display in mg/dL, using the conversion \(1\text{ mg/dL}=88.4\text{ µmol/L}\). The expected transformed value is:
If the screen displays two decimal places, it should show 0.81 mg/dL, with the specified unit and the correct source-result time. A traceable test checks the selected source record, conversion, rounding, and screen display separately. It should also confirm that the 88 µmol/L record was excluded because of its availability time, not mistakenly treated as eligible based only on collection time.
Worked Example: Checking a Rounded Recommendation on Screen
In a hypothetical interface test, the recommendation service’s controlled response is 437 mg every 24 hours. The interface specification says to display doses to the nearest 25 mg, with exact halfway cases rounded upward. The purpose is to verify presentation of this known response, not to judge whether the recommendation is clinically appropriate.
The number of 25 mg increments is:
The nearest whole increment is 17 because 17.48 is closer to 17 than to 18. Thus the displayed dose is \(17\times25\text{ mg}=425\text{ mg}\). The expected screen text is 425 mg every 24 hours, provided that this is the specified presentation rule. If the interface also shows the unrounded service response, it must label that value clearly rather than presenting 437 mg as the rounded dose.
The test should compare more than the number: check the unit, interval, patient or encounter context, and any required note that the displayed amount is rounded. A screen showing “425” without a unit or interval would not satisfy the full output requirement, even though its numeric value is correct.
Worked Example: Handling a Stale Required Result
A hypothetical request is made at 09:00 on 12 May. The specification requires a weight no more than 30 days old and a laboratory result no more than 24 hours old. It says that if a required laboratory result is stale, the system must not present a dose recommendation and must identify the unavailable input.
The weight is 68.4 kg, collected on 1 May and available that day. It is within the 30-day limit. The laboratory result is 72 µmol/L, collected at 08:30 on 10 May and available at 09:10 on 10 May. At the request time, its age based on collection time is:
Because 48 hours 30 minutes exceeds the 24-hour limit, the result is stale. Its availability time confirms that it was available before the request, but availability does not make it current. The expected behavior is therefore to withhold the recommendation and show the specified stale-result status. The screen should not silently substitute the old result or imply that a recommendation was produced from current data.
This case tests two distinct rules: whether the record was available by the request time and whether it met the age requirement. A test that checks only one of those rules would not fully verify the behavior.
Designing Tests and Diagnosing Failures
A practical test set combines representative end-to-end cases with focused tests for individual rules. Begin with a traceable case that has known source records and an expected screen output. Then vary one feature at a time: a result becomes available just after the request, a value is at a rounding boundary, a required field is missing, or the unit differs from the usual source unit. This makes it easier to identify which rule failed.
Specify the patient or synthetic test identifier, encounter, request time, time zone, and applicable software or interface configuration. Use controlled test data rather than real patient information.
List candidate records, eligibility rules, selected values, conversion and rounding rules, the controlled recommendation response, and the required interface fields.
Record the observed selected record and transformed value before checking the rendered screen. This localizes discrepancies instead of treating the final screen as an opaque result.
Define acceptance criteria in advance. A missing test environment or unavailable source feed is blocked, not a pass; a mismatch with an expected value or required display is a failure.
Use exact comparison where the specification requires an exact identifier, status, unit label, or formatted string. For continuous numeric values, use the stated conversion and display precision. If a numeric tolerance is allowed, specify it in advance and justify it from the interface or data contract; do not invent a tolerance after observing a mismatch. A display rounded to two decimal places can be checked against the documented rounding rule, not against an arbitrary broad range.
Useful diagnostics include checking whether the selected record has the expected identifier and timestamps; whether the transformed value has the expected unit; and whether the displayed text agrees with the service response and formatting rule. Test values around boundaries, including just before and after a time cutoff and values immediately below, at, and above a rounding midpoint. Also inspect the complete screen state: stale or missing inputs may require a status message and no recommendation, not merely a blank value.
Approaches, Limits, and Common Pitfalls
| Approach | What it can reveal | Important limitation |
|---|---|---|
| Focused component tests | Errors in selection, conversion, formatting, or a single status rule. | Do not show that connected components work together in the deployed workflow. |
| End-to-end trace tests | Whether a defined source case reaches the expected screen output through the integrated path. | A final match can conceal an intermediate error unless intermediate values are checked. |
| Manual screen review | Visual omissions, confusing labels, and layout problems. | Can miss hidden data-selection or conversion errors and is difficult to reproduce consistently. |
These approaches complement one another. Focused tests localize rule failures; end-to-end cases check integration; manual review helps assess whether required information is visibly presented. None alone covers every possible data combination, workflow state, or display configuration. The test set should therefore be chosen from documented requirements and plausible failure points, with particular attention to clinically important fields and boundary conditions.
Common mistake: “The final dose matches the expected number, so the pipeline is verified.” This reasoning is too strong. The wrong record or unit conversion may coincidentally produce the same displayed number, and the screen may still omit a required unit, timing detail, or warning. The correction is to test the expected source record, transformations, service response, and complete interface output as distinct assertions.
A further limitation is scope. Passing these tests does not show that a recommendation is well calibrated, clinically beneficial, or transferable to another site. Those questions require other forms of evaluation. Likewise, a finite collection of tests cannot prove that every possible input behaves correctly; it provides evidence about specified behaviors under the tested conditions. Tests also depend on accurate requirements. If timestamp definitions or unit conventions are ambiguous, resolve that ambiguity before treating an output as correct.
Check Your Understanding
For each question, identify the verification rule and compare your reasoning with the solution.
- A request occurs at 15:00. Record A was collected at 14:00 and available at 15:10. Record B was collected at 13:30 and available at 14:00. Under a rule requiring availability by request time and then selecting the most recently collected eligible record, which record is selected?
- A known service response is 512 mg. The interface rounds to the nearest 50 mg, with exact halfway cases rounded upward. What dose should the screen display?
- A required result is available before a request but is older than the specified maximum age. Should the system display a recommendation based on that result if the rule requires withholding recommendations for stale inputs?
- Why is a correct final number insufficient evidence that source-record selection and unit conversion are both correct?
Solutions. (1) Select Record B. Record A is not available until 15:10, after the request, so it is ineligible despite its later collection time. (2) \(512/50=10.24\) increments, which rounds to 10 increments; \(10\times50\text{ mg}=500\text{ mg}\). The screen should show 500 mg, with any required schedule and context. (3) No. Availability by the request time does not override the age limit. The expected behavior is to withhold the recommendation and present the specified stale-input status. (4) Different errors can offset one another or happen to yield the same displayed value. Check the selected record, transformed value, and rendered output separately to detect and localize such failures.