“The Interim Final Rule for Breach Notification for Unsecured Protected Health Information, issued pursuant to the Health Information Technology for Economic and Clinical Health (HITECH) Act, was published in the Federal Register on August 24, 2009, and became effective on September 23, 2009. During the 60-day public comment period on the Interim Final Rule, HHS received approximately 120 comments.

HHS reviewed the public comment on the interim rule and developed a final rule, which was submitted to the Office of Management and Budget (OMB) for Executive Order 12866 regulatory review on May 14, 2010.  At this time, however, HHS is withdrawing the breach notification final rule from OMB review to allow for further consideration, given the Department’s experience to date in administering the regulations.  This is a complex issue and the Administration is committed to ensuring that individuals’ health information is secured to the extent possible to avoid unauthorized uses and disclosures, and that individuals are appropriately notified when incidents do occur.  We intend to publish a final rule in the Federal Register in the coming months.”

You may follow developments with this Final Rule at the Department of Health and Human Services (HHS) Office for Civil Rights (OCR) Web site, and HIPAA.com will bring you updates as well.

Stay tuned!

[20100730]

]]> http://www.hipaa.com/2010/07/hhs-pulls-breach-notification-file-rule/feed/ 0 http://www.hipaa.com/2010/07/ocr-reports-107-breaches-affecting-over-4-million-individuals-ii/ http://www.hipaa.com/2010/07/ocr-reports-107-breaches-affecting-over-4-million-individuals-ii/#comments Fri, 09 Jul 2010 13:00:10 +0000 Ed Jones http://www.hipaa.com/?p=2269 The Office for Civil Rights (OCR) regularly updates its Web site listing of breaches affecting 500 or more individuals. As of July 2, 2010, there were 107 breaches listed that were reported to have occurred between September 22, 2009 and June 11, 2010. Individuals affected by these publicly listed breaches totaled 4,086,980. Six of the 107 breaches, or 5.6% of the total, affected 3,353,627 individuals, or 82% of the total. This is the second of three postings that analyzes the data from these 107 breaches. This posting (II) covers paper breaches. The first posting (I) covered electronic breaches, and the final posting (III) looks at the prevalence of business associate involvement.

Public listing of such breaches is required by the Health Information Technology for Economic and Clinical Health Act (HITECH Act) that was enacted as part of the American Recovery and Reinvestment Act of 2009. The breach list has been on the OCR Web site since February 23, 2010, the day after OCR began enforcement of breach notification for breaches that occurred on or after February 22. Excluding seven breaches that were not identified as to location, 25% involved breaches of protected health information (PHI) in hard copy (paper)form and 75% in various electronic forms.

Of the 25 identified hard copy (paper) breaches, the largest category was “other,” which means that OCR either needs to require more detailed information on “what happened” of covered entities reporting breaches or to provide greater specificity regarding the category: Type of Breach, if covered entities provide such information.

Of the hard copy (paper) breaches providing information in that category, six involved theft, five unauthorized access, four improper disposal, four loss, and one incorrect mailing. Included in those totals are three compound types reported by covered entities: one theft/loss, one theft/unauthorized access, and one improper disposal/loss.

The OCR Web site that lists breaches is at: hhs.gov.

Legal authority for the NPRM is in Sections 13400 to 13410 of Subtitle D (Privacy) of the HITECH Act, which was enacted as part of the American Recovery and Reinvestment Act of 2009 (Public Law 111-5), enacted on February 17, 2009. Those sections cover:

13400:  Definitions

13401:  Application of Security Provisions and Penalties to Business Associates of Covered Entities; Annual Guidance on Security Provisions

13402:  Notification in the Case of Breach

13403:  Education on Health Information Privacy

13404:  Application of Privacy Provisions and Penalties to Business Associates of Covered Entities

13405:  Restrictions on Certain Disclosures and Sales of Health Information; Accounting of Certain Protected Health Information Disclosures; Access to Certain Information in Electronic Format

13406:  Conditions on Certain Contacts as Part of Health Care Operations

13407:  Temporary Breach Notification Requirement for Vendors of Personal Health Records and Other Non-HIPAA Covered Entities

13408:  Business Associate Contracts Required for Certain Entities

13409:  Clarification of Application of Wrongful Disclosures Criminal Penalties

13410:  Improved Enforcement

These sections appear in Subtitle D (Privacy) on pp. 258-276 of Public Law 111-5, which is available for download on hipaa.com.  The NPRM represents enabling rules for referenced statutory provisions from within some or all of those sections.

The Abstract of the NPRM is:

“The Department of Health and Human Services Office for Civil Rights will issue rules to modify the HIPAA Privacy, Security, and Enforcement Rules as necessary to implement the privacy, security, and certain enforcement provisions of subtitle D of the [HITECH Act](Title XIII of the American Recovery and Reinvestment Act of 2009).”

In addition to the NPRM discussed above, OMB still has under review the Final Rule entitled:  HIPAA Administrative Simplification; Notification in the Case of Breach (RIN:  0991-AB56), which would replace the Interim Final Rule that was published in the Federal Register on August 24, 2009 (74 Federal Register 42739-42770).

The Abstract of the Final Rule is:

“The Department will issue final rules for HIPAA covered entities and business associates with respect to breach notification of unsecured protected health information as required by section 13402 of the [HITECH Act](Title XIII of the American Recovery and Reinvestment Act of 2009).”

(20100705)

Public listing of such breaches is required by the Health Information Technology for Economic and Clinical Health Act (HITECH Act) that was enacted as part of the American Recovery and Reinvestment Act of 2009.  The breach list has been on the OCR Web site since February 23, 2010, the day after OCR began enforcement of breach notification for breaches that occurred on or after February 22.  Excluding seven breaches that were not identified as to location, 25% involved breaches of protected health information (PHI) in hard copy (paper) form and 75% in various electronic forms.  Of the electronic breaches, which included several in multiple electronic forms, 34 involved laptops, 15 desktops, 11 portable devices, 9 servers, and the remaining 11 miscellaneous forms (2 hard disks, 2 computers (not otherwise identified), 2 backup tapes, 2 electronic medical records (EMRs), 2 other (not identified), and 1 CD).

Of the 75 electronic breaches, 58, or 77%, involved theft, and 11, or 15%, involved unauthorized access, with 7 of those 11 also reported in association with theft.  There were six reported losses, or 8%, with 2 of those 6 also reported in association with theft.  There were four reported hacking incidents, or 5%, with 1 of those 4 also reported in association with unauthorized access.  Finally, there were 6, or 8%, defined as other, with 1 of those 6 also reported in association with theft.

Of the 34 breaches involving a laptop, 32, or 94% involved a theft, and the remaining 2 breaches, or 6%, involved a loss. Of the 11 breaches involving a portable device, 10, or 91%, involved a theft, with one, or 9%, a loss.  Whether a theft or loss, the evidence from the growing number of publicly reported breaches is that portable computers and devices must be encrypted to secure protected health information, in accordance with the August 24, 2009, Guidance Specifying the Technologies and Methodologies that Render Protected Health Information Unusable, Unreadable, or Indecipherable to Unauthorized Individuals (74 Federal Register 42742-42743) in order to avoid the growing costs to breaching entities of complying with provisions of the breach notification rule, reputational harms to those entities, and financial and inconvenience harms to affected individuals. [20100702]

On October 30, 2009, HHS published in the Federal Register the Interim Final Rule (IFR): HIPAA Administrative Simplification: Enforcement.[1] This IFR strengthened HIPAA enforcement of February 17, 2009-enacted HITECH Act penalty revisions, which were effective for violations beginning on February 18, 2009. The enforcement IFR was effective on November 30, 2009. This IFR followed by several months HHS Secretary Kathleen Sebelius’ delegation of enforcement of the HIPAA Security Rule to the Office for Civil Rights (OCR)[2], which had HIPAA Privacy Rule enforcement responsibilities since the April 14, 2003, compliance date for the Privacy Rule.

OCR’s unified enforcement of the HIPAA Privacy Rule, HIPAA Security Rule, and the Breach Notification Rule and higher penalties increase the likelihood and severity of consequences of noncompliance with those rules, especially with the advent of compliance audits in addition of complaint investigations.

Before the February 17, 2009-enacted HITECH Act penalty revisions, civil penalties for HIPAA violations were $1000 for each violation or $25,000 for all violations of the same provision in a calendar year period. Under the HITECH Act, penalties are substantially increased and have been divided into four tiers, with a maximum of $1.5 million for all violations of an identical provision in a calendar year. The tiered Penalties now range as follows, for each violation:

• $100-$50,000 if the covered entity did not know an, by exercising reasonable diligence, would not have known, that it violated such provision.
• $1,000-$50,000 if the violation was due to reasonable cause and not to willful neglect.
• $10,000-$50,000 if the violation was due to willful neglect and was corrected “during the 30-day period beginning on the first date the covered entity liable for the penalty knew, or, by exercising reasonable diligence, would have known that the violation occurred.”[3]
• $50,000 or more if the violation was due to willful neglect and was not corrected as required.

In announcing strengthened enforcement, OCR Director Georgina Verdugo said:

“The Department’s implementation of these HITECH Act enforcement provisions will strengthen the HIPAA protections and rights related to an individual’s health information…. This strengthened penalty scheme will encourage health care providers, health plans and other health care entities required to comply with HIPAA to ensure that their compliance programs are effectively designed to prevent, detect and quickly correct violations of the HIPAA rules… Such heightened vigilance will give consumers greater confidence in the privacy and security of their health information and in the industry’s use of health information technology.”[4]

Currently, there is at OMB for review as a Notice of Proposed Rulemaking (NPRM): Modifications to the HIPAA, Privacy, Security, and Enforcement Rules Under the Health Information Technology for Economic and Clinical Health Act.[5] According to the Abstract: “The Department of Health and Human Services Office for Civil Rights will issue rules to modify the HIPAA Privacy, Security, and Enforcement Rules as necessary to implement the privacy, security, and certain enforcement provisions of subtitle D [Privacy] of the [HITECH Act].” After clearance at OMB, the NPRM will be published in the Federal Register. Be alert to NPRM modifications to privacy, security, and enforcement requirements, and the likelihood of relative quick—by HIPAA time standards—compliance dates for each through follow-on interim final rules.

Please visit the OCR Enforcement Web site for additional information now and updated information in the future.

[1] Department of Health and Human Services, Office of the Secretary, “45 CFR Part 160, HIPAA Administrative Simplification: Enforcement; Interim Final Rule,” Federal Register, v.74, n.209, October 30, 2009, pages 56123-56131. Citations to this document are in the format: 74 FR page(s). This document is available online at: www.hhs.gov/ocr/privacy/hipaa/administrative/enforcementrule/enfifr.pdf.

[2] OCR also is responsible for enforcement of the HITECH Act Breach Notification Rule. The delegation of enforcement of the HIPAA Security Rule was from the Centers for Medicare & Medicaid Services (CMS), which retains enforcement authority for the HIPAA Transaction and Code Set and Identifiers Rules. See Department of Health and Human Services, Office of the Secretary, “Office for Civil Rights; Delegation of Authority,” Federal Register, v.74, n.148, August 4, 2009, page 38630. This document is available online at: www.hhs.gov/ocr/privacy/hipaa/administrative/securityrule/srdelegation.pdf.

[3] 74 Federal Register 56131.

[4] Department of Health and Human Services, “HHS Strengthens HIPAA Enforcement, “ news release, October 30, 2009, which is available online at: http://www.hhs.gov/news/press/2009pres/10/20091030a.html.

[5] This document, Regulation Identifier Number (RIN) 0991- AB57, was received at OMB on April 12, 2010, and attributes of this NPRM, but not its content, are available online at: http://www.reginfo.gov/public/do/eAgendaViewRule?pubId=201004&RIN=0991-AB57.

This report comes several days after OCR’s release last Friday of its Draft Security Rule Guidance on Risk Analysis, the first in a series of guidances on security, that hipaa.com posted earlier today, and precedes the likely release later this month of the Notice of Proposed Rulemaking (NPRM):  Modifications to the HIPAA Privacy, Security, and Enforcement Rules Under the Health Information Technology for Economic and Clinical Health Act, which is currently at the Office of Management and Budget (OMB) for review prior to publication in the Federal Register.

In addition, the renewed emphasis on HIPAA Security Rule compliance may be due in part to the growing number of posted “Breaches Affecting 500 or More Individuals” on the OCR Web site.

As of May 6, 2010, OCR had listed on this site 77 covered entities that had experienced such breaches, with the total number of affected individuals 2,430,167.  Of the total listed breaches, 63 involved covered entities only and 14, 0r 18%, involved a business associate in some manner.  Of the 72 reported breaches identifying whether paper or electronic protected health information (PHI) was involved, 18, or 25% involved paper and 54, or 75%, involved electronic media.  Forty-five of those 54 breaches, or just over 83%, were instances of theft or loss, most often laptop or other portable devices, highlighting the need for encrypting PHI to secure it on those electronic media according to NIST-validated standards identified in the August 24, 2009, HHS Guidance.  That Guidance was discussed in earlier hipaa.com postings and is available on this site .

With increased enforcement comes the need for greater attention paid to HIPAA Privacy and Security Rule compliance and training.  hipaa.com will announce new online HIPAA privacy and security training initiatives later this month.  You may register on hipaa.com to be notified of the training announcement.

This eight-page document is available online.

The Draft Guidance on Risk makes the following key points:

“The Security Rule does not prescribe a specific risk analysis methodology, recognizing that methods will vary dependent on the size, complexity, and capabilities of the organization.  Instead, the Rule identifies risk analysis as the foundational element in the process of achieving compliance, and it establishes several objectives that any methodology adopted must achieve….

“The risk analysis process should be ongoing.  In order for an entity to update and document its security measures ‘as needed,’ which the Rule requires, it should conduct continuous risk analysis to identify when updates are needed….

“Risk analysis is the first step in an organization’s Security Rule compliance efforts.  Risk analysis is an ongoing process that should provide the organization with a detailed understanding of the risks to the confidentiality, integrity, and availability of e-PHI.”

OCR requests public comment on the Draft Guidance on Risk Analysis, which can be sent to OCRPrivacy@hhs.gov.

On the same day, April 29, the Office for Civil Rights (OCR) of the Department of Health and Human Services (HHS) reported on its Web site 67 entities reporting “Breaches Affecting 500 or More Individuals” over the period September 22, 2009 to March 19, 2010.  That is up from the 36 that OCR listed on its initial posting of the list on February 23, 2010.  The current list is available on the OCR Web site.

Clearly, more “awareness and understanding” training on security safeguards and privacy controls regarding use and disclosure of protected health information (PHI) is necessary.  Such training is required under the HIPAA Privacy and Security Rules and includes training regarding the new HITECH Act Breach Notification Rule requirements.

HIPAA.com will have announcements about such training in May, offerred through HIPAA School.  You may register on the hipaa.com site for email notification of further details about HIPAA School training, and for postings provided on hipaa.com.  (20100429)

Here are the appropriate authorities:

Section 13401 of Part 1 (Improved Privacy Provisions and Security Provisions) of Subtitle D (Privacy) of the HITECH Act (pp. 260): Application of Security Provisions and Penalties to Business Associates of Covered Entities

(a) Application of Security Provisions.  Sections 164.308 [Administrative Safeguards], 164.310 [Physical Safeguards], 164.312 [Technical Safeguards], and 164.316 [Policies and Procedures and Documentation Requirements] of title 45, Code of Federal Regulations, shall apply to a business associate of a covered entity in the same manner that such sections apply to the covered entity.  The additional requirements of this title that related to security and that are made applicable with respect to covered entities shall also be applicable to such a business associate and shall be incorporated into the business associate agreement between the business associate and the covered entity. [42 USC 17931]

(b) Application of Civil and Criminal Penalties.  In the case of a business associate that violates any security provision specified in subsection (a), sections 1176 and 1177 of the Social Security Act (42 U.S.C. 1320d-5, 1320d-6) shall apply to the business associate with respect to such violation in the same manner such sections apply to a covered entity that violates such security provisions. [42 USC 17931]

NOTE:  Effective the day after of enactment of the HITECH Act (February 18, 2009), financial penalties were substantially increased for noncompliance with HIPAA standards, which cover policies, procedures, actions, assessments, and documentation requirements discovered during a compliance audit or complaint investigation.

Section 13423 of Part 2 (Relationship to Other Laws; Regulatory References; Effective Date; Reports) of Subtitle D (Privacy) of the HITECH Act (pp. 276):  Effective Date

Except as otherwise specifically provided, the provisions of part 1 shall take effect on the date that is 12 months after the date of the enactment of this title. [42 USC 17953]

Today marks the beginning of direct federal regulation of business associates’ compliance with the HIPAA Security Rule. [02/17/10]

42 USC 17931 (PART 1–IMPROVED PRIVACY PROVISIONS AND SECURITY PROVISIONS, Section 13401:  Application of Security Provisions and Penalties to Business Associates of Covered Entities; Annual Guidance on Security Provisions).

(a)  APPLICATION OF SECURITY PROVISIONS.–Sections 164.308 (Administrative Safeguards), 164.310 (Physical Safeguards), 164.312 (Technical Safeguards), and 164.316 (Policies and Procedures and Documentation Requirements) of title 45, Code of Federal Regulations, shall apply to a business associate of a covered entity in the same manner that such sections apply to a covered entity.  The additional requirements of this title that relate to security and that are applicable with respect to covered entities shall also be applicable to such a business associate and shall be incorporated into the business associate agreement between the business associate and the covered entity.

(b) APPLICATION OF CIVIL AND CRIMINAL PENALTIES.–In the case of a business associate that violates any security provision specified in subsection (a) [above], sections 1176 [General Penalty for Failure to Comply with Requirements and Standards] and 1177 [Wrongful Disclosure of Individually Identifiable Health Information] of the Social Security Act shall apply to the business associate with respect to such violation in the same manner such sections apply to a covered entity that violates such security provision….

42 USC 17953 (Section 13423:  EFFECTIVE DATE.  Except as otherwise specifically provided, the provisions of part 1 shall take effect on the data that is 12 months after the date of the enactment of this title [which was February 17, 2009].

If you are a covered entity, make sure that your business associates are aware to the upcoming Security Rule safeguards, policies and procedures, and documentation compliance provisions by February 17, 2010, and that your business associate agreement reflects this obligation. [01/18/2010]

As the healthcare industry continues to digest profound HITECH changes to HIPAA Privacy and Security rules, two observations already are apparent and indisputable for covered entities and their business associates.  First, time and resources spent on a workforce that is well-trained on the Privacy and Security rules will be an investment of exponential value. Second, enforcement of those same rules will make negligent and uncorrected errors very costly. A well-trained workforce makes fewer mistakes, and identifies and fixes those that it makes. A workforce that violates the rules because it does not know them or does not care to know them makes an inviting target for HITECH’s new enforcement initiatives. The lesson seems clear: train on HITECH and re-train on existing HIPAA rules–or pay some new and onerous penalties for workforce mistakes.

Here are three hard truths about the HITECH amendments. First, after HITECH, penalties for each violation of HIPAA can now exceed civil penalties for violating the anti-kickback statute. Second, HITECH mandates much more enforcement by HHS, including compliance audits, and allows enforcement by state Attorneys General. Third, under the recently adopted breach notification rules, covered entities are required to submit annually logs of protected health information (PHI) breaches to the Secretary of HHS. Because by definition each of those reported “breaches” involves a violation of the Privacy Rule, covered entities also will be informing the Secretary of their Privacy Rule violations. You won’t have to worry about possible whistleblowers; you are the whistleblower.

One major piece of good news in HITECH is that Congress provided that unless a violation is caused by willful neglect, penalties for the violation may be avoided by taking corrective action within 30 days. This is where training comes in, and where training pays off. A vigorous training program enables the workforce of a covered entity to identify violations quickly because the workforce knows what are proper PHI uses and disclosures and what are not. For example, if workforce members do not understand the concept of “minimum necessary”, they will not know that sending an entire medical record to a third party payer is highly likely to violate the Privacy Rule. If workforce members know what is the “minimum necessary” disclosure, they will either avoid an improper disclosure or move to correct it within the thirty-day corrective action grace period.

As with so many other areas of HIPAA, HITECH introduces many new concepts. New regulations have been published on unsecured breaches and more regulations are coming on privacy, security, and enforcement. Making these rules comprehensible to your workforce members (including management) and applicable to your environment requires training—and some re-training on the existing HIPAA Privacy and Security rules and how they all fit together.

HIPAA’s Security Rule is as much about good business practices as it is about securing confidential patient information. Data integrity, one of the pillars of HIPAA’s Security Rule, contains overarching security themes that pose layered questions, such as, how does the system’s functionality allow you to know who has been in the system, what did the user do with the content after he or she accessed it, or did the system block a potential intruder who did not use the correct user ID and password?

When evaluating an EHR system, you want to ask how data validation functionalities work. So during the EHR due diligence, I would ask, “How does your EHR software enable the practitioner to generate quality measurement reports, (suggest you hold up the Meaningful Use Matrix), and how do we validate the data going into the system is accurate and placed in the correct fields?” As an EHR project manager, I request a data validation report on the third and fifth day of Go-Live week so that we can quickly catch and retrain data entry errors.

Further, training requires that workforce members, including management, demonstrate awareness and understanding on an ongoing basis, and that covered entities and business associates document that their workforce members have been trained.  As examples, the first implementation specifications of the Security Rule ‘Security Awareness and Training’ standard is “Security reminders (addressable). Periodic security updates.”  [45 CFR (a)(5)(ii)(A)]  [emphasis added]  One part of the  implementation specification for the Privacy Rule ‘Training’ standard states that a “covered entity must provide training … [t]o each member of covered entity’s workforce whose functions are affected by a material change in the policies or procedures required by this subpart, within a reasonable period of time after the material change becomes effective…” [45 CFR 164.530(b)(2)(c)] [emphasis added].

Another requires that a new workforce member receive training “within a reasonable period of time after the person joins the covered entity’s workforce.” These examples regarding training are dynamic, as indicated in the italicized words and phrases, and the need to conduct training of new workforce members. Although the comment in the preamble of the January 16, 2009, Final Rule pertaining to HIPAA Electronic Transaction Standards refers to ‘administrative transactions’, it may be instructive in the context of training as well:  ”HHS does not recognize certification of any systems or software for purposes of HIPAA compliance.” [74 Federal Register 3310] The burden on a covered entity or business associate is to conduct and periodically review its risk assessment, implement policies and procedures to safeguard protected health information, conduct ‘awareness’ training for all workforce members based on those policies and procedures, update that training if policies and procedures change or HIPAA privacy and security regulations are initiated or modified, and document in writing those activities. Certification is not a requirement in that process.

Three Key Properties

The three key properties that underpin privacy and security under the Health Insurance Portability and Accountability Act (HIPAA) are availability, confidentiality, and integrity.

Availability is the property that data or information is accessible and useable upon demand by an authorized person.

Confidentiality is the property that data or information is not made available or disclosed to unauthorized persons or processes.

Integrity is the property that data or information have not been altered or destroyed in an unauthorized manner.

These definitions appear in 45 CFR § 164.304, where CFR is Code of Federal Regulations.  Part 164 covers Security and Privacy.  These definitions fall into Subpart C, which covers Security Standards for the Protection of Electronic Protected Health Information.  These properties also underpin the “Guidance Specifying the Technologies and Methodologies that Render Protected Health Information Unusable, Unreadable, or Indecipherable to Unauthorized Individuals’ that appears in the Interim Final Rule:  Breach Notification for Unsecured Protected Health Information, issued by the Office of Civil Rights (OCR) of the U.S. Department of Health and Human Services (HHS) and published in the Federal Register on August 24, 2009.

Protected Health Information

To get to protected health information, you have to examine two definitions that were in Section 1171 of Part C of Subtitle F of Public Law 104-191 (August 21, 1996): Health Insurance Portability and Accountability Act of 1996:  Administrative Simplification.  These statutory definitions are of health information and individually identifiable health information.

“Health information means any information, whether oral or recorded in any form or medium, that–

(A) is created or received by a health care provider, health plan, public health authority, employer, life insurer, school or university, or health care clearinghouse; and

(B) relates to the past, present, or future physical or mental health or condition of any individual, the provision of health care to an individual, or the past, present, or future payment for the provision of health care to an individual.”

“Individually identifiable health information is information that is a subset of health information, including demographic information collected from an individual, and:

(1) Is created or received by a health care provider, health plan, employer, or health care clearinghouse; and

(2) Relates to the past, present, or future physical or mental health or condition of an individual; the provision of health care to an individual; or the past, present, or future payment for the provision of health care to an individual; and

(i)   That identifies the individual; or

(ii) With respect to which there is a reasonable basis to believe the information can be used to identify the individual.”

Protected health information is defined in 45 CFR 160.103, where ‘CFR’ means ‘Code of Federal Regulations’, and, as defined, is referenced in Section 13400 of Subtitle D (’Privacy’) of the HITECH Act.

“Protected health information means individually identifiable health information [defined above]:

(1) Except as provided in paragraph (2) of this definition, that is:

(i)    Transmitted by electronic media;

(ii)   Maintained in electronic media; or

(iii)  Transmitted or maintained in any other form or medium.

(2) Protected health information excludes individually identifiable health information in:

(i)    Education records covered by the Family Educational Rights and Privacy Act, as amended, 20 U.S.C. 1232g;

(ii)   Records described at 20 U.S.C. 1232g(a)(4)(B)(iv); and

(iii)  Employment records held by a covered entity in its role as employer.”

The HIPAA Privacy Rule covers protected health information in any medium while the HIPAA Security Rule covers electronic protected health information.

With those definitions in place, the question becomes:  what elements comprise protected health information such that if they were removed, items (i) and (ii) of (2) in the definition of individually identifiable health information would not obtain.  The answer is in the de-identification standard and its two implementation specifications of the HIPAA Privacy Rule [45 CFR 164.514]:

“(a) Standard:  de-identification of protected health information.  Health information [defined above] that does not identify an individual and with respect to which there is no reasonable basis to believe that the information can be used to identify an individual is not individually identifiable health information.

(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 subject of the information; and

(ii) Documents the methods and results of the analysis that justify such determination; or

(2)

(i) The following identifiers of the individual or of relatives, employers, or household members of the individual, are removed:

(A) Names;

(B) All geographic subdivisions smaller than a State, including street address, city, county, precinct, zip code, and their equivalent geocodes, except for the initial three digits of a zip code if, according to the current publicly available data from the Bureau of the Censue:

(1) The geographic unit formed by combining all zip codes with the same three initial digits contains more than 20,000 people; and

(2) The initial three digits of a zip code for all such geographic units containing 20,000 or fewer people is changed to 000.

(C) All elements of dates (except year) for dates directly related to an individual, including birth date, admission date,, discharge date, date of death; and all ages over 89 and all elements of dates (including year) indicative of such age, except that such ages and elements may be aggregated into a single category of age 90 or older;

(D) Telephone numbers;

(E) Fax numbers;

(F) Electronic mail addresses;

(G) Social security numbers;

(H) Medical record numbers;

(I) Health plan beneficiary numbers;

(J) Account numbers;

(K) Certificate/license numbers;

(L) Vehicle identifiers and serial numbers, including license plate numbers;

(M) Device identifiers and serial numbers;

(N) Web Universal Resource Locators (URLs);

(O) Internet Protocol (IP) address numbers;

(P) Biometric identifiers, including finger and voice prints;

(Q) Full face photographic images and any comparable images; and

(R) Any other unique identifying number, characteristic, or code, except as permitted by paragraph (c) of this section; and

(ii) The covered entity does not have actual knowledge that the information could be used alone or in combination with other information to identify an individual who is a subject of the information.

(c) Implementation specifications:  re-identification.  A covered entity may assign a code or other means of record identification to allow information de-identified under this section to be re-identified by the covered entity, provided that:

(1) Derivation.  The code or other means of record identification is not derived from or related to information about the individual and is not otherwise capable of being translated so as to identify the individual; and

(2) Security.  The covered entity does not use or disclose the code or other means of record identification for any other purpose, and does not disclose the mechanism for re-identification.”

With HHS’s release of the Interim Final Rule, ‘Breach Notification for Unsecured Protected Health Information,’ published in the Federal Register on Monday, August 24, 2009, note the following:  ”If information is de-identified in accordance with 45 CFR 164.514(b) [the first implementation specification, defined above], it is not protected health information, and thus, any inadvertent or unauthorized use or disclosure of such information will not be considered a breach for purposes of this subpart.” [74 Federal Register 42743]

The Delegation of Authority was published in the August 4, 2009, Federal Register.

Numerous forces are driving the health care industry towards the use of health information technology, such as the potential for reducing medical errors and health care costs, and increasing individuals’ involvement in their own health and health care. To facilitate this advancement and reap its benefits while reducing the risks, it is important to consider individual privacy interests together with the potential benefits to population health.

• Download (Requires Acrobat Reader)

Rather, an addressable implementation specification means that a covered entity must use reasonable and appropriate measures to meet the standard. As we noted in earlier postings on HIPAA.com, business associates of covered entities will be required to comply with the Security Rule safeguard standards, beginning February 17, 2010. This requirement is one of the HITECH Act provisions of the American Recovery and Reinvestment Act (ARRA), signed by President Obama on February 17, 2009.

What to Do

Implement electronic controls to ensure that electronic protected health information has not been altered or destroyed in an unauthorized manner.

How to Do It

A covered entity or its electronic information systems vendor should establish electronic controls to protect  electronic protected health information from being altered or destroyed. The covered entity’s risk analysis will determine how the covered entity should authenticate electronic protected health information in its electronic information systems. Considerations should include how many times the covered entity’s system has crashed and damaged information in storage, or how many times incorrect information has been added to the database that should not have been allowed. An outcome of the risk analysis, based on these types of considerations, will be how to mitigate risk through preventive electronic controls. Controls that check for human errors and accuracy of back-ups should be employed. In addition, intrusion detection systems should be used if there is evidence of hacking or tampering attempts.

The Security Official of the covered entity is responsible for designing policies and procedures to ensure the integrity of electronic protected health information. A policy should be regular testing for data integrity. A covered entity should check with its electronic information systems vendor to see if its systems have automatic data integrity testing capabilities. If not, the vendor should be able to recommend software programs to add to the covered entity’s electronic information systems to do such testing. The policy for the covered entity also should include regular examination of test logs to ensure that integrity checks have run successfully.

For compliance with this Technical Safeguard Standard, a covered entity is required to implement policies and procedures to protect electronic protected health information from improper alteration or destruction.

Integrity means that a covered entity’s data are dependable and accurate. It also means that the authorized user can have access to the right information at the appropriate time, and that the data are not altered or destroyed in any manner. Inaccurate electronic protected health information could result in harm or even potential death of a patient. In addition, the risk of such information could adversely impair the business viability of one or more covered entities. It is for these reasons that integrity is one of the foundational concepts underpinning HIPAA Administrative Simplification, along with availability and confidentiality.

The Technical Safeguard Standards of access control and audit control can help in maintaining confidentiality of electronic protected health information, but data comprising such information can become inaccurate or corrupt from several sources, including data entry errors, hacking or tampering, mechanical errors in storage devices, transmission error, and inadequate data capture from poorly integrated or interfaced electronic information systems. Also, corruption of data can be due to software or programming bugs, computer viruses, or human error. A covered entity must ensure that its electronic protected health information, as well as other critical electronic business information, has not been altered or destroyed without its knowledge and approval.

What to Do

A covered entity is required to implement hardware, software, and/or procedural mechanisms that record and examine activity in electronic information systems that contain or use electronic protected health information.

How to Do It

During the risk analysis, a covered entity needs to define the reasons for establishing audit trail mechanisms and procedures for its electronic information systems that contain or use electronic protected health information. These reasons may include, but are not limited to, system troubleshooting, policy enforcement, compliance with the Security Rule, mitigating risks of security incidents, monitoring workforce member activities and actions. With regard to workforce member activities and actions, audit controls might focus on the following:

» Are workforce members accessing information or performing tasks beyond the scope of their job descriptions?
» Are workforce members sharing user IDs, measured by a user logged onto two or more workstations simultaneously?
» Are workforce members logged onto workstations for several days, indicating that users are not logging off?  An automatic logoff system may mitigate risk when workforce members leave workstations unattended during the workday, but the better practice at the end of the workday is for the covered entity to have a policy of workforce members taking the responsibility to log off.

In establishing or fine-tuning its policies and procedures with respect to audit controls, a covered entity should focus on the following, under the direction of its Security Official:

» Maintaining a regular and frequent review of audit trails and activity logs for electronic information systems containing electronic protected health information.
» Investigating immediately any suspicious entries such as unauthorized accesses or attempts to access electronic information systems containing electronic protected health information.
» Applying sanctions to workforce members for inappropriate activity related to electronic information systems containing electronic protected health information.
» Determining if workforce members are downloading executable files that may violate software licensing agreements or that may corrupt electronic information systems containing electronic protected health information.

Finally, with the Federal Trade Commission (FTC) Red Flags Rule to protect against identity theft, requiring compliance by covered entities that offer extended payment plans, covered entities need to examine their policies and procedures with respect to this Rule prior to the August 1, 2009 compliance date. Additional information is available on the HIPAA.com site.

Covered entities are required to have in place audit controls to monitor activity on their electronic systems that contain or use electronic protected health information. In addition, they have to have a policy in place for regularly monitoring and reviewing of audit records to ensure that activity on those electronic systems is appropriate. Such activity would include, but is not limited to, logons and logoffs, file accesses, updates, edits, and any security incidents.

Monitoring and review of audit trails must be as close to real time as possible to be useful. There is no benefit in discovering a problem days or weeks after it has occurred. How a covered entity sets its policies and procedures will be based on outcomes of the covered entity’s risk analysis. If a security incident occurs, failure to exercise this audit control standard may be proof in an inquiry that a covered entity had the capability of knowing what was occurring, but failed to exercise timely corrective action.

What to Do

Establish and implement procedures to create and maintain retrievable exact copies of electronic protected health information.

How to Do It

Covered entities must backup electronic protected health information on a regular basis. When a computer system fails, it may be relatively easy to reinstall computer programs and recover software applications. However, it may be relatively difficult to recover or recreate electronic data that are lost from files that are damaged or from files whose filenames are detached from underlying data.

A covered entity should consult with its computer and software vendors on implementing appropriate data backup routines. Prudence dictates having backup located offsite from the covered entity, even if the covered entity’s software accommodates exact-copy backup capability or it has an onsite data safe that is fire resistant and designed to protect electronic media from damage due to magnetism, heat, water, and air-borne contaminants such as smoke and dust.

A covered entity’s choice of a backup system will depend on the size of the covered entity and the number of its business locations. Each facility is required to have its own backup plan implementation, which may be part of an overall covered entity strategy. A large covered entity may use a complex procedure, such as real-time encrypted data streaming or periodic batch duplicate download to a secure offsite location. A small covered entity might do a daily tape, CD, or DVD backup and maintain the electronic media offsite in a secure location. Outputs of the risk analysis will provide guidance on the type of data backup plan, which should be reviewed periodically. The covered entity should take into consideration that electronic data storage capacities grow, the relative costs of such storage decline, and the penalties for failure under the Security Rule were increased as part of the HITECH provisions in the American Recovery and Reinvestment Act (ARRA) signed by President Obama on February 17, 2009.

HIPAA.com will outline What to do and How to do it for each of the five contingency plan implementation specifications. Here, we describe sample policy and procedures for contingency plan. The inputs for your contingency plan and each of the implementation specifications will be outputs of your covered entity’s risk analysis.

Sample Policy

Our covered entity responds to emergencies that may impair our computer systems and electronic protected health information. Workforce members are responsible for complying with these policies and procedures.

Sample Procedures

Our covered entity’s Security Official has identified key elements of our contingency plan. These are:

Contingency Planning Group

Our covered entity’s Security Official defines the mission of this contingency planning group, chairs the group, and assigns workforce members to the group.

Operating Environment and Core Applications

Examples may include, but are not limited to: electronic protected health information; application and database servers; telephone and other communication systems; operational business systems (e.g., patient scheduling systems, practice management systems, e-prescribing systems, claims adjudication systems, clearinghouse systems); internet systems and applications; email exchange servers; desktop systems; workstations, laptops, tablets, and personal data assistants (PDAs); network servers, scanners, and printers.

Facility Locations

Covered entity physical location(s) and contingency recovery sites, including secure offsite application, electronic protected health information database, and hardware locations.

Key Covered Entity Workforce Members Responsible for Achieving Contingency Recovery

Names and contact information for 24/7 accessibility; name of party or parties responsible for declaring a contingency and invoking contingency recovery plan; and outline of steps to achieve contingency recovery.

If a fire swept through a covered entity’s facility, the covered entity would need a plan to recover patient and billing files and to contact workforce members, patients, and business associate vendors to inform them of how it would stay in business.

This standard requires covered entities to establish contingency plans to respond to emergencies that could adversely impact electronic protected health information.  The list of potential emergencies needs to be compiled during the covered entity’s required risk analysis, and may include, but is not limited to, power outage, vandalism, system failure, theft, disk crash, fire, chemical spill, and natural disasters such as tornado, earthquake, flood, and  hurricane.  Contingency plans focus on safeguarding electronic protected health information and recovery for systems that may be impaired as the result of an emergency.

With growing use of electronic business systems by covered entities, increasing attention must not only be placed on having a contingency plan, but also periodically testing and updating the plan.  This Contingency Plan standard reflects the importance of that attention, to say nothing of the increased penalties for failure that are included in the HITECH provisions that were enacted as part of the American Recovery and Reinvestment Act (ARRA) signed by President Obama on February 17, 2009.

The Contingency Plan standard requires covered entities to develop and implement data backup, disaster recovery, and emergency mode operation plans.  Even in the absence of the required Contingency Plan standard of the Security Rule, it would be prudent business practice to do such development and implementation with electronic business systems.  During the risk assessment, for preparation of the Contingency Plan by a covered entity, key questions would be:

» What are likely losses that could occur, and from what source?
» How would the covered entity’s customers be affected?
» What impact would there be on a covered entity’s reputation from a loss?
» What are likely costs associated with any loss?
» What are efforts, costs, and time needed to recover?
» What is the impact on the covered entity’s viability as a business?

In general, the following steps will assist any covered entity develop and implement a Contingency Plan:

» The covered entity establishes a contingency planning group in the covered entity, chaired by the Security Official.
» The planning group assesses threats and vulnerabilities as part of the covered entity’s required risk analysis.
» The planning group assigns priorities to threats and vulnerabilities that may impact computer systems and electronic protected health information.
» The Security Official, with assistance of the planning group, develops policies and procedures for contingency recovery strategies.
» The Security Official implements contingency recovery plans, discusses these plans with workforce members, trains key workforce members to implement plan provisions in the event of a contingency, and periodically tests workforce member compliance and performance with plan provisions.
» The Security Official reviews and updates the covered entity’s contingency plans periodically.

What to Do

Conduct a risk assessment to determine the practice’s security safeguards and vulnerabilities.

How to Do It

As you go through your risk assessment, assign a value from 1 to 5 for each risk/ Risks receiving a “1″ value indicate the risk is probably low, but still needs attention; a risk given a “5″ rating means the event, such as theft, breaking into the offices, fire, weather damage, has happened at least once, and is likely to happen again.

For those risks given a 3 or 4 rating, assign an owner or owners to manage those risks. For example, you’ve decided to purchase EHR software, and you’ll be purchasing new tablets for all the clinicians. Without even accessing a risk assessment, you can already build a list of potential problem areas, such as theft, malicious software, or damage from dropping. HIPAA’s physical safeguard standard, (45 CFR 164.310{b}) requires that you implement policies and procedures that specify the proper functions to be performed, the manner in which those functions are to be performed, and the physical attributes of the surroundings of a specific workstation that can access electronic protected health information.

You not only want to safeguard protected health information, you also want to safeguard your investment. The owners of this physical safeguard could be a lead physician, a nurse, and a lab technician.

If you are the Security Official and have any concerns about your responsibilities, or if you’d like a copy of our risk assessment, give us a call or send us an email. We’re here to help.

• Download (Requires Acrobat Reader)

• Download (Requires Acrobat Reader)