RankShieldMD
Request early access
Resource // Clinical-AI decision provenance

What clinical-AI
decision provenance is.

And why every AI decision needs a receipt. It attests the decision. It never makes it. That boundary is what keeps it non-device.

Read the guide → The product
Attests, never rendersPHI-freePost-quantumNon-device
What it is

What clinical-AI decision provenance is (and why every AI decision needs a receipt)

Clinical-AI decision provenance is cryptographic evidence that a specific clinical-AI decision came from an approved, un-tampered model running on clean data, sealed at decision time to an externally-anchored, tamper-evident log and independently verifiable later, without exposing patient data. As AI moves from the research bench into triage, imaging, documentation, and early autonomous-prescribing pilots, a new class of risk appears that traditional security never addressed: not the theft of data, but the unprovable decision. A recommendation reaches a patient, and weeks later no one can confirm which model produced it, on which version, or whether the inputs were intact. The published framework for an auditable, source-verified clinical-AI record[1] establishes the academic ground here; RankShieldMD ships the commercial, externally-anchored, post-quantum, per-decision implementation of that idea. Two principles govern the design, and we hold to both honestly: attest, don't decide, and prove without exposing, so verification never requires revealing protected health information.

How do you prove a clinical-AI decision is genuine?

You prove it by separating the proof from the data: recording verifiable statements about a decision rather than its clinical contents. RankShieldMD attests each decision in four steps, and none of them touch patient data. First, it registers a cryptographic baseline of the approved model, a hash of the model and its container, so there is a fixed reference for what the validated model means.

Second, at decision time, it captures digests of the inputs and the output, never the underlying PHI, which is rejected at the guard before anything is sealed. Third, it seals those digests, together with the model fingerprint and a per-decision credential, to an append-only transparency log built on the same certificate-transparency principle standardized as RFC 6962[8], signs them with composite post-quantum cryptography, and anchors the log root to an external record so the structure is pinned in time. Fourth, it emits an evidence package with a verify recipe: an auditor, an FDA reviewer, or opposing counsel can recompute the hash chain and confirm the signed root using standard tools, without access to your systems and without trusting RankShieldMD. Tamper with the model, the data, or the record after the fact, and verification returns false. The medical data stays where it belongs, governed by the clinical systems built for it, while RankShieldMD holds only the cryptographic proof about the decision. That separation is what lets the same evidence be handed to a hospital board, a regulator, and opposing counsel without any of them needing access to the patient record itself.

How a clinical-AI decision becomes verifiable, PHI-free evidence in four steps THE ATTESTATION FLOW How a decision becomes verifiable, PHI-free evidence 1 Registerbaseline Hash of theapproved modeland container. 2 Capturedigests Inputs and outputonly. Raw PHI isnever captured. 3 Seal andsign Append-only log,post-quantum sig,external anchor. 4 Emitevidence Verify recipe.Anyone recomputesthe hash chain. The guard rejects raw identifiers Verify later, without the patient record: Intact evidence → verify true Tampered evidence → verify false
The four-step attestation flow. Digests of the model, inputs, and output are sealed and signed, while raw protected health information is rejected at the guard, so the evidence stays checkable without ever holding patient data.

Why can't ordinary logs prove an AI decision?

Ordinary logs cannot prove a decision because they are mutable and PHI-laden: they can be edited after the fact, and they usually sit alongside the very data they are meant to protect. An API log or an LLM trace records what a system claims happened, not a tamper-evident statement anyone can independently check.

HIPAA already expects mechanisms to record and examine activity in systems containing electronic protected health information under the Security Rule audit-control standard[6], but a log that a privileged user can quietly rewrite does not survive the question prove this one. A record that documents a clinical decision needs two properties an ordinary log lacks. It must be operation-level and tamper-evident, cryptographically chained or write-once, so a later edit is detectable. And, done right, it should hold no PHI at all, only one-way digests, verified identities, and event metadata. RankShieldMD is built to both requirements, which is why adopting it shrinks the covered-entity footprint rather than enlarging it: the ledger is useless to a thief because there is no protected data inside it to steal.

Does proving a decision make the software an FDA device?

No. Proving a decision keeps the software non-device, because it never produces or drives the clinical decision itself. Under the FDA clinical-decision-support criteria, software crosses into being a regulated device on the fourth criterion, when it makes or drives the decision. RankShieldMD is engineered to stay on the other side of that line.

Its clinical-AI capability attests that a decision was genuine, that a given output truly came from a given model, on a given version, with intact inputs, at a given time, and it never renders, scores, or recommends the decision. That boundary is not modesty; it is a safety and honesty requirement. A provenance layer that quietly positioned itself as a decision-maker would invite the over-reliance that makes clinical AI dangerous, and it would misrepresent what the technology does. The February 3, 2026 FDA final guidance on cybersecurity in medical devices sets the expectations that RankShieldMD evidence helps a submission satisfy[3], and the FD&C Act §524B obligations for cyber devices are the statutory backdrop[7]. RankShieldMD supports those submissions; it is not itself a clearance, and it never makes a medical claim. Keeping the role bounded to verifiable attestation has a practical payoff that SaMD and clinical-AI vendors care about directly: you gain an independent integrity signal for your model without pulling a new component into your device classification, and RankShieldMD never enters your device clinical pathway. Claim only what you can prove is the discipline, applied where the cost of overclaiming is highest.

How is provenance different from an AIBOM or model monitoring?

Provenance differs from an AIBOM and from model monitoring because they operate at different layers, and the difference is the whole point. An AI bill of materials and a model card describe a model at the supply-chain level, its components, datasets, and lineage, a static inventory of what went into the system[5]. Model monitoring watches aggregate behavior over time, flagging drift across many predictions.

Both are useful, and RankShieldMD can emit AIBOM artifacts itself. But neither proves anything about an individual runtime decision. When a specific result is questioned after the fact, an inventory of the model's ingredients and a dashboard of last month's drift cannot tell you whether this decision came from the approved model on intact data. Per-decision provenance is the finer, missing layer: a cryptographic receipt for each decision, sealed at the moment it happens, that can be verified in isolation. It is the difference between knowing what is generally in the kitchen and having a signed, tamper-evident receipt for the specific meal that was served. Governance platforms document risk and policy; monitoring tools observe behavior; RankShieldMD proves the decision. The three are complementary layers, not substitutes. Provenance is simply the one that survives the question prove this one, because it attaches a checkable record to each individual decision rather than to the program that produced them all. A buyer evaluating AI-trust tooling should ask which layer a vendor actually delivers, since a governance dashboard and a per-decision receipt are easy to conflate and very different to rely on when a single decision is challenged.

Does decision provenance tell you the citations are real?

No, and the distinction is worth drawing sharply because the two questions get collapsed constantly. Decision provenance answers which model produced this output, on which inputs, unaltered since. Evidence provenance answers a different question: are the sources this output cited real, and do they say what the output claims they say. A system can have either without the other. A perfectly sealed decision record tells you nothing about whether the paper it referenced exists, and a well-grounded retrieval pipeline with genuine citations tells you nothing about which model version ran.

The second question is not hypothetical. A 2026 study in Critical Care Explorations had two blinded domain-expert reviewers check 300 references generated by three frontier models across ten neurocritical care topics, verifying each against PubMed, DOI, Google Scholar and CrossRef. It found that "165 of 300 references (55.0%) contained a verifiable citation inaccuracy" and "85 of 300 (28.3%) were completely fabricated."[9] Those are references a clinician would have to check by hand to catch.

For clinical decision support specifically, this reaches further than accuracy. The FDA's fourth criterion, the one that separates non-device software from a regulated device, requires that the software let a health care professional independently review the basis of a recommendation.[7] A citation the clinician cannot verify, or that misrepresents the source it points to, erodes the exact property that criterion depends on. Citation traceability is not a quality nicety in a CDS context. It is load-bearing for the line the product is trying to stay on the right side of, which we cover in non-device by design.

An evidence-provenance record binds different fields than a decision record. It needs the identity of each retrieved source, a stable one such as a DOI or PMID, a digest of the passage actually supplied to the model rather than the document as a whole, and the binding of both to the output that used them. The passage digest is the part usually skipped, and it is what lets someone later confirm that the sentence relied on was really in that source at that time, rather than a paraphrase the model produced and attributed.

One honest limit. Sealing which source was retrieved, and that the record has not been altered, is a mechanical claim we can make. Judging whether a real source actually supports the clinical assertion made from it is a clinical and editorial function, not a cryptographic one. Provenance can prove a citation was present and unaltered. It cannot prove the citation was apt.

Why does the proof need to be quantum-safe?

The proof needs to be quantum-safe because the evidence behind a clinical decision must stay unforgeable for as long as the decision matters, and that is measured in decades, well within the window where quantum computers could threaten today's cryptography[2]. A proof that is unforgeable now but forgeable in fifteen years is not good enough for a record of a person's care.

There is also a specific, documented threat pattern: harvest now, forge later, where an adversary copies today's classically-signed evidence and waits for a capable quantum computer to forge or repudiate it retroactively. Long-retention healthcare records are an attractive target precisely because they are kept for so long[2]. That is why RankShieldMD signs every attestation with composite post-quantum signatures, ML-DSA-65 paired with Ed25519, built to the NIST post-quantum standards FIPS 203, 204, and 205[4], so the evidence stays verifiable and unforgeable as cryptography evolves. We state the posture honestly: it is quantum-safe, not quantum-proof. No quantum computer capable of breaking current cryptography exists yet, and no one can guarantee any system is unbreakable; what we can do is build to the standards so a decade of decisions stays defensible.

References

Sources

  1. [1] Frontiers in Artificial Intelligence (2026). An auditable and source-verified framework for clinical AI decision support: integrating RAG with data provenance. frontiersin.org →
  2. [2] npj Digital Medicine / Nature (2025). Quantum cryptography and data protection for medical devices before and after they meet Q-Day. nature.com →
  3. [3] FDA (February 3, 2026, final). Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions. federalregister.gov →
  4. [4] NIST (August 13, 2024). FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), FIPS 205 (SLH-DSA). csrc.nist.gov →
  5. [5] Frontiers in Computer Science (January 2026). Operationalising artificial intelligence bills of materials for verifiable AI provenance and lifecycle assurance (Radanliev et al.). frontiersin.org →
  6. [6] HHS/OCR. HIPAA Security Rule 45 CFR §164.312(b) audit controls; §164.528 accounting of disclosures. ecfr.gov →
  7. [7] FD&C Act §524B (Consolidated Appropriations Act 2023, effective March 29, 2023). fda.gov →
  8. [8] IETF (June 2013). RFC 6962, Certificate Transparency. rfc-editor.org →
  9. [9] Critical Care Explorations (2026). Hallucination Rate of Peer-Reviewed Citations Generated by Large Language Models in Neurocritical Care. 300 references across three models, verified against PubMed, DOI, Google Scholar and CrossRef by two blinded domain-expert reviewers. pmc.ncbi.nlm.nih.gov
Knowledge check

Check your understanding of decision provenance.

A quick check on the key points. Pick an answer to see whether it holds and why.

Question 1 of 5

What does clinical-AI decision provenance actually prove?

Question 2 of 5

How does the seal avoid touching protected health information?

Question 3 of 5

Does attesting a decision make the software an FDA-regulated device?

Question 4 of 5

How is per-decision provenance different from an AIBOM or model monitoring?

Question 5 of 5

Why does the proof need to be quantum-safe?

Answer engine

Clinical-AI provenance, questions answered.

Straight answers about verifiable healthcare AI. Tap a question, or type your own.

Jamie Kloncz, founder of RankShieldMD
Jamie Kloncz, founderverified human ✓
Ask me anything about proving your clinical AI. I built RankShieldMD so a small practice can prove its AI, not just be asked to trust it.
Does decision provenance tell you an AI CDS citation is real?
No. Those are two different questions and they are routinely collapsed. Decision provenance answers which model produced an output, on which inputs, unaltered since. Evidence provenance answers whether the sources cited are real and say what the output claims. A sealed decision record tells you nothing about whether the referenced paper exists, and a well-grounded retrieval pipeline tells you nothing about which model version ran. A 2026 study in Critical Care Explorations found that of 300 model-generated references checked against PubMed, DOI, Google Scholar and CrossRef, 55.0% contained a verifiable citation inaccuracy and 28.3% were completely fabricated.
Why does citation traceability matter for the FDA non-device line?
Because the fourth clinical decision support criterion requires that the software let a health care professional independently review the basis of a recommendation. A citation the clinician cannot verify, or one that misrepresents the source it points to, erodes the property that criterion depends on. In a CDS context, traceable evidence is not a quality nicety, it is load-bearing for staying non-device. An evidence record has to bind the identity of each retrieved source, a digest of the passage actually supplied to the model, and the binding of both to the output. RankShieldMD can seal which source was retrieved and that the record is unaltered; whether a real source supports the clinical assertion is a clinical judgment, not a cryptographic one.
What is clinical-AI decision provenance?
Clinical-AI decision provenance is cryptographic evidence that a specific clinical-AI decision came from an approved, un-tampered model running on clean, unaltered data. RankShieldMD seals a digest of the model, the inputs, and the output to an externally-anchored, post-quantum-signed transparency log at the moment the decision is made. Anyone holding the evidence can verify it later, without trusting the vendor and without exposing any patient data. The published academic framing calls this an auditable, source-verified clinical-AI record; RankShieldMD ships the commercial, per-decision implementation of that idea.
Why does every clinical-AI decision need a receipt?
Because when a decision is later questioned, someone has to prove what actually happened: which model ran, on what version, and on what data. Ordinary logs can be edited, and dashboards ask you to trust them. A cryptographic receipt, generated at decision time and sealed to an append-only log, makes the answer checkable instead of assertable. Clinical AI now triages, flags findings, drafts orders, and in early pilots renews prescriptions. As autonomy grows, so does the number of moments a board, an auditor, or a regulator may ask you to prove a single decision was genuine.
How does the seal avoid touching patient data?
It records verifiable statements about a decision, not its clinical contents. RankShieldMD captures one-way digests of the inputs and the output plus a fingerprint of the model, then seals those digests to the transparency log. Raw identifiers and protected health information are rejected at the guard before anything is written, so no PHI enters the ledger. The medical data stays in the clinical systems built to govern it. The proof about the decision is all that RankShieldMD holds, which is why adopting it shrinks a covered entity footprint rather than growing it.
Does proving a decision make the software an FDA device?
No. Under the FDA clinical-decision-support criteria, software becomes a regulated device when it produces or drives the clinical decision itself, which is the fourth criterion. RankShieldMD is engineered to stay on the other side of that line. It attests that a decision was genuine and never renders, scores, or recommends the decision. That boundary keeps RankShieldMD non-device, keeps clinical judgment with clinicians, and gives a vendor an independent integrity signal without inheriting RankShieldMD regulatory burden. It supports FDA submissions and EU documentation; it is not itself a clearance.
How is provenance different from an AIBOM or model monitoring?
They work at different layers. An AI bill of materials and a model card describe a model at the supply-chain level: its components, datasets, and lineage, a static inventory. Model monitoring watches aggregate behavior over time and flags drift. Neither proves anything about an individual runtime decision. Per-decision provenance is the finer, missing layer: a cryptographic receipt for each decision, sealed the moment it happens, verifiable in isolation. RankShieldMD can emit AIBOM artifacts too, but that is a separate capability. Governance documents risk, monitoring observes behavior, and provenance proves the specific decision that was questioned.
Does the ledger ever hold protected health information?
No. RankShieldMD is PHI-free by construction. Model, input, and output are reduced to digests, and raw identifiers are rejected at the guard, so protected data never enters the log. This is both a privacy design and a security one: the ledger is useless to anyone who steals it, because there is nothing sensitive inside. It also maps cleanly to HIPAA audit-control expectations for recording and examining system activity, since the record is operation-level and tamper-evident rather than a copy of the underlying patient data.
Why does the proof need to be quantum-safe?
Because the evidence behind a clinical decision must stay unforgeable for as long as the decision matters, and that is measured in decades. A documented threat pattern, harvest now and forge later, has an adversary copy today classically-signed evidence and wait for a capable quantum computer to forge or repudiate it retroactively. Long-retention healthcare records are an attractive target for exactly that reason. RankShieldMD signs every attestation with composite ML-DSA-65 and Ed25519, built to the NIST post-quantum standards. It is quantum-safe, not quantum-proof: no quantum computer able to break current cryptography exists yet, and we never claim otherwise.
Get started

Turn "trust our model" into "verify our model."

Register a baseline, attest a decision, and hand your buyer proof they can check. Per decision, verifiable, PHI-free, non-device.

Run a verification → The product