Info Law Group : Technology Lawyers & Attorneys : Information Law Group : Privacy, Security & Intellectual Property Law

Legal Framework and Basis for these Fines and Penalties

It is best to start at the beginning and take a quick look at the legal framework for the fines and penalties imposed on the hospitals. In this case it was a potent combination of California laws involving:

(1) a breach notice law that requiring hospitals to provide notice to the CDPH of unlawful or unauthorized access to, and use or disclosure of medical information with 5 days after detection;

(2) a duty to prevent unlawful or unauthorized access to, and use or disclosure of medical information; and

(3) an obligation to establish and implement appropriate administrative, technical, and physical safeguards to protect the privacy of a patient’s medical information and reasonably safeguard confidential medical information from any unauthorized access or unlawful access, use, or disclosure; and

(4) potential fines of $25,000 per patient ($17,500 per subsequent breach per patient) capped at $250,000 per event.

These legal requirements are all contained in two bills that amended California law in 2008: AB 211 and SB 541 (you can find the final amendments incorporated into the actual statutes here and here).  Also referenced by the CDPH is Title 22, Section 70707(b)(8) of California's Code of Regulations, which lists the following as a mandatory "patient right" under the law:

Confidential treatment of all communications and records pertaining to the care and the stay in the hospital. Written permission shall be obtained before the medical records can be made available to anyone not directly concerned with the care.

Legal Defensibility

To refresh, the following summarizes a legally defensible security approach:

The focus of legal defensibility is understanding how a plaintiff ’s attorney, judge, jury, or regulator will view an organization’s security posture in light of applicable legal requirements. Under a legal defensibility analysis security choices become legal positions or arguments to be used to persuade legal decision-makers that an organization’s security was legally sound, and increase the likelihood that a judge, jury, or regulator will find a company legally compliant. Ultimately, there may not be a clear “right” or “wrong” answer, but rather a more or less persuasive legal argument/position on security.

In the case of the California laws outlined in this post, hospitals should be asking themselves as they develop their security programs, how will the CDPH interpret the security obligations contained in those laws, and in the event (or the inevitability as the case may be) of a security breach, what legal arguments does the hospital have to persuade regulators to refrain from issuing a fine?

A full blown analysis of the key security-related legal issues is well beyond the scope of this blogpost. However, there are some key issues posed by these laws that would be addressed under a legal defensibility approach.

Relationship between AB 211 and SB 541.

The obligations set forth in AB 211 and SB 541 appear to overlap and impact the development of an information security program. The relevant amendment set forth in SB 541 reads as follows:

1280.15. (a) A clinic, health facility, home health agency, or hospice licensed pursuant to Section 1204, 1250, 1725, or 1745 shall prevent unlawful or unauthorized access to, and use or disclosure of, patients’ medical information, as defined in subdivision (g) of Section 56.05 of the Civil Code and consistent with Section 130203.

(emphasis supplied).  Section 130203 was actually added by AB 211, and provides in relevant part:

Every provider of health care shall establish and implement appropriate administrative, technical, and physical safeguards to protect the privacy of a patient’s medical information. Every provider of health care shall reasonably safeguard confidential medical information from any unauthorized access or unlawful access, use, or disclosure.

One reading of SB 541 is that no violation would exist due to a failure to prevent unauthorized access as long as the hospital could establish that it had “appropriate administrative, technical and physical safeguards” and reasonably safeguarded medical information (see AB 211). Another might read this part of SB 541 as creating regulatory liability if a hospital fails to prevent unauthorized access to medical records regardless of the hospital's security stance.  Listening to the press conference put on by the CDPH it is not clear whether (or to what extent) they took the hospitals' security into account (and the CDPH indicated that it had not issued any "best practices" in this regard).  

From a legal defensibility standpoint, legal analysis should be performed to determine arguments for and against each position.  This analysis might look deeper into the legislative history behind these laws as wells as prior decisions and documents issued by the CDPH (e.g. the survey findings reports issued by the CDPH).  That legal analysis will help to inform the hospital’s security team as to what actions to take and where to focus its efforts.

Appropriate Controls

Assuming that establishing and implementing appropriate/reasonable safeguards would provide a hospital with the means to escape regulatory fines, a legal defensibility approach would require research and analysis as to the meaning of “appropriate” and “reasonable” in this context. This meaning might be derived from legislative history, case law, other statutes using analogous language or decisions or documents issued by the CDPH concerning security measures (or the lack thereof).

Hospitals lawyers that perform this analysis while they are building their security program can help to guide their security teams to address crucial areas and reduce liability.  Would compliance with particular standards improve their legal position? Would a evidence of a comprehensive security risk assessment persuade regulators that the hospital had done the right thing despite the breach? What security measures has the CDPH stressed or scrutinized in prior investigations? Employing a legal defensibility strategy would allow the hospitals to have established legal positions concerning their security in order persuade regulators not to impose fines and penalties 

Risk Factors to Mitigate Potential for Fines

Both SB 541 and AB 211 set forth specific factors that regulators may take into account when deciding whether a security breach involving medical information is worthy of a fine and how much the fine should be. For instance, SB 541 provides:

For purposes of the investigation, the department shall consider the clinic’s, health facility’s, agency’s, or hospice’s history of compliance with this section and other related state and federal statutes and regulations, the extent to which the facility detected violations and took preventative action to immediately correct and prevent past violations from recurring, and factors outside its control that restricted the facility’s ability to comply with this section. The department shall have full discretion to consider all factors when determining the amount of an administrative penalty pursuant to this section.

Again, the key issue here is when developing the information security program, in light of these factors, what security should be implemented to reduce legal risk. More to the point, based on these factors, what arguments exist for the hospital to claim that they should not be fined. For example, based on references to detection, prevention and “immediate correct[ion],” a hospital that established a security program with strong intrusion detection and prevention controls might persuade regulators to refrain from imposing fines. Moreover, if the security program’s incident response procedures stressed rapid correction of breaches, and such correction took place, this fact may mitigate against the imposition of fees.

There are many other legal issues presented by this language that could impact how a security program is implemented so that it is legally defensible. For example, which of these factors do the legislators or regulators weigh more heavily (or are they all treated the same)? Is there any evidence (perhaps past regulatory actions and documents related thereto) that indicate other factors regulators may take into account when deciding whether to impose fees (at the CDPH press conference the spokesperson indicated that it had taken the "rural" nature of two hospitals into account in assessing penalties). Answering these questions requires careful legal analysis and coordination between a hospital's legal and security teams.

Preferably all of these legal defense considerations are proactively baked into a security program when it is built (instead of having to construct arguments reactively in the wake of a security breach). Preferably these legal positions are documented and preserved for use in case something goes wrong (instead of having to create them ad hoc in the heat of a breach situation).  Having established positions is even more important for these California laws since hospitals only have five days before they are required to provide notice to the CDPH.  Five days is likely not enough time to conduct a full investigation and analysis, and construct complex legal arguments.

Conclusion

It remains to be seen whether these fines are a one-time warning shot for deterrence purposes, or  potentially the beginning of significant series of fines for California healthcare entiteis that have reported more than 3,400 patient confidentiality breaches since January 1, 2009.  Either way these fines highlight the need for a legal defensibility approach when developing an information security program.

This is the reality in California for hospitals: you will need to report breaches to the CDPH within five days of detection, the CDPH has the potential to impose stiff fines if they believe you have violated various laws, and the hospital with have to establish that despite the breach it was doing the right thing and should not be fined. Hospitals that have not considered how to build security programs that provide solid legal arguments in favor of compliance with these laws may find themselves unable to dissuade regulators from imposing fines. They will be in a defensive and reactive posture under extreme time pressure instead of a proactive and prepared posture.  Considering security and patient confidentiality for a legal defensibility standpoint may help to mitigate some of this risk.

State Security and Breach Notification Laws

Since California adopted SB 1386, which went into effect in 2003, nearly all US states have enacted security breach notice laws that require notice to affected individuals, and in some cases to public authorities, when a party has reason to believe that the security of protected categories of personal data has been compromised. The protected categories are typically SSN (Social Security Number), driver’s license, financial account or payment card details (usually only if the password or access code is also compromised), and, increasingly, medical data not covered by federal HIPAA privacy protections.

All of these laws make an exemption from the notice obligation if the data were encrypted (some add that this is true only if there is no reason to believe that the decryption key was also compromised). The laws, and regulations adopted under the laws, typically do not specify the level or kind of encryption. For example, California’s Office of Privacy Protection published guidance specifically on the subject of “Recommended Practices on Protecting the Confidentiality of Social Security Numbers” in April 2007, which has only this to say about encryption, on page 11:
“Protect records containing SSNs, including back-ups, during storage by encrypting the numbers in electronic records or storing records in other media in locked cabinets.”

Partly as a consequence of these security and breach notice laws, organizations should limit their use and storage of these categories of personal data to the extent they are really necessary for business operations. Storage on servers or on archived media, and transmission over internal networks and VPN connections, may or may not be sufficiently secure without encryption, depending on the company’s risk assessment and IT security practices. Organizations should encrypt such data when it is resident on laptops or other portable devices and when it is in transit over the public Internet.

Massachusetts and Nevada have recently adopted stricter and more specific rules, however, that may become a model for other states. These increase the regulatory pressure for encrypting protected categories of personal data.

Massachusetts

The Massachusetts Personal Information Security Regulation (201 CMR 17.00) is now scheduled to take effect on March 1, 2010. The Regulation was promulgated by the Office of Consumer Affairs and Business Regulation (OCABR) under the authority of the Massachusetts personal information security law.

The Regulation will require all parties that “own or license” any of the protected categories of personal data concerning Massachusetts residents to encrypt the data in laptops or other portable devices, as well as in wireless transmissions and in transmission over public networks.

Note that the Regulation does not limit its coverage of financial account data to cases where the access code or PIN is compromised, as do most security and breach notice laws. The Regulation extends to any nonpublic financial account or payment card data, as well as to SSNs and driver’s license numbers. The Regulation does not cover medical information, however.

The Regulation mandates a number of “Computer System Security Requirements” (201 CMR sec. 17.04) for businesses that handle the protected categories of personal data. These expressly include the following:

“(3) Encryption of all transmitted records and files containing personal information that will travel across public networks, and encryption of all data containing personal information to be transmitted wirelessly . . .

(5) Encryption of all personal information stored on laptops or other portable devices . . .”

The level and type of encryption are not specified.

Nevada

Nevada recently amended its personal information security law, which already required “reasonable” security measures as well as breach notice (Nevada Rev. Stats. secs. 603A.010 et seq.). The amendments take effect on January 1, 2010.

The law covers SSNs, driver’s license numbers, and payment card or financial account data in combination with an access code or PIN. Medical information is not covered.

Under the amended law, businesses that accept payment cards (credit cards and debit cards) must comply with the Payment Card Industry Digital Security Standard (PCI DSS). In addition, a party handling any of the protected categories of information must encrypt the data if it transfers the data electronically “outside of the secure system of the data collector” or if the data is stored on a device (laptop, USB drive, etc.) that is moved “beyond the logical or physical controls of the data collector or its data storage contractor.”

“Encryption” is defined in the amendments with reference to “established standards,” specifically including FIPS and mentioning the need for standards-based key management as well as encryption protocols:

‘Encryption’ means the protection of data in electronic or optical form, in storage or in transit, using:

(1) An encryption technology that has been adopted by an established standards setting body, including, but not limited to, the Federal Information Processing Standards issued by the National Institute of Standards and Technology, which renders such data indecipherable in the absence of associated cryptographic keys necessary to enable decryption of such data; and

(2) Appropriate management and safeguards of cryptographic keys to protect the integrity of the encryption using guidelines promulgated by an established standards setting body, including, but not limited to, the National Institute of Standards and Technology.”

Thus, while the law itself does not specify the form of encryption, it puts the burden on the user to choose an appropriate and standards-based method.

HITECH

Title XIII of ARRA, the federal economic recovery legislation adopted early in 2009, is labeled the Health Information Technology for Economic and Clinical Health Act (HITECH). It amends the HIPAA medical privacy provisions by adding a federal security breach notice requirement for nonpublic, personally identifiable health information. While HIPAA applies only to certain covered entities (healthcare providers and insurance companies and clearinghouses), HITECH also applies to “business associates” that provide services to those entities. HITECH reaches as well any employers that are covered by HIPAA because, for example, they operate company clinics or manage their own health plans.

HITECH requires notice to affected individuals when there has been a security breach exposing personally identifiable health data. HIPAA already lists 18 identifiers (names, addresses, SSNs, health plan ID numbers, etc.) that must be removed to establish that health records have been “de-identified.” Where compromised records have not been fully de-identified by removing these data fields, HITECH sec. 132400 also recognizes that the information may not be personally identifiable if it is effectively encrypted:

“(b) Implementation specifications: Requirements for de-identification of protected health information. A covered entity may determine that health information is not individually identifiable health information only if:

(1) A person with appropriate knowledge of and experience with generally accepted statistical and scientific principles and methods for rendering information not individually identifiable:

(i) Applying such principles and methods, determines that the risk is very small that the information could be used, alone or in combination with other reasonably available information, by an anticipated recipient to identify an individual who is a subject of the information; and (ii) Documents the methods and results of the analysis that justify such determination; . . . .”

Thus, HITECH does not specify a particular form of encryption but leaves it to IT security experts to decide whether the data are effectively unidentifiable in the hands of an unauthorized user. Note that the statute requires covered entities to maintain documentation of this professional analysis, and that the analysis must be based on “generally accepted” principles and methods – which means that professional opinions are likely to refer to published specifications and industry standards.

Red Flags

The 2007 Identity Theft Red Flags Rule (promulgated under the 2003 FACTA amendments to the federal Fair Credit Reporting Act) went into effect in November 2008, although the FTC suspended enforcement until November 1, 2009. (Similar rules were issued by the federal financial regulatory agencies, for the institutions they supervise.) The Rule requires covered entities to develop and implement written policies to prevent identity theft, including recognition of warning signs or “red flags” of suspected ID theft.

The Rule applies not only to traditional financial institutions but to “creditors,” defined as companies that “regularly defer payment for goods or services,” whether or not charging interest or finance charges, and therefore store personal information about individual debtors. Some employers, for example, sell goods or services to employees on deferred payment terms and may be treated as covered entities for that reason. (However, the Red Flag FAQs written by FTC staff take the view that an employer is not a covered entity simply because it sponsors a 401k or other qualified retirement plan that allows participants to borrow from their retirement funds.)
For covered entities, the mandatory policy to prevent ID theft must identify signs of possible security breaches involving certain data, as well as appropriate responses to those alerts. The covered data are SSNs and tax identification numbers, healthcare IDs, financial account and credit/debit card details, personally identifiable medical information, and identifying data from consumer reports (which are often used for employee background checks as well as for credit applications).
The Rule itself does not mandate encryption measures. However, most covered entities will necessarily address encryption in their written anti-ID theft policies. Their “red flags” should also include an alert if there is evidence that encryption keys have been misused, stolen, or hacked.