8.4 Integrity Controls

Think about whether 40 units can ever be correct, and who should decide.

1. Block is right only for values that are never valid (e.g. outside the 0.5–100 unit range). 40 units is within the range and is the correct dose for some patients, so blocking would stop legitimate care.
2. Warn relies on the same person who made the error to catch it. Busy staff click through warnings (alert fatigue), so the maker is still checking his own work.
3. Route adds an independent checker (maker-checker, separation of duties). The pharmacist confirms with the doctor before the dose reaches the patient. Legitimate high doses still go through; mistakes are caught.

Best answer: C, route it to a pharmacist to confirm (a warning to the doctor can appear as well, but the independent check is what makes it safe). Keep hard blocks for impossible values.

1. The problem: the medication process relies on the pharmacist as checker (TP2 Verify Order). One overloaded pharmacist is likely to skip checks to save time, especially re-checks of edited orders. Separation of duties then exists only on paper: in practice the maker’s entry goes straight to the patient.
2. Options (compensating controls):
   • Make the system enforce verification: an order (new or edited) cannot be released to the ward until it is verified.
   • Add a second checker for high-risk drugs: two nurses independently double-check before giving insulin, heparin, etc.
   • Use remote pharmacist verification from another site at night.
   • Review all night-shift edits in the morning (detective).

Answer: separation of duties weakens because the single checker skips checks; enforce verification in the system and add compensating checks (nurse double-check, remote verification, morning review).

1. A reconciliation mismatch is a signal to investigate, not proof of which side is wrong.
2. Either side could be wrong: the EHR value could come from an interface or conversion fault; the analyzer value could come from a faulty or uncalibrated analyzer or a bad sample. 0.5 is also a value that would normally be life-threatening, which itself is suspicious.
3. Next checks:
   • the audit trail for the EHR value (who/what wrote it, when, old and new values);
   • the interface: any recent change or update to the analyzer-to-EHR link (change records);
   • the analyzer: calibration and quality-control results;
   • if needed, re-test the sample, and alert the doctor so no treatment decision is based on either value meanwhile.

Answer: C, trust neither yet; investigate (audit trail, interface changes, analyzer QC, re-test) before deciding.

1. Wednesday 23:00 was taken after Monday, so it very likely contains the dormant malware. Restoring it would bring the attacker back, and encryption could start again. Reject A.
2. Sunday 23:00 was taken before the malware arrived, so it is the latest clean restore point. But restoring it alone loses Monday–Wednesday data: orders, results and notes from three days. In a hospital, missing data is itself an integrity failure (incomplete, not current). B alone is not enough.
3. Sunday + rebuild: restore the clean Sunday backup, then re-enter Monday–Wednesday from paper records, the lab and pharmacy systems, and other sources, and verify the result (reconciliation).

Answer: C, restore Sunday 23:00 (clean) and rebuild Monday–Wednesday from paper and other systems. Lesson: keep enough backup history and an immutable copy, and test restores.

1. What happened: during deployment, the new code was not copied to one of eight servers. A reused flag activated old, unused code on that server, which sent a flood of wrong orders at market open.
2. Source: structural/technical (a badly deployed change), not adversarial.
3. Controls:
   • Deploy to ALL servers and verify against a configuration baseline (would have shown one server differed).
   • Remove old, unused code and do not reuse flags (tested in a test system before deployment).
   • A rollback plan that can be executed fast (would have limited the loss).
   • A review step right after deployment.

Answer: an incomplete, unverified deployment woke up dead code; configuration-baseline checks of every server, removal of old code with proper testing, and a fast rollback plan would have prevented or limited the loss.

1. Right way (correction with a trail):
   • keep the original value (40) visible in the history;
   • add the corrected value (4);
   • record who made the correction, when, and why (reason code).
2. Why typing over is wrong:
   • it destroys the evidence that an error happened, so no one can investigate the cause or learn from it;
   • the record is no longer complete, which is itself an integrity failure;
   • the change cannot be traced (Clark-Wilson audit), and it weakens the record’s value as legal evidence.

Answer: keep the original, add the correction, and log who, when and why; overwriting hides the error and breaks the history.