Health Pass

Track: Identity · Lane: Concept

This entry is for patients opening a new AI health tool, who need to prove they're an eligible patient so they can get care from the first message, without handing over their name, date of birth, address, and Member ID to prove one fact, and without every platform keeping an unverified permanent copy.

This is a Concept-lane submission: research, design, and a working demo of the core mechanism. It's not a Build-lane product.

Inspiration

I signed up for Teladoc, Amwell, and Sesame Care myself, in August 2026.

Every platform collected the same bundle from scratch, legal name, date of birth, address, insurance carrier and Member ID, with no portability between them. All of it to establish one fact: this is an eligible patient.

Teladoc asked for overlapping pieces of it across three separate screens in a single signup. None of it was verified. No document check, no ID scan, they took my word. So the disclosure buys the platform a liability, not an assurance. And because nothing is verified, there's no verified event to reuse, which is exactly the gap a passport-held proof fills.

Sesame Care stages it differently: its AI triage runs on zero disclosure, and one ZIP code returned 232 providers to me. It also proves the real gap by accident, in its own intake flow, it tells patients to copy an AI conversation and paste it back in, because there's no real way to carry that context yet, which is the whole argument for a passport rather than a better intake form.

What it does

Health Pass lets a patient prove they're an eligible patient to any new AI health tool, without handing over their name, date of birth, address, or insurance Member ID to establish it.

Passport claim: this person is a verified, eligible patient. Nothing more travels on the durable path.

Verification happens once, elsewhere: identity through a state digital ID or a provider like Stripe Identity, eligibility attested by the payer or a platform that has actually run the check, timestamped and short-lived because coverage changes. The Passport doesn't verify, it reuses one verified event.

Three things stay deliberately separate:

How it works

A masking gate sits between the Passport and any requesting platform. Nothing is granted by default. Every platform requests specific fields with a stated purpose and duration, the patient approves, edits the request down, or denies, and every release is logged with the exact payload sent.

Clinical context is generalized before anything leaves. Date of birth becomes an age band, address becomes a 3-digit ZIP, exact dates become months. A platform receives "mid-30s, hypertension, lisinopril, onset ~6 weeks" and never gets the identifiers. A k-anonymity check runs on the outgoing combination before release, catching the case where individual fields look safe but together they don't. Sesame already proves ZIP-level location is enough to match providers, so this isn't a theoretical threshold, it's one already working in production.

The gate works at the point of disclosure, not storage, so it holds regardless of where the Passport itself lives.

Design rule: the pass can only ever save a step, never gate access to care. If an eligibility attestation is stale, the patient falls back to direct verification with the platform, exactly as they would today.

Challenges I ran into

The hardest one: you can't revoke a disclosure. Once a platform has read something in, deleting it from the Passport retracts nothing, and retention law generally requires them to keep it for years anyway. That's why this design puts control at the point of release, not at deletion after the fact.

Going forward, everything stays revocable: every context grant is scoped to a purpose and duration, and the patient can deny or edit down any future request at any point. What's already left the gate is the one thing no design can pull back, which is exactly why control has to sit at release instead of waiting on deletion.

Beyond that: re-identification from combined fields, the risk of making identity-unmasking too frictionless, and consent fatigue if the system relies on patients reading every request carefully.

What's next

A masking gate over the health connectors AI Passport already ships, no hospital contracts, no new cryptography needed for version one. The open question I don't have an answer to yet: who authors the generalization rules per field, since clinical usefulness and privacy pull in opposite directions.

🚀 Check out our presentation deck: View Slides

Built With

• healthcare
• identity-verification
• k-anonymity
• privacy
• python