MediTrack: Making Availability and Alarm Latency Verifiable
MediTrack is a patient telemetry system for a 220-bed hospital. The marketing-derived requirement reads: 'The system shall provide continuous monitoring with 99.99% availability and shall alarm within 2 seconds.' The proposed architecture is a single on-premises server with a redundant disk and a monthly 4-hour maintenance window. The clinical safety board requires that no single failure remove monitoring from more than 8 beds. The program has a fixed budget of $1.4M and 10 months. The systems engineer must baseline requirements and architecture at the preliminary design review. Active-active clustering quotes exceed the budget by $300k. A warm-standby option costs $120k but has a 90-second failover. Alarm latency has been measured only in the lab at the 50th percentile, where it is 0.8 s. Two clinicians have asked what '2 seconds' means during network congestion.
1. Rewrite the availability and alarm requirements so they are verifiable, including measurement conditions and definitions.
Read the worked answer
The current text is untestable because 'continuous' has no boundary, '99.99%' has no interval or definition of unavailability, and 'within 2 seconds' has no percentile, start point, or load condition.
Availability rewrite: 'The central monitoring function shall be available at least 99.99% per calendar year, where unavailability starts when any monitored bed's waveform or alarm data is not displayed and updated within its specified interval, and ends when service is restored. Planned maintenance may be excluded only if it satisfies the constraint that no single activity removes monitoring from more than 8 beds.' The exclusion clause matters: the clinical board's 8-bed rule effectively forbids taking the whole system down, so maintenance must be designed as rolling work, not simply excluded from the metric.
Alarm rewrite: 'From the physiologic condition being present at the sensor to annunciation at the central station and the bedside, latency shall be no more than 2 s at the 95th percentile and no more than 4 s at the 99th percentile, under stated patient load, network utilization up to 70%, and with clocks synchronized to a common reference.' Define the measurement points, the load profile, and the treatment of sensor dropout. Add a separate availability figure for the alarm path, because a system can be 'available' while its alarm chain is degraded.
2. Evaluate the architecture options against the rewritten requirements and recommend a baseline, showing the calculations.
Read the worked answer
First, size the availability target: 99.99% per year allows about 52.6 minutes of downtime. A monthly 4-hour window is 48 hours per year, or about 99.45% availability, so the current architecture fails by a wide margin even before failures. The redundant disk does not address server or maintenance outage.
Warm standby at $120k: each unplanned failover costs 90 s, so two failovers per year cost 3 minutes, which is well inside 52.6 minutes. The problem is planned maintenance and the 8-bed constraint. A single failover removes all 220 beds for 90 s, violating the no-single-failure-removes-more-than-8-beds rule. Mitigate by partitioning monitoring into zones of no more than 8 beds served by separate server instances, or by ensuring bedside local annunciation continues independently during failover. With rolling maintenance, patch the standby, fail over, patch the primary, and fail back, which removes planned downtime if zone-level continuity is preserved.
Active-active would be simpler but is $300k over a $1.4M budget. Recommend warm standby plus zone partitioning and local annunciation, conditional on a 30-day availability demonstration. If partitioning cannot be built within 10 months, the requirement or the budget must change; do not baseline an architecture that cannot meet the number.
3. What verification and validation evidence should the safety board require before accepting the baseline?
Read the worked answer
Verification must demonstrate the statistical requirements, not just nominal operation. For availability, run a 30-day instrumented trial with automated outage detection using the rewritten definition, plus fault-injection tests that kill the primary server, corrupt the disk, and saturate the network. Include planned-maintenance drills to prove rolling patching causes no more than 8 beds to lose monitoring. Calculate demonstrated availability with confidence bounds; 30 days cannot prove 99.99% by itself, so combine field measurement with reliability analysis and failure-mode testing.
For alarm latency, measure end-to-end from a physiologic simulator at the sensor to annunciation, with synchronized clocks, at multiple load levels including congestion. Report the full distribution, not the mean or median; the 50th-percentile 0.8 s result says nothing about the 95th or 99th percentile. Test sensor dropout, reconnection, and failover, since those are when alarms are most at risk.
Validation belongs to the clinical users: scenario-based acceptance in the actual ward workflow, including alarm escalation and nurse response. The safety board should also see traceability from the 8-bed constraint and alarm requirements to these tests, and independent test execution rather than developer self-certification.