hipaa-audit

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

HIPAA Audit — Health Insurance Portability and Accountability Act

HIPAA审计——健康保险流通与责任法案

HIPAA governs how Protected Health Information (PHI) is handled in the United States healthcare ecosystem. The engineering surface area is large because PHI is broader than people often realize: a calendar entry naming a patient's appointment is PHI; an IP address logged on a portal accessed by a patient may be PHI in combination with a health condition.

The skill is structured around the four HIPAA rules with emphasis on the Security Rule's three safeguard categories (Administrative / Physical / Technical) — that's where engineering work happens. Privacy Rule, Breach Notification Rule, and HITECH layer on top.

Final compliance determinations stay with counsel and your privacy officer; this skill is the technical engineering layer.

Cross-references:

privacy-engineering

for the GDPR / CCPA-shaped privacy work that often overlaps;

iam-audit

for access control and authentication;

crypto-audit

for encryption-at-rest and in-transit detail;

secrets-audit

for key management;

siem-detection

for audit-log engineering;

incident-triage

and

security-comms

for breach response.

HIPAA规范美国医疗生态系统中受保护健康信息（PHI）的处理方式。由于PHI的范围比人们通常认知的更广泛，涉及的工程领域也很广：标注患者预约的日历条目属于PHI；患者访问的门户上记录的IP地址，若与健康状况结合，也可能被视为PHI。

本技能围绕HIPAA的四项规则构建，重点关注安全规则的三类保障措施（管理/物理/技术）——这正是工程工作的核心领域。隐私规则、违规通知规则和HITECH则作为补充层。

最终合规判定由法律顾问和隐私官负责；本技能仅提供技术工程层面的支持。

交叉参考：

privacy-engineering

（涉及常重叠的GDPR/CCPA类隐私工作）；

iam-audit

（访问控制与身份认证）；

crypto-audit

（静态与传输加密细节）；

secrets-audit

（密钥管理）；

siem-detection

（审计日志工程）；

incident-triage

和

security-comms

（违规响应）。

Scope — who is covered and what is PHI

范围——合规主体与PHI定义

Who must comply

谁必须合规

Covered entity (CE) — health plans, healthcare clearinghouses, healthcare providers who transmit health info electronically in connection with HIPAA-defined transactions
Business associate (BA) — anyone who creates / receives / maintains / transmits PHI on behalf of a covered entity (cloud hosts holding PHI, SaaS analytics, EHR vendors, billing services, even some attorneys and consultants)
Subcontractor of a BA — also a BA. The chain extends; every link needs a BAA with the link above

If a system handles PHI for a CE without a BAA, that's a violation regardless of how secure the handling is.

覆盖实体（Covered Entity, CE）——健康计划、医疗结算所，以及在HIPAA定义的交易中以电子方式传输健康信息的医疗服务提供者
业务关联方（Business Associate, BA）——代表覆盖实体创建/接收/维护/传输PHI的任何主体（存储PHI的云服务商、SaaS分析工具、电子健康记录供应商、账单服务提供商，甚至部分律师和顾问）
BA的分包商——同样属于BA范畴。责任链会延伸，每个环节都需与上一环节签订BAA

若系统为CE处理PHI却未签订BAA，无论处理方式多么安全，均属违规。

What is PHI / ePHI

什么是PHI / ePHI

PHI = individually identifiable health information held or transmitted by a CE or BA. ePHI = the electronic form.

The 18 HIPAA identifiers (Safe Harbor de-identification list — if all are stripped, data is no longer PHI):

Names
Geographic subdivisions smaller than state (street, city, county, ZIP — full ZIP if population < 20,000; first 3 digits OK in most cases)
Dates more specific than year (DOB, admission, discharge, death) — for individuals over 89, even the year requires aggregation
Phone numbers
Fax numbers
Email addresses
Social Security numbers
Medical record numbers
Health plan beneficiary numbers
Account numbers
Certificate / license numbers
Vehicle identifiers and serial numbers (including license plates)
Device identifiers and serial numbers
URLs
IP addresses
Biometric identifiers (finger, voice)
Full-face photographs and comparable images
Any other unique identifying number, characteristic, or code

Important: removing the 18 identifiers via Safe Harbor is one of two de-identification methods. The other is Expert Determination (statistical analysis confirming low re-identification risk). De-identified data is not PHI; pseudonymized data is still PHI (because the key linking the surrogate back to the individual is still held somewhere).

PHI = 覆盖实体或业务关联方持有或传输的可识别个人身份的健康信息。ePHI = 其电子形式。

18项HIPAA标识符（安全港去标识化列表——若全部移除，数据不再属于PHI）：

姓名
小于州级的地理细分区域（街道、城市、县、邮政编码——若人口少于20000，完整邮政编码需移除；多数情况下保留前3位即可）
比年份更具体的日期（出生日期、入院、出院、死亡日期）——对于89岁以上的个体，即使年份也需进行聚合处理
电话号码
传真号码
电子邮箱地址
社会保障号码
病历号
健康计划受益人编号
账户编号
证书/执照编号
车辆标识符及序列号（含车牌）
设备标识符及序列号
URL
IP地址
生物识别标识符（指纹、语音）
正面照片及同类图像
任何其他唯一识别号码、特征或代码

重要提示： 通过安全港方法移除18项标识符是两种去标识化方法之一。另一种是专家判定法（通过统计分析确认重新识别风险较低）。去标识化数据不属于PHI；伪匿名化数据仍属于PHI（因为将替代标识与个人关联的密钥仍被某处持有）。

Scope reduction patterns

范围缩减方案

The most common scope reductions:

Limit data classes collected — if you don't need DOB, don't collect it; don't transmit it; don't store it
Pseudonymize internally where regulators allow, but understand that internal pseudonyms are still ePHI (the linking table is held by the CE / BA)
Use BA-signed services where possible — AWS, Google Cloud, Azure, Stripe Healthcare, certain analytics vendors sign BAAs; many SaaS tools do not
Use services that contractually commit to never receive PHI — analytics platforms that scrub on ingest, error reporters with strict PII filtering

最常见的范围缩减方式：

限制收集的数据类别——若不需要出生日期，则不收集、不传输、不存储
在监管允许的情况下内部伪匿名化，但需了解内部伪匿名数据仍属于ePHI（关联表由CE/BA持有）
尽可能使用已签署BAA的服务——AWS、Google Cloud、Azure、Stripe Healthcare及部分分析供应商会签署BAA；许多SaaS工具默认不提供
使用合同承诺绝不接收PHI的服务——在数据摄入阶段清理PHI的分析平台、严格过滤PII的错误报告工具

Security Rule — the three safeguard categories

安全规则——三类保障措施

Administrative safeguards (program-level)

管理保障措施（项目层面）

These are policy and program controls. Engineering teams contribute artifacts; the privacy officer owns the program.

§164.308(a)(1) Security Management Process — risk analysis (the foundation; redone on material change), risk management, sanction policy, information system activity review
§164.308(a)(2) Assigned Security Responsibility — a named Security Official
§164.308(a)(3) Workforce Security — authorization / supervision, termination procedures
§164.308(a)(4) Information Access Management — access authorization, modification
§164.308(a)(5) Security Awareness and Training — including security reminders, malicious software protection, log-in monitoring, password management
§164.308(a)(6) Security Incident Procedures — see
```
incident-triage
```
§164.308(a)(7) Contingency Plan — backup, disaster recovery, emergency mode operation, testing
§164.308(a)(8) Evaluation — periodic technical and non-technical evaluation
§164.308(b)(1) Business Associate Contracts — BAA with every BA

Engineering audit input: evidence packages for risk analysis (asset inventory, threat model, controls list), workforce-security records (access reviews, joiner/mover/leaver evidence), training completion records.

这些是政策和项目管控措施。工程团队提供相关文档；隐私官负责项目整体管理。

§164.308(a)(1) 安全管理流程——风险分析（基础工作，发生重大变更时需重新开展）、风险管理、处罚政策、信息系统活动审查
§164.308(a)(2) 指定安全负责人——任命一名正式的安全官员
§164.308(a)(3) 员工安全管理——授权/监督、离职流程
§164.308(a)(4) 信息访问管理——访问授权、权限修改
§164.308(a)(5) 安全意识与培训——包括安全提醒、恶意软件防护、登录监控、密码管理
§164.308(a)(6) 安全事件处理流程——参见
```
incident-triage
```
§164.308(a)(7) 应急计划——备份、灾难恢复、紧急模式运行、测试
§164.308(a)(8) 评估——定期开展技术与非技术评估
§164.308(b)(1) 业务关联方合同——与每个BA签订BAA

工程审计输入： 风险分析的证据包（资产清单、威胁模型、管控措施列表）、员工安全记录（访问审查、入职/调岗/离职证据）、培训完成记录。

Physical safeguards (data center / facility)

物理保障措施（数据中心/设施）

For modern SaaS, most physical safeguards are inherited from the cloud provider's compliance posture (covered by the cloud's BAA). Verify:

§164.310(a) Facility Access Controls — for any office space where ePHI is processed
§164.310(b) Workstation Use — policies for workstations that access ePHI
§164.310(c) Workstation Security — physical security of those workstations
§164.310(d) Device and Media Controls — disposal, media re-use, accountability, data backup and storage

Engineering audit input: confirm cloud provider's BAA covers the relevant physical-safeguard obligations; confirm workstation disk encryption and remote-wipe for any employee laptop touching ePHI.

对于现代SaaS而言，大多数物理保障措施继承自云服务商的合规体系（由云服务商的BAA覆盖）。需验证：

§164.310(a) 设施访问控制——针对任何处理ePHI的办公场所
§164.310(b) 工作站使用规范——访问ePHI的工作站使用政策
§164.310(c) 工作站安全——这些工作站的物理安全措施
§164.310(d) 设备与介质管控——处置、介质复用、问责、数据备份与存储

工程审计输入： 确认云服务商的BAA涵盖相关物理保障义务；确认所有接触ePHI的员工笔记本电脑已启用磁盘加密和远程擦除功能。

Technical safeguards (where engineering audits)

技术保障措施（工程审计核心领域）

This is where this skill spends its time.

本技能的重点内容在此部分。

§164.312(a) Access Control

§164.312(a) 访问控制

Unique user identification — required. Every individual accessing ePHI has a unique ID. No shared accounts
Emergency access procedure — break-glass path for emergency PHI access, logged
Automatic logoff — addressable; idle session termination
Encryption and decryption — addressable; encrypt ePHI at rest (in practice, treat as required; OCR enforcement strongly suggests this)

Audit grep patterns:

Shared service-account access to PHI tables:
```
SELECT.*patient
```
,
```
SELECT.*encounter
```
from non-individual accounts
Lack of session timeout: search for session config without explicit timeout
Unencrypted ePHI at rest: confirm DB-level + bucket-level encryption per data store

唯一用户标识——强制要求。每个访问ePHI的个体都拥有唯一ID，禁止共享账户
紧急访问流程——设置紧急访问PHI的应急路径，并记录日志
自动登出——可选要求；闲置会话需终止
加密与解密——可选要求；对静态ePHI进行加密（实际操作中需视为强制要求；OCR的执法实践强烈建议执行此措施）

审计检索模式：

共享服务账户访问PHI表：从非个人账户执行
```
SELECT.*patient
```
、
```
SELECT.*encounter
```
等操作
缺少会话超时设置：搜索未明确设置超时的会话配置
静态ePHI未加密：确认每个数据存储的数据库级和存储桶级加密情况

§164.312(b) Audit Controls

§164.312(b) 审计控制

Hardware, software, and procedural mechanisms that record and examine activity in systems containing ePHI

In practice: every read, every write, every access decision involving ePHI logged. Logs preserved for at least 6 years (HIPAA's general document-retention period). See

siem-detection

for the engineering implementation.

记录和检查含ePHI系统活动的硬件、软件及流程机制

实际操作中：所有涉及ePHI的读取、写入、访问决策均需记录日志。日志需保留至少6年（HIPAA的通用文档保留期限）。工程实现参见

siem-detection

。

§164.312(c) Integrity

§164.312(c) 完整性

Mechanisms to authenticate ePHI — verify ePHI has not been altered or destroyed in unauthorized manner
Addressable in practice — hash / signature controls on critical ePHI records, immutable log storage

验证ePHI的机制——确认ePHI未被未经授权地篡改或销毁
实际操作中为可选要求——对关键ePHI记录实施哈希/签名管控，采用不可变日志存储

§164.312(d) Person or Entity Authentication

§164.312(d) 个人或实体身份认证

Verify identity of person or entity accessing ePHI
MFA is not explicitly required by Security Rule text — but post-2013 enforcement and HHS guidance strongly recommend MFA for any remote access to ePHI; treat as effectively required. New HHS guidance (2024+) is moving MFA toward explicit requirement

See

iam-audit

for implementation.

验证访问ePHI的个人或实体身份
安全规则文本未明确要求多因素认证（MFA）——但2013年后的执法实践及HHS指南强烈建议对任何远程访问ePHI的场景使用MFA；需视为实际强制要求。2024年后的新HHS指南正推动将MFA列为明确要求

实现细节参见

iam-audit

。

§164.312(e) Transmission Security

§164.312(e) 传输安全

Integrity controls — addressable; protect ePHI in transit from improper modification
Encryption — addressable in text but treat as required; TLS 1.2+ for any ePHI traversing networks

See

crypto-audit

完整性控制——可选要求；保护传输中的ePHI不被非法修改
加密——文本中为可选要求，但需视为强制要求；任何传输ePHI的网络需使用TLS 1.2+协议

实现细节参见

crypto-audit

。

Privacy Rule — what can be done with PHI

隐私规则——PHI的使用规范

The Privacy Rule sets the rules for how PHI is used and disclosed. The Security Rule says "protect it"; the Privacy Rule says "you can only use it for these specific purposes."

Engineering-relevant slices:

Minimum Necessary Standard — when using or disclosing PHI for purposes other than treatment, use or disclose only the minimum necessary. The engineering implementation: role-based access, query-level scoping (don't
```
SELECT *
```
from patient tables), API contracts that return only the fields the caller needs
TPO exception — Treatment, Payment, and Healthcare Operations do not require authorization. Most other uses do
Individual rights — right to access (similar to GDPR DSAR — 30-day delivery), right to amend, accounting of disclosures
Notice of Privacy Practices — published, presented at first interaction

Audit grep patterns:

Over-broad PHI queries:
```
SELECT \*.*patient
```
,
```
SELECT \*.*encounter
```
,
```
SELECT \*.*observation
```
— almost always a minimum-necessary violation
API endpoints returning full patient records when callers only need specific fields
Analytics platforms / monitoring tools receiving PHI without a TPO basis

隐私规则规定了PHI的使用和披露规则。安全规则要求“保护PHI”；隐私规则则明确“仅可用于这些特定目的”。

与工程相关的要点：

最小必要标准——当出于治疗以外的目的使用或披露PHI时，仅使用或披露必要的最小范围。工程实现：基于角色的访问控制、查询级范围限定（不要从患者表中执行
```
SELECT *
```
）、API契约仅返回调用方所需字段
TPO例外——治疗（Treatment）、支付（Payment）、医疗运营（Healthcare Operations）无需授权。大多数其他用途均需授权
个人权利——访问权（类似GDPR的DSAR——需在30天内交付）、修改权、披露记录查询权
隐私实践通知——需发布，并在首次互动时向用户展示

审计检索模式：

过度宽泛的PHI查询：
```
SELECT \*.*patient
```
、
```
SELECT \*.*encounter
```
、
```
SELECT \*.*observation
```
——几乎均违反最小必要标准
API端点返回完整患者记录，而调用方仅需特定字段
分析平台/监控工具在无TPO依据的情况下接收PHI

Breach Notification Rule

违规通知规则

A breach is the unauthorized acquisition, access, use, or disclosure of unsecured PHI that compromises the security or privacy of the PHI. "Unsecured" = not encrypted per HHS guidance (encryption is the safe harbor).

Notification timing:

Recipient	Timing
Affected individuals	Without unreasonable delay, no later than 60 calendar days after discovery
Department of Health and Human Services (HHS / OCR)	Within 60 days of discovery for breaches affecting ≥ 500 individuals; annually for breaches < 500
Media	Same 60-day window for breaches affecting > 500 in a state or jurisdiction
Business associate to covered entity	Without unreasonable delay, no later than 60 days

A "breach" includes the unauthorized access — not just exfiltration. If a workforce member views a record they had no need to view, that is a breach (unless one of the limited exceptions applies).

Engineering hook: ability to scope a breach quickly. Audit logs (Security Rule §164.312(b)) are the source of truth. Time-to-scope directly impacts the 60-day clock.

Safe harbor: if the PHI was encrypted per HHS-recognized standards (and the key wasn't also compromised), the unauthorized acquisition may not be a breach. This is the strongest reason to encrypt ePHI at rest comprehensively.

See

incident-triage

(response),

security-comms

(notification draft — legal review required),

breach-patterns

(post-incident pattern extraction).

违规指未经授权获取、访问、使用或披露未受保护的PHI，且此类行为损害了PHI的安全性或隐私性。“未受保护”指未按照HHS指南进行加密（加密是安全港豁免条件）。

通知时限：

接收方	时限
受影响个人	无不合理延迟，最晚不超过发现违规后的60个日历日
卫生与公众服务部（HHS / OCR）	若违规影响≥500人，需在发现后60天内上报；影响<500人的违规需按年度上报
媒体	若违规在某州或司法管辖区影响>500人，需在同一60天窗口期内通知
业务关联方向覆盖实体	无不合理延迟，最晚不超过60个日历日

“违规”包括未经授权的访问——不仅指数据泄露。若员工查看了其无需查看的记录，即构成违规（除非符合有限的例外情况）。

工程关联点： 能够快速界定违规范围。安全规则§164.312(b)规定的审计日志是事实依据。范围界定的时间直接影响60天的上报时限。

安全港豁免： 若PHI已按照HHS认可的标准加密（且密钥未同时泄露），则未经授权的获取可能不被视为违规。这是全面加密静态ePHI的最有力理由。

HITECH layer

HITECH补充层

HITECH (2009) strengthened HIPAA in several ways relevant here:

Made BAs directly liable for many Security Rule violations (was previously CE-only)
Increased civil monetary penalties (tiered up to $1.5M per provision per year)
Made the Breach Notification Rule federal (replacing some state-level patchwork)
Strengthened the right of patients to obtain electronic copies of their PHI

For modern engineering work, HITECH means: a BA that handles ePHI is subject to most of the Security Rule directly. Vendors cannot hide behind the CE.

HITECH（2009年）从多个方面强化了HIPAA，相关要点如下：

使BA直接对多项安全规则违规负责（此前仅CE需负责）
提高民事罚款金额（分级最高可达每项条款每年150万美元）
将违规通知规则定为联邦规则（取代部分州级零散规定）
强化患者获取其PHI电子副本的权利

对于现代工程工作而言，HITECH意味着：处理ePHI的BA需直接遵守安全规则的大部分要求。供应商无法躲在CE背后逃避责任。

Audit checklist

审计清单

markdown

undefined

markdown

undefined

HIPAA Audit Findings

HIPAA审计发现

Entity: [name]

实体：[名称]

Entity type: Covered Entity / Business Associate / Subcontractor

实体类型：覆盖实体 / 业务关联方 / 分包商

Date: [date]

日期：[日期]

Auditor: [name]

审计员：[名称]

Scope

范围

Administrative safeguards

管理保障措施

Subsection	Status	Findings
Security Management Process
Assigned Security Responsibility
Workforce Security
Information Access Management
Security Awareness and Training
Security Incident Procedures
Contingency Plan
Evaluation
BA Contracts

小节	状态	发现
安全管理流程
指定安全负责人
员工安全管理
信息访问管理
安全意识与培训
安全事件处理流程
应急计划
评估
BA合同

Technical safeguards

技术保障措施

Subsection	Status	Findings
Access Control — unique IDs
Access Control — emergency access
Access Control — automatic logoff
Access Control — encryption at rest
Audit Controls
Integrity
Person / Entity Authentication (MFA)
Transmission Security (encryption in transit)

小节	状态	发现
访问控制——唯一ID
访问控制——紧急访问
访问控制——自动登出
访问控制——静态加密
审计控制
完整性
个人/实体身份认证（MFA）
传输安全（传输加密）

Privacy Rule

隐私规则

Minimum necessary applied in code (no SELECT * on PHI tables)
Notice of Privacy Practices published and presented
Individual access path implemented (30-day delivery)
Amendment / accounting of disclosures process exists

代码中已应用最小必要标准（无PHI表的SELECT *操作）
隐私实践通知已发布并展示
个人访问路径已实现（30天内交付）
修改/披露记录查询流程已存在

Breach response readiness

违规响应准备

Audit logs sufficient to scope a breach within 60-day clock
Incident-response procedures tested
Notification templates drafted (see security-comms)
Encryption-as-safe-harbor verified across ePHI stores

审计日志足以在60天时限内界定违规范围
事件响应流程已测试
通知模板已起草（参见security-comms）
已验证所有ePHI存储的加密安全港豁免条件

Findings detail

发现详情

[Per finding: section reference, severity, location, evidence, remediation]

[每条发现：章节参考、严重程度、位置、证据、整改措施]

Recommendations

建议

[Prioritized]


Disposition rule (Fixed / Deferred / Accepted Risk) per `owasp-audit`. HIPAA accepted-risk is highly disfavored — most "accepted risks" should be documented as residual risk with compensating controls and re-evaluation triggers.

[按优先级排序]


处置规则（已修复/延期/接受风险）参考`owasp-audit`。HIPAA不鼓励接受风险——大多数“接受风险”应记录为残余风险，并附带补偿控制措施和重新评估触发条件。

Common audit findings (real-world starting hypotheses)

常见审计发现（实际场景初始假设）

PHI in non-BAA vendor pipelines — Sentry, Datadog, Mixpanel, Segment, Slack receiving PHI without a BAA (Sentry has a BAA path; Datadog has a healthcare offering; Mixpanel does not by default — verify each vendor's BAA stance)
Unique-user-ID violation via shared service accounts — engineering team uses a shared admin account for ad-hoc PHI access
SELECT *
on PHI tables — minimum-necessary violation; API serializers returning all fields when callers need few
DOB stored when only age range needed — minimization gap
Backups encrypted but with key co-located — safe harbor depends on key separation
Lower environments seeded from production — staging DB contains real PHI from a prod dump
MFA not enforced for all ePHI access paths — pre-2024 environments may have gaps; trend is toward universal MFA requirement
Audit log retention < 6 years — HIPAA's 6-year retention applies to documentation required by the rules, including audit logs that evidence compliance
No automatic logoff on ePHI-accessing workstations / clinical applications
BA chain breaks — vendor's subcontractor handles ePHI but the BA never put their own BAA in place with the subcontractor

PHI流入未签署BAA的供应商管道——Sentry、Datadog、Mixpanel、Segment、Slack在未签订BAA的情况下接收PHI（Sentry提供BAA签署路径；Datadog有医疗健康领域产品；Mixpanel默认不提供——需验证每个供应商的BAA政策）
共享服务账户违反唯一用户ID要求——工程团队使用共享管理员账户临时访问PHI
PHI表执行
SELECT *
操作——违反最小必要标准；API序列化器返回所有字段，而调用方仅需少数字段
存储出生日期，但仅需年龄范围——数据最小化存在漏洞
备份已加密，但密钥与数据共存——安全港豁免依赖密钥分离
测试环境从生产环境导入数据—— staging数据库包含来自生产环境的真实PHI
未对所有ePHI访问路径强制实施MFA——2024年前的环境可能存在漏洞；趋势是要求全面实施MFA
审计日志保留期限<6年——HIPAA要求规则所需文档保留6年，包括证明合规的审计日志
访问ePHI的工作站/临床应用未设置自动登出
BA责任链断裂——供应商的分包商处理ePHI，但BA未与该分包商签订BAA

Boundaries

边界说明

This skill is the engineering audit and preparation. Privacy Officer / counsel make final determinations on covered-entity status, BA relationships, and notification decisions
Refuse to help build flows that violate HIPAA — PHI to non-BAA vendors, shared-account access to PHI, transmission of PHI via end-user messaging tech (consumer email, SMS, chat) outside narrow authorization, marketing uses of PHI without authorization
For breaches: this skill scopes the breach and produces engineering inputs to the notification; the notification itself goes through
```
security-comms
```
and counsel
HIPAA enforcement (OCR) has expanded since 2013; regulatory interpretation continues to evolve. Where this skill's content lags current OCR guidance, current OCR guidance prevails
State laws may impose stricter requirements (e.g., Texas HB 300, California CMIA) — preempted only where state law is less protective; otherwise state requirements apply on top
Genetic information has additional protections under GINA — out of scope here, refer to specialized guidance

本技能仅提供工程审计和准备支持。覆盖实体身份、BA关系及通知决策的最终判定由隐私官/法律顾问负责
拒绝协助构建违反HIPAA的流程——例如向未签署BAA的供应商传输PHI、共享账户访问PHI、在未获明确授权的情况下通过终端用户通讯技术（消费者邮箱、短信、聊天工具）传输PHI、未经授权将PHI用于营销等
对于违规事件：本技能负责界定违规范围并为通知提供工程输入；通知本身需通过
```
security-comms
```
和法律顾问审核
自2013年起，HIPAA的执法（OCR）范围不断扩大；监管解释持续演变。若本技能内容滞后于当前OCR指南，以当前OCR指南为准
州级法律可能施加更严格的要求（如得克萨斯州HB 300、加州CMIA）——仅当州级法律保护性较弱时才会被 preempt；否则州级要求需叠加执行
遗传信息受GINA额外保护——不在本技能范围内，请参考专门指南

References

参考资料

HHS HIPAA Rules —
```
hhs.gov/hipaa
```
(regulatory text, FAQs, OCR resolution agreements)
HHS / OCR Audit Protocol — used by OCR auditors; useful checklist for self-assessment
HHS Security Risk Assessment Tool — free tool for small/medium providers
NIST SP 800-66 Rev. 2 (2024) — "Implementing the HIPAA Security Rule: A Cybersecurity Resource Guide" — the most current technical guidance
HITRUST CSF — common controls framework that maps to HIPAA Security Rule; many BAs pursue HITRUST certification as compliance evidence
OCR Resolution Agreements — published enforcement actions; useful precedent for what OCR considers material
HHS Wall of Shame — public breach portal; useful for industry-pattern context
45 CFR Parts 160 and 164 — the regulatory text itself
OCR Cybersecurity Newsletter — quarterly guidance updates
"HIPAA Plain & Simple" — Carolyn P. Hartley — practitioner reference

HHS HIPAA规则——
```
hhs.gov/hipaa
```
（法规文本、常见问题、OCR和解协议）
HHS / OCR审计协议——OCR审计员使用的协议；可作为自我评估的实用清单
HHS安全风险评估工具——面向中小型医疗服务提供者的免费工具
NIST SP 800-66 Rev. 2（2024）——《实施HIPAA安全规则：网络安全资源指南》——最新的技术指南
HITRUST CSF——映射到HIPAA安全规则的通用控制框架；许多BA通过获取HITRUST认证作为合规证据
OCR和解协议——已公开的执法行动；可作为OCR认定重大违规的参考先例
HHS违规公示墙——公开的违规门户；可用于了解行业违规模式
45 CFR Parts 160 and 164——法规原文
OCR网络安全通讯——季度指南更新
《HIPAA简明指南》——Carolyn P. Hartley——从业者参考书籍