Source profileQuality 93/100

maziyarpanahi/openmed/skills/checking-hipaa-compliance/SKILL.md

checking-hipaa-compliance

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, BA

Source repository stars
4,847
Declared platforms
0
Static risk flags
0
Last source update
2026-08-04
Source checked
2026-08-04

Decision brief

What it does—and where it fits

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 g…

Best for

  • You are about to deploy OpenMed (or any pipeline) on real PHI and need a
  • You must document safeguards and minimum-necessary controls for an
  • You want to decide between Safe Harbor and Expert Determination

Not for

  • Tasks that require unconfirmed production actions or broad system permissions.
  • Environments where the pinned source and install steps cannot be inspected.

Compatibility matrix

Platform support, with evidence labels

PlatformStatusEvidenceWhat to check
CodexNot declaredNo explicit evidencePortability before use
Claude CodeNot declaredNo explicit evidencePortability before use
CursorNot declaredNo explicit evidencePortability before use
Gemini CLINot declaredNo explicit evidencePortability before use
Open the compatibility checker

Installation

Inspect first. Install second.

The source command is displayed only when detected. A safe inspection prompt is always available so your agent can explain every action before execution.

Source-detected install commandSource
npx skills add https://github.com/maziyarpanahi/openmed --skill "skills/checking-hipaa-compliance"
Safe inspection promptEditorial

Inspect the Agent Skill "checking-hipaa-compliance" from https://github.com/maziyarpanahi/openmed/blob/e412ae8f3b04ae79b13663d34a422efc22109a3a/skills/checking-hipaa-compliance/SKILL.md at commit e412ae8f3b04ae79b13663d34a422efc22109a3a. List every install step, command, network request, credential, file read/write, external action, and rollback step. Explain whether it fits my task. Do not install or execute anything until I approve.

Workflow

What the source asks the agent to do

  1. 01

    Quick start

    Review the “Quick start” section in the pinned source before continuing.

    Review and apply the “Quick start” source section.
  2. 02

    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…

    Map the data flow. Diagram every place PHI is created, received,Confirm the legal basis. Is the operator a covered entity or businessRun the three safeguard groups from
  3. 03

    When to use

    You are about to deploy OpenMed (or any pipeline) on real PHI and need a

    You are about to deploy OpenMed (or any pipeline) on real PHI and need aYou must document safeguards and minimum-necessary controls for anYou want to decide between Safe Harbor and Expert Determination
  4. 04

    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 actualExpert Determination — a qualified statistician certifies "very small"HIPAA recognizes two de-identification methods (45 CFR 164.514):
  5. 05

    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."

    sample = "John Doe (MRN 1234567), DOB 1970-01-15, seen 2024-03-02 in Boston."

Permission review

Static risk signals and limitations

No configured static risk pattern was detected

This is not proof of safety. Runtime behavior, indirect dependencies, and hidden external systems are outside the static scan.

Evidence record

Why each signal appears

EvidenceSourceComputedTestedEditorial
SignalValueEvidence typeMeaning
Quality score93/100ComputedDocumentation, specificity, maintenance, and trust rules
Repository stars4,847SourceRepository attention, not individual Skill quality
Compatibility0 platformsSourceDeclared in the catalog source record
Usage guideautomated source guideEditorialGenerated or reviewed according to the visible evidence level

Pinned source

Provenance and original SKILL.md

Repository
maziyarpanahi/openmed
Skill path
skills/checking-hipaa-compliance/SKILL.md
Commit
e412ae8f3b04ae79b13663d34a422efc22109a3a
License
Apache-2.0
Collected
2026-08-04
Default branch
master
View the original SKILL.md

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=TrueAuditReport.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

Alternatives

Compare before choosing