Prove your model.
Keep your buyers.
Give every decision your model makes an independent receipt your hospital buyers can verify. No device burden. No PHI. No asking anyone to just trust you.
RankShieldMD is an independent evidence layer for clinical-AI and SaMD vendors. It seals a digest of your model, its inputs, and its output to an externally-anchored, post-quantum-signed transparency log at the moment of each decision, so your buyers can verify your model instead of trusting it — without you exposing patient data or inheriting a device burden you never signed up for.
Buyers will demand
per-decision proof.
Clinical AI is moving toward autonomous action — early autonomous-prescribing pilots, an FDA clearance for autonomous care, and the agency's first AI warning letter in April 2026. As models act with less human review, health-system procurement stops asking whether your model is accurate in aggregate and starts asking whether this decision was genuine. A vendor who can only assert integrity stalls in security review; a vendor who can hand over a verifiable receipt for every decision moves through it.
The trust signal,
not the device burden.
Under the FDA's clinical-decision-support criteria, software becomes a regulated device when it produces or drives the decision — the fourth criterion. RankShieldMD stays strictly on the attestation side of that line: it proves that a decision was genuine, and never makes one. So you gain an independent integrity signal for your model without adding regulatory surface to your product. Attest, don't render — that is what keeps this evidence non-device.
It feeds your
PCCP and postmarket.
Provenance is the integrity trail a predetermined change-control plan needs to show the deployed model matches the authorized one. The same per-decision receipts carry into FDA postmarket monitoring and into EU AI Act technical documentation. One attestation stream supports several obligations, so the evidence you generate for a buyer is the same evidence you file with a regulator. It supports your compliance work; it does not replace it.
Turn a claim
into a sales asset.
Most vendors offer attestations a buyer must take on faith. RankShieldMD ships proofs a buyer's security team can check: recompute the hash chain, confirm the post-quantum-signed root, with no access to your systems and no need to trust you or us. That turns "trust our model" into "verify our model" — a concrete differentiator in the security review that usually slows enterprise health-system deals. Independent verifiability is a procurement advantage.
Register a baseline.
Hand over proof.
Register a cryptographic baseline of your approved model, attest decisions at runtime on digests only, and give your buyer evidence they can verify themselves. Per decision, PHI-free, non-device.
What does RankShieldMD do for a clinical-AI vendor?
For a clinical-AI or SaMD vendor, RankShieldMD is an independent evidence layer that attaches a cryptographic, externally-verifiable receipt to every decision your model makes — proving the output came from your approved, un-tampered model on intact data, without exposing patient information and without turning your product into a regulated device. It is not a rival model and it never renders a clinical decision; it sits alongside the model you already ship and attests what it does. At decision time it seals a digest of the model, the inputs, and the output to an externally-anchored, post-quantum-signed transparency log, and it emits an evidence package with a verify recipe your buyer can run. Two principles govern the design, and we hold to both honestly: attest, don't decide — RankShieldMD proves provenance, it never makes clinical judgments — and prove without exposing, so verification never requires revealing protected health information. The result is a trust signal you can hand to a hospital security team, a regulator, or your own board, and each of them can confirm it independently. We are careful about what we claim: it supports your compliance obligations, it does not make you compliant, and we did not invent verifiable clinical-AI audit.
Why will your hospital buyers soon demand decision provenance?
Because clinical AI is crossing from suggestion into action, and procurement follows the risk. For years a clinical-AI tool proposed and a clinician disposed, so a buyer could reasonably lean on human review as the backstop. That backstop is thinning. Documented 2026 developments point the same direction: an autonomous-prescribing pilot, an FDA clearance for autonomous care, and the FDA's first AI warning letter in April 2026. As models act with less human review in the loop, the question a hospital security team asks changes shape. It is no longer only "is your model accurate across a population" but "can you prove this decision came from the model you validated, on data that was not altered, at the time it was made." A vendor who can only assert integrity — pointing at logs that can be edited and dashboards that ask for trust — stalls in that review. A vendor who can hand over a verifiable receipt for each decision answers it directly. Per-decision provenance is quietly becoming a procurement requirement rather than a nice-to-have, and the vendors who build it in early will meet the demand instead of scrambling to retrofit it once a buyer, or a regulator, insists.
How do you get the trust signal without becoming a regulated device?
By attesting decisions rather than rendering them — a boundary the FDA's own rules draw precisely. Under the clinical-decision-support criteria, software crosses into being a regulated device when it produces or drives the clinical decision itself; that is the fourth criterion. RankShieldMD is engineered to stay on the other side of it. Its role is to prove 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 scores, recommends, or makes the decision. Because this evidence layer only attests and never renders, adding it to your product does not add regulatory surface to your product. You gain an independent integrity signal that a buyer can verify, and you keep the device classification you already hold; RankShieldMD does not enter your clinical pathway and does not inherit or transfer a device burden. That discipline is deliberate, and it is also an honesty commitment: a provenance layer that quietly positioned itself as a decision-maker would invite exactly the over-reliance that makes clinical AI dangerous, and it would misrepresent what the technology does. Keeping the role bounded to verifiable attestation is what lets a vendor take the trust signal and leave the device burden behind.
How does provenance feed a predetermined change-control plan (PCCP)?
By supplying the integrity trail that shows the deployed model matches the authorized one at every moment. A predetermined change-control plan commits a vendor to a defined, pre-agreed process for updating a model without a fresh submission for each change. The plan describes what may change and how; provenance is the evidence that only sanctioned changes actually happened. RankShieldMD registers a cryptographic baseline of the approved model, and when you ship an update that falls inside your plan, the sealed baseline moves with it. At any point you can demonstrate which version was live and that no unsanctioned model ran in production — the exact integrity claim a PCCP relies on. The same per-decision receipts do double duty beyond the plan: they are integrity evidence you can carry into FDA postmarket monitoring, where you must show the fielded model is behaving as authorized, and into EU AI Act technical documentation, which expects a durable record of the system's operation. One attestation stream, several obligations. We state the boundary plainly: this supports a PCCP, postmarket monitoring, and EU documentation; it is not itself a clearance, and it makes no medical claim. It gives your regulatory team defensible, independently-checkable evidence to build those documents on, rather than asking reviewers to take integrity on faith.
What does it take to integrate?
Two moves, neither of which touches patient data. First, register a cryptographic baseline of your 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, attest through RankShieldMD: it captures digests of the inputs and the output, never the PHI, which is rejected at the guard before anything is sealed. Those digests, the model fingerprint, and a per-decision credential are sealed to an append-only transparency log, signed with composite post-quantum cryptography, and anchored to an external record so the whole structure is pinned in time. You get back an evidence package with a verify recipe your buyer, an auditor, or an FDA reviewer can run using standard tools, without access to your systems and without trusting RankShieldMD. Because the attestation runs alongside the decision on digests rather than gating the clinical output, it does not change your model's behavior or your clinical flow — it is an evidence sidecar, not a control point in the pathway. That also means integrating it does not alter your product's regulatory status. The work is measured in a baseline registration plus an attestation call, not a re-architecture, and the evidence you generate is the same evidence you hand to a buyer and file with a regulator.
Where to go next.
Clinical-AI decision provenance
The per-decision receipt: cryptographic evidence that an output came from your approved model on intact data, PHI-free and non-device.
Explore →PRODUCTDiagnostic Provenance Ledger
The externally-anchored, post-quantum-signed transparency log every attestation seals to, verifiable without trusting the vendor.
Explore →REGULATORYFDA clinical decision support
How the attest-not-render boundary maps to the FDA CDS criteria and keeps this evidence layer non-device by design.
Explore →What we are careful never to claim.
It attests, it does not render
RankShieldMD proves a decision was genuine; it never scores or makes one. Because it only attests, this evidence keeps you non-device under the FDA CDS criteria — you keep the trust signal and leave the device burden behind.
It supports, it does not clear
The evidence feeds a PCCP, postmarket monitoring, and EU AI Act documentation. It supports your compliance; it is not a clearance and makes no medical claim. Compliance is your organization's overall posture.
It never sees PHI
Model, input, and output are reduced to digests. Raw identifiers are rejected at the guard. The ledger is useless to anyone who steals it — there is no protected data inside — and it is quantum-safe, not quantum-proof.
Ask RankShieldMD for clinical-AI vendors.
What is RankShieldMD for a clinical-AI or SaMD vendor?
It is an independent evidence layer that attests each of your model’s decisions with a cryptographic, externally-anchored, post-quantum-signed receipt. It proves an output came from your approved, un-tampered model on intact data, without exposing patient information, so your hospital buyers can verify your model rather than being asked to trust it.
Does RankShieldMD compete with our model?
No. It never renders, scores, or recommends a clinical decision. It sits alongside your model and attests the decisions your model already makes. It is complementary infrastructure, not a rival product, and it is careful never to enter your clinical pathway.
Did RankShieldMD invent verifiable clinical-AI audit?
No. The concept exists in published academic research. What RankShieldMD ships is the commercial, externally-anchored, post-quantum, per-decision implementation. We never claim to have invented the idea.
Will adding RankShieldMD make us a regulated device?
No. Because RankShieldMD attests decisions rather than rendering them, this evidence stays on the non-device side of the FDA clinical-decision-support criteria, specifically the fourth criterion about producing or driving the decision. It adds a trust signal to your model without adding regulatory surface to it.
Does the evidence layer see PHI?
No. It is PHI-free by construction. It seals digests of the model, inputs, and output; raw patient identifiers are rejected at the guard and never enter the ledger. Adopting it shrinks your PHI footprint rather than growing it.
How does provenance support a predetermined change-control plan?
A PCCP commits you to a defined process for updating a model. Provenance gives you the integrity trail that shows the deployed model matches the authorized one at any moment. When you ship an approved update, the sealed baseline changes with it, so you can demonstrate that only sanctioned versions ran. It supports the plan; it is not itself the clearance.
Does the same evidence feed postmarket monitoring and the EU AI Act?
Yes. The per-decision receipts are integrity evidence you can carry into FDA postmarket monitoring and into EU AI Act technical documentation. One attestation stream supports several obligations at once. It supports compliance; it does not by itself make you compliant.
Why will hospital buyers start demanding decision provenance?
Because clinical AI is moving toward autonomous action. Documented developments in 2026 include an autonomous-prescribing pilot, an FDA clearance for autonomous care, and the FDA’s first AI warning letter in April 2026. As models act with less human review, procurement will ask you to prove each decision was genuine, and independent provenance is the cleanest way to answer.
How does provenance help us win procurement?
It turns “trust our model” into “verify our model.” A buyer’s security team can recompute the hash chain and confirm the signed root themselves, with no access to your systems. That is a concrete differentiator in a security review, and it shortens the trust conversation that usually slows enterprise health-system deals.
Is independent verifiability really a sales advantage?
Yes, because it is checkable rather than assertable. Most vendors offer attestations that a buyer must take on faith. An externally-anchored, independently-verifiable receipt lets the buyer confirm the claim without trusting you or us, which is exactly the kind of evidence a mature health-system security review rewards.
What does it take to integrate?
Register a cryptographic baseline of your approved model, then attest decisions through RankShieldMD at runtime using digests only, never PHI. You receive evidence packages with a verify recipe you or your buyer can run. It sits beside your model, not inside its clinical pathway, so it does not alter your product’s regulatory status.
Does integrating change our latency or clinical flow?
The attestation runs alongside the decision on digests, not on patient data, and it does not render or gate the clinical output. It is designed to be an evidence sidecar, so your model’s behavior and clinical flow stay yours.
Is the evidence quantum-safe?
Yes. Proofs are signed with composite ML-DSA-65 and Ed25519 so evidence stays defensible as cryptography evolves. It is quantum-safe, not quantum-proof: no quantum computer capable of breaking today’s 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 — no PHI, no device burden.