[BreachExchange] Bar to Data Breach Litigation May Be Dropping; Implications for Digital Health Technologies

[Audrey McNeil]

https://www.natlawreview.com/article/bar-to-data-breach-
litigation-may-be-dropping-implications-digital-health

At the beginning of August, the D.C. Circuit found that the fact that a
data breach has occurred and individual consumer information has been lost
may constitute sufficient injury to confer standing on those individual
victims at the pleading stage–irrespective of whether any stolen
information has been misused. Specifically, Attias, et al. v. CareFirst,
Inc., et al., No. 16-7108, 2017 WL 3254941 (D.C. Cir. Aug. 1, 2017) ruled
that a class of health insurance policyholders could maintain their suit
against CareFirst, due to a cyberattack on the insurance provider’s
servers. The court found that “a heightened risk of future identity theft”
was enough to confer standing. Id. at *4 n.2. The court based its decision
on the fact of the breach and the associated heightened risk rather than on
whether any of the policy holders’ identities had actually been stolen.
Relying on a prior decision by the Seventh Circuit, the court observed,
“Why else would hackers break into a . . . database and steal consumers’
private information?” Id. at *6 (quoting Remijas v. Neiman Marcus Grp., 794
F.3d 688, 693 (7th Cir. 2015)).

Despite the clarity with which the D.C. Circuit reached its decision, the
circuits have split over what exactly an individual whose data has been
stolen must show to establish standing in federal court. Article III
requires a plaintiff to demonstrate an “injury in fact” that is “fairly
traceable” to the defendant’s challenged conduct and is “likely to be
redressed by a favorable judicial decision.” Spokeo, Inc. v. Robins, 136 S.
Ct. 1540, 1540 (2016) (quoting Lujan v. Defenders of Wildlife, 504 U.S.
555, 560-61). Some circuits have ruled that the theft of data, without
more, does not constitute such an injury. See, e.g., Beck et al. v.
McDonald et al., 848 F.3d 262 (4th Cir. 2017). The CareFirst court joined a
growing list of circuits ruling to the contrary.

CareFirst also serves as an independent reminder that the theft of medical
data can have significant ramifications for victims. Armed with information
such as insurance identifiers, a fraudster may “impersonate[] the victim
and obtain medical services” in the victim’s name, leading to potentially
inaccurate medical records, improper health care, depletion of insurance,
ineligibility for health or life insurance, and disqualification from jobs.
CareFirst, 2017 WL 3254941, at *6.

Implications for Digital Health Technologies:

CareFirst also highlights the importance of managing data security risks in
designing digital health technologies, both because of the potential ease
with which a prospective plaintiff may have standing to bring suit and
because of the sensitive nature of medical information.  Digital health
companies should take steps to manage this risk whether they are building
their digital solutions themselves or working with business partners and
service providers.  Very often working with business partners and service
providers is the quickest and most efficient way to market with a digital
solution, but this does mean relying on the data security practices of a
third party.  In view of this, appropriate due diligence and contractual
terms with respect to data security are essential in digital health
agreements.  In addition, the processes and procedures governing a data
security incident and any associated plaintiffs’ claims should be addressed
in the agreement.  The healthcare industry has been a particular target for
ransomware attacks, so contractual commitments with regard to back up and
restoration of end user data is important.  The promise of digital health
is partly premised on companies being methodical and careful in their
commercial contracting and business partner/service provider management.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.riskbasedsecurity.com/pipermail/breachexchange/attachments/20170828/bc10c1c8/attachment.html>