Security & privacy
QR codes in HIPAA contexts: keeping PHI out of the pixels
Never encode protected health information in a QR code. A printed code is plain text with no access control: anyone who photographs it can decode it, forever. The safe pattern is an opaque random token that resolves only inside an authenticated system, and a business associate agreement for any provider whose servers touch the flow.
A printed QR code is plain text, forever
A QR code has no encryption, no password, no access control. Whatever the payload says, every scanner (the intended nurse and the visitor photographing across the ward) reads it identically, and a photograph preserves it indefinitely. This page is educational material for designing safer healthcare QR flows, not legal advice; HIPAA questions belong with your compliance officer or counsel.
One property catches people out: error correction makes codes impossible to redact. Blacking out part of a code with a marker does not remove data: Reed–Solomon error correction exists precisely to reconstruct the payload from partial damage, up to 30% at level H. A code containing PHI cannot be un-published by defacing it; the only redaction is complete destruction.
Never put PHI in the payload
Protected health information is, roughly, health information tied to an identifiable person, and a QR payload combining a name with an appointment, diagnosis, medication or test result is exactly that, printed in a machine-readable format on paper that will travel through bins, recycling and photographs. Payloads to rule out entirely:
- Name plus appointment details on a reminder letter
- Prescription or dosage details on take-home paperwork
- Test results or diagnosis codes on printed reports
- A pre-filled vCard of a patient's contact record
The safe pattern: opaque token, authenticated portal
Encode a random, meaningless token and let an authenticated system do the resolving:
https://portal.hospital.example/r/8f3k2-vq9x7
The properties that make this work:
- The token is random, not derived from anything (not a national ID, not a date of birth). It reveals nothing if leaked and cannot be guessed.
- It resolves only after authentication, so the code is a shortcut, not a key.
- It can expire or be revoked, giving the printed artefact a lifespan the ink itself lacks.
Hospital patient wristbands largely follow this shape already: the band carries an identifier that is useless outside the clinical system that looks it up. That is the model to copy: identifier out in the world, record behind the login.
Providers and business associates
Two third parties can end up touching your flow:
- A server-side generator receives whatever you type into it at creation: see what your QR provider can see. If the payload contained PHI, a consumer QR website just processed PHI with no business associate agreement in sight. Client-side generation removes this party altogether: the code is built in the browser and the payload never leaves the device.
- A dynamic redirect provider logs every scan of a dynamic code. Scan logs of a code printed on discharge paperwork sit uncomfortably close to health-adjacent data, so the BAA question must be asked before, not after, deployment, and most consumer QR platforms will not sign one.
Practical checklist
- Payload is a URL to your own domain plus a random token. Nothing human-meaningful.
- Resolution requires authentication; tokens expire.
- Codes generated client-side or on infrastructure inside your compliance boundary.
- No third-party redirect layer, or a BAA in place if one is unavoidable.
- Verify each code decodes to exactly the intended token before print.
FAQ
Can I put patient information in a QR code?
No. A printed code is unencrypted, readable by anyone, and permanent once photographed. Encode an opaque token that resolves inside an authenticated system instead, so the code itself carries nothing about the patient.
Are QR codes HIPAA compliant?
A QR code is just printed text, so compliance depends on the flow: what the payload contains, who processes it at creation, and who logs scans. A token-to-portal design generated client-side introduces no PHI processing at all.
Do I need a BAA with a QR code provider?
If a provider's servers touch PHI (a server-side generator receiving a PHI payload, or a dynamic provider logging scans in a patient context) the business associate question arises, and most consumer QR services will not sign one. Client-side generation and static direct links avoid the third party entirely.
What do hospital wristband QR codes contain?
Typically an identifier that only the hospital's own systems can resolve, not the medical record itself. The record stays behind authentication; the wristband is a lookup key.
Try it: free, no signup
Related
- Are QR codes safe?, Scanning a QR code is safe in itself: it decodes text and nothing else. The risk is entirely in what you do next. A code cannot install software, dial,…
- QR codes and GDPR, when a scan becomes personal data, When a QR flow processes personal data under GDPR: scan logs, lawful basis, notices at the code, and the static-direct design that avoids processing entirely.
- QR codes and PCI DSS: what is actually in scope, UPI, PIX and EPC codes carry account references, not card numbers, largely out of PCI scope. Where QR payment flows do and do not touch PCI DSS.
- What your QR code provider can see, A server-side QR generator receives your payload at creation and standard server logs record it. What providers see at creation, at scan and at account level.