Records and Patient Data (RC)

Records and Patient Data (CRI-RC), The Hospital: a radiograph of a stack of records with a padlock.

Taxonomies › Hospitals and medical devices › Records and Patient Data

The Hospital · CRI-RC · suit 09 of 17 · 13 entries

The EHR and patient administration, orders and results, identity matching, sensitive categories, portals, research use and the audit trail.

Scope: EHR/EPR, patient administration, orders and results, identity matching and duplicate records, problem and allergy lists, record integrity, mass data theft, extortion of patients, sensitive categories (mental health, sexual health, genomic, HIV, abortion, VIP), research and secondary use, de-identification, data sharing with insurers and governments, audit logs, patient portals.

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.

Records and Patient Data: 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-RC-A Allergies and medications rewritten

† Wrong or delayed treatment

Threat. Clinicians act on the allergy list, medication history, blood group and resuscitation status in the record. If these can be changed without strong control and visible history, a patient is given a drug they react to, or not resuscitated.

Principle. Safety-critical facts in the record must be hard to change and every change must be obvious.

Design measures:

  1. Require re-authentication and a reason to change allergies, resuscitation status or blood group.
  2. Show recent changes to safety-critical fields prominently to the next clinician.
  3. Alert on bulk or unusual edits to these fields across many patients.

Card prompts:

  • Who can change allergies, blood group or resuscitation status?
  • How obvious is a recent change to a clinician opening the record?
  • What review follows a change to a safety-critical fact?

Mappings: STRIDE T · LINDDUN Nc · CAPEC-1 · CWE-862, CWE-863 · ATT&CK T1565.001 · MDS2 IGAU, AUDT, AUTH · ISO 27799

CRI-RC-K Whole record stolen for extortion

Threat. The record holds every patient’s history in a few databases and reporting replicas. Attackers copy it in bulk, then extort the hospital and threaten to publish, and the data can never be taken back.

Principle. No single account or system should be able to copy the whole patient record unnoticed.

Design measures:

  1. Limit bulk query and export rights to a few monitored service accounts.
  2. Detect and alarm on unusual volumes leaving reporting databases and backups.
  3. Encrypt replicas and backups with keys held separately from the systems that read them.

Card prompts:

  • Which accounts or systems could copy the whole record?
  • Would a bulk export from a reporting replica raise an alarm?
  • How are backups and replicas protected from the same theft?

Mappings: STRIDE I · LINDDUN DD, I · CAPEC-116 · CWE-359, CWE-1220 · ATT&CK T1213.006, T1567.002, T1657 · MDS2 STCF, AUDT, MPII · ISO 27799

CRI-RC-Q Patients extorted one by one

Threat. Therapy notes, sexual health and other sensitive records are stored as readable text. Once stolen, attackers contact patients individually and demand payment to keep their notes private.

Principle. The most sensitive notes must be useless to anyone who steals them.

Design measures:

  1. Encrypt sensitive note categories at field level with separately held keys.
  2. Prepare a plan to warn and support patients quickly if notes are taken.
  3. Keep sensitive notes out of bulk extracts and reporting copies.

Card prompts:

  • Which notes would hurt a patient most if published?
  • Are those notes stored as readable text?
  • What support would patients get if their notes were stolen?

Mappings: STRIDE I · LINDDUN DD, I, L · CWE-312, CWE-359 · ATT&CK T1657, T1005 · MDS2 STCF, MPII · ISO 27799

CRI-RC-J Two patients become one record

† Wrong or delayed treatment

Threat. Patient matching merges records on name, date of birth and partial identifiers. A wrong merge or a stolen identity mixes another person’s allergies, results and diagnoses into a patient’s record, and both are treated on the wrong history.

Principle. Merging identities must be deliberate, reviewed and reversible.

Design measures:

  1. Require review of merges below a high matching confidence, by trained staff.
  2. Keep merges reversible with full history of which data came from which identity.
  3. Flag records where new data conflicts with established facts, such as blood group or sex at birth.

Card prompts:

  • Which identifiers does patient matching rely on?
  • Who reviews a merge before it takes effect?
  • How is a wrong merge undone, and who is told?

Mappings: STRIDE S, T · LINDDUN L, I · CAPEC-151 · CWE-1288 · MDS2 IGAU, AUDT · ISO 27799

CRI-RC-10 Sensitive categories open to every user

Threat. Mental health, sexual health, HIV, abortion, gender identity and genetic records are visible to anyone who can open the patient. Where the law, family or employer is hostile, disclosure puts the patient at real risk.

Principle. Access to sensitive categories should follow the care relationship, not the login.

Design measures:

  1. Tag sensitive categories and restrict them to the treating team, with logged break-glass.
  2. Let patients choose additional restrictions where the law allows.
  3. Keep sensitive categories out of default printouts, summaries and shared feeds.

Card prompts:

  • Who can open mental health, sexual health or genetic records?
  • Does access follow the care relationship or just the login?
  • What extra step guards the most sensitive categories?

Mappings: STRIDE I · LINDDUN DD, I, Nc · CWE-1220, CWE-359 · MDS2 AUTH, MPII · ISO 27799

CRI-RC-9 Staff browse records without reason

Threat. Insiders look up celebrities, colleagues, neighbours and former partners. Access is logged, but nobody reviews the logs, so curiosity and stalking go unnoticed and unpunished.

Principle. Every look at a record should be attributable and reviewed against a care relationship.

Design measures:

  1. Analyse access logs automatically for patients with no care link to the viewer.
  2. Flag high-interest records and alert on access to them.
  3. Tell staff the logs are reviewed and act visibly on findings.

Card prompts:

  • Who reviews access logs, and how often?
  • How would a colleague browsing a neighbour’s record be detected?
  • What happens to staff found looking without reason?

Mappings: STRIDE I, R · LINDDUN DD, D, I · CAPEC-122 · CWE-778 · ATT&CK T1213 · MDS2 AUDT, AUTH · ISO 27799

CRI-RC-8 Patient portal accounts taken over

Threat. Portals let patients and their proxies read records and message clinicians. Reused passwords, weak recovery and loose proxy access let attackers, or a coercive partner or relative, read and change what the patient sees.

Principle. Portal access must be as strong as the data it shows, and proxies must be revocable by the patient.

Design measures:

  1. Offer phishing-resistant authentication and detect credential stuffing.
  2. Let patients see and revoke proxies, and alert them to new devices and proxy access.
  3. Make account recovery require more than details found in the record.

Card prompts:

  • How strong are portal logins and account recovery?
  • Who can be granted proxy access, and can the patient revoke it?
  • How would a coercive relative’s access be noticed?

Mappings: STRIDE S, I · LINDDUN DD, I, L · CAPEC-600 · CWE-308, CWE-640 · ATT&CK T1110.004 · MDS2 PAUT, AUDT · ISO 27799

CRI-RC-7 Health data shared beyond its purpose

Threat. Tracking scripts on appointment and portal pages, research extracts and contracts with insurers or authorities move health data to parties the patient never expected. Once shared, it is linked with other data and cannot be recalled.

Principle. Each flow of patient data must have a stated purpose and the least data it needs.

Design measures:

  1. Remove third-party tracking from any page that shows or collects health data.
  2. Keep a register of data flows with purpose, legal basis and owner, reviewed yearly.
  3. Send only the fields each recipient needs.

Card prompts:

  • Which third parties receive data from portal and appointment pages?
  • Does every data flow have a stated purpose?
  • What does each extract contain beyond what its purpose needs?

Mappings: STRIDE I · LINDDUN DD, U, Nc, L · CWE-201, CWE-359 · MDS2 MPII, DIDT · ISO 27799

CRI-RC-6 De-identified data re-identified

Threat. Research and analytics datasets have names removed but keep dates, postcodes, rare conditions and free text. Linking them with other data identifies patients, sometimes in seconds.

Principle. Treat de-identification as a risk to measure, not a step that is done.

Design measures:

  1. Assess re-identification risk for each release and generalise rare values.
  2. Remove or scrub free text before release.
  3. Release data inside a controlled research environment instead of handing out copies.

Card prompts:

  • Which quasi-identifiers remain in research datasets?
  • Has anyone measured the re-identification risk?
  • Who decides whether free text can leave the record?

Mappings: STRIDE I · LINDDUN L, I, DD · CWE-212, CWE-359 · MDS2 DIDT · ISO 27799

CRI-RC-5 Audit trail can be edited

Threat. System administrators and vendor support can change or delete audit records. Then nobody can prove who changed a record or viewed it, which matters in incidents, complaints and court.

Principle. The audit trail must be beyond the reach of the people and systems it records.

Design measures:

  1. Ship audit records to a separate, append-only store as they are written.
  2. Separate audit administration from system administration.
  3. Check the audit stream for gaps and alarm when it stops.

Card prompts:

  • Who can alter or delete audit records, including vendor support?
  • Where is the audit trail kept, out of administrators’ reach?
  • Could you prove in court who viewed a record?

Mappings: STRIDE R · LINDDUN Nr · CAPEC-268 · CWE-778, CWE-223 · ATT&CK T1070 · MDS2 AUDT · ISO 27799

CRI-RC-4 Records released to impostors

Threat. Records teams answer requests from patients, police, insurers and solicitors by phone, email and post. Someone posing as the patient or an official obtains a full record.

Principle. Release of records must verify who is asking and whether they are entitled.

Design measures:

  1. Verify identity through a channel already on file, not one given in the request.
  2. Send records through an authenticated portal rather than email or post.
  3. Review third-party requests for entitlement and release the minimum needed.

Card prompts:

  • How do records staff verify who is asking for a record?
  • Which requests arrive by phone or email, and how are they checked?
  • What would an impostor need to obtain a full record?

Mappings: STRIDE S, I · LINDDUN DD, I · CAPEC-407, CAPEC-412 · CWE-1390 · ATT&CK T1598.004 · MDS2 PAUT, MPII · ISO 27799

CRI-RC-3 Printouts and caches left behind

Threat. Shared workstations, browser caches, downloaded letters and downtime printouts hold patient data long after the task. Anyone using the next session, bin or printer tray can read them.

Principle. Patient data should not outlive the task on shared equipment.

Design measures:

  1. Clear local caches and downloads when a clinical session ends.
  2. Use secure print release and confidential waste on wards.
  3. Lock or log off unattended sessions quickly, using tap-to-switch to keep it practical.

Card prompts:

  • What patient data stays on shared workstations after a session?
  • Where do downtime printouts end up?
  • Who clears browser caches and downloaded letters, and when?

Mappings: STRIDE I · LINDDUN DD · CAPEC-204 · CWE-524, CWE-525 · ATT&CK T1005 · MDS2 ALOF, STCF · ISO 27799

CRI-RC-2 Patients cannot see who looked

Threat. Patients have no view of who accessed their record or where it was shared. They cannot notice misuse, object to a disclosure or correct what was sent.

Principle. Patients should be able to see how their record has been used.

Design measures:

  1. Show patients an access and sharing history in the portal.
  2. Let patients report access they do not recognise and track the response.
  3. Explain in plain language who routinely sees their record and why.

Card prompts:

  • Can patients see who accessed their record?
  • How would a patient object to a disclosure?
  • Where can patients see where their record was shared?

Mappings: STRIDE R · LINDDUN U, Nc · CWE-223 · MDS2 AUDT, MPII · ISO 27799

Seen in the wild

Mappings

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

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

← Clinical Software and AI · Hospitals and medical devices overview · Integration and Interoperability →

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