> ## 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.

# Laboratory and Diagnostics (LD)

- URL: https://www.ostering.com/taxonomies/hospital-and-medical-devices/cri-laboratory-and-diagnostics/
- Published: 2026-11-05T21:00:00.000Z
- Updated: 2026-11-05T20:42:03.773Z
- Description: Laboratory and Diagnostics: 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/) › Laboratory and Diagnostics

**The Patient · CRI-LD · suit 07 of 17 · 13 entries**

Analysers, LIS and middleware, point-of-care tests, blood bank, pathology and digital pathology, sequencers and outsourced lab services.

**Scope:** Analysers, middleware and LIS, point-of-care testing, blood bank and transfusion matching, pathology and digital pathology, microbiology, sequencers and genomic data; result tampering, wrong patient, reference ranges, QC data, reagent supply, results that silently stop flowing, outsourced lab services.

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.

![Laboratory and Diagnostics: each entry's ID, title, threat, mitigation principle and design measures. The full text follows below.](https://www.ostering.com/media/posts/164/hospitals-taxonomy-table-07-LD.png =1400x2645)

*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

<span id="cri-ld-a"></span>

### CRI-LD-A Results altered before reaching the record

**† Wrong or delayed treatment**

**Threat.** Analyser results pass through middleware and the laboratory information system to the record with no end-to-end integrity check. A changed potassium, troponin or glucose value is filed as genuine, and clinicians treat, discharge or withhold treatment on it.

**Principle.** A result must be provably the value the analyser measured, from instrument to record.

**Design measures:**

1. Sign or hash each result at the analyser or middleware and verify it before filing in the record.
2. Reconcile result counts and values between analyser logs and the record on a schedule, and alert on mismatches.
3. Restrict who and what can edit a validated result, and keep every amendment visible with its reason.

**Card prompts:**

- How do you prove a result is the value the analyser measured?
- Which systems between analyser and record could change a value?
- Would anyone notice a plausible but altered potassium result?

**Mappings:** STRIDE T · CAPEC-153, CAPEC-385 · CWE-924, CWE-353 · ATT&CK T1565.002, T1565.001 · MDS2 IGAU, TXIG, AUDT · IEC 81001-5-1; IEC 80001-1

<span id="cri-ld-k"></span>

### CRI-LD-K Blood matched to the wrong patient

**† Direct harm**

**Threat.** Blood bank systems trust the group, antibody results and sample labels they are given. A changed group, a swapped sample identity or a forged crossmatch release leads to an incompatible transfusion, which can kill within minutes.

**Principle.** Transfusion safety must never rest on a single record that one person or system can change.

**Design measures:**

1. Require two independent identity checks at sampling and at the bedside, enforced by the system, not by policy alone.
2. Keep historical blood group records read-only and flag any new group that differs from them.
3. Log and alert on every manual override of electronic crossmatch or issue rules.

**Card prompts:**

- Which records must agree before blood is released for a patient?
- Could one person or system change a group or crossmatch alone?
- How is sample identity checked from bedside to blood bank?

**Mappings:** STRIDE T, S · CAPEC-153, CAPEC-151 · CWE-1288, CWE-863 · ATT&CK T1565.001 · MDS2 IGAU, AUTH, AUDT · IEC 62304

<span id="cri-ld-q"></span>

### CRI-LD-Q Outsourced pathology fails every hospital

**† Wrong or delayed treatment**

**Threat.** Many hospitals send their tests to one shared pathology provider. When its systems are encrypted or cut off, every hospital it serves loses blood tests, crossmatching and results at once, and operations, cancer care and emergency work stop across a region.

**Principle.** No single laboratory service should be able to stop testing for a whole region.

**Design measures:**

1. Design and contract for a fallback laboratory route, with tested result and request paths, for each critical test.
2. Keep isolated, offline-capable blood bank and urgent testing capacity on each acute site.
3. Rehearse a regional pathology outage with the provider and the hospitals it serves.

**Card prompts:**

- Which hospitals stop testing if the shared provider goes down?
- What tests can run locally when the provider is unreachable?
- How would crossmatching continue during a regional outage?

**Mappings:** STRIDE D · CWE-1357 · ATT&CK T1486, T1199 · MDS2 DTBK, CONN · IEC 80001-1

<span id="cri-ld-j"></span>

### CRI-LD-J Results stop flowing and nobody notices

**† Wrong or delayed treatment**

**Threat.** Interfaces between analysers, middleware and the record fail quietly: a stalled queue, an expired certificate, a dropped feed. Critical results sit undelivered while the ward assumes nothing abnormal came back.

**Principle.** Silence from the laboratory must never look the same as a normal result.

**Design measures:**

1. Send heartbeats on every result interface and alarm to the laboratory and IT when one stops.
2. Show pending and overdue results to the requesting clinician, with the time each was expected.
3. Phone critical results by a defined route that does not depend on the interface working.

**Card prompts:**

- How would anyone know results had stopped flowing to the record?
- What happens to a critical result stuck in a queue?
- Which certificates or feeds could expire silently?

**Mappings:** STRIDE D · CWE-754, CWE-778 · ATT&CK T1489 · MDS2 AUDT, CONN · IEC 80001-1

<span id="cri-ld-10"></span>

### CRI-LD-10 Autoverification rules quietly loosened

**† Wrong or delayed treatment**

**Threat.** Laboratory systems release normal results automatically using rules, reference ranges and critical limits held in configuration. Changing those rules lets abnormal results release as normal, or suppresses critical-value calls, across every patient tested.

**Principle.** The rules that decide what a clinician sees must be controlled like the analyser itself.

**Design measures:**

1. Put autoverification rules, reference ranges and critical limits under change control with two-person approval.
2. Compare the live rule set against an approved baseline every day and alert on any difference.
3. Sample auto-released results for manual review so a loosened rule shows up quickly.

**Card prompts:**

- Who can change autoverification rules and critical limits?
- How is a rule change reviewed before it goes live?
- Would loosened rules be noticed across thousands of results?

**Mappings:** STRIDE T · CAPEC-75, CAPEC-176 · CWE-15, CWE-732 · ATT&CK T1565.001 · MDS2 AUTH, AUDT, IGAU · IEC 62304

<span id="cri-ld-9"></span>

### CRI-LD-9 Bedside tests filed to wrong patient

**† Wrong or delayed treatment**

**Threat.** Glucose meters, blood gas analysers and other bedside tests rely on shared operator codes and patient barcodes that are easily bypassed. Results land on the wrong record, and the wrong patient is treated.

**Principle.** Every bedside test must be tied to a verified operator and a verified patient.

**Design measures:**

1. Require a patient wristband scan before testing, with no manual entry except a logged emergency route.
2. Give each operator an individual credential and lock devices to trained users.
3. Hold results that fail identity checks in a queue for review rather than filing them.

**Card prompts:**

- How is each bedside test tied to an operator and a patient?
- Can staff bypass the patient barcode on a bedside meter?
- Are operator codes on bedside devices individual or shared?

**Mappings:** STRIDE S, R · CAPEC-151 · CWE-308, CWE-1390 · MDS2 PAUT, AUTH, IGAU · IEC 80001-1

<span id="cri-ld-8"></span>

### CRI-LD-8 Pathology slides swapped or edited

**† Wrong or delayed treatment**

**Threat.** Digital pathology stores whole-slide images that pathologists and AI read remotely. If images can be replaced, relabelled or edited, a cancer is missed or invented, and the error looks like a sound diagnosis.

**Principle.** A slide image must stay bound to its specimen and provably unchanged from scanner to report.

**Design measures:**

1. Hash images at the scanner and check the hash whenever an image is opened for reporting.
2. Bind each image to specimen and patient identifiers inside signed metadata, not filenames.
3. Restrict write and delete rights on the image store to the scanning workflow.

**Card prompts:**

- How is a slide image bound to its specimen?
- Who can replace or relabel stored slide images?
- Would a pathologist see that an image had been edited?

**Mappings:** STRIDE T, S · CAPEC-148, CAPEC-165 · CWE-353, CWE-1230 · ATT&CK T1565.001 · MDS2 IGAU, AUTH · DICOM PS3.15

<span id="cri-ld-7"></span>

### CRI-LD-7 Quality control records faked

**† Wrong or delayed treatment**

**Threat.** Quality control and calibration results show whether an analyser can be trusted. If they can be edited or skipped without trace, a drifting analyser keeps reporting wrong values and the laboratory's records say all was well.

**Principle.** Quality control evidence must be captured automatically and be impossible to rewrite quietly.

**Design measures:**

1. Capture QC and calibration results directly from the analyser, not by manual entry.
2. Block patient result release when QC has failed or is overdue, with a logged override.
3. Keep QC history in an append-only store that analyser and laboratory staff cannot edit.

**Card prompts:**

- Is quality control captured automatically or typed in?
- Can a QC result be edited or skipped without trace?
- Who reviews QC trends for a drifting analyser?

**Mappings:** STRIDE T, R · CAPEC-268 · CWE-778, CWE-223 · ATT&CK T1565.001, T1070 · MDS2 AUDT, IGAU · IEC 62304

<span id="cri-ld-6"></span>

### CRI-LD-6 Analysers as a network foothold

**Threat.** Analysers often run an old embedded operating system that the hospital may not patch, on the same network as everything else. One compromised analyser becomes a foothold for ransomware or a route to other laboratory and clinical systems.

**Principle.** An analyser should reach only what it needs and nothing should reach it except its own systems.

**Design measures:**

1. Place analysers in their own network zone with allow-lists limited to middleware and vendor service.
2. Ask for an SBOM and a supported-until date before purchase, and plan replacement around it.
3. Monitor analyser traffic for anything outside its normal pattern.

**Card prompts:**

- What can each analyser reach on the network?
- Who patches analysers, and how long does it take?
- What reaches the analyser that isn't its own system?

**Mappings:** STRIDE E, T · CAPEC-310 · CWE-1104, CWE-1329 · ATT&CK T1210 · EMB3D TID-210, TID-202 · MDS2 SAHD, MLDP, RDMP · IEC 80001-1; IEC 81001-5-1

<span id="cri-ld-5"></span>

### CRI-LD-5 Analyser locked by reagent licensing

**† Wrong or delayed treatment**

**Threat.** Some analysers check reagent tags or licences against the manufacturer's cloud before running. When that link fails, is blocked or the vendor is attacked, testing stops even though reagents and staff are ready.

**Principle.** Clinical testing must not depend on a vendor service being reachable at the moment of the test.

**Design measures:**

1. Require offline grace periods for licence and reagent checks, written into the purchase contract.
2. Test what the analyser does when its vendor link is cut, before go-live.
3. Keep an emergency unlock procedure the laboratory can use without the vendor.

**Card prompts:**

- Does testing stop if the vendor's licence service is unreachable?
- How long can analysers run without the manufacturer's cloud?
- Who is called when reagent checks block testing at night?

**Mappings:** STRIDE D · CWE-1357 · ATT&CK T1489 · MDS2 CONN, RMOT · IEC 80001-1

<span id="cri-ld-4"></span>

### CRI-LD-4 Genomic data leaves the building

**Threat.** Sequencers and analysis pipelines send genomic data to cloud services. Genomes identify patients and their relatives, cannot be reissued after a breach, and are often stored with weaker controls than the clinical record.

**Principle.** Genomic data must be treated as the most sensitive data the hospital holds.

**Design measures:**

1. Encrypt genomic data at rest and in transit and keep keys under the hospital's control.
2. Separate identifiers from sequence data and link them only inside an authorised service.
3. Record every export and limit which destinations a sequencer can send data to.

**Card prompts:**

- Where do sequencers and pipelines send genomic data?
- Are genomic data protected at least as well as the record?
- Who could link a stored genome back to a patient's relatives?

**Mappings:** STRIDE I · LINDDUN I, L, DD · CWE-359, CWE-319 · ATT&CK T1530, T1567.002 · MDS2 STCF, TXCF, DIDT · ISO 27799

<span id="cri-ld-3"></span>

### CRI-LD-3 Public health reports spoofed or suppressed

**Threat.** Laboratories report notifiable infections to public health automatically. If that feed can be forged or blocked, an outbreak goes unseen, or a false one triggers costly responses and alarm.

**Principle.** Reports that drive public health action must be authenticated and their absence noticed.

**Design measures:**

1. Authenticate both ends of the reporting link and sign each report.
2. Reconcile reported cases with laboratory positives daily and investigate gaps.
3. Alert when a reporting feed goes quiet for longer than its normal interval.

**Card prompts:**

- How does public health know a notifiable report is genuine?
- Would anyone notice the reporting feed had stopped?
- Who checks that every required report was sent?

**Mappings:** STRIDE S, T, D · CAPEC-194 · CWE-924 · ATT&CK T1565.002 · MDS2 NAUT, TXIG

<span id="cri-ld-2"></span>

### CRI-LD-2 Laboratory exports leak in spreadsheets

**Threat.** Results are exported to spreadsheets for audit, research and service reviews. Identifiable data spreads into shared drives and email, and formula content in exported cells can run when the file is opened.

**Principle.** Data leaving the laboratory system should carry no more than the task needs.

**Design measures:**

1. Pseudonymise exports by default and require approval for identifiable extracts.
2. Neutralise formula characters in exported fields.
3. Log every export with its requester, purpose and destination.

**Card prompts:**

- What identifiable data goes into exported spreadsheets?
- Where do exported files end up, and who can open them?
- Are exported cells checked for formula content?

**Mappings:** STRIDE I · LINDDUN DD, L · CWE-1236, CWE-212 · ATT&CK T1005 · MDS2 DIDT, MPII, AUDT · ISO 27799

## Seen in the wild

- **Synnovis pathology attack, London, 2024** ([CRI-LD-Q](/taxonomies/hospital-and-medical-devices/cri-laboratory-and-diagnostics/#cri-ld-q)). Ransomware at Synnovis, pathology provider to King's College Hospital and Guy's and St Thomas', led to thousands of postponed operations and appointments and an appeal for O-type blood donors. In June 2025 King's confirmed a patient had died unexpectedly during the attack, with a long wait for a blood test result among the contributing factors; the local care board reported 170 patients harmed, mostly low harm. Sources: [The Register: Qilin ransomware attack on NHS supplier contributed to patient fatality](https://www.theregister.com/2025/06/26/qilin_ransomware_nhs_death/); [Digital Health: Patient death linked to cyber attack on NHS pathology provider](https://www.digitalhealth.net/2025/06/patient-dies-as-a-result-of-cyber-attack-on-nhs-pathology-provider/).

## Mappings

![Laboratory and Diagnostics: the mappings of each entry to STRIDE, LINDDUN, CAPEC, CWE, ATT&CK, EMB3D, MDS2 and standards.](https://www.ostering.com/media/posts/164/hospitals-mapping-table-07-LD.png =1400x1119)

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

---

← [Imaging and Radiation](/taxonomies/hospital-and-medical-devices/cri-imaging-and-radiation/) · [Hospitals and medical devices overview](/taxonomies/hospital-and-medical-devices/) · [Clinical Software and AI](/taxonomies/hospital-and-medical-devices/cri-clinical-software-and-ai/) →

*© 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/).*
