Everything engineering and compliance teams need to find protected health information in text: what PHI actually is, the complete Safe Harbor identifier list mapped to detectable entity types, de-identification methods, BAAs, penalties, and working code.
Start ReadingProtected health information (PHI) is the legal category at the center of HIPAA: individually identifiable health information that is created, received, maintained, or transmitted by a covered entity — a health plan, a healthcare clearinghouse, or a provider that bills electronically — or by one of its business associates. Three conditions must hold at once. The information must relate to someone's past, present, or future physical or mental health, to the provision of care, or to payment for care; it must identify the individual or provide a reasonable basis for identifying them; and it must be held within the HIPAA-regulated ecosystem.
That last condition trips people up constantly. A blood pressure reading in a hospital's EHR is PHI. The identical reading typed into a consumer wellness app that has no relationship with a covered entity is not — it may still be personal data under state law or the FTC's health breach rules, but HIPAA does not reach it. Conversely, information that looks harmless becomes PHI through context: an appointment reminder containing only a name and a date is PHI, because the existence of a treatment relationship is itself health information.
PHI is therefore best understood as identifiability plus health context. The health context usually comes for free — if your organization is a provider, payer, or vendor to one, nearly everything you process has it. The identifiability half is where engineering can act, and it is exactly what HIPAA's de-identification standard operationalizes: remove the identifiers, and the data ceases to be PHI at all. That is why automated PII detection is the workhorse of HIPAA programs — it finds the identifiers, with character offsets, so they can be removed, masked, or audited at scale.
One more scoping note: HIPAA covers PHI in any form — electronic (ePHI), paper, and oral. This guide focuses on text, because text is where PHI sprawls uncontrollably: clinical notes, discharge summaries, claims, prior-authorization faxes rendered by OCR, patient portal messages, call-center transcripts, and the email threads that stitch all of it together.
HIPAA is not one rule but a family of them, extended by the HITECH Act in 2009. Three regulations matter most for anyone building systems that touch PHI — and each of them quietly assumes you can find identifiers in your data on demand.
Sets the rules for using and disclosing PHI. Its two engineering-relevant pillars are the minimum necessary standard — use or disclose only the least PHI required for a purpose — and the de-identification standard at §164.514, which defines exactly when data stops being PHI. Minimum necessary is where detection earns its keep daily: stripping identifiers from data flowing to analytics, QA, or vendors is the most defensible way to demonstrate it.
Covers electronic PHI specifically and requires administrative, physical, and technical safeguards proportionate to risk. You cannot safeguard ePHI you have not located: the mandatory risk analysis presumes an inventory of where ePHI lives, including the places nobody designed — application logs, crash dumps, test databases, and shared drives. Automated scanning of those surfaces is how mature programs keep the inventory honest; see scanning logs for PII.
When unsecured PHI is impermissibly disclosed, covered entities must notify affected individuals, HHS, and sometimes the media — unless a documented risk assessment shows a low probability of compromise. Two detection angles: first, breach scoping means answering "whose identifiers were in that mailbox or file share?", which is a scanning problem. Second, and better, data that was properly de-identified before the incident was never PHI, so its exposure is not a breach at all.
Safe Harbor (§164.514(b)(2)) lists eighteen categories of identifiers that must be removed — for the patient and for relatives, employers, and household members. The table maps each one to the entity types the PII Detection API returns, so a de-identification pipeline can be configured as a concrete entity list rather than a legal abstraction.
| # | Safe Harbor Identifier | API Entity Types | Notes |
|---|---|---|---|
| 1 | Names | PERSON_NAME | Includes nicknames, initials, and relatives' names scattered through narrative text. See detecting names. |
| 2 | Geographic subdivisions smaller than a state | ADDRESS, CITY, ZIP_CODE, GPS_COORDINATES | Street address, city, county, precinct, ZIP. The first three ZIP digits may be kept if the area holds >20,000 people. |
| 3 | All date elements (except year) related to the individual | DATE_OF_BIRTH, AGE | Birth, admission, discharge, and death dates; all ages over 89 must be aggregated. See detecting dates of birth. |
| 4 | Telephone numbers | PHONE_NUMBER | Any format, any country — patients paste them into portal messages freely. |
| 5 | Fax numbers | PHONE_NUMBER | Still ubiquitous in referrals and prior authorizations. |
| 6 | Email addresses | EMAIL_ADDRESS | Bodies, headers, and signatures alike. See email PII scanning. |
| 7 | Social Security numbers | SSN | Formatted or bare nine digits; context separates them from other numerics. See detecting SSNs. |
| 8 | Medical record numbers | MEDICAL_RECORD_NUMBER | Facility-specific formats; context cues like "MRN" drive recognition. See detecting MRNs. |
| 9 | Health plan beneficiary numbers | HEALTH_INSURANCE_ID | Member IDs, Medicare Beneficiary Identifiers, group numbers on claims. |
| 10 | Account numbers | FINANCIAL_ACCOUNT_NUMBER, CREDIT_CARD_NUMBER | Billing accounts, guarantor accounts, cards used for copays. |
| 11 | Certificate / license numbers | DRIVERS_LICENSE_NUMBER, NATIONAL_ID | Driver's licenses collected at intake, professional license numbers. |
| 12 | Vehicle identifiers, incl. license plates | SERIAL_NUMBER | VINs and plates appear in ambulance, trauma, and workers'-comp records. |
| 13 | Device identifiers & serial numbers | DEVICE_ID, SERIAL_NUMBER, IMEI | Pacemaker and implant serials, pump IDs, monitoring hardware. |
| 14 | Web URLs | URL | Patient portal links and personal sites embedded in correspondence. |
| 15 | IP addresses | IP_ADDRESS | Telehealth session logs and portal access records. See detecting IPs. |
| 16 | Biometric identifiers | BIOMETRIC_DATA | Fingerprints, voiceprints, retinal data referenced in records. |
| 17 | Full-face photographs and comparable images | Image analysis | Detection applies to images and to textual references to identifiable photos. |
| 18 | Any other unique identifying number, characteristic, or code | NATIONAL_ID, TAX_ID, PASSPORT_NUMBER, custom via custom_instruction | The catch-all: study IDs, tattoo descriptions, "the mayor's daughter" — anything uniquely identifying. |
Two practical warnings. Identifier 18 means Safe Harbor can never be reduced to a fixed regex list — a unique characteristic ("the only left-handed violinist on the transplant list") identifies just as surely as a number, which is why context-aware NER matters. And the standard also requires that the covered entity has no actual knowledge that the remaining information could identify the individual; automated detection satisfies the removal half, while that residual judgment stays human.
HIPAA gives exactly two exits from PHI status. Safe Harbor is the mechanical route: remove all eighteen identifier categories and confirm no actual knowledge of residual identifiability. Its virtue is auditability — you can point to a pipeline, an entity list, and a scan report and show your work. Its cost is utility: stripping all date elements and fine-grained geography can hollow out datasets meant for epidemiology, readmission analysis, or ML training, where the interval between admission and discharge may be the whole signal.
Expert Determination is the statistical route: a person with appropriate expertise applies accepted statistical and scientific principles and documents that the risk of re-identification is "very small" for the anticipated recipient. It can preserve far more utility — keeping date shifts consistent within a patient, retaining three-digit ZIPs, generalizing ages into bands — but it produces an expert's opinion tied to a specific dataset and recipient, must be refreshed as data and context change, and costs real money per engagement.
In practice the two methods are complements, not rivals, and both sit downstream of the same detection step. Safe Harbor pipelines feed the full 18-identifier entity list to the API and mask everything found. Expert Determination workflows use the same detection pass differently: the expert needs a complete census of which identifiers appear, where, and at what frequency before they can model risk at all, and the transformation they prescribe (suppress this, generalize that, shift dates) is executed against the detector's character offsets. Either way, recall is the currency — an identifier you never found is an identifier you never treated.
Choose Safe Harbor when you need a defensible default for routine sharing and internal secondary use; bring in Expert Determination when research utility justifies the overhead. And validate your recall before trusting either — the accuracy guide shows how to measure it on your own clinical text, and the live demo lets you paste a de-identified-looking note and see what a modern detector still finds.
Structured EHR fields are the easy part — the schema tells you where the MRN column is. The risk lives in free text, where identifiers appear without labels, in mid-sentence, misspelled, and about third parties. These are the surfaces where automated detection changes the game.
Narrative notes are the densest PHI surface in healthcare: "Mrs. Alvarez, a 91-year-old retired teacher from Cedar Rapids, was admitted on 3/14 after her daughter Karen called EMS." One sentence, five identifier categories, zero labels. Names of relatives, employers, and neighborhoods all count under Safe Harbor, and only a model reading full sentences catches them — the case for NER over regex in one line.
Claims concentrate the numeric identifiers: member IDs, MRNs, guarantor account numbers, provider NPIs, service dates, and occasionally card numbers from copay processing. Free-text adjustment reasons and appeal letters then add names and narrative context. Claims files exported to Excel for analysis are a classic uncontrolled-copy problem — every export is a candidate for a de-identification pass first.
Speech-to-text turns every patient phone call into ePHI: callers state their name, date of birth, and member ID in the first thirty seconds because verification scripts ask them to. Transcription noise ("my member ID is A as in apple, four seven...") defeats format-based matching, while context-aware detection still flags it. Relevant industry views: telehealth and call centers.
Patients volunteer everything in portal messages and email — symptoms, medication lists, photos of insurance cards. Meanwhile decades of faxes and scanned intake forms sit in document stores as images, invisible until OCR extracts their text. The document scanning guide covers the OCR-then-detect pipeline; email scanning covers the mailbox side.
The requests below use the standard API contract: one POST, a target entity list, and structured findings back with offsets and confidence. Start with cURL to see the shape, then the Python Safe Harbor pass, then a Node.js transcript filter.
# cURL — scan a clinical note fragment for core PHI identifiers
curl -X POST https://piidetectionapi.com/api/moderate.php \
-H "Content-Type: application/json" \
-d '{
"api_key": "YOUR_API_KEY",
"api_type": "pii_detection",
"text": "Pt Maria Alvarez (MRN 8837412, DOB 04/12/1951) seen 3/14. Daughter Karen 555-201-8834. Aetna member W229041188.",
"entities": ["PERSON_NAME","MEDICAL_RECORD_NUMBER","DATE_OF_BIRTH","PHONE_NUMBER","HEALTH_INSURANCE_ID"],
"mask_mode": "replace",
"threshold": 0.4
}'
# Python — Safe Harbor de-identification pass covering the 18 identifier categories
import requests
SAFE_HARBOR_ENTITIES = [
"PERSON_NAME", "ADDRESS", "CITY", "ZIP_CODE", "GPS_COORDINATES",
"DATE_OF_BIRTH", "AGE", "PHONE_NUMBER", "EMAIL_ADDRESS", "SSN",
"MEDICAL_RECORD_NUMBER", "HEALTH_INSURANCE_ID", "FINANCIAL_ACCOUNT_NUMBER",
"CREDIT_CARD_NUMBER", "DRIVERS_LICENSE_NUMBER", "NATIONAL_ID",
"SERIAL_NUMBER", "DEVICE_ID", "IMEI", "URL", "IP_ADDRESS",
"BIOMETRIC_DATA", "PASSPORT_NUMBER", "TAX_ID",
]
def deidentify_note(note_text: str) -> dict:
resp = requests.post(
"https://piidetectionapi.com/api/moderate.php",
json={
"api_key": "YOUR_API_KEY",
"api_type": "pii_detection",
"text": note_text,
"entities": SAFE_HARBOR_ENTITIES,
"mask_mode": "replace",
"threshold": 0.35, # favor recall: a missed identifier is a breach
},
timeout=30,
)
resp.raise_for_status()
data = resp.json()
# Audit trail: log entity types and counts, never the matched text itself
counts = {}
for e in data["detected_entities"]:
counts[e["type"]] = counts.get(e["type"], 0) + 1
return {"deidentified": data["anonymized_text"], "identifier_counts": counts}
result = deidentify_note("Mrs. Alvarez of 14 Elm St was discharged 3/18; f/u with Dr. Chen.")
print(result["deidentified"])
# Mrs. [NAME] of [ADDRESS] was discharged [DATE]; f/u with Dr. [NAME].
// JavaScript (Node fetch) — redact PHI from telehealth transcripts before archiving
async function scrubTranscript(segmentText) {
const resp = await fetch("https://piidetectionapi.com/api/moderate.php", {
method: "POST",
headers: { "Content-Type": "application/json" },
body: JSON.stringify({
api_key: process.env.PII_API_KEY,
api_type: "pii_detection",
text: segmentText,
exclude_entities: ["MEDICAL_TERM", "DIAGNOSIS"], // keep clinical content for QA review
mask_mode: "redact",
threshold: 0.4,
custom_instruction: "Do not flag clinician names prefixed with Dr. in our provider directory context",
}),
});
const { anonymized_text, entities_detected } = await resp.json();
return { clean: anonymized_text, flagged: entities_detected };
}
The full parameter reference lives in the API documentation. Note the low thresholds throughout: in de-identification, false negatives are breaches while false positives merely cost a little utility, so healthcare pipelines deliberately trade precision for recall.
Between fully identified PHI and fully de-identified data, HIPAA defines a third state: the limited data set (§164.514(e)). It permits retention of certain quasi-identifiers that Safe Harbor would strip — full dates of service and birth, city, state, five-digit ZIP code, and ages including those over 89 — while still requiring removal of sixteen categories of direct identifiers: names, street addresses, phone and fax numbers, emails, SSNs, MRNs, health plan numbers, account numbers, license and vehicle numbers, device identifiers, URLs, IPs, biometrics, and full-face photos.
A limited data set is still PHI — that is the crucial difference from de-identified data. It may be used only for research, public health, or healthcare operations, and only under a data use agreement in which the recipient commits not to re-identify or contact individuals and to apply appropriate safeguards. In exchange, researchers keep the temporal and geographic resolution that makes outcomes studies possible.
Operationally, producing a limited data set is the same pipeline as Safe Harbor with a shorter entity list. Take the Safe Harbor configuration from the code section above and remove DATE_OF_BIRTH, AGE, CITY, and ZIP_CODE from the entities array — or equivalently move them to exclude_entities — and the API masks the direct identifiers while leaving dates and geography intact. Running the two configurations as separate, version-controlled profiles ("safe_harbor_v3", "lds_v3") gives auditors a clean answer to "exactly what was removed from this extract, and when?"
Teams in pharma and clinical trials lean on limited data sets heavily, since trial analytics die without dates. The discipline to maintain is provenance: label every extract with the profile that produced it, because a limited data set that wanders into a context without a data use agreement is simply an unauthorized PHI disclosure.
If a vendor creates, receives, maintains, or transmits PHI on behalf of a covered entity, that vendor is a business associate, and HIPAA requires a signed business associate agreement (BAA) before any PHI flows. A PHI detection service processing your clinical text is squarely in that definition. The BAA binds the vendor to the Security Rule, restricts uses to the contracted service, requires breach reporting to you, and flows the same obligations down to subcontractors.
So the diligence checklist for a detection API is concrete. Will the vendor sign a BAA? What is the retention policy for submitted text — is it processed transiently or stored? What encryption applies in transit and at rest? Is there independent attestation such as GDPR-native? PII Detection API operates under strict, audited security controls, supports BAAs for healthcare customers, and processes text for detection without retaining it as training data — contact us to put an agreement in place, and see pricing for plan tiers.
For workloads where PHI cannot leave your network boundary at all — a common posture for large health systems — an on-premise deployment runs the same detection engine inside your infrastructure, which changes the HIPAA analysis entirely: no disclosure to a third party occurs, so scanning falls under your existing safeguards rather than a vendor relationship. This is the standard architecture for high-volume EHR de-identification and for healthcare providers with strict data-residency commitments.
One subtlety worth naming: using a detection API to remove identifiers is itself a use of PHI, so the BAA must be in place before your de-identification pipeline runs, not after. The output of that pipeline, once Safe Harbor is satisfied, is no longer PHI and can flow to analytics vendors, LLM providers, and research partners without HIPAA attaching at all — which is precisely why de-identification at the boundary is such a powerful architectural pattern.
HHS Office for Civil Rights enforces HIPAA through a four-tier civil penalty structure keyed to culpability, established by HITECH and adjusted annually for inflation. State attorneys general can bring parallel actions, and the Department of Justice handles criminal cases.
| Tier | Culpability | Per-Violation Range (base) | Annual Cap (per provision) |
|---|---|---|---|
| 1 | Unknowing — did not know and could not reasonably have known | $100 – $50,000 | Approx. $1.5M base per violated provision per year, inflation-adjusted upward annually (over $2M in recent schedules) |
| 2 | Reasonable cause — knew or should have known, but not willful neglect | $1,000 – $50,000 | |
| 3 | Willful neglect, corrected within 30 days | $10,000 – $50,000 | |
| 4 | Willful neglect, not corrected | $50,000 minimum |
Criminal exposure escalates from fines and up to one year in prison for knowing violations, to five years where PHI is obtained under false pretenses, to $250,000 and ten years where it is sold or used for commercial advantage or malicious harm. The largest OCR settlements — Anthem's $16M after the 79-million-record breach being the high-water mark — all followed breaches of data that detection-and-minimization programs are designed to shrink. The cheapest identifier to defend is the one that was masked before the incident.
Patterns that separate durable HIPAA programs from checkbox exercises, distilled from how health systems, payers, and health-tech vendors actually deploy detection.
Run low confidence thresholds (0.3–0.4) on de-identification paths and accept some over-masking; a missed MRN is a reportable event, an over-masked word is a nuisance. Then sample masked output monthly, measure per-entity precision and recall on your own note types, and track drift — methodology in the accuracy guide.
Place detection at every point where data leaves the treatment context: exports to analytics, vendor feeds, LLM prompts, support tooling, and test databases. Data that crosses the boundary already masked never expands your breach surface. Version-control the entity profiles (Safe Harbor, limited data set) so every extract is traceable to a configuration.
The EHR is guarded; the danger is everywhere PHI seeped without design — application logs, crash reports, Slack exports, spreadsheets on file shares, dev/test databases. Schedule discovery scans across those surfaces and feed findings into your Security Rule risk analysis. Guides: database discovery and test data scanning.
Log what compliance needs — entity types, counts, offsets, confidence, profile version, timestamp — and never the matched text, or your audit log becomes a new PHI store. Structured API responses make this a filtering exercise. Pair with a signed BAA (or on-premise deployment) and documented threshold rationale, and your next OCR audit response writes itself.
DIAGNOSIS, PRESCRIPTION, TREATMENT, MEDICAL_TERM) via exclude_entities while masking the 18 identifier categories. The result reads as medicine with the person removed: "[NAME], [AGE], presented with acute pancreatitis; started on IV fluids."Paste a clinical note into the live demo and watch all 18 Safe Harbor categories light up with offsets and confidence scores — then pick a plan and put a BAA in place when you are ready.
Try the Live Demo View Pricing