> ## Content Index
> Fetch the complete content index at: https://www.ostering.com/llms.txt
> Use this file to discover other available public pages before exploring further.
# Emergency and External Communications (EC)
- URL: https://www.ostering.com/taxonomies/hospital-and-medical-devices/cri-emergency-and-external-communications/
- Published: 2026-11-05T21:00:00.000Z
- Updated: 2026-11-05T20:40:16.064Z
- Description: Emergency and External Communications: 13 threats in the Hospital and Medical Device Threat Taxonomy, each with a principle, design measures and mappings.
- Author: Brett Crawley
[Taxonomies](/taxonomies/) › [Hospitals and medical devices](/taxonomies/hospital-and-medical-devices/) › Emergency and External Communications
**The Hospital · CRI-EC · suit 13 of 17 · 13 entries**
Ambulance dispatch, prehospital ECG and pre-alerts, emergency services radio, diversion, image transfer, telehealth, hospital-at-home hubs, staff call-in, patient SMS and backup links.
**Scope:** Ambulance dispatch and its links, prehospital ECG/telemetry and pre-alerts, electronic patient care records, emergency services radio, emergency call handoff, diversion status boards, inter-hospital transfer and image sharing, telehealth and video, hospital-at-home monitoring hubs, staff call-in and major-incident cascades, patient SMS and portals (smishing), public information, backup radio and satellite, GNSS for ambulance location.
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.
*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](/taxonomies/hospital-and-medical-devices/#downloads).*
## The threats
### CRI-EC-A Dispatch links fail without warning
**† Wrong or delayed treatment**
**Threat.** Ambulance dispatch, hospital status and handover links run over one integration path that nobody monitors end to end. When it fails or is taken down, crews and emergency departments keep working from stale information, ambulances queue or go to the wrong place, and no one notices until patients are harmed.
**Principle.** Every link between dispatch and the hospital is monitored end to end and has a rehearsed fallback that does not share its failure.
**Design measures:**
1. Send heartbeat messages across each dispatch and handover link and alarm in both control rooms when one goes quiet.
2. Keep a voice and radio fallback for status and pre-alerts on separate infrastructure, with numbers held offline.
3. Rehearse loss of the dispatch link jointly with the ambulance service at least yearly, including the switch back.
**Card prompts:**
- Who monitors the dispatch link to the hospital end to end?
- How would both control rooms know the link had gone quiet?
- What fallback for status and pre-alerts shares none of its failure?
**Mappings:** STRIDE D · CAPEC-582, CAPEC-607 · CWE-754, CWE-1320 · ATT&CK T1489, T1498 · MDS2 DTBK, CONN · IEC 80001-1
### CRI-EC-K Diversion status falsified or stale
**† Wrong or delayed treatment**
**Threat.** Regional capacity and diversion boards accept status changes from any logged-in user or unauthenticated feed. A false closed sends ambulances past the nearest capable hospital; a false open sends a stroke or trauma patient to a hospital whose scanner or theatre is down.
**Principle.** Diversion status is changed only by named, authorised people, is confirmed out of band, and shows its age.
**Design measures:**
1. Require named authentication and a second confirmation by phone before a hospital's diversion status changes.
2. Show the time and author of every status change on the board, and mark status older than a set period as stale.
3. Publish service-level status (CT, cath lab, theatres) separately from whole-site diversion so crews route by capability.
**Card prompts:**
- Who can change a hospital's diversion status, and how is it confirmed?
- Does the board show how old each status is?
- What happens when a status feed is unauthenticated or stale?
**Mappings:** STRIDE S, T, R · CAPEC-148, CAPEC-194 · CWE-306, CWE-863 · ATT&CK T1565.001, T1078 · MDS2 AUTH, AUDT, IGAU
### CRI-EC-Q Prehospital ECG and pre-alert tampered
**† Wrong or delayed treatment**
**Threat.** Twelve-lead ECGs and stroke or trauma pre-alerts travel from the ambulance to the hospital by fax, email, messaging or a vendor cloud without integrity or patient binding. An altered, delayed or misattributed tracing means the cath lab or stroke team is not activated, or is activated for the wrong patient.
**Principle.** Prehospital clinical data is signed at source, bound to the patient and incident, and its delivery is confirmed by a person.
**Design measures:**
1. Sign ECGs on the monitor or gateway and verify the signature before display in the hospital.
2. Bind each transmission to an incident number and patient identifiers, and show both prominently to the receiving clinician.
3. Require a spoken acknowledgement of time-critical pre-alerts and alarm the crew when none arrives in time.
**Card prompts:**
- How is a prehospital ECG bound to the right patient and incident?
- Who confirms that a pre-alert has actually arrived?
- Which routes carry tracings: fax, email, messaging or vendor cloud?
**Mappings:** STRIDE S, T, I · LINDDUN L, DD · CAPEC-94, CAPEC-148 · CWE-924, CWE-319, CWE-353 · ATT&CK T1565.002, T1557 · EMB3D TID-408 · MDS2 TXIG, TXCF, NAUT · IEC 81001-5-1
### CRI-EC-J Emergency services radio jammed or spoofed
**† Wrong or delayed treatment**
**Threat.** Ambulance crews rely on one radio system for clinical advice, backup and handover, with no tested alternative. Jamming, a rogue transmitter or loss of the radio core leaves crews unable to call for help or receive changed instructions, and spoofed traffic can send them to false incidents.
**Principle.** Crews keep at least two independent ways to reach control, and voice instructions that change a destination are verified.
**Design measures:**
1. Provide a second bearer, such as cellular with priority access or satellite, that does not share the radio core or sites.
2. Detect and report interference by monitoring receiver noise at base sites and from vehicles.
3. Verify destination changes received by voice through the vehicle's data terminal or a call-back procedure.
**Card prompts:**
- What second way do crews have to reach control?
- How is a radio instruction that changes destination verified?
- What would crews do if the radio core went down?
**Mappings:** STRIDE S, D · CAPEC-601, CAPEC-599, CAPEC-605 · CWE-940 · MDS2 CONN
### CRI-EC-10 Emergency call handoff flooded or faked
**† Wrong or delayed treatment**
**Threat.** The interface that passes calls and incident data from the emergency call centre to ambulance dispatch trusts every record it receives and has no limit on volume. A flood of fake calls or injected incidents exhausts call-takers and ambulances, and real emergencies wait.
**Principle.** Incident handoff between call centres and dispatch authenticates its source, limits volume and lets operators spot coordinated floods.
**Design measures:**
1. Authenticate each system that can create incidents in dispatch and reject records from anything else.
2. Rate-limit and alarm on surges of calls or incidents from one number range, route or interface.
3. Keep a surge procedure that lets clinicians triage queued calls by risk when volume is abnormal.
**Card prompts:**
- How does dispatch know an incident record came from the call centre?
- What limits the volume of incidents the handoff accepts?
- Could operators spot a coordinated flood of fake calls?
**Mappings:** STRIDE S, D · CAPEC-125, CAPEC-194 · CWE-770, CWE-940 · ATT&CK T1498, T1499.003 · MDS2 NAUT, AUDT
### CRI-EC-9 Image transfer between hospitals unverified
**† Wrong or delayed treatment**
**Threat.** Image-sharing links between hospitals accept studies from any connected peer and import them straight into the local archive. A wrong-patient study, an altered image or a DICOM file carrying malware arrives with the trust of a referral, and when the link is down a time-critical neurosurgical or trauma referral stalls.
**Principle.** Images from other organisations are authenticated, matched to the patient by a person, and checked before they enter the local archive.
**Design measures:**
1. Authenticate each sending organisation and node, and keep a list of peers allowed to send.
2. Quarantine imported studies until patient identity is reconciled and files are scanned for embedded executable content.
3. Keep a tested secondary route for urgent referrals, such as a separate image-sharing service, with known contacts.
**Card prompts:**
- Which hospitals can push images straight into your archive?
- Who matches an incoming study to the right patient?
- What happens to a time-critical referral when the link is down?
**Mappings:** STRIDE S, T, D · LINDDUN L, DD · CAPEC-148, CAPEC-636 · CWE-353, CWE-349 · ATT&CK T1565.002, T1204.002 · MDS2 NAUT, IGAU, MLDP · DICOM PS3.15
### CRI-EC-8 Hospital-at-home hub goes blind
**† Wrong or delayed treatment**
**Threat.** Virtual wards depend on one monitoring hub that gathers observations from patients' homes through a vendor platform and mobile networks. If the hub, platform or feed fails or is tampered with, deteriorating patients look stable and nobody is called, because silence reads as normal.
**Principle.** A virtual ward treats missing data as an alarm and keeps a way to reach every patient when the platform fails.
**Design measures:**
1. Alarm on each patient whose readings stop arriving within the expected interval, not only on abnormal readings.
2. Keep an offline list of virtual-ward patients with phone numbers and escalation plans, refreshed every shift.
3. Restrict who can change alert thresholds and log every change with the reason and clinician.
**Card prompts:**
- Does the virtual ward treat missing observations as an alarm?
- How would staff reach every patient if the platform failed?
- Which links between home and hub could fail silently?
**Mappings:** STRIDE T, D, R · LINDDUN DD · CAPEC-607, CAPEC-148 · CWE-754, CWE-1320 · ATT&CK T1565.001, T1489 · MDS2 DTBK, AUDT, AUTH · IEC 80001-1
### CRI-EC-7 Staff call-in cascade abused
**Threat.** Major-incident and staff call-in messages go out by SMS or automated calls that anyone can imitate, and the cascade platform has weak login. A false major incident pulls staff in and drains the next shift; a blocked or hijacked cascade leaves the hospital short when a real one starts.
**Principle.** Call-in messages are verifiable by staff, the cascade is protected like a clinical system, and a manual fallback exists.
**Design measures:**
1. Tell staff how genuine call-ins look and give them a number or app to confirm one before travelling.
2. Protect the cascade platform with multi-factor login and two-person activation for a major incident.
3. Hold printed call-in trees and a switchboard procedure for when the platform is down.
**Card prompts:**
- How can staff tell a genuine call-in message from a fake?
- Who can log in to the cascade platform, and how?
- What is the manual fallback if the cascade is blocked?
**Mappings:** STRIDE S, D · CAPEC-148, CAPEC-416 · CWE-308, CWE-290 · ATT&CK T1684.001, T1078 · MDS2 PAUT, AUTH
### CRI-EC-6 Telehealth consult hijacked or impersonated
**† Wrong or delayed treatment**
**Threat.** Video and phone consultations use reusable links and no identity check on either side. Someone can join or take over a consult, impersonate the clinician to give harmful advice or extract details, or impersonate the patient to obtain prescriptions and records.
**Principle.** Both parties in a remote consultation are identified, and session links are single-use and bound to the appointment.
**Design measures:**
1. Issue single-use, time-limited links bound to the appointment, and lock the room once both parties join.
2. Verify the patient's identity at the start of each consult and record that it was done.
3. Show the clinician's verified name and organisation in the client, and give patients a way to confirm it.
**Card prompts:**
- How are the clinician and the patient each identified on a remote consult?
- Are session links single-use and tied to the appointment?
- Could someone join a consult without anyone noticing?
**Mappings:** STRIDE S, I, E · LINDDUN I, DD, D · CAPEC-593, CAPEC-151 · CWE-308, CWE-1467 · ATT&CK T1684.001 · MDS2 PAUT, TXCF · ISO 27799
### CRI-EC-5 Ambulance location depends on GNSS
**† Wrong or delayed treatment**
**Threat.** Ambulance location, nearest-vehicle allocation and timestamps on care records depend on GNSS. Jamming or spoofing near a station or along a route misplaces vehicles, sends a distant crew to a cardiac arrest, and leaves records with wrong times.
**Principle.** Vehicle location and time come from more than one source, and implausible positions are flagged before allocation.
**Design measures:**
1. Combine GNSS with cellular location and vehicle odometry, and flag positions that jump or freeze.
2. Let dispatchers override automated allocation when location quality is flagged as poor.
3. Take care-record timestamps from a trusted network time source, with GNSS only as a fallback.
**Card prompts:**
- What other source confirms ambulance position besides GNSS?
- How are implausible vehicle positions flagged before allocation?
- Which records take their timestamps from GNSS?
**Mappings:** STRIDE S, T, D · CAPEC-627, CAPEC-628, CAPEC-599 · CWE-348, CWE-346 · MDS2 IGAU
### CRI-EC-4 Patients trained to click hospital links
**Threat.** Hospitals send appointment reminders, results notices and payment requests by SMS and email with links, from senders anyone can imitate. Patients learn to trust them, so fake messages, fake portals and fake public notices harvest credentials, take payments or tell people the emergency department is closed.
**Principle.** Patients can tell genuine hospital messages from fakes, and messages never ask them to log in or pay through a link.
**Design measures:**
1. Register sender IDs and domains, and publish how genuine messages look and what they will never ask for.
2. Point patients to the portal or app by name instead of sending login links in messages.
3. Monitor for look-alike domains, sender IDs and social accounts, and publish service status only on known channels.
**Card prompts:**
- How can patients tell a genuine hospital message from a fake?
- Do any hospital messages ask patients to log in or pay by link?
- How would you warn the public about fake hospital notices?
**Mappings:** STRIDE S, I · LINDDUN DD, U · CAPEC-98, CAPEC-543, CAPEC-630 · CWE-451 · ATT&CK T1566.002, T1583.001
### CRI-EC-3 Ambulance care records leak or lag
**Threat.** Electronic patient care records live on crew tablets and sync through a vendor cloud. When the sync fails at handover the emergency department works from a verbal summary, and a lost or poorly managed tablet exposes records of everyone the crew treated.
**Principle.** Prehospital records reach the receiving hospital reliably and are protected on the device for as long as they are held.
**Design measures:**
1. Encrypt records on the tablet, enrol tablets in device management, and remote-wipe on loss.
2. Hand over a printable or local copy of the record when the cloud sync has not completed.
3. Purge records from the tablet once the hospital has acknowledged receipt.
**Card prompts:**
- What happens at handover when the care record fails to sync?
- How are crew tablets protected if one is lost?
- How long do records stay on the tablet after handover?
**Mappings:** STRIDE I, D · LINDDUN DD, I · CAPEC-507 · CWE-312 · ATT&CK T1005 · MDS2 STCF, TXCF, DTBK · ISO 27799
### CRI-EC-2 Backup radio and satellite never tested
**Threat.** Satellite phones, backup radio and spare lines sit in a cupboard with flat batteries, expired subscriptions and outdated numbers. On the day every other channel fails, the hospital cannot reach the ambulance service, neighbouring hospitals or its own staff.
**Principle.** Fallback communications are part of routine operations, tested on a schedule, and their directories are kept current offline.
**Design measures:**
1. Test every fallback channel monthly with a real call to the ambulance service and a neighbouring hospital.
2. Keep batteries charged, subscriptions in force, and a printed directory beside each device.
3. Name who owns each fallback device and include its use in major-incident exercises.
**Card prompts:**
- When were backup radio and satellite phones last used in anger or drill?
- Who keeps fallback directories current and offline?
- Are subscriptions, batteries and numbers checked on a schedule?
**Mappings:** STRIDE D · CWE-1329
## Seen in the wild
- **Advanced and NHS 111, 2022** ([CRI-EC-A](/taxonomies/hospital-and-medical-devices/cri-emergency-and-external-communications/#cri-ec-a)). Ransomware at software supplier Advanced disrupted the Adastra system used by NHS 111 and out-of-hours services, and exposed data on about 80,000 people. The UK Information Commissioner fined Advanced £3.07 million in March 2025. Sources: [ICO: Software provider fined £3m following 2022 ransomware attack](https://ico.org.uk/about-the-ico/media-centre/news-and-blogs/2025/03/software-provider-fined-3m-following-2022-ransomware-attack/).
- **University Hospital Düsseldorf, 2020** ([CRI-EC-K](/taxonomies/hospital-and-medical-devices/cri-emergency-and-external-communications/#cri-ec-k)). Ransomware took down systems at University Hospital Düsseldorf and it stopped taking emergency admissions; a woman sent to a hospital in another city died. Prosecutors opened a homicide inquiry but closed it, concluding her condition alone caused her death and the delay did not affect the outcome. Sources: [MIT Technology Review: A patient has died after ransomware hackers hit a German hospital](https://www.technologyreview.com/2020/09/18/1008582/a-patient-has-died-after-ransomware-hackers-hit-a-german-hospital); [Born's Tech and Windows World: ransomware at Uniklinik Düsseldorf not responsible for death](https://borncity.com/win/2020/11/18/ransomware-befall-in-uniklinik-dsseldorf-nicht-fr-todesfall-verantwortlich/).
- **Ascension, 2024** ([CRI-EC-K](/taxonomies/hospital-and-medical-devices/cri-emergency-and-external-communications/#cri-ec-k)). A ransomware attack took Ascension's electronic health records offline across its hospitals, staff worked on paper and some ambulances were diverted; data on about 5.6 million people was taken. Sources: [BleepingComputer: Ascension health data of 5.6 million stolen in ransomware attack](https://www.bleepingcomputer.com/news/security/ascension-health-data-of-56-million-stolen-in-ransomware-attack/).
- **DICOM files carrying malware, 2019** ([CRI-EC-9](/taxonomies/hospital-and-medical-devices/cri-emergency-and-external-communications/#cri-ec-9)). Cylera researchers showed that the DICOM file format allows an image file to also be a working Windows executable, so malware could hide inside medical images protected as patient data (CVE-2019-11687). Sources: [NVD: CVE-2019-11687](https://web.nvd.nist.gov/vuln/detail/CVE-2019-11687); [GovInfoSecurity: Researchers, malware can be hidden in medical images](https://www.govinfosecurity.com/researchers-malware-be-hidden-in-medical-images-a-12388).
## Mappings
Across the 13 entries, the STRIDE counts are Denial of service 9, Spoofing 9, Tampering 5, Information disclosure 4, Repudiation 2, Elevation of privilege 1 (an entry can carry more than one). 12 map to CAPEC 3.9, 13 to CWE 5.0, 10 to ATT&CK v20.0, 1 to MITRE EMB3D and 6 to LINDDUN. The MDS2 capabilities a buyer should check first are DTBK (3), AUTH (3), AUDT (3). 9 carry the amber † for wrong or delayed treatment. A blank means nothing fitted well; a loose tag would mislead.
---
← [Clinical Communications](/taxonomies/hospital-and-medical-devices/cri-clinical-communications/) · [Hospitals and medical devices overview](/taxonomies/hospital-and-medical-devices/) · [Facilities and Building Systems](/taxonomies/hospital-and-medical-devices/cri-facilities-and-building-systems/) →
*© 2026 Jonathan Brett Crawley. Licensed under [CC BY-NC-ND 4.0](https://creativecommons.org/licenses/by-nc-nd/4.0/) with additional permissions: see the licence on the [hospitals and medical devices overview](/taxonomies/hospital-and-medical-devices/).*