The Word Real-Time in a Clinical Scheduling Contract

Diagnosis. R-114 fails the standard characteristics of a good requirement (ISO/IEC/IEEE 29148: necessary, unambiguous, complete, singular, feasible, verifiable, traceable). Specifically:

• Not measurable. 'Real time' has no threshold, percentile, or measurement point. One stakeholder reads it as 1 second; another reads it as 'whenever the screen refreshes'.
• Not bounded in scope. Which events (create, reschedule, cancel, room change)? Which displays (all clinics, or only the affected clinic)? Which clients (wall displays, mobile, print)?
• No conditions or degrade behaviour. What happens in a Wi-Fi dead zone? Silence on this is what makes the two stakeholders' positions look irreconcilable when they are actually different requirements.
• No verification method. Nothing in the baseline says how acceptance will be judged, which is precisely how a dispute at milestone becomes a contract dispute.

Rewrite. 'When a clinician commits a create, reschedule, or cancel for an appointment in clinic C, the change shall be visible on every display subscribed to clinic C within 2 seconds at the 95th percentile and 5 seconds at the 99th percentile, measured from database commit to rendered display. If a display has not received a confirmed update for 60 seconds, it shall show a visible stale indicator with the timestamp of the last successful sync. Verification: load test with 200 concurrent commits across 3 clinics plus field observation in 2 dead-zone clinics.'

Attributes to attach: unique ID, rationale (double-booking incident), source and owner, priority, verification method, assumption about network coverage, and a trace link to the double-booking risk it mitigates and to the acceptance test case. The stale indicator is the key addition: it converts an infeasible absolute guarantee into a feasible guarantee plus an honest failure mode.

The business owner decides; engineering informs. The decision is not a technical preference, it is a risk-acceptance decision about patient safety versus operating cost, so the accountable party is the clinical owner of the affected process (here, the nursing director, with the hospital's IT lead as a consulted party), not the business analyst, not the vendor's product owner, and not the infrastructure lead alone. A vendor cannot silently choose the cheaper option for a requirement a customer wrote for safety reasons.

The process:

1. Options analysis, not a debate. Produce three costed options: (a) push with dead-zone fallback, (b) 30-second polling with a stale indicator, (c) hybrid - push where the network supports it, polling elsewhere. For each: build effort, operating cost over five years, and the residual double-booking risk.
2. Make the trade-off explicit in money and harm. The 60% operating-cost difference is a recurring figure; the double-booking is a patient-harm event. Put both in the same document so the decision is made on the record rather than by whoever is louder.
3. Escalate to the joint steering group if consensus fails. The vendor's product owner has no authority to accept a safety risk on the client's behalf, and the infrastructure lead has no authority to accept a clinical risk.
4. Record the decision. A decision log entry naming the decision, the date, the decider, the options rejected and why, and the residual risk accepted by name. This is what protects everyone at audit and at acceptance.
5. Route it through change control. R-114 is baselined and contract-linked, so any rewording goes through a formal change request with schedule and fee impact, not a hallway agreement.

Practical interim step: the vendor should build the display service behind a single subscription interface so push and poll are interchangeable, and defer the transport choice one sprint. That buys the decision time without stopping work, and it means the wrong choice is a swap, not a rewrite.

Exposure. The contract has an unmeasurable acceptance criterion and 15% of the fee riding on it. Each party will measure differently at acceptance: the vendor will demonstrate a 30-second refresh and call it real time; the hospital will put a stopwatch on a display in a dead zone and fail it. Because no acceptance test exists, there is no agreed arbiter, so the dispute lands in commercial negotiation, and the vendor's position is weak because its own product owner signed the ambiguous wording without comment. Secondary exposure: rework of the display layer if the decision goes to push, plus a compressed rework window because the pilot date does not move.

This week:

1. Raise a formal clarification/change request today, with the rewritten requirement from the previous task attached. Late is worse than imperfect; nine days is enough to change a transport decision and not enough to change one after the demo.
2. De-risk the demo without pre-empting the decision. Refactor to the subscription interface so the demo shows 'a schedule change appears on a subscribed display' rather than 'polling works'. Demoing the mechanism prejudges the argument.
3. Draft the acceptance test now, in the client's presence, even though the threshold is unresolved. Writing '2 seconds p95' on a shared page surfaces the disagreement in a room where it is cheap.
4. Quantify the rework delta for push versus polling so the steering group sees a number, not a preference.
5. Update the risk register with the double-booking risk, the acceptance risk, and the owner of each.

The general lesson this scenario tests: an ambiguous non-functional requirement is not a documentation nuisance, it is an unpriced commercial and safety liability, and its cost grows the longer it stays unmeasured.