Trust across organizations,
proven cryptographically.
Cross-organization exchange only works if you can prove who is on the other end. RankShieldMD issues verifiable trust credentials — and checks them without a central store of patient data.
RankShieldMD issues verifiable trust credentials that bind an organization's identity, its role in the exchange, and a validity window, all signed by the trust registry's certificate authority. Any participant can confirm a credential is genuine — and that a request truly came from its holder — using only the public CA key, with no clinical data ever leaving your systems.
Who is really
on the other end?
When a hospital, a payer, and a national network exchange records, each has to answer one question before any data moves: is the party querying me who they claim to be, and are they trusted right now? Directories go stale. Certificates get shared. A revoked participant can keep transacting for days. The gap is not the data format — it is a verifiable answer to "is this org trusted, and did this request really come from them?"
A credential
you can check.
A verifiable trust credential binds an organization's identity (its OID), its role — QHIN, participant, or sub-participant — and a validity window, all sealed by the registry's certificate authority. verifyTrustCredential confirms the signature against the CA public key, the expiry, revocation, and standing. Change a single field — a role, a date — and it fails as bad_signature. It needs only the public key.
A stolen credential
is inert.
A credential alone is not enough to transact. verifyExchange requires a VTC plus a signed request — proof-of-possession over the request digest, using RFC 9421 signed messages — plus a purpose-of-use gate. An attacker who copies a credential cannot produce that signature without the private key. The result is a single verdict: authorized or rejected.
Is this org
trusted?
A public trust registry answers that in one lookup: current status, role, and validity for any OID. Revocation is a federatable negative — when a credential is pulled, the registry publishes it, and every verifier honors it at once. Trust ends the moment it should, and none of it requires a central pool of patient data. The records stay home; only the proof moves.
Federate trust,
not patient data.
Issue verifiable trust credentials for your exchange partners, verify a signed request end to end, and confirm standing against the public registry — all without a central honey-pot. Cross-organization, verifiable, PHI-free.
What is verifiable trust for health data exchange?
Verifiable trust for health data exchange is cryptographic proof that a cross-organization health-data request or response came from a real, currently-trusted organization — provable by anyone holding a public key, without a central store of patient data. When a hospital, a payer, a laboratory, and a nationwide network share records, the format of the data is the easy part; the hard part is establishing, on every transaction, that the party on the other end is who they claim to be and is trusted at that moment. Traditional answers lean on directories and shared secrets that go stale, get copied, or keep a revoked participant transacting long after their standing ended. RankShieldMD closes that gap by issuing verifiable trust credentials — certificate-authority-signed statements that bind an organization's identity, role, and validity window — and by pairing each transaction with a signed request that proves the sender holds the private key. Two principles govern the design, and we hold to both honestly: move proof, not records — the clinical payload stays in your exchange systems and never enters our credentials or logs — and verify without a central honey-pot, so trust federates across organizations instead of pooling into one high-value target. RankShieldMD supports the TEFCA and FHIR trust fabric; it is not a QHIN and does not certify one.
What is a verifiable trust credential (VTC)?
A verifiable trust credential is a certificate-authority-signed credential that binds three things an exchange partner must be able to trust: who an organization is, what it is allowed to do, and when that holds. The identity is carried as an OID, the same kind of stable organizational identifier that health exchange frameworks already use, so a VTC slots into existing directories rather than replacing them. The role field records the organization's place in the exchange — QHIN, participant, or sub-participant — as an attested attribute; it describes standing that already exists, and RankShieldMD never confers that status itself. The validity window pins a not-before and a not-after, so a credential cannot be honored before it is issued or after it lapses. All of it is sealed by the trust registry's certificate authority, which is what makes the credential verifiable rather than merely asserted. The check that consumes it, verifyTrustCredential, is deliberately federatable: it confirms the signature against the CA public key, checks the expiry, checks revocation, and checks that the organization is still in good standing. Because verification needs only the public CA key, any participant can run it independently, offline, without a private relationship with RankShieldMD. Tamper with any field — change a role from participant to QHIN, stretch the validity window, swap the OID — and the check returns bad_signature, naming the reason. The credential is a fact you can check, not a claim you have to take on faith. And because the credential is self-contained and signed, a partner does not have to phone home to RankShieldMD on every transaction to establish trust; the check works even when the two organizations have no prior relationship, no shared secret, and no direct connection beyond the exchange itself. That is what makes it a genuine primitive for federation rather than another point-to-point integration.
How does proof-of-possession stop a stolen credential?
By making the credential worthless on its own. A verifiable trust credential proves an organization is trusted, but presenting one does not prove that you are that organization — and that distinction is exactly where credential theft lives. RankShieldMD closes it with proof-of-possession. The transaction-time check, verifyExchange, does not accept a VTC alone; it requires the presenter to also submit a request signed with the private key bound to that credential, over a digest of the request itself, using RFC 9421 signed HTTP messages. That signature can only be produced by whoever holds the private key, and the key never travels with the credential. So an attacker who intercepts, copies, or replays a VTC — from a log, a stale directory export, a misconfigured endpoint — still cannot transact, because they cannot sign a fresh request as its holder. The copied credential is inert. On top of possession, verifyExchange evaluates a purpose-of-use gate: the signed request carries a declared reason for the query, and the check confirms that reason is one the presenting organization is permitted to assert before returning authorized or rejected. The verdict binds three questions into one federatable answer — is this organization trusted, did this exact request come from them, and is the stated purpose allowed — and it records that decision without ever recording the clinical content of the exchange.
How does this fit TEFCA and FHIR exchange?
It supplies the cryptographic trust layer that both frameworks assume but neither hands you directly. TEFCA — the Trusted Exchange Framework and Common Agreement — defines the policy fabric for nationwide health-data sharing: who may participate, in what roles, under what obligations. FHIR — Fast Healthcare Interoperability Resources — defines the data format and the APIs that carry records between systems. Both take for granted that a participant can establish, transaction by transaction, who is on the other end of the connection. That is the assumption RankShieldMD makes verifiable. Verifiable trust credentials express identity and role in a form that a partner can check against a certificate authority, so "this OID is a trusted participant" becomes a cryptographic fact rather than a directory entry. Signed requests apply the same rigor to FHIR API calls: an incoming query carries an RFC 9421 signature the receiver can verify, so the call is provably from the credential's holder and not a replay. The public trust registry gives everyone a shared, current view of standing, and revocation propagates as a federatable negative the instant a participant should no longer be honored. RankShieldMD supports these frameworks; it is careful never to claim to be them. It is not a Qualified Health Information Network, it does not certify QHINs, and the role field it attests reflects standing conferred elsewhere. What it adds is the checkable trust primitive that lets FHIR and TEFCA exchange happen between organizations that have never met.
Why cross-org trust without a central honey-pot matters
Because the moment you centralize trust, you tend to centralize the data with it — and a single store of everyone's records is the highest-value target in healthcare. The instinct in cross-organization exchange is to build a hub that holds a master copy, or a broker that sees every query and response as it passes through. Both create a honey-pot: one breach, and the exposure is not one institution's patients but the whole federation's. RankShieldMD is built to make that honey-pot never form. Records stay where they already live, governed by the clinical systems built for them; what moves between organizations is proof — a signed credential, a signed request, a published status. Verification runs against a public CA key and the registry's current view, so no verifier needs a private pool of anyone's data to confirm trust, and there is no central archive to compromise. Trust federates: each participant can check every other participant independently, and revocation reaches all of them as a shared negative rather than a message that has to fan out from a single authority. This is the same discipline that runs through everything RankShieldMD builds — hold only the proof, never the sensitive payload — applied where the blast radius of getting it wrong is largest. It is PHI-free by construction: the credentials, the registry, and the exchange logs carry identities, roles, and digests, never protected health information. The result is a trust fabric that gets stronger as more organizations join, instead of accumulating a bigger prize for the next attacker.
What we are careful never to claim.
We are not a QHIN
TEFCA and FHIR are frameworks we support. RankShieldMD is not a Qualified Health Information Network and does not certify one. The role field on a credential attests standing conferred elsewhere; we never grant it.
It supports compliance
Verifiable trust credentials produce evidence that supports your exchange and interoperability obligations. It is not itself a compliance certification, and it makes no medical claim.
It never sees PHI
Credentials, the registry, and exchange logs carry identities, roles, and digests only. Protected health information stays in your clinical systems. There is no central pool to breach.
Ask RankShieldMD about health data exchange trust.
What is verifiable trust for health data exchange?
It is cryptographic proof that a health-data query or response came from a real, currently-trusted organization — not just an assertion in a directory. RankShieldMD issues verifiable trust credentials (VTCs) that bind an organization's identity, role, and validity window, and provides a public check anyone can run against the CA public key. It supports your TEFCA and FHIR trust obligations; it never sees protected health information.
Do you exchange patient records or hold PHI?
No. RankShieldMD is PHI-free by construction. It attests who is trusted and verifies that a request was signed by that party. The clinical payload stays in your exchange systems and never enters our credentials, registry, or logs.
Are you a QHIN, or do you certify QHINs?
No. TEFCA and FHIR are frameworks we support. RankShieldMD is not a Qualified Health Information Network and does not certify one. We issue and verify cryptographic trust credentials that carry a role field — such as QHIN, participant, or sub-participant — as an attribute; we never confer that status ourselves.
What is a verifiable trust credential (VTC)?
A VTC is a CA-signed credential that binds an organization's identity (its OID), its role in the exchange (QHIN, participant, or sub-participant), and a validity window (not-before and not-after). Because it is signed by the trust registry's certificate authority, anyone holding the CA public key can confirm it is genuine and unaltered, offline, without calling back to us.
What happens if someone tampers with a VTC?
Verification fails as bad_signature. The signature covers every field, so changing the role from participant to QHIN, extending the validity window, or swapping the OID breaks the cryptographic seal. verifyTrustCredential returns a rejection and names the reason. Tampering is detectable with only the public CA key.
How does revocation work?
Revocation is a federatable negative. When an organization's credential is pulled — offboarding, key compromise, loss of good standing — the trust registry publishes that state, and verifyTrustCredential checks it alongside the signature and expiry. A revoked VTC fails even though its signature is still mathematically valid, so trust ends the moment it should.
How does proof-of-possession stop a stolen credential?
A VTC alone is not enough to transact. verifyExchange requires the presenter to also submit a request signed with the private key bound to that credential — proof-of-possession over the request digest, using RFC 9421 signed HTTP messages. An attacker who copies a VTC cannot produce that signature without the private key, so a stolen credential is inert.
What is verifyExchange?
It is the transaction-time gate. verifyExchange takes a VTC, a signed request that proves possession of the bound key over the request digest, and a purpose-of-use claim, then returns authorized or rejected. It combines "is this org trusted" with "did this exact request come from that org, for a permitted purpose" in one federatable check.
What is a purpose-of-use gate?
Cross-organization exchange frameworks require that each query carries a declared reason — treatment, payment, operations, and so on. verifyExchange evaluates the purpose-of-use claim on the signed request against what the presenting organization is permitted to assert, and rejects requests whose stated purpose is not allowed. It records the decision without recording the clinical content.
What is the public trust registry?
It is a read-only view that answers one question: is this organization trusted right now? Any participant can look up an OID and see the current status, role, and validity — and confirm revocation — without a private relationship with us. It turns "trust" from a static directory entry into a live, checkable fact.
Why cross-org trust without a central honey-pot?
Because a single store of everyone's records is the highest-value target in healthcare. RankShieldMD keeps records where they already live and moves only proof. Verification runs against a public CA key and a published status, so there is no central pool of patient data to breach. Trust federates; the honey-pot never forms.
How does this fit TEFCA and FHIR exchange?
TEFCA defines the policy trust fabric for nationwide exchange and FHIR defines the data format and APIs. Both assume that participants can establish who is on the other end. RankShieldMD supplies the cryptographic layer for that assumption: verifiable credentials for identity and role, signed requests for FHIR API calls, and a registry for standing. We support these frameworks; we are not them.
Is it quantum-safe?
Yes. Trust credentials and signed requests use composite ML-DSA-65 paired with Ed25519, so evidence of who was trusted, and who signed a given request, 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 directory" into "verify our credential."
Issue a verifiable trust credential, verify a signed request end to end, and check standing against the public registry — no honey-pot required.