HIPAA Breach Notification Rule HIPAA-Breach

As a business associate, HDS is squarely within Subpart D's reach. The practical effect of this row is to set the boundary that the encryption and risk-assessment rows below refine: what counts as unsecured PHI in an HDS deployment is governed by the transit/at-rest posture described under 164.402(2), which today leaves at-rest ePHI inside the unsecured category.

The two limbs of §164.402 are refined in the dedicated rows below: 164.402(1) covers the four-factor risk assessment, for which the audit log and access-version chain are the structured inputs, and 164.402(2) covers the unsecured-PHI safe harbor, where HDS is honest that at-rest content encryption is not yet shipped. The definitional analysis itself — deciding whether a given event meets the breach definition — remains the implementer's, supported by HDS evidence.

Factor mapping: (i) nature and extent of PHI — audit records identify the API methods and the streams/event types touched; (ii) unauthorized person — each audit record carries the access identity behind the call; (iii) acquired vs. merely viewed — the method-level distinction (read vs. attachment download, success vs. denied) is recorded; (iv) mitigation extent — the access-version history shows revocation and scope-down timestamps relative to the incident. The analytical write-up that weighs these factors and reaches the low-probability conclusion is the implementer's artefact; HDS supplies and preserves the inputs.

This is an honest-gap row. In-transit protection (TLS) aligns with the FIPS-validated standards referenced by HHS guidance, so leaked data in flight is generally outside the unsecured-PHI definition. At rest, HDS does not yet provide NIST SP 800-111-equivalent content encryption for ePHI; until that ships, at-rest ePHI remains unsecured PHI for the purposes of this rule and any compromise must be assessed as a potential breach. The gap, its compensating controls and the remediation plan are tracked in the cited internal record.

HDS is not a bulk-notification system. The contribution is identification: filtering the audit log by the implicated credential and time window yields the distinct set of affected subjects, with evidence. Producing the roster and the per-recipient delivery sit with the covered entity, who carries this duty.

Discovery and scoping are typically the slowest steps before notices can be drafted. By making the access history queryable, HDS compresses scoping so that meeting the 60-day deadline becomes a matter of process discipline. Acting on the evidence within the window — and recording when discovery occurred — remains the implementer's responsibility.

The "types of PHI involved" element can be derived from the streams and event types touched, as recorded in the audit data used under 164.402(1). The dates-of-breach-and-discovery, the steps individuals should take, the entity's response, and the contact procedures are not data HDS holds; they are composed by the covered entity. HDS therefore facilitates the evidence-derivable element and documents the rest.

First-class mail, email, telephone, and substitute notice are all organizational channels the covered entity operates with its own communications stack. HDS neither selects nor sends. Its only adjacent contribution is preserving an audit record if the implementer chooses to log delivery attempts as events.

Determining whether the 500-resident threshold is met for a given State or jurisdiction draws on the per-subject roster that HDS audit evidence helps assemble. Identifying and notifying prominent media outlets is entirely the covered entity's process.

For breaches of 500 or more individuals the notice is contemporaneous with individual notification; smaller breaches are logged and submitted annually. In both cases the factual inputs can be drawn from HDS evidence, while the act of submitting and tracking the report sits with the covered entity.

HDS maintains an internal breach-notification procedure that defines discovery, escalation, content assembly and the upstream notification to affected covered entities, with the 60-day ceiling. The per-user audit log is the data source for the "identities of affected individuals" element and for the timing evidence backing "without unreasonable delay". When an implementer is itself a business associate to a covered entity and stores PHI on HDS, the same procedure and evidence support its own upstream notification chain.

Whether the statement is oral (subject to a 30-day cap) or written (bounded by the official's stated period), the implementer must record it and pause the affected notifications accordingly. HDS retention keeps the underlying evidence intact for the duration so notification can proceed once the delay lapses.

The audit and access history give an implementer the factual spine for the §164.414 demonstration: it can show the scope of any incident and the basis for a no-breach conclusion. The organizational records that sit on top of that data — incident-response files, notification records, and the documented rationale for any decision not to notify — are the implementer's to maintain. HDS also retains its own breach-procedure execution records as evidence of its §164.410 performance.