# Verifiable Trust for FHIR/TEFCA Health Data Exchange | RankShieldMD > Prove who is trusted across organizations and that a signed request truly came from them. Verifiable trust credentials for FHIR and TEFCA exchange, no central honey-pot, PHI-free. > > Source: https://rankshieldmd.com/health-data-exchange-trust/ · RankShieldMD (verifiable AI & post-quantum security for healthcare) RankShieldMD // Health data exchange trust # 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. 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. Request early access → See how it works Verifiable trust PHI-free No honey-pot Post-quantum RankShieldMD registry · PHI-free Trust credential · QHIN oid 2.16.840… · valid Checking… Signed request · RFC 9421 proof-of-possession · 0x7b40… Checking… Registry status · standing not revoked · in window Checking… Scroll to descend The cross-org trust problem ## 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?" What it is ## 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 a credential binds ## Four fields, one checkable seal. A verifiable trust credential binds who an organization is, what it may do, and when that holds, then seals all of it with the registry certificate authority. Each field is covered by the signature, and the whole credential verifies against a public key alone. 01 ### Identity The organization's OID, the same stable identifier health exchange frameworks already use, so a VTC slots into existing directories. identity · OID 02 ### Role QHIN, participant, or sub-participant, recorded as an attested attribute. It describes standing that already exists; we never confer it. attested attribute 03 ### Validity window A not-before and a not-after, so a credential cannot be honored before it is issued or after it lapses. not-before / not-after 04 ### CA signature Sealed by the trust registry certificate authority. Anyone with the public CA key verifies it offline, with no call home. verify offline Verifiable trust credentials ## 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. Proof-of-possession ## 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](https://www.rfc-editor.org/info/rfc9421). 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. Standards ## 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](https://www.healthit.gov/topic/interoperability/policy/trusted-exchange-framework-and-common-agreement-tefca), defines the policy fabric for nationwide health-data sharing: who may participate, in what roles, under what obligations. FHIR, [Fast Healthcare Interoperability Resources](https://www.hl7.org/fhir/overview.html), 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](https://www.rfc-editor.org/info/rfc9421) 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. No central honey-pot ## 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. Honest by design ## 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. References ## Primary sources The frameworks and cryptographic standards this page relies on, linked to their authoritative publishers. - HHS / ASTP-ONC. [Trusted Exchange Framework and Common Agreement (TEFCA)](https://www.healthit.gov/topic/interoperability/policy/trusted-exchange-framework-and-common-agreement-tefca). HealthIT.gov, on the nationwide trust framework and the role of Qualified Health Information Networks. - HHS / ASTP-ONC. [Health Level 7 (HL7) Fast Healthcare Interoperability Resources (FHIR)](https://www.healthit.gov/topic/standards-technology/standards/fhir). HealthIT.gov, on FHIR as the nationwide standard for health data exchange. - HL7 International. [FHIR Overview](https://www.hl7.org/fhir/overview.html), on FHIR Resources and the exchange API. - IETF. [RFC 9421: HTTP Message Signatures](https://www.rfc-editor.org/info/rfc9421), on creating and verifying signatures over HTTP messages, including signing a subsequent request (proof-of-possession). - NIST. [FIPS 204: Module-Lattice-Based Digital Signature Standard (ML-DSA)](https://csrc.nist.gov/pubs/fips/204/final), the post-quantum signature standard secure against large-scale quantum computers. - IETF. [RFC 8032: Edwards-Curve Digital Signature Algorithm (EdDSA)](https://www.rfc-editor.org/info/rfc8032), on Ed25519. Answer engine ## Ask RankShieldMD about health data exchange trust. Straight answers about verifiable healthcare AI. Tap a question, or type your own. Jamie Kloncz, founder verified 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. 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. Early access ## 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. Cross-organization, verifiable, PHI-free. Request early access → Ask a question