One verified identity for every
clinician, device, and system.
Before you can prove a decision, an access, or an order, you have to prove who acted. Identity is the foundation every other product consumes.
The healthcare identity fabric gives every actor — clinician, clinical device, implant, EHR system, and organization — one verifiable credential, signed with RFC 9421 HTTP Message Signatures. One active credential per NPI or UDI. Crypto-agile, and instantly revocable. PHI-free by construction.
Every product
starts with "who."
Access audit records who touched a record. Telehealth signs who placed an order. The implant layer proves which device acted. TEFCA exchange checks who is on the other end. Each one gates on a single verify check against the identity fabric — so "who" is proven once, and trusted everywhere. Get identity wrong and every layer above it is built on sand.
RFC 9421.
One per NPI or UDI.
Every actor signs its requests with its own key using RFC 9421 HTTP Message Signatures. RankShieldMD verifies the signature against the one active credential bound to that clinician’s NPI or that device’s UDI. Two identities can’t claim to be the same clinician; a cloned device can’t masquerade as the original. Valid signature, active credential, or it doesn’t proceed.
Ed25519 now.
Post-quantum when flipped.
The signature algorithm is a property of the credential, not the whole system. Today the fabric verifies Ed25519. Flip on the post-quantum profile and it verifies composite-mldsa65-ed25519 — ML-DSA-65 paired with Ed25519 — so an identity stays defensible as cryptography evolves. Long-lived implants move to post-quantum keys in the field, no recall. Quantum-safe, not quantum-proof.
Compromised?
Revoked instantly.
A clinician leaves. A device is stolen. An EHR connection is compromised. RankShieldMD marks the credential inactive in the node-key registry and the certificate record, and every subsequent verify returns false for that actor — immediately. Because products verify against the live registry, not a cached token, there is no window where a revoked identity still works.
Give every actor
a verifiable identity.
Enroll your clinicians, devices, implants, EHR systems, and organizations. Bind each to its NPI or UDI. Sign with RFC 9421, verify against the live registry, and rotate or revoke in an instant. Crypto-agile, PHI-free, non-device.
What is a healthcare identity fabric?
A healthcare identity fabric is a verifiable identity layer that gives every actor in a clinical system — clinician, clinical device, implant, EHR system, and organization — one cryptographic identity that anyone can check, enforcing exactly one active credential per NPI or UDI and letting every other product gate its actions on a single verification. In medicine, almost every security question begins with the word "who." Who placed this order? Which device produced this reading? Who exported this record? Who is on the far end of this data exchange? For decades those questions were answered with usernames, passwords, and bearer tokens — secrets that can be shared, stolen, phished, or replayed, and that tell you only that someone presented the right string, not that a specific, still-authorized actor genuinely acted. RankShieldMD replaces that with cryptographic identity: each actor holds a private key and a signed verifiable credential, signs its requests with RFC 9421 HTTP Message Signatures, and is verified against the one active credential bound to its NPI or UDI. Two principles hold the design honest. Attest, don’t decide — the fabric proves who an actor is, and never makes a clinical judgment — and prove without exposing, so identities and signatures are all it holds. It is PHI-free by construction.
Why is verified identity the foundation of clinical-AI security?
Because every claim you might want to prove about a clinical system reduces, first, to a claim about who acted — and if that first link is weak, nothing built on top of it can be trusted. Consider the products RankShieldMD offers. Decision provenance proves that a given clinical-AI output came from an approved model; but it only matters if you can prove which system, run by which organization, produced it. PHI-free access audit records who touched a record; the record is only as trustworthy as the identity behind the "who." Telehealth signs orders; the signature is meaningless unless the signing key genuinely belongs to the clinician and no one else. The implant and device layer proves that a specific device acted; that proof rests entirely on the device’s identity being unforgeable and unique. Health-data exchange over TEFCA checks the party on the other end; that check is an identity verification. In every case the higher-level product performs the same primitive underneath: a verify against the identity fabric. That is why identity is not one product among several but the substrate they all consume. Build it on shared secrets and you inherit every weakness of shared secrets across the whole platform. Build it on unique, verifiable, revocable cryptographic credentials, and every layer above inherits that strength instead. Foundation first: get "who" right, and the rest of the platform stands on solid ground.
How does RankShieldMD verify a clinician, device, or implant?
With RFC 9421 HTTP Message Signatures, checked against the one active credential bound to the actor’s NPI or UDI. The mechanism is the same across all five actor types — clinician, clinical_device, implant, ehr_system, and org — which is what makes it a fabric rather than a patchwork. First, the actor is enrolled: an organization registers it, binds it to its NPI (for a clinician) or its UDI (for a device or implant), and the fabric issues a verifiable credential while recording the actor’s public key in the node-key registry. From then on, whenever the actor makes a request, it signs that request with its private key following the RFC 9421 standard, which covers not only the identity but the content of the request, so nothing can be altered in transit without breaking the signature. RankShieldMD verifies the signature against the active credential. If the signature is valid and the credential is active, the action proceeds; if the key is unknown, the signature is wrong, or the credential has been revoked, verification returns false. Crucially, the fabric enforces exactly one active credential per NPI or UDI — so a cloned device, a stale key, or a second party claiming to be the same clinician does not verify. There are no shared secrets and no bearer tokens to steal or replay: possession of a valid, active private key, provably bound to a real registered identifier, is the whole of the proof.
What happens when a credential must be revoked?
Revocation is instant, and it propagates everywhere the fabric is consumed, because every product verifies against the live registry rather than a cached token. When a clinician leaves, a device is lost or stolen, or an EHR connection is compromised, RankShieldMD marks that credential inactive in the node-key registry and in the certificate record. From that moment, every subsequent verification of that actor returns false — in access audit, in telehealth order signing, in the implant layer, in TEFCA exchange, everywhere. There is no lingering window in which a revoked identity still works, which is the failure mode that makes stolen bearer tokens and long-lived sessions so dangerous: a leaked token keeps working until it expires, but a revoked credential stops working the instant revocation lands. Rotation is the gentler sibling of revocation and shares the same machinery. Rotation replaces an actor’s key while keeping the identity active — used for routine key hygiene, for crypto-agility upgrades such as moving an implant to post-quantum keys, or when compromise is suspected but the actor is still legitimate. Both operations take effect immediately across every product, because both are enforced through the same node-key and certificate records that verification reads on every request. Instant, uniform, and platform-wide: that is what it means for revocation to be a property of the fabric rather than a feature bolted onto each product.
How is this different from a hospital IAM system?
Traditional identity and access management answers "may this user log in?"; the healthcare identity fabric answers "did this specific, still-authorized actor cryptographically sign this action?" — and it does so for machines and institutions, not just people. A conventional IAM stack authenticates human users into applications, typically with passwords, single sign-on, and bearer tokens, and then trusts the session it issues. That model has three gaps the fabric is built to close. It centers on people, so clinical devices, implants, and EHR systems — the actors that generate most clinical events — are second-class or absent. It relies on bearer credentials, which are secrets: anything that holds the token is treated as the user, so a stolen token is a stolen identity until it expires. And its trust is issued once at login, then assumed for the life of the session. The identity fabric inverts each of these. It treats clinician, clinical_device, implant, ehr_system, and org as first-class actors under one model. It uses keypairs and RFC 9421 signatures instead of bearer secrets, so possession of a signature over a specific request — not possession of a reusable token — is the proof, and the credential is verified fresh on every action against the live registry. It is crypto-agile, moving from Ed25519 to composite-mldsa65-ed25519 without re-architecting. And it is PHI-free and non-device: it attests who acted and never makes a clinical decision. The fabric is not a replacement for hospital IAM in every sense; it is the verifiable identity substrate that RankShieldMD’s own products consume when they need to prove, not assume, who acted.
What we are careful never to claim.
It never sees PHI
The fabric holds identities, public keys, and signatures — never protected health information. Raw identifiers are rejected at the guard. Adopting it shrinks your PHI footprint rather than growing it.
It attests, it never decides
It proves who an actor is. It never renders, scores, or drives a clinical decision. That boundary keeps it non-device and keeps clinical judgment with clinicians.
Quantum-safe, not quantum-proof
Crypto-agile from Ed25519 to composite ML-DSA-65 plus Ed25519. No quantum computer that breaks today’s cryptography exists yet, and we never claim any system is unbreakable.
Ask RankShieldMD about healthcare identity.
What is a healthcare identity fabric?
A verifiable identity layer that gives every actor in a clinical system — clinician, clinical device, implant, EHR system, and organization — one cryptographic identity that can be checked by anyone. RankShieldMD binds each identity to a signed credential, enforces one active credential per NPI or UDI, and lets every other product gate its actions on a single verify check. It is PHI-free: identities and signatures only.
Which actors get an identity?
Five actor types: clinician, clinical_device, implant, ehr_system, and org. Each gets a verifiable credential and a keypair. A clinician is bound to their NPI; a device or implant is bound to its UDI; EHR systems and organizations are bound to their registered identifiers. One identity model covers people, machines, and institutions.
Why is identity the foundation of the platform?
Because every other RankShieldMD product answers a question that starts with "who." Access audit records who touched a record; telehealth signs who placed an order; the implant layer proves which device acted; TEFCA exchange checks who is on the other end. Each one gates on a shared verify check against the identity fabric, so the answer to "who" is proven once and consumed everywhere.
How do you verify a clinician, device, or implant?
With RFC 9421 HTTP Message Signatures. The actor signs its request with its private key; RankShieldMD verifies the signature against the active credential bound to its NPI or UDI. If the signature is valid and the credential is active, the action proceeds. If the key is unknown, the signature is wrong, or the credential is revoked, verification returns false. No shared secrets, no bearer tokens to steal.
What is RFC 9421 and why does it matter?
RFC 9421 is the IETF standard for HTTP Message Signatures — it defines how to sign an HTTP request so a receiver can verify exactly who sent it and that nothing was altered in transit. Using a published standard rather than a proprietary scheme means the verification is interoperable, auditable, and does not depend on trusting RankShieldMD as a black box.
What does "one active credential per NPI or UDI" mean?
It means the fabric enforces uniqueness: a given NPI (a clinician) or UDI (a device or implant) can have exactly one active credential at a time. Registering a new credential supersedes the old one; a cloned or stale credential is not "active" and fails verification. This closes the door on two identities claiming to be the same clinician or the same device.
How is a new identity enrolled?
An organization registers an actor, binds it to its NPI or UDI, and the fabric issues a verifiable credential and records the public key in the node-key registry. From that moment the actor can sign requests, and any product can verify them. Enrollment is an administrative action, not a clinical one — RankShieldMD attests identity, it never makes clinical judgments.
Is the identity fabric quantum-safe?
It is crypto-agile. Today it verifies Ed25519 signatures; when the composite post-quantum profile is flipped on, it verifies composite-mldsa65-ed25519 — ML-DSA-65 paired with Ed25519 — so an identity 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.
What happens when you flip on post-quantum?
Because the fabric is crypto-agile, the signature algorithm is a property of the credential, not the whole system. Actors re-enroll or rotate to a composite-mldsa65-ed25519 credential, and verification accepts the new profile. Long-lived actors — especially implants that outlive their original cryptography — can be moved to post-quantum keys in the field, without a recall.
What happens when a credential must be revoked?
Revocation is instant. RankShieldMD marks the credential inactive in the node-key registry and the certificate record, and every subsequent verification returns false for that actor. Because products verify against the live registry rather than a cached token, a revoked clinician, stolen device, or compromised EHR connection loses access the moment revocation lands.
How is rotation different from revocation?
Rotation replaces an actor’s key while keeping the identity active — used for routine key hygiene, crypto-agility upgrades, or suspected compromise. Revocation deactivates the credential entirely. Both are enforced through the same node-key and certificate records, so both take effect immediately across every product that verifies against the fabric.
How does verified identity support compliance?
A verifiable, revocable identity per actor produces the "who did what" evidence that access-control and audit obligations rely on. It supports compliance with access-control and audit requirements; it is not itself a certification and makes no medical claim. RankShieldMD produces the identity evidence; your organization’s overall posture is what achieves compliance.
Is this a medical device?
No. The identity fabric attests who an actor is; it never renders, scores, or drives a clinical decision. That boundary keeps it non-device: it is security and identity tooling that helps clinicians, manufacturers, and health systems meet their obligations, not software that makes or influences care.
Prove who acted — before you prove anything else.
Enroll your actors, bind each to its NPI or UDI, and hand every other product a single verify check it can trust.