# Request Access to RankShieldMD | Verifiable Healthcare AI > Bring a decision, an access flow, or a device from your environment. We will seal it, and your team will verify the evidence, without PHI and without trusting us. > > Source: https://rankshieldmd.com/request-access/ · RankShieldMD (verifiable AI & post-quantum security for healthcare) RankShieldMD // Request access # Run a verification in your environment. **Bring a decision, an access flow, or a device.** We seal it, and your team verifies the evidence, without PHI and without trusting us. RankShieldMD is opening access to select healthcare partners. Tell us who you are and what you want to prove, and we will set up a verification you can run and check with your own tools. Request a verification → What you get Verifiable PHI-free Post-quantum Non-device RankShieldMD ledger · PHI-free Clinical-AI decision your model · 0x5377a9a1… Sealing… Record access · export verified actor · 0xa6ee5342… Sealing… Device command signed · 0xfa65fce3… Sealing… Scroll to descend 01 // What you get ## A proof you can check. We run one of your clinical-AI decisions, record accesses, or device commands through the fabric and hand you an **evidence package** with a verify recipe. Your team recomputes the hash chain and confirms the post-quantum-signed root independently. No PHI leaves your systems. 02 // How it works ## Digests in. Proof out. You send digests and verified identities, never protected health information, which is rejected at the guard. We seal them to an externally-anchored, post-quantum-signed transparency log and return evidence anyone can verify , including you, without trusting us. 03 // Honest ## We attest. We never decide. RankShieldMD proves that a clinical-AI decision was genuine; it never makes, scores, or recommends one. It is **non-device** and **PHI-free** by construction, and it produces evidence that supports compliance rather than claiming to make you compliant . 04 // Standards ## Built to open standards. RFC 6962 transparency log, composite ML-DSA-65 with Ed25519 signatures, RFC 9421 signed requests, and the IETF RATS verifier role, so the evidence is portable and checkable outside our systems , not a proprietary silo. 05 // Get started ## Tell us what you want to prove. A hospital CISO, a device maker, or a clinical-AI vendor, whoever is accountable when AI acts inside care. Send the form below and we will follow up to set up a verification. Go to the form ↓ Request access ## Request a verification. Tell us who you are and what you want to prove. We reply from a real person, not a bot. We never ask for protected health information. Answer engine ## Ask the founder. 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 do I get in early access? We run one of your clinical-AI decisions, record accesses, or device commands through the fabric and hand you an evidence package with a verify recipe. Your team recomputes the hash chain and confirms the post-quantum-signed root independently. No PHI leaves your systems. How does the verification work? You send digests and verified identities, never protected health information, which is rejected at the guard. We seal them to an externally-anchored, post-quantum-signed transparency log and return evidence anyone can verify, including you, without trusting us. Does RankShieldMD make or influence the clinical decision? No. RankShieldMD proves that a clinical-AI decision was genuine; it never makes, scores, or recommends one. It is non-device and PHI-free by construction, and it produces evidence that supports compliance rather than claiming to make you compliant. What open standards is it built on? RFC 6962 transparency log, composite ML-DSA-65 with Ed25519 signatures, RFC 9421 signed requests, and the IETF RATS verifier role, so the evidence is portable and checkable outside our systems, not a proprietary silo. Who should request access? A hospital CISO, a device maker, or a clinical-AI vendor, whoever is accountable when AI acts inside care. Send the form and we will follow up to set up a verification. Do you ever need protected health information? No. We never request or store PHI. You send digests and verified identities only, and raw identifiers are rejected at the guard before anything is sealed, so a verification shrinks your PHI footprint rather than growing it. Early access ## Put your medicine on the proof layer. Bring a decision, an access flow, or a telehealth order from your environment. We'll seal it, and your team will verify the evidence, without PHI, and without trusting us. Request a verification → Ask a question