Clustered 2 filings across 1 jurisdiction · filing window Sep 20, 2016 → Sep 21, 2016. View entity profile → Other incidents for this victim →
incident inc_9fd3242b1f8441de · merge_method deterministic · confidence 100%
Discovered → first regulatory filing
Time between earliest and latest filing
Not recorded for this incident
Discovery variance · Leak precedence · Materiality delta · SEC filing delay — no leak-site claim in this cluster; no SEC 8-K in this cluster; needs two dated filings.
Health (basic) · Identity (basic) · Government ID
CA
HHS OCR · State AG
Earliest sighting first · deep chronology in Litigation Timeline
Aug 1, 2016
When the intrusion reportedly occurred, per the linked filings
Aug 1, 2016
Reported by HHS OCR filing
USC Keck and Norris Hospitals reported a data breach to the California Attorney General. The breach occurred on August 1, 2016. The attached consumer notification letter was empty, so specific details regarding the nature of the breach, data types affected, and number of individuals impacted are not available in the provided source text.
USC Keck and Norris Hospitals (CA) reported to HHS on 2016-09-21 a Hacking/IT Incident (ransomware) affecting 16,000 individuals. On August 1, 2016, ransomware encrypted files on two network servers storing ePHI including names, demographic information, dates of birth, treatment information, diagnoses, and in some cases Social Security numbers. The CE shut down impacted servers, restored data from backups without paying ransom, and implemented additional malware prevention measures. OCR investigated and obtained assurances of corrective action.
Affected (this filing): 16,000
About this clustering
DisclosureLens links filings into incidents through layered matchers: deterministic rules (same source document, multistate filings of one breach, tight-window same-victim pairs), a weighted-similarity scorer for cross-source candidates, and an operator review queue for everything uncertain. Each link records its own method and confidence — shown per filing in the timeline below. The system defaults to NOT merging when uncertain, because a false merge (collapsing two unrelated breaches) is more harmful than a false split (showing related filings separately); uncertain pairs route to human review instead of auto-merging. Filing summaries shown in the timeline are AI-generated extracts — verify each against its linked source.