Checking HIPAA compliance before deploying on PHI
Before any pipeline touches protected health information (PHI), the
operating entity (a covered entity or its business associate) must have the
HIPAA Privacy Rule and Security Rule safeguards in place. This skill
walks a concrete pipeline against those requirements and emits a gap report:
which controls are met, which are missing, and where OpenMed's on-device
de-identification and signed audit trail satisfy a requirement.
The full control list — administrative, physical, and technical safeguards with
their 45 CFR citations — is in
references/hipaa-checklist.md. This skill is a
self-assessment aid, not legal advice; a Privacy Officer signs off on
compliance.
When to use
- You are about to deploy OpenMed (or any pipeline) on real PHI and need a
go/no-go compliance review.
- You must document safeguards and minimum-necessary controls for an
audit, a BAA, or a security questionnaire.
- You want to decide between Safe Harbor and Expert Determination
de-identification and record the rationale.
- You need a reproducible gap report you can hand to a Privacy/Security Officer.
The two paths to "no longer PHI"
HIPAA recognizes two de-identification methods (45 CFR 164.514):
- Safe Harbor — remove all 18 identifier categories and have no actual
knowledge the result can re-identify. Deterministic, the common path.
- Expert Determination — a qualified statistician certifies "very small"
re-identification risk. Used when you must keep some quasi-identifiers.
OpenMed's deidentify(..., policy="hipaa_safe_harbor") targets the Safe Harbor
identifier set on-device, and deidentify(..., audit=True) produces a signed,
PHI-free AuditReport that documents what was removed — the evidence a Safe
Harbor attestation and a Security Rule audit control both want.
Quick start
import openmed
# A representative record from the pipeline (synthetic — never log real PHI).
sample = "John Doe (MRN 1234567), DOB 1970-01-15, seen 2024-03-02 in Boston."
# 1) De-identify on-device under the Safe Harbor policy.
result = openmed.deidentify(sample, method="replace", policy="hipaa_safe_harbor")
print(result.deidentified_text) # identifiers removed/surrogated
# 2) Produce the signed, no-PHI audit record for the compliance file.
report = openmed.deidentify(sample, policy="hipaa_safe_harbor", audit=True)
report.sign(b"<release-hmac-key-from-vault>", key_id="hipaa-2026")
# 3) Walk the checklist (see references/hipaa-checklist.md) and record gaps.
controls = {
"encryption_at_rest": True,
"encryption_in_transit": True,
"access_controls_rbac": True,
"audit_logging": True, # satisfied in part by the signed AuditReport
"minimum_necessary": False, # <-- gap: pipeline pulls full notes
"baa_in_place": True,
"deidentification_method": "safe_harbor",
}
gaps = [name for name, ok in controls.items() if not ok]
print("GAPS:", gaps)
Workflow
- Map the data flow. Diagram every place PHI is created, received,
maintained, or transmitted — including model caches, temp files, and logs.
- Confirm the legal basis. Is the operator a covered entity or business
associate? Is a BAA in place with every downstream vendor that touches
PHI? OpenMed running on-device means no third-party processor for the NLP
step — note that as a control in your favor.
- Run the three safeguard groups from
references/hipaa-checklist.md:
administrative (risk analysis, workforce training, sanctions),
physical (facility/device controls), and technical (access control, audit
controls, integrity, transmission security).
- Enforce minimum necessary. Pull only the fields the task needs; mask the
rest. De-identify as early in the flow as the use case allows.
- Record the de-identification method (Safe Harbor vs Expert Determination)
and attach the signed
AuditReport as evidence.
- Emit the gap report — met / not-met / N/A per control, with the 45 CFR
citation and the remediation owner. Hand it to the Privacy Officer.
Hand-off to / from OpenMed
- De-identification:
deidentifying-clinical-text (openmed.deidentify,
policy="hipaa_safe_harbor") is the technical control that converts PHI to
non-PHI on-device — the heart of a HIPAA pipeline.
- Identifier coverage:
auditing-safe-harbor-checklist maps detected spans
to the 18 Safe Harbor categories so you can prove each is handled.
- Audit control:
auditing-deidentification-runs (audit=True →
AuditReport.sign()/.verify()) gives the tamper-evident, PHI-free record the
Security Rule audit-controls standard (164.312(b)) expects.
- No-PHI logging:
enforcing-nophi-logging keeps identifiers out of logs and
traces (a recurring audit finding).
- OpenMed is local-first — the NLP step adds no new business associate.
Edge cases & gotchas
- De-identified data is out of scope — but only if done right. Safe Harbor
requires all 18 categories removed and no actual knowledge of
re-identifiability. A residual rare ZIP3 or a free-text name the model missed
re-introduces PHI. Verify coverage; don't assume.
- Limited Data Sets are still PHI. Dates and ZIPs retained under a Data Use
Agreement (164.514(e)) are not de-identified — different rules apply.
- Logs and caches are PHI too. Model caches, exception messages, and temp
files holding raw notes are in scope. This is the most common gap.
- A BAA is required for every vendor that creates/receives/maintains/
transmits PHI on your behalf — including cloud storage and any LLM API. Running
OpenMed on-device avoids adding one for the NLP step.
- Minimum necessary is a duty, not a nicety (164.502(b)). Don't pull full
charts when a problem list suffices.
- Breach notification clock. Unsecured PHI exposure triggers 164.400-414
duties; encryption to NIST standards renders data "secured" and can avoid the
notification trigger.
- Not legal advice. This checklist supports, but does not replace, a Privacy
Officer's determination and (for Expert Determination) a qualified statistician.
Standards & references
1---2name: checking-hipaa-compliance3description: Runs a HIPAA Privacy and Security Rule checklist over a data pipeline and produces a gap report before deploying OpenMed on PHI. Use when the user is about to process protected health information, needs a pre-deployment compliance review, wants to know which administrative, physical, and technical safeguards apply, is scoping a Business Associate Agreement, or must document minimum-necessary and de-identification controls. Trigger keywords: HIPAA, Privacy Rule, Security Rule, 45 CFR 164, PHI, BAA, business associate, minimum necessary, safeguards, Safe Harbor, Expert Determination, gap analysis, compliance review. Pairs adjacent to OpenMed: the checklist shows where openmed.deidentify and signed audit reports satisfy the de-identification and audit-control requirements. The control list lives in references/hipaa-checklist.md. This is a structured self-assessment aid, not legal advice.4license: Apache-2.05---67# Checking HIPAA compliance before deploying on PHI89Before any pipeline touches **protected health information (PHI)**, the10operating entity (a covered entity or its business associate) must have the11HIPAA **Privacy Rule** and **Security Rule** safeguards in place. This skill12walks a concrete pipeline against those requirements and emits a **gap report**:13which controls are met, which are missing, and where OpenMed's on-device14de-identification and signed audit trail satisfy a requirement.1516The full control list — administrative, physical, and technical safeguards with17their 45 CFR citations — is in18[references/hipaa-checklist.md](references/hipaa-checklist.md). This skill is a19**self-assessment aid**, not legal advice; a Privacy Officer signs off on20compliance.2122## When to use2324- You are about to deploy OpenMed (or any pipeline) on real PHI and need a25 go/no-go compliance review.26- You must document **safeguards** and **minimum-necessary** controls for an27 audit, a BAA, or a security questionnaire.28- You want to decide between **Safe Harbor** and **Expert Determination**29 de-identification and record the rationale.30- You need a reproducible gap report you can hand to a Privacy/Security Officer.3132## The two paths to "no longer PHI"3334HIPAA recognizes two de-identification methods (45 CFR 164.514):35361. **Safe Harbor** — remove all **18 identifier categories** and have no actual37 knowledge the result can re-identify. Deterministic, the common path.382. **Expert Determination** — a qualified statistician certifies "very small"39 re-identification risk. Used when you must keep some quasi-identifiers.4041OpenMed's `deidentify(..., policy="hipaa_safe_harbor")` targets the Safe Harbor42identifier set on-device, and `deidentify(..., audit=True)` produces a signed,43PHI-free `AuditReport` that documents *what* was removed — the evidence a Safe44Harbor attestation and a Security Rule audit control both want.4546## Quick start4748```python49import openmed5051# A representative record from the pipeline (synthetic — never log real PHI).52sample = "John Doe (MRN 1234567), DOB 1970-01-15, seen 2024-03-02 in Boston."5354# 1) De-identify on-device under the Safe Harbor policy.55result = openmed.deidentify(sample, method="replace", policy="hipaa_safe_harbor")56print(result.deidentified_text) # identifiers removed/surrogated5758# 2) Produce the signed, no-PHI audit record for the compliance file.59report = openmed.deidentify(sample, policy="hipaa_safe_harbor", audit=True)60report.sign(b"<release-hmac-key-from-vault>", key_id="hipaa-2026")6162# 3) Walk the checklist (see references/hipaa-checklist.md) and record gaps.63controls = {64 "encryption_at_rest": True,65 "encryption_in_transit": True,66 "access_controls_rbac": True,67 "audit_logging": True, # satisfied in part by the signed AuditReport68 "minimum_necessary": False, # <-- gap: pipeline pulls full notes69 "baa_in_place": True,70 "deidentification_method": "safe_harbor",71}72gaps = [name for name, ok in controls.items() if not ok]73print("GAPS:", gaps)74```7576## Workflow77781. **Map the data flow.** Diagram every place PHI is created, received,79 maintained, or transmitted — including model caches, temp files, and logs.802. **Confirm the legal basis.** Is the operator a covered entity or business81 associate? Is a **BAA** in place with every downstream vendor that touches82 PHI? OpenMed running on-device means *no* third-party processor for the NLP83 step — note that as a control in your favor.843. **Run the three safeguard groups** from85 [references/hipaa-checklist.md](references/hipaa-checklist.md):86 administrative (risk analysis, workforce training, sanctions),87 physical (facility/device controls), and technical (access control, audit88 controls, integrity, transmission security).894. **Enforce minimum necessary.** Pull only the fields the task needs; mask the90 rest. De-identify as early in the flow as the use case allows.915. **Record the de-identification method** (Safe Harbor vs Expert Determination)92 and attach the signed `AuditReport` as evidence.936. **Emit the gap report** — met / not-met / N/A per control, with the 45 CFR94 citation and the remediation owner. Hand it to the Privacy Officer.9596## Hand-off to / from OpenMed9798- **De-identification:** `deidentifying-clinical-text` (`openmed.deidentify`,99 `policy="hipaa_safe_harbor"`) is the technical control that converts PHI to100 non-PHI on-device — the heart of a HIPAA pipeline.101- **Identifier coverage:** `auditing-safe-harbor-checklist` maps detected spans102 to the 18 Safe Harbor categories so you can prove each is handled.103- **Audit control:** `auditing-deidentification-runs` (`audit=True` →104 `AuditReport.sign()/.verify()`) gives the tamper-evident, PHI-free record the105 Security Rule audit-controls standard (164.312(b)) expects.106- **No-PHI logging:** `enforcing-nophi-logging` keeps identifiers out of logs and107 traces (a recurring audit finding).108- OpenMed is **local-first** — the NLP step adds no new business associate.109110## Edge cases & gotchas111112- **De-identified data is out of scope — but only if done right.** Safe Harbor113 requires *all 18* categories removed *and* no actual knowledge of114 re-identifiability. A residual rare ZIP3 or a free-text name the model missed115 re-introduces PHI. Verify coverage; don't assume.116- **Limited Data Sets are still PHI.** Dates and ZIPs retained under a Data Use117 Agreement (164.514(e)) are not de-identified — different rules apply.118- **Logs and caches are PHI too.** Model caches, exception messages, and temp119 files holding raw notes are in scope. This is the most common gap.120- **A BAA is required for every vendor** that creates/receives/maintains/121 transmits PHI on your behalf — including cloud storage and any LLM API. Running122 OpenMed on-device avoids adding one for the NLP step.123- **Minimum necessary is a duty, not a nicety** (164.502(b)). Don't pull full124 charts when a problem list suffices.125- **Breach notification clock.** Unsecured PHI exposure triggers 164.400-414126 duties; encryption to NIST standards renders data "secured" and can avoid the127 notification trigger.128- **Not legal advice.** This checklist supports, but does not replace, a Privacy129 Officer's determination and (for Expert Determination) a qualified statistician.130131## Standards & references132133- HHS HIPAA for Professionals (hub): https://www.hhs.gov/hipaa/for-professionals/index.html134- Privacy Rule, 45 CFR Part 164 Subpart E: https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-E135- Security Rule, 45 CFR Part 164 Subpart C: https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-C136- De-identification guidance (Safe Harbor & Expert Determination), 164.514: https://www.hhs.gov/hipaa/for-professionals/privacy/special-topics/de-identification/index.html137- HHS Security Risk Assessment Tool: https://www.healthit.gov/topic/privacy-security-and-hipaa/security-risk-assessment-tool138- NIST SP 800-66r2 (implementing the Security Rule): https://csrc.nist.gov/pubs/sp/800/66/r2/final