Designing an emergency medical card: what a stranger should see when you can't consent

Picture the worst case: someone is found unconscious after a car crash. Their phone is in their pocket. The paramedic has seconds, not minutes, and the person can't answer a single question. What should a stranger be able to see in that moment, without the person's consent, because consent is impossible? We've been designing the emergency card for Anpheros around that question. Here are the decisions we made, the trade-offs we argued about, and the standards that make the result readable by systems that aren't ours. 1. Show less, not more The tempting answer is "everything, it's an emergency". We decided the opposite. When the card's QR code is scanned, the page shows only the basics a first responder can act on: who the person is and their age blood group allergies vaccinations current medications emergency contacts That's it. There is no emergency "break-glass" access to the full history. No past diagnoses, no lab results, no notes. Why so strict? Nobody can consent. The person is unconscious. Everything beyond the basics is information they never agreed to show a stranger. The history is rarely actionable at the roadside. Paramedics treat what's in front of them. An allergy or an anticoagulant changes what they do in the next ten minutes; a diagnosis from 2019 usually doesn't. A QR code can be scanned by anyone. Whoever finds the phone sees the same page as the paramedic. The page has to be safe for both. Full history access goes through a different path: a clinician requests it, and the patient approves it once they can, per scope and per duration. 2. The medications trade-off Medications were the one item we went back and forth on. A full medication list is long, and some of it is sensitive (psychiatric medication, HIV treatment, hormone therapy). But some classes matter enormously in an emergency: anticoagulants, insulin, corticosteroids, antiepileptics, immunosuppressants. Because we store medications with ATC codes, one option is to filter automatically and show only the high-risk classes on the public page. The other is to show the list the person chose to put on their card. There's no perfect answer. Whatever you choose, make it the person's decision, made in advance, with a preview of exactly what a stranger will see. 3. Readable in the reader's language A tourist collapses in Lisbon; the paramedic reads Portuguese. A card written in English free text helps a little. A card in Polish doesn't help at all. The fix isn't translation at scan time. It's storing coded data from the start: allergies and conditions as SNOMED CT or ICD-10 codes medications as ATC codes blood group as a coded Observation (LOINC 882-1) Then the emergency page renders the labels in the reader's language. Coded data translates cleanly; free text like "allergic to the pink antibiotic" never will. 4. Build on open standards, not a proprietary format The emergency subset maps almost one-to-one onto the International Patient Summary (IPS): allergies and intolerances, medication summary, immunizations, problems. Using IPS means any IPS-aware system can read the same data, not just our app. For moving it around, SMART Health Links are designed for exactly this: a link, often in a QR code, that resolves to encrypted FHIR data, with an optional expiry and passcode. If you build your own format, you've built a card that only your app can read. That's the opposite of what an emergency card is for. 5. The Wallet privacy asymmetry nobody mentions Putting the card in the phone's Wallet, next to boarding passes, is the obvious UX choice. But the two platforms work very differently: Apple Wallet: the .pkpass file is signed by you and delivered from your server straight to the device. For updates, Apple relays a push notification; the pass content comes from your server. Google Wallet: the pass is an object you create through Google's REST API. It lives on Google's infrastructure and syncs to the user's account. Google offers a "private pass" type for sensitive data; check what guarantees it gives in your jurisdiction. For health data in the EU (a special category under GDPR Article 9), that difference matters. Our rule: the Wallet pass carries only the minimum (name, date of birth, blood group and the QR code), and everything else stays on our servers behind the QR. If you need to change what's shown, you change it in one place. 6. It complements a bracelet, it doesn't replace one If you read what paramedics say about phone medical IDs, the pattern is consistent: locked phones, every brand hides the info somewhere different, and there's rarely time to look. A bracelet or a wallet card gets checked because it's visible. So we treat the digital card as a complement. If someone has a serious allergy, epilepsy, diabetes or takes anticoagulants, a physical bracelet is still the first thing a responder will see. Summary Decision Our choice Why What the QR shows Basics only Nobody can consent; basics are what's actionable Break-glass history None History access needs the patient's own approval Medications Person decides, with preview High value, but some are sensitive Language Coded data, rendered per reader Free text doesn't translate Format IPS + SMART Health Links Readable by systems that aren't ours Wallet pass Minimal fields + QR Keeps most Art. 9 data off third-party infrastructure I'm the founder of Anpheros, a patient-owned health record built on FHIR R4 and IPS, so these are decisions we live with. If you're building something similar, I'd love to hear where you landed, especially on the medications question.