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.
75
93%
Does it follow best practices?
Run evals on this skill
Adds up to 20 points to the overall score
View guide
Passed
No findings from the security scan
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.
HIPAA recognizes two de-identification methods (45 CFR 164.514):
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.
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)AuditReport as evidence.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.auditing-safe-harbor-checklist maps detected spans
to the 18 Safe Harbor categories so you can prove each is handled.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.enforcing-nophi-logging keeps identifiers out of logs and
traces (a recurring audit finding).80da98c
If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.