Clinical Communications (CC)

Clinical Communications (CRI-CC), The Hospital: a radiograph of a handset and a pager sending a signal.

Taxonomies › Hospitals and medical devices › Clinical Communications

The Hospital · CRI-CC · suit 12 of 17 · 13 entries

Nurse call, alarm routing to handsets, pagers and bleeps, DECT and Wi-Fi phones, secure and shadow messaging, crash calls, switchboard and overhead paging.

Scope: Nurse call, alarm routing middleware to handsets, pagers/bleeps (often unencrypted), DECT and Wi-Fi handsets, secure messaging and shadow use of consumer messaging, crash/emergency call lines, switchboard, overhead paging, staff smartphones, handover tools, on-call rotas.

Entries are ranked Ace (most severe) to 2. In the taxonomy the ID is a stable reference, not a severity: rate each finding in your own system.

Clinical Communications: each entry's ID, title, threat, mitigation principle and design measures. The full text follows below.

Text version: every entry is written out below, with its card prompts and mappings. The same text is in the PDF and Excel downloads on the overview page.

The threats

CRI-CC-A Alarms that never reach the nurse

† Wrong or delayed treatment

Threat. Monitor and pump alarms travel through middleware to nurses’ handsets, with no end-to-end confirmation of delivery. When the middleware fails, is misconfigured or is tampered with, alarms vanish while every system shows normal.

Principle. Every clinical alarm is confirmed as delivered and acknowledged, and escalates when it is not.

Design measures:

  1. Require acknowledgement within a set time and escalate unacknowledged alarms to another clinician and the central station.
  2. Monitor the middleware with end-to-end test alarms and alert on any failure to deliver.
  3. Keep audible bedside and central alarms active as a backstop whatever the middleware does.

Card prompts:

  • How is delivery of an alarm to a handset confirmed?
  • What happens when an alarm is not acknowledged in time?
  • Would anyone notice the middleware had stopped forwarding alarms?

Mappings: STRIDE T, D, R · CAPEC-603 · CWE-392, CWE-754 · ATT&CK T0878, T0815 · MDS2 IGAU, AUDT · IEC 80001-1; ISO 14971

CRI-CC-K Crash calls on one platform

† Wrong or delayed treatment

Threat. The cardiac arrest and rapid response call path runs on the same IP telephony and network as everything else. When ransomware or an outage takes it down, staff cannot summon the resuscitation team.

Principle. Emergency call paths have an independent fallback that works when the main network and telephony are down.

Design measures:

  1. Provide an independent backup for crash and emergency calls, such as dedicated lines, radios or hard-wired alarms.
  2. Test the emergency call path daily, end to end, and log the result.
  3. Train staff on the downtime method and display it at every call point.

Card prompts:

  • What carries a crash call from the handset to every team bleep?
  • How does the caller know the team was reached?
  • What is the fallback, and when was it last tested?

Mappings: STRIDE D · CAPEC-603 · CWE-1357 · ATT&CK T1489, T1498 · MDS2 DTBK, CONN · IEC 80001-1

CRI-CC-Q Nurse call failing silently

† Wrong or delayed treatment

Threat. IP nurse call systems sit on shared networks with default settings. A fault or attack stops patient calls from reaching staff, or marks them answered, and patients who cannot leave their bed have no other way to get help.

Principle. Nurse call is designed and monitored as a patient-safety system with a known fallback.

Design measures:

  1. Supervise every call point and alert on lost connections or stuck states.
  2. Isolate nurse call on its own segment and harden its servers and default accounts.
  3. Define ward procedures, such as increased rounding, for when nurse call is degraded.

Card prompts:

  • How would staff know nurse call had stopped working?
  • What does a patient who can’t leave the bed do if it fails?
  • Who monitors nurse call as a safety system?

Mappings: STRIDE T, D · CAPEC-176 · CWE-1392, CWE-754 · ATT&CK T0814 · MDS2 SAHD, CONN · IEC 80001-1

CRI-CC-J False alarms and fake calls

† Wrong or delayed treatment

Threat. Handsets and paging accept alarms and messages from anything that can reach the messaging gateway. Injected false alarms or fake emergency calls send staff to the wrong bed, mask real alarms and wear down trust in the system.

Principle. Only authenticated systems can raise alarms and emergency calls, and staff can see where each came from.

Design measures:

  1. Authenticate every system that can send to the alarm and messaging gateway, and reject the rest.
  2. Show the source device, location and patient on every alarm so staff can judge it quickly.
  3. Alert on unusual alarm volumes or sources.

Card prompts:

  • Which systems can send alarms or calls to handsets?
  • Can staff see where an alarm or emergency call came from?
  • How would injected false alarms be spotted and stopped?

Mappings: STRIDE S, T · CAPEC-148, CAPEC-151 · CWE-306, CWE-940 · ATT&CK T1565.002 · MDS2 NAUT, TXIG · IEC 80001-1

CRI-CC-10 Pages read and spoofed by radio

Threat. Pagers and bleeps carry patient names, conditions and locations unencrypted over radio. Anyone with a cheap receiver can read them, and anyone with a transmitter can send pages that look genuine.

Principle. Paging carries no patient-identifiable data in the clear, and pages that start clinical action are authenticated.

Design measures:

  1. Move clinical paging to encrypted, authenticated messaging, or strip patient details from pages.
  2. Use pages only as a call-back prompt, with clinical detail given on a verified channel.
  3. Plan retirement of unencrypted paging, keeping a resilient alert method in its place.

Card prompts:

  • What patient details appear in pager messages?
  • Could a cheap receiver read your hospital’s pages?
  • How would a spoofed page be told from a genuine one?

Mappings: STRIDE S, I · LINDDUN DD, I · CAPEC-157, CAPEC-148 · CWE-319, CWE-290 · ATT&CK T1040 · MDS2 TXCF, TXIG · ISO 27799

CRI-CC-9 Clinical care on consumer messaging

Threat. When official tools are slow, clinicians share patient photos, results and decisions in consumer messaging groups on personal phones. Data sits outside the record and the hospital, with no audit, retention or way to remove it.

Principle. Official clinical messaging is quicker than the shadow alternative, and decisions made in it reach the record.

Design measures:

  1. Provide an approved secure messaging app that handles photos and groups as easily as consumer apps.
  2. Write messaging decisions back to the record automatically or prompt for it.
  3. Set clear guidance, and remove clinical content from personal devices when staff leave.

Card prompts:

  • Why do clinicians reach for consumer messaging instead?
  • How do decisions made in messages reach the record?
  • What happens to patient photos on personal phones?

Mappings: STRIDE I, R · LINDDUN DD, U, Nc · CAPEC-545 · CWE-359, CWE-213 · ATT&CK T1213.005 · MDS2 MPII, STCF · ISO 27799

CRI-CC-8 Impersonating a clinician by message

† Wrong or delayed treatment

Threat. Secure messaging trusts the display name. Anyone with a hijacked account, or a lookalike profile, can send orders, ask for results or request a change in treatment, and the recipient acts on it.

Principle. Clinical instructions sent by message come from verified identities, and high-risk requests are confirmed on a second channel.

Design measures:

  1. Tie messaging accounts to verified staff identity, with phishing-resistant authentication.
  2. Show role and verification status clearly, and flag external or newly created accounts.
  3. Require a call-back or order entry for high-risk instructions such as drug or dose changes.

Card prompts:

  • How does a recipient verify who sent a clinical message?
  • Which requests need confirming on a second channel?
  • What could a hijacked messaging account ask for?

Mappings: STRIDE S, R · CAPEC-151, CAPEC-98 · CWE-290, CWE-308 · ATT&CK T1566.003, T1534 · MDS2 PAUT, AUTH · IEC 80001-1

† Wrong or delayed treatment

Threat. Switchboard, on-call rotas and contact directories decide who gets called. A tampered rota or a convincing caller sends emergency calls to the wrong person, or obtains direct numbers and patient whereabouts.

Principle. Rotas and directories are controlled data, and switchboard follows verification scripts.

Design measures:

  1. Restrict and log edits to on-call rotas and contact directories, with change alerts to the owning team.
  2. Give switchboard staff verification scripts for requests about patients or staff.
  3. Check critical rotas automatically against expected coverage before each shift.

Card prompts:

  • Who can edit on-call rotas and the staff directory?
  • What verification does switchboard apply to unusual callers?
  • How would a tampered rota be noticed during the night?

Mappings: STRIDE S, T · LINDDUN DD · CAPEC-415, CAPEC-407 · CWE-732 · ATT&CK T1566.004 · MDS2 AUTH, AUDT

CRI-CC-6 Shared handsets with no owner

† Wrong or delayed treatment

Threat. Ward handsets are passed between staff without login. Whoever holds one sees patient alarms and messages and can acknowledge them, and there is no record of who did.

Principle. Each alarm acknowledgement is tied to the person holding the handset at the time.

Design measures:

  1. Require quick sign-in to handsets at shift start, by badge or code, and sign out on dock.
  2. Record who acknowledged every alarm and message.
  3. Hide message content on the lock screen and wipe handsets on return.

Card prompts:

  • How do you know who held a handset when an alarm was acknowledged?
  • Do staff sign in to ward handsets at handover?
  • What can someone holding a spare handset see and do?

Mappings: STRIDE S, R, I · LINDDUN DD, Nr · CAPEC-122 · CWE-308, CWE-1463 · MDS2 PAUT, ALOF, AUDT

CRI-CC-5 Overhead paging hijacked

Threat. Overhead paging and public address systems are now IP-based and reachable from the wider network. A false emergency code or evacuation announcement can cause panic or disrupt care across a site.

Principle. Public address is reachable only from authorised consoles, and emergency announcements need authenticated sources.

Design measures:

  1. Isolate the PA system and permit only named consoles to broadcast.
  2. Require authentication for emergency and evacuation announcements.
  3. Log every broadcast and alert on unexpected sources.

Card prompts:

  • Which consoles and systems can trigger overhead announcements?
  • How is an emergency announcement authenticated?
  • What would a false evacuation code cost the site?

Mappings: STRIDE S, D · CAPEC-148 · CWE-306 · MDS2 AUTH, CONN

CRI-CC-4 Clinical apps on personal phones

Threat. Staff run clinical messaging and record apps on their own phones without device management. Lost or shared phones expose patient data on lock screens, in backups and in notifications.

Principle. Clinical apps protect their own data, whatever device they run on.

Design measures:

  1. Use app-level protection: separate PIN, encrypted storage and remote wipe of app data.
  2. Hide clinical content from notifications and exclude it from personal backups.
  3. Require a minimum operating system version and screen lock to run clinical apps.

Card prompts:

  • What patient data shows on lock screens and notifications?
  • Do clinical apps protect their data on unmanaged phones?
  • What happens to app data when a phone is lost?

Mappings: STRIDE I · LINDDUN DD · CAPEC-507 · CWE-312, CWE-359 · ATT&CK T1005 · MDS2 STCF, ALOF · ISO 27799

CRI-CC-3 Status boards in public view

Threat. Electronic whiteboards and patient status screens show names, diagnoses and risks where visitors can see them, and some can be edited from any ward PC without login.

Principle. Status displays show only what the audience needs, and edits are authenticated.

Design measures:

  1. Use initials or bed numbers on displays visible to the public.
  2. Require authenticated edits and log changes to patient status.
  3. Position screens and set privacy modes by location.

Card prompts:

  • What do status boards show that visitors can read?
  • Who can edit a status board, and is a login required?
  • Which details could be removed without hurting care?

Mappings: STRIDE I, T · LINDDUN DD, I · CAPEC-699 · CWE-359, CWE-862 · MDS2 MPII, AUTH

CRI-CC-2 Recordings with clinical detail

Threat. Call recordings, voicemail and message archives hold clinical conversations, kept indefinitely and readable by telephony administrators and suppliers.

Principle. Communications records are kept for a defined purpose and period, under clinical data protection.

Design measures:

  1. Set retention limits for recordings and archives and purge on schedule.
  2. Encrypt recordings and limit access by role, with audit.
  3. Include telephony suppliers in data protection agreements.

Card prompts:

  • How long are call recordings and voicemail kept?
  • Who can listen to archived clinical conversations?
  • Do suppliers have access to communication archives?

Mappings: STRIDE I · LINDDUN DD, Nc · CAPEC-545 · CWE-312 · ATT&CK T1123 · MDS2 STCF, MPII · ISO 27799

Seen in the wild

Mappings

Clinical Communications: the mappings of each entry to STRIDE, LINDDUN, CAPEC, CWE, ATT&CK, EMB3D, MDS2 and standards.

Across the 13 entries, the STRIDE counts are Spoofing 6, Information disclosure 6, Tampering 5, Denial of service 4, Repudiation 4 (an entry can carry more than one). 13 map to CAPEC 3.9, 13 to CWE 5.0, 10 to ATT&CK v20.0 and 7 to LINDDUN. None map to MITRE EMB3D. The MDS2 capabilities a buyer should check first are AUTH (4), AUDT (3), CONN (3). 7 carry the amber † for wrong or delayed treatment. A blank means nothing fitted well; a loose tag would mislead.

← Networks and Wireless · Hospitals and medical devices overview · Emergency and External Communications →

© 2026 Jonathan Brett Crawley. Licensed under CC BY-NC-ND 4.0 with additional permissions: see the licence on the hospitals and medical devices overview.