Hawaii Family Dental: Hacking Incident Reported Affecting 45,853 Patients

What the source establishes

Hawaii Dental Group, Inc DBA Hawaii Family Dental reported this incident to HHS OCR on 2026-09-11. The filing classifies the incident mechanism as a hacking incident and reports 45,853 individuals affected. Those two facts are what the record supports directly: a hacking classification, at a scale of 45,853, indicates the compromised asset was a digital system capable of housing a consolidated patient population — not an isolated paper record or single workstation. The filing does not state what technical vector was used to gain access, and no conclusion is drawn here about phishing, credential compromise, or unpatched software.

What HIPAA requires here

When a hacking incident of this scale is possible, the Security Rule's core administrative and technical requirements are what stand between an intrusion and a reportable breach. §164.308(a)(1)(ii)(A) requires an accurate, thorough risk assessment covering everywhere ePHI lives. §164.308(a)(1)(ii)(B) requires that identified risks actually be reduced. §164.312(a)(1) and §164.312(a)(2)(i) require that access to ePHI be limited to authorized persons and that each user be individually identifiable, so activity can be attributed rather than shared. §164.312(d) requires verifying that a person seeking access is who they claim. §164.308(a)(1)(ii)(D) and §164.312(b) require that system activity be logged and that those logs actually be reviewed. §164.404 and §164.408 govern notifying affected individuals and the Secretary once a breach is discovered.

Patient Protect mapping

Patient Protect scores a guided risk assessment and retains the documentation under §164.308(a)(1)(ii)(A), but an unanswered assessment discharges nothing, and it only reaches what the practice has entered. It controls access and issues unique identities inside its own environment under §164.312(a)(1) and §164.312(a)(2)(i), but it has no reach into the practice's other systems — including whatever system holds the full patient database if that system is not Patient Protect itself. It verifies identity into its own platform via MFA under §164.312(d), and records activity in its own system under §164.312(b), but neither claim extends to authentication or audit coverage elsewhere. It provides the incident documentation workflow under §164.308(a)(6)(ii) and §164.404/§164.408, but does not perform identification or response outside itself, and does not itself make any required notification.

Controls worth reviewing

A principal can check, today, which internet-facing system currently holds the practice's full patient database in one accessible location — practice management software, imaging server, a cloud portal — and list every account with direct login or remote access to it. Confirm whether each of those accounts has its own unique credential (§164.312(a)(2)(i)) or whether a shared login is in use. Confirm whether multi-factor authentication is enabled on that system specifically, not only on ancillary tools (§164.312(d)). Pull the access log for that system and confirm someone is actually reviewing it, not just generating it (§164.308(a)(1)(ii)(D)). Confirm any former employee's access to that system was actually revoked, not merely disabled in one tool among several (§164.308(a)(3)(ii)(C)).