RankShieldMD
RANKSHIELDMD Request 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.

Clinical-AI decision provenance is cryptographic evidence that a specific decision came from an approved, un-tampered model running on clean data. RankShieldMD seals a digest of the model, the inputs, and the output to an externally-anchored, post-quantum-signed transparency log the instant the decision happens, so it is verifiable later, without trusting us, and without exposing any patient information.

attests · never rendersPHI-freenon-device
RANKSHIELDMD LEDGER
LIVE · PHI-FREEsealed 0
01 // THE NEW RISK CLASS

The unprovable
AI decision.

Clinical AI now triages, flags findings, drafts orders, and in early pilots renews prescriptions. When one is later questioned, no one can prove what happened: was it the model you validated, or a drifted, swapped, fine-tuned, or data-poisoned version? Logs can be edited. Dashboards ask for trust. Provenance closes the gap with a verifiable receipt for each decision, generated the moment it happens.

02 // HOW IT SEALS

Four steps.
No patient data.

First, register a cryptographic baseline of the approved model. Second, at decision time, capture digests of the inputs and output, never the PHI, which is rejected at the guard. Third, seal those digests to an append-only transparency log, sign with post-quantum cryptography, and anchor externally. Fourth, emit an evidence package with a verify recipe anyone can run.

03 // THE NON-DEVICE LINE

It attests.
It never renders.

Under the FDA clinical-decision-support criteria, software becomes a regulated device when it produces or drives the clinical decision, the fourth criterion. By staying strictly on the attestation side, proving that a decision was genuine, never making it, RankShieldMD stays non-device: an independent trust signal without inheriting our regulatory burden.

04 // VERIFIABLE

Check it
yourself.

Every proof ships with a verify recipe. Your auditors, an FDA reviewer, or opposing counsel can recompute the hash chain and confirm the post-quantum-signed root using standard tools, without access to your systems and without trusting RankShieldMD. Tamper with the model, the data, or the record, and verification returns false.

05 // GET STARTED

Give every decision
a receipt.

Register a model baseline, run a decision through the same path, and verify the evidence with your own tools. Per decision, verifiable, PHI-free, non-device.

SCROLL TO DESCEND
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[1], 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.

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 June 27, 2025 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.

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. https://www.frontiersin.org/journals/artificial-intelligence/articles/10.3389/frai.2026.1737532/full
  2. [2] npj Digital Medicine / Nature (2025). Quantum cryptography and data protection for medical devices before and after they meet Q-Day. https://www.nature.com/articles/s41746-025-02082-3
  3. [3] FDA (June 27, 2025, final). Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions. https://www.federalregister.gov/documents/2025/06/27/2025-11669
  4. [4] NIST (August 2024). FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), FIPS 205 (SLH-DSA). https://www.nist.gov
  5. [5] Frontiers in Computer Science (January 2026). AIBOM / ML-BOM definition (Radanliev et al.). https://www.frontiersin.org/journals/computer-science/articles/10.3389/fcomp.2026.1735919/full
  6. [6] HHS. HIPAA Security Rule §164.312(b) audit controls; §164.528 accounting of disclosures. https://www.hhs.gov/hipaa
  7. [7] FD&C Act §524B (Consolidated Appropriations Act 2023, effective March 29, 2023). https://www.fda.gov/medical-devices
Answer engine

Clinical-AI provenance, questions answered.

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.

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.