# 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.

Source: https://useqr.app/docs/security/qr-codes-in-hipaa-contexts · Last reviewed 2026-08-21 · UseQR is free forever, no signup.

---

## 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](/docs/spec/error-correction-levels-explained) 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](/vcard-qr-code) 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](/qr-codes-on/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](/docs/security/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](/docs/security/dynamic-qr-codes-and-privacy). 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

1. Payload is a URL to your own domain plus a random token. Nothing human-meaningful.
2. Resolution requires authentication; tokens expire.
3. Codes generated client-side or on infrastructure inside your compliance boundary.
4. No third-party redirect layer, or a BAA in place if one is unavoidable.
5. [Verify each code decodes](/docs/developers/why-verify-that-your-qr-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

- https://useqr.app/url
- https://useqr.app/validate
- https://useqr.app/scan