The CDS override defense, recorded as it happened

A patient's family files a complaint with the HHS Office for Civil Rights. They allege that the clinical decision support tool failed to flag a drug-drug interaction. The clinician wrote a prescription. There was an adverse event. The family's lawyer is alleging the override note was added later, after the bad outcome, to cover the clinician.

This is the worst kind of healthcare complaint to defend, because the evidence the OCR wants — the CDS state at the moment of prescription — depends on three different systems that almost never agree about timestamps. The drug-database version was managed by the pharmacy. The clinical guideline edition was managed by medical informatics. The CDS model in force was managed by IT. The override note lives in the EHR.

Reconstructing the whole reasoning state at 14:18 on January 9th is, in most hospital stacks, an eight-week project that costs about $250,000 — and at the end of it you still can't fully prove that the override note was written contemporaneously.

The three questions the OCR will ask

1. What did the CDS know at 14:18? Reconstruct the drug database version, the guideline edition, the patient's allergies on record, the CDS model in force.
2. What did the clinician do with the recommendation? Override or accept. Reason documented or not.
3. When was the override note written? Contemporaneous with the prescription, or after the adverse event?

If those three questions each take a week to research, you've already lost the case in the family lawyer's eyes — even if the override was real, the appearance of incomplete records will produce a settlement.

The bitemporal reconstruction

The first OCR question — "what did the CDS know at 14:18?" — is an AT RECORDED query:

MATCH (e:Encounter) AT RECORDED '2026-01-09T14:18:00Z'
  WHERE e.id = 'ENC-44712'
OPTIONAL MATCH (e)-[:USED_DRUG_DB]->(d:DrugDB) AT RECORDED '2026-01-09T14:18:00Z'
OPTIONAL MATCH (e)-[:USED_GUIDELINE]->(g:Guideline) AT RECORDED '2026-01-09T14:18:00Z'
OPTIONAL MATCH (e)-[:CDS_RECOMMENDED]->(r:Recommendation) AT RECORDED '2026-01-09T14:18:00Z'
RETURN e, d.version, g.version, r

Each MATCH clause reads the clinical knowledge graph as it was recorded at 14:18. The drug DB version (FDB v18.4.2). The guideline edition (Beers Criteria 2023 — the CMS-adopted current edition that day). The recommendation: AVOID warfarin + amiodarone, severe interaction.

The CDS did flag the interaction. The clinician's override was a documented decision the record fully captures. This isn't a tool failure — it's an override decision with a documented reason (rate-control priority).

The override-timing record

This is the question the family's lawyer cares about most. Was the override note written contemporaneously, or after the adverse event?

The graph's write history answers it. Each committed node and relationship write, including the override note, is recorded with the time it was written and the SHA-256 hash of the previous record. In this example the override was recorded at 14:19:03, sixty-three seconds after the prescription. To list the versions of the override record (the id is fictional):

MATCH (o:Override {id: 'OVR-44712'})
CALL db.history(id(o)) YIELD version, timestamp, validFrom
RETURN version, timestamp, validFrom ORDER BY version

timestamp shows when each version was recorded, in nanoseconds since the Unix epoch. If the note had been edited later, the edit would appear as a new version with its own recorded time. GET /graphs/{name}/audit/verify re-hashes the graph’s write history and returns clean or the first broken record. The check covers the whole graph and has no date window. The history log is not signed or anchored outside the server, so the check does not detect a rewrite of the whole log, or removal of the most recent records, by someone with write access to the server. Altering an earlier record in place would make it return the first broken record.

The HIPAA + state privacy bind

While the OCR complaint is open, the family also files a state genetic-privacy deletion request. Most hospital stacks face an impossible bind here — GDPR-equivalent state privacy laws demand deletion, but 45 CFR 164.530(j) requires retention of audit metadata for six years.

Crypto-shred (per-subject encryption keys and key destruction) is in development. Contact us before relying on it for erasure requests.

The numbers

The figures in this post and in the walkthrough are illustrative. The queries above give the reviewer what the CDS recorded at 14:18, when the override was recorded, and the result of the history check.

Illustrative walkthrough on the Healthcare tab.