The 212 Must-Haves: Scheduling at Riverbend Hospital

Classification

• Separate safety-critical, regulatory/compliance, operational, and experience/delight requirements. A requirement that affects correct patient identification, scheduling of urgent follow-ups, or medication-related appointments is safety-critical and cannot be traded for speed or convenience.
• Separate functional from non-functional requirements. The sub-two-second booking target, the 10-minute timeout, MFA, and availability are non-functional and need measurable acceptance criteria.

Prioritization techniques

• Use MoSCoW for scope negotiation, but do not let a workshop vote turn safety requirements into 'coulds.'
• Use Kano to distinguish basic expectations from delighters; travel-time auto-fill is likely a delighter, not a basic need.
• Build a traceability matrix from requirement to design, test, and business outcome. This exposes duplicates and orphan requirements among the 212.
• Score with explicit criteria: patient safety impact, regulatory obligation, volume of use, dependency on legacy retirement, effort, and reversibility. Weight safety and compliance as pass/fail gates, not as points.

How safety changes prioritization: a requirement that prevents a wrong-patient or missed-urgent-appointment scenario outranks a faster search. Insurance eligibility may be financially critical but is not the same as clinical safety. The steering committee should cut from experience and low-volume operational features first, and should require clinical sign-off on any change to safety-critical scope.

Reasoning: 212 must-haves is a symptom of unresolved conflict, not a scope list. The analysis must make the conflict visible and force explicit trade-offs against safety, time, and budget.

Design recommendation

• Buy the core scheduling capability; configure rather than custom-build. Scheduling is not a differentiator for the hospital, and custom code increases validation, upgrade, and safety risk. Use vendor configuration for workflows, eligibility integration, and role-based screens.
• Treat the six-second search as a design problem, not an automatic custom build. Test whether the vendor can improve performance through indexing, precomputed slot caches, pagination, asynchronous search, and load balancing. Set a measurable target and a fallback: if the vendor cannot meet it, negotiate a roadmap commitment or a bounded custom optimization with performance tests.
• Defer travel-time auto-fill from the MVP. It is a delighter with high integration and equity risk. Offer a simpler phase-one capability such as a distance/region filter or a link to a mapping service. Validate demand with a prototype before committing custom logic.

Trade-offs to make explicit

• Custom travel-time logic would create a maintenance burden, require mapping-data licensing, and raise privacy questions about patient location. It also may disadvantage patients with unreliable addresses.
• A six-second search may be acceptable for low-volume administrative users but not for high-volume clinic check-in. Segment users and set different targets if necessary.

Reasoning: the design should protect clinical safety and upgradeability first, then optimize experience. Configured capability plus a phased travel-time option is more reversible than a custom build under a fixed budget and nine-month deadline.

Resolution approach

1. Clarify the risk. A 10-minute timeout is a control, not the objective. The objective is to prevent unauthorized access on shared or unattended clinical workstations. Assess the actual exposure: shared devices, badge access, physical controls, and the sensitivity of scheduling data.

2. Use adaptive, role-based controls. Apply shorter timeouts for high-risk roles or sensitive screens and longer inactivity periods for active clinical workflows, with automatic lock rather than session destruction. Require re-authentication with a fast badge tap or PIN where the workstation supports it.

3. Design for shared workstations. Use proximity badges, quick user switching, screen privacy filters, and clear lock-screen behavior. These reduce the clinical cost of re-authentication without removing MFA at login.

4. Document a policy exception with compensating controls. If the security standard allows exceptions, require risk acceptance by the security owner, evidence of the compensating controls, and a review date. Do not simply ignore the standard.

5. Measure. Track timeout-related workflow interruptions, abandoned sessions, and security events. Use the data to tune the control.

Reasoning: the conflict is real but not binary. The design should meet the security intent with controls that fit clinical work, and any deviation should be explicit, risk-accepted, and reviewed.