checking-hipaa-compliance

name	checking-hipaa-compliance
description	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.
license	Apache-2.0
metadata	{"project":"OpenMed","category":"compliance-regulatory","pairs":"adjacent","version":"1.0"}

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):

1. Safe Harbor — remove all 18 identifier categories and have no actual knowledge the result can re-identify. Deterministic, the common path.
2. 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

1. Map the data flow. Diagram every place PHI is created, received, maintained, or transmitted — including model caches, temp files, and logs.
2. 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.
3. 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).
4. 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.
5. Record the de-identification method (Safe Harbor vs Expert Determination) and attach the signed AuditReport as evidence.
6. 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

• HHS HIPAA for Professionals (hub): https://www.hhs.gov/hipaa/for-professionals/index.html
• Privacy Rule, 45 CFR Part 164 Subpart E: https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-E
• Security Rule, 45 CFR Part 164 Subpart C: https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-C
• De-identification guidance (Safe Harbor & Expert Determination), 164.514: https://www.hhs.gov/hipaa/for-professionals/privacy/special-topics/de-identification/index.html
• HHS Security Risk Assessment Tool: https://www.healthit.gov/topic/privacy-security-and-hipaa/security-risk-assessment-tool
• NIST SP 800-66r2 (implementing the Security Rule): https://csrc.nist.gov/pubs/sp/800/66/r2/final