Exercise set

Connected Clinical Technology Network, Alarm, and Cybersecurity Exercises

Worked connected-clinical-technology exercises for network load, alarm latency, updates, patches, logs, failover and release gates.

Branch: Biomedical Engineering
Content: Exercise set
Updated: Jul 03, 2026
Revision: v1.0.0 · reviewed

These exercises practise connected clinical technology as a networked safety system. They cover monitor traffic, packet overhead, alarm latency, jitter, alarm floods, packet loss, QoS headroom, software-update release, patch-window capacity, vulnerability exposure, compensating controls, rollback time, certificate expiry, time synchronisation, failover exposure, cybersecurity triage, log retention and release gates.

The focus is narrower than general clinical equipment fleet management. A connected medical technology page should answer whether alarms, data flows, update procedures, network paths, cybersecurity controls and recovery plans support the intended clinical workflow.

How to Use These Exercises

For each calculation, define:

the device group, network segment, server, application and clinical workflow boundary;
the alarm, data-export, remote-support or update function being protected;
the latency, bandwidth, exposure, rollback or evidence threshold;
the verification method and configuration version;
the action when aggregate completion passes but a patient-care-critical path fails.

The common mistake is treating a connected device as an IT endpoint only. Clinical technology connectivity must protect patient alarms, device identity, data integrity, validated configuration and bedside recovery.

Release Evidence Notes

Network evidence should be measured at the clinical boundary. A switch-port average can hide wireless roaming, alarm floods, mobile-device sleep state, packet bursts or server failover problems.

Alarm evidence should include tails, not only averages. A mean latency below limit is weak if the 95th or 99th percentile violates escalation time.

Cybersecurity evidence should become device-level action. A vulnerability notice is not closed until affected assets, software versions, patch status, compensating controls, downtime plan and rollback evidence are recorded.

Update evidence should preserve clinical function. A successful install count is not enough if alarm routing, data export, user acknowledgement or remote support was not retested after the change.

Engineering Boundary Notes

These exercises use simplified thresholds for training. Real medical technology cybersecurity and connectivity decisions require local policy, manufacturer instructions, network architecture review, clinical governance, risk management, privacy/security requirements and applicable regulatory obligations.

A calculation can show that a link has bandwidth headroom or a patch window is feasible. It does not prove clinical release unless the specific alarm path, configuration, user workflow and recovery plan were tested.

Scenario Map

Scenario	Exercises	Primary calculation	Engineering decision
Network and alarm performance	1-8	bandwidth, overhead, latency, jitter, alarm flood load, packet loss and QoS	Decide whether the connected workflow has technical headroom.
Update and cybersecurity exposure	9-13	release completion, patch capacity, exposure days, residual RPN and rollback time	Decide whether software or security remediation can be released.
Operations and evidence retention	14-18	certificate coverage, time sync, failover exposure, triage workload, log retention and release gates	Decide whether connected clinical technology can remain in service.

Exercise 1: Physiological Monitor Network Load

A unit has:

N=64

physiological monitors. Each monitor sends:

R=24\ \text{kbit/s}

of waveform and numeric data to a central system. Protocol overhead adds:

18\%

Calculate total traffic and compare it with a local planning limit of:

2.0\ \text{Mbit/s}

Solution

Payload traffic:

B_p=64(24)=1536\ \text{kbit/s}

Traffic with overhead:

B_t=1536(1.18)=1812.48\ \text{kbit/s}

Convert:

B_t=1.812\ \text{Mbit/s}

Headroom to the planning limit:

H=2.0-1.812=0.188\ \text{Mbit/s}

The traffic passes the simplified planning limit, but headroom is narrow.

Engineering Comment

Average data rate is not the whole network design. Alarm bursts, retries, roaming, encryption overhead and server polling can consume the remaining headroom.

Plausibility Check

Sixty-four devices at about $24$ kbit/s gives about $1.5$ Mbit/s before overhead, so a final value near $1.8$ Mbit/s is reasonable.

Exercise 2: Packet Overhead and Effective Payload

A bedside gateway sends:

900

packets per second. Each packet carries $160$ bytes of clinical payload and $54$ bytes of headers. Calculate payload rate, total line rate and payload efficiency.

Solution

Payload rate:

B_p=900(160)(8)=1{,}152{,}000\ \text{bit/s}

Total line rate:

B_t=900(160+54)(8)=1{,}540{,}800\ \text{bit/s}

Payload efficiency:

\eta=\dfrac{160}{160+54}=0.748

Therefore:

\eta=74.8\%

Engineering Comment

Small packets are common in monitoring but inefficient. Header overhead should be included when validating wireless capacity or virtual network segmentation.

Plausibility Check

Headers are about one third of payload size, so efficiency below $80\%$ is plausible.

Exercise 3: Alarm Routing Latency Budget

An alarm path has four measured average delays:

Segment	Delay
device detection	$0.45$ s
network transport	$0.18$ s
server rule processing	$0.70$ s
mobile notification	$1.15$ s

The local average latency limit is:

3.0\ \text{s}

Calculate total latency and margin.

Solution

Total latency:

t=0.45+0.18+0.70+1.15=2.48\ \text{s}

Margin:

M=3.0-2.48=0.52\ \text{s}

The average latency passes the simplified limit.

Engineering Comment

Average latency is not complete alarm validation. Peak latency, mobile-device sleep, wireless roaming, failover and alarm floods must also be tested.

Plausibility Check

The largest segment is mobile notification, but all four delays sum to less than $3$ s, so the pass is plausible.

Exercise 4: Jitter Buffer for Numeric Trend Display

A monitoring feed has nominal update interval:

T=1.0\ \text{s}

Measured one-way packet delay has:

d_{50}=80\ \text{ms},\qquad d_{95}=260\ \text{ms}

The display can tolerate $400$ ms of buffering. If the buffer is set to:

B=d_{95}-d_{50}+50\ \text{ms}

calculate the buffer and decide whether it fits the display limit.

Solution

Buffer:

B=260-80+50=230\ \text{ms}

Margin:

M=400-230=170\ \text{ms}

The buffer fits the display limit.

Engineering Comment

Buffering can smooth jitter but adds latency. It may be acceptable for trend display and unacceptable for urgent alarm delivery.

Plausibility Check

The measured jitter span is $180$ ms, so a $230$ ms buffer with margin is reasonable.

Exercise 5: Alarm Flood Server Load

A central alarm server is rated for:

1200\ \text{alarm events/min}

during a short burst. A simulated alarm flood has $80$ devices, each generating $11$ events per minute. Calculate server load and utilization.

Solution

Flood load:

L=80(11)=880\ \text{events/min}

Utilization:

U=\dfrac{880}{1200}=0.733

Therefore:

U=73.3\%

Engineering Comment

Server capacity is only one alarm-flood control. Notification queues, escalation logic, acknowledgement workflow and clinical alarm fatigue must also be validated.

Plausibility Check

The load is clearly below $1200$ events/min, so utilization below $100\%$ is expected.

Exercise 6: Packet Loss Retry Exposure

A device sends:

5000

clinical data packets per hour. The measured packet-loss probability is:

p=0.003

Each lost packet triggers one retry. Estimate expected retries per hour and the retry percentage.

Solution

Expected retries:

R=5000(0.003)=15\ \text{retries/h}

Retry percentage:

R_{\%}=0.003(100)=0.30\%

Engineering Comment

A small loss percentage can still matter if losses cluster during alarms or handoff. The timing and clinical context of loss are as important as the average.

Plausibility Check

Three losses per thousand packets over five thousand packets gives fifteen retries.

Exercise 7: QoS Bandwidth Reservation

A clinical VLAN has usable capacity:

C=50\ \text{Mbit/s}

The policy reserves:

30\%

for alarms and monitoring. Current validated clinical traffic is:

11.8\ \text{Mbit/s}

Calculate reserved capacity and margin.

Solution

Reserved capacity:

C_r=0.30(50)=15\ \text{Mbit/s}

Margin:

M=15-11.8=3.2\ \text{Mbit/s}

The validated traffic fits the reserved class.

Engineering Comment

QoS only helps if classification is correct. Misclassified backup, video or guest traffic can still compete with clinical monitoring if the policy is not tested.

Plausibility Check

Thirty percent of $50$ is $15$ , and $11.8$ leaves a few Mbit/s of headroom.

Exercise 8: Alarm Tail-Latency Gate

A test measures $600$ alarm deliveries. The project rule requires:

95\%

of alarms to arrive within $4$ s. In the test, $576$ alarms arrive within $4$ s. Calculate the pass percentage and decision.

Solution

Pass percentage:

P=\dfrac{576}{600}=0.960

Therefore:

P=96.0\%

The result passes the $95\%$ tail-latency gate.

Engineering Comment

The remaining $24$ delayed alarms still deserve review. Tail failures during specific rooms, access points or mobile devices may indicate a localized unsafe path.

Plausibility Check

$95\%$ of $600$ is $570$ , and $576$ is slightly above that threshold.

Exercise 9: Controlled Software Update Release

A connected monitoring update requires four post-update checks on:

N=76

devices: install success, functional check, data export and alarm routing. The completed counts are:

Check	Completed
install success	$76$
functional check	$74$
data export	$72$
alarm routing	$70$

The release rule requires alarm routing to be complete for all devices. Calculate the aggregate completion percentage and decide whether release is allowed.

Solution

Total required check instances:

N_t=4(76)=304

Completed check instances:

N_c=76+74+72+70=292

Aggregate completion:

C=\dfrac{292}{304}=0.9605=96.1\%

Alarm routing completion:

C_a=\dfrac{70}{76}=92.1\%

Release is not allowed because alarm routing is not complete for all devices.

Engineering Comment

Aggregate completion can hide the missing patient-care-critical check. A monitoring update is not released until alarms reach the intended clinical path.

Plausibility Check

The overall number looks high, but six missing alarm-routing checks are enough to block release under the stated rule.

Exercise 10: Patch Window Capacity

A vulnerability patch takes:

22\ \text{min/device}

including install, reboot and functional check. The after-hours window is:

7.5\ \text{h}

Three technicians can work in parallel. How many devices can be patched in the window?

Solution

Technician-minutes available:

T_a=3(7.5)(60)=1350\ \text{technician-min}

Devices patched:

N=\dfrac{1350}{22}=61.36

Whole devices:

N=61\ \text{devices}

Engineering Comment

The result assumes devices are accessible, backups are complete, credentials work and clinical downtime windows are honored. Those constraints often dominate patch execution.

Plausibility Check

Each technician can patch about $20$ devices in the window, so three technicians patch about $60$ devices.

Exercise 11: Vulnerability Exposure in Device-Days

A vulnerability affects:

N=48

connected infusion pumps. Routine patching would leave devices exposed for $12$ days. Accelerated patching reduces exposure to $3.5$ days. The local unmitigated exposure limit is:

250\ \text{device-days}

Compare both plans.

Solution

Routine exposure:

E_r=48(12)=576\ \text{device-days}

Accelerated exposure:

E_a=48(3.5)=168\ \text{device-days}

Reduction:

\Delta E=576-168=408\ \text{device-days}

Routine patching fails the $250$ device-day limit. Accelerated patching passes.

Engineering Comment

Exposure is not only calendar time. Network segmentation, exploitability, clinical dependency, available loaners and compensating controls should be documented for affected devices.

Plausibility Check

Reducing exposure duration by more than two thirds should reduce device-days by more than two thirds, which it does.

Exercise 12: Compensating Control Residual RPN

A connected device vulnerability has initial scores:

S=8,\qquad O=5,\qquad D=6

where $S$ is severity, $O$ occurrence and $D$ detection difficulty. A compensating control does not change severity, but reduces occurrence to $2$ and detection difficulty to $3$ . Calculate initial and residual RPN.

Solution

Initial RPN:

RPN_i=8(5)(6)=240

Residual RPN:

RPN_r=8(2)(3)=48

Reduction:

\Delta=240-48=192

Engineering Comment

The control is credible only if it is implemented at the boundary where the vulnerability exists. A paper rule that is not enforced on the device network does not reduce occurrence or detection difficulty.

Plausibility Check

Severity stays fixed while occurrence and detection difficulty fall substantially, so the RPN should drop substantially.

Exercise 13: Rollback Time Reserve

A software update plan allocates:

90\ \text{min}

for each clinical area. Installation and verification take $54$ min. Rollback, if needed, takes $28$ min. The local rule requires:

10\ \text{min}

of contingency after rollback. Check whether the plan has enough reserve.

Solution

Worst-case time:

T_w=54+28+10=92\ \text{min}

Reserve margin:

M=90-92=-2\ \text{min}

The plan does not have enough rollback reserve.

Engineering Comment

Rollback is a clinical safety control. If the rollback path cannot fit inside the approved downtime window, the update plan should be revised before release.

Plausibility Check

The required worst-case time is just above the window, so a small negative margin is expected.

Exercise 14: Certificate Expiry Coverage

A device integration uses $132$ client certificates. The policy requires renewal at least:

21\ \text{days}

before expiry. The certificate inventory shows:

Days to expiry	Count
$0$ to $20$	$9$
$21$ to $45$	$37$
more than $45$	$86$

Calculate the noncompliant percentage.

Solution

Noncompliant certificates:

N_n=9

Percentage:

P_n=\dfrac{9}{132}=0.0682=6.8\%

Compliant certificates:

N_c=132-9=123

Engineering Comment

Certificate expiry can become a clinical outage if data export, alarms or remote support depend on mutual authentication. Renewal status should be visible before the last safe window.

Plausibility Check

Nine certificates out of a little over one hundred is slightly below $7\%$ , so the percentage is plausible.

Exercise 15: Time Synchronisation Error for Alarm Review

An alarm server clock is:

1.8\ \text{s}

ahead of network time. A bedside gateway is:

0.7\ \text{s}

behind network time. Calculate the maximum timestamp separation between the two records. The review rule allows:

2.0\ \text{s}

Solution

Timestamp separation:

\Delta t=1.8-(-0.7)=2.5\ \text{s}

Margin:

M=2.0-2.5=-0.5\ \text{s}

The time-synchronisation condition fails.

Engineering Comment

Clock error can corrupt incident reconstruction. In alarm investigations, a few seconds may change the apparent order of detection, notification, acknowledgement and response.

Plausibility Check

One clock is early and the other is late, so the separation should be the sum of magnitudes: $2.5$ s.

Exercise 16: Failover Outage Exposure

A primary alarm server fails over to a secondary server. During testing, the alarm path is unavailable for:

18\ \text{s}

per failover event. The site expects:

4

planned failover tests per year and allows at most:

90\ \text{s/year}

of planned alarm-path unavailability. Calculate annual exposure.

Solution

Annual planned exposure:

E=18(4)=72\ \text{s/year}

Margin:

M=90-72=18\ \text{s/year}

The planned failover exposure passes the simplified annual limit.

Engineering Comment

The test must also prove alarm recovery, message ordering and escalation state. A short outage is not acceptable if alarms are dropped or duplicated incorrectly.

Plausibility Check

Four events under twenty seconds each should total under eighty seconds, so $72$ s is reasonable.

Exercise 17: Cybersecurity Alert Triage Workload

A monitoring rule generates:

420

alerts per week. Historical review shows:

18\%

need clinical technology investigation. Each investigation takes:

16\ \text{min}

The clinical engineering cybersecurity liaison has:

18\ \text{h/week}

available for triage. Calculate workload and utilization.

Solution

Investigations per week:

N_i=0.18(420)=75.6

Weekly investigation time:

T=75.6(16)=1209.6\ \text{min}

Convert:

T=\dfrac{1209.6}{60}=20.16\ \text{h/week}

Utilization:

U=\dfrac{20.16}{18}=1.12=112\%

The triage workload exceeds available capacity.

Engineering Comment

Cybersecurity monitoring can fail operationally even when detection works. Alert rules must be tuned so clinical technology staff can investigate device-relevant findings before exposure accumulates.

Plausibility Check

About $76$ investigations at roughly a quarter hour each is about $19$ to $20$ hours, so the overload is plausible.

Exercise 18: Connected Technology Release Gate

A release package for connected patient monitors has five gates:

Gate	Weight	Result
network load headroom	$0.20$	$0.94$
alarm latency evidence	$0.25$	$0.92$
software update completion	$0.20$	$0.96$
cybersecurity remediation	$0.20$	$0.88$
rollback and failover proof	$0.15$	$0.93$

The weighted release threshold is:

S\ge 0.92

and cybersecurity remediation may not be below:

0.90

Calculate the weighted score and decision.

Solution

Weighted score:

\begin{aligned} S&=0.20(0.94)+0.25(0.92)+0.20(0.96)+0.20(0.88)+0.15(0.93)\\ &=0.188+0.230+0.192+0.176+0.1395\\ &=0.9255 \end{aligned}

Therefore:

S=92.55\%

The weighted score passes. Cybersecurity remediation fails its floor:

0.88<0.90

The release is held or restricted until remediation evidence improves.

Engineering Comment

Connected clinical technology release should preserve critical-floor gates. A good network score cannot compensate for unresolved device-level cybersecurity exposure.

Plausibility Check

The total score is slightly above the threshold, but the failed cybersecurity floor controls the decision, exactly as the rule states.

Validation Package Checklist

Network load calculations include protocol overhead, burst behavior and reserved clinical traffic classes.
Alarm testing reports mean and tail latency, failed deliveries, failover behavior and acknowledgement workflow.
Software updates are tied to device identity, configuration version, rollback plan and post-update clinical function.
Vulnerability remediation is tracked by affected asset, software version, patch status, compensating control and exception owner.
Certificate, time-sync and log-retention checks are treated as clinical availability controls when alarms or data export depend on them.
Cybersecurity monitoring workload is sized so alerts can be investigated before exposure grows.
Release decisions keep patient-care-critical gates visible even when aggregate completion looks high.

Common Release Mistakes

Validating bandwidth from average traffic while ignoring alarm bursts, retries and wireless roaming.
Reporting only mean alarm latency when tail latency controls clinical escalation.
Treating software install success as release without retesting alarm routing and data export.
Closing vulnerability tickets without device-level patch or compensating-control evidence.
Assuming rollback is available when the rollback window cannot fit the approved clinical downtime.
Letting certificates, clocks or logs expire because they look like IT administration rather than clinical safety controls.
Creating alert rules that exceed clinical engineering investigation capacity.
Using a weighted release score to hide a failed cybersecurity or alarm gate.

REF