PHI vs PII: What the Distinction Means for Software Design

What Makes Data PHI

PHI is individually identifiable health information relating to past, present or future health, care or payment, created or received by a covered entity or business associate, in any form or medium.

What PII Covers

PII is any information that can identify a person, such as names, emails, device IDs or location data. It is not limited to healthcare, and many different laws define it differently.

Context Changes Classification

Data becomes PHI when linked with health information in a HIPAA-covered context. A consumer wellness app outside HIPAA may hold similar data that is regulated instead by state or consumer protection laws.

State Privacy Laws

State laws, such as consumer health data statutes, can regulate health-related information not covered by HIPAA. Digital health products must check state requirements, especially when serving consumers directly rather than providers.

GDPR Special Category Data

Under GDPR, health data is special category data requiring an explicit lawful basis and stronger protections. Products serving European users must meet GDPR obligations alongside, or instead of, HIPAA requirements.

7. Social Security Numbers

Collect SSNs only when necessary, as our HIPAA compliance guide advises. Encrypt them at field level, display only the last four digits, restrict decryption to specific services and never use them as identifiers or keys.

8. Medical Record Numbers

MRNs are identifiers even though they look internal. Use surrogate keys in your schema, keep MRNs in a protected identity table and avoid exposing them in URLs or client-side code.

9. Health Plan Beneficiary Numbers

Member IDs are needed for eligibility and claims workflows. Encrypt them, limit access to billing roles and ensure clearinghouse and payer integrations receive them only over encrypted, BAA-covered connections. Mask them onscreen.

10. Account Numbers

Patient account and billing numbers identify individuals in financial systems. Protect them like other identifiers, and avoid printing them in emails, notifications or exported reports shared outside secured environments. Restrict exports.

11. Certificate and License Numbers

Driver's license numbers and similar certificates identify individuals. If collected for identity verification, store them encrypted, retain them only as long as necessary and delete them according to documented policy.

12. Vehicle Identifiers and Serial Numbers

Vehicle identification numbers and license plates are identifiers, relevant for transport services and accident-related care. Treat them as PHI when linked to patient records, and exclude them from analytics datasets.

Separate Identity From Clinical Data

Store names, contact details and government identifiers in a protected identity table. Clinical, scheduling and billing tables reference patients through surrogate keys, never direct identifiers such as MRNs or emails.

CREATE TABLE patient_identity (
  patient_key UUID PRIMARY KEY,
  mrn_encrypted BYTEA NOT NULL,
  full_name_encrypted BYTEA NOT NULL,
  birth_date_encrypted BYTEA NOT NULL,
  email_hash CHAR(64)
);

CREATE TABLE lab_result (
  result_id UUID PRIMARY KEY,
  patient_key UUID REFERENCES patient_identity(patient_key),
  loinc_code VARCHAR(20) NOT NULL,
  value_numeric NUMERIC,
  resulted_at TIMESTAMPTZ NOT NULL
);

Encrypt Identifier Fields

Apply field-level encryption to high-risk identifiers, such as SSNs, MRNs and member IDs. Use hashes for matching when plaintext is unnecessary, and manage keys through a dedicated key management service.

Restrict Identity Table Access

Grant identity table access only to services that genuinely need it, such as registration or patient communication. Log every access, and review permissions whenever new services are added. Automate permission reviews.

Keep Identifiers Out of Logs and Events

Log surrogate keys and request IDs, not names or MRNs. Review analytics events, error reports and message queues, because identifiers often leak through these channels unnoticed. Scan these channels regularly.

Design for De-identification

Separating identity from clinical data makes de-identification easier, because analytics pipelines can exclude identity tables entirely, then generalize dates and locations to meet Safe Harbor or Expert Determination requirements. Document methods.