Violation of Privacy Rule Leads to $800,000 HIPAA Settlement

Indiana-based Parkview Health System (“Parkview”) has agreed to settle potential violations of the HIPAA Privacy Rule with the HHS Office for Civil Rights (“OCR”) by paying $800,000 and adopting a corrective action plan to address deficiencies in its HIPAA compliance program. The resolution agreement can be found here.

According to the HHS press release, the OCR opened an investigation after receiving a complaint from a retiring physician alleging that Parkview had violated the HIPAA Privacy Rule. In September 2008, Parkview took custody of medical records pertaining to approximately 5,000 to 8,000 patients while assisting the retiring physician to transition her patients to new providers, and while considering the possibility of purchasing some of the physician’s practice. On June 4, 2009, Parkview employees, with notice that the physician was not at home, left 71 cardboard boxes of these medical records unattended and accessible to unauthorized persons on the driveway of the physician’s home, within 20 feet of the public road and a short distance away from a heavily trafficked public shopping venue. It is unclear whether any of these medical records were actually viewed by anyone else.

In addition to the $800,000 payment, Parkview entered into a corrective action plan that requires them to:

  • Develop, maintain and revise, as necessary, written policies and procedures addressing requirements of the Privacy Rule and the corrective action plan (“Policies and Procedures”).  Specifically these Policies and Procedures must at a “minimum, provide for administrative, physical and technical safeguards (“safeguards”) to protect the privacy of non-electronic PHI to ensure that such PHI is appropriately and reasonably safeguarded from any intentional, unintentional or incidental use or disclosure that is in violation of the Privacy Rule.”
  • Provide Policies and Procedures to HHS within 30 days of Resolution Agreement’s Effective Date for HHS’s review and approval.
  • Distribute Policies and Procedures to all Parkview workforce members.
  • Periodically review the Policies and Procedures and update them to reflect changes in operations at Parkview, federal law, HHS guidance and/or any material compliance issues discovered by Parkview.
  • Notify HHS in writing within 30 days if Parkview determines that a workforce member has violated the Policies and Procedures (“Reportable Events”).
  • Provide general safeguards training to all workforce members who have access to PHI, as required by the Privacy Rule.
  • Provide training on its approved Policies and Procedures to all workforce members.
  • Submit to HHS a final report demonstrating Parkview’s compliance with the corrective action plan.

Organizations should pay careful attention to the transfer and disposal of both electronic and paper patient records. The OCR has provided helpful FAQs about HIPAA and the disposal of protected health information. For more information about complying with the HIPAA Privacy Rule, please contact Jefferson Lin or Elana Zana.

 

 

$4.8 Million HIPAA Settlement – Patient Data on the Web

On May 7, 2014, HHS announced that New York-Presbyterian Hospital (“NYP”) and Columbia University (“CU”) agreed to collectively pay $4.8 million in the largest HIPAA settlement to date. The organizations settled charges that they potentially violated the HIPAA Privacy and Security Rules by failing to secure thousands of patients’ electronic protected health information (“ePHI”).

NYP and CU operate a shared data network that links patient information systems containing ePHI. On September 27, 2010, the two entities submitted a joint breach report following the discovery that the ePHI of 6,800 individuals had been impermissibly disclosed due to a deactivated server, resulting in ePHI being accessible on internet search engines. The ePHI included patient statuses, vital signs, medications, and laboratory results.

HHS Office for Civil Rights’ (“OCR”) subsequent investigation determined that neither entity had conducted an accurate and thorough risk analysis or developed an adequate risk management plan to address potential threats and hazards to ePHI security. Further, OCR found that NYP failed to implement appropriate policies and procedures for authorizing access to its databases and failed to comply with internal policies on information access management.

NYP agreed to pay $3.3 million and CU agreed to pay $1.5 million. In addition, both entities agreed to Corrective Action Plans that require each entity to:

  • Conduct a comprehensive and thorough risk analysis;
  • Develop and implement a risk management plan;
  • Review and revise policies and procedures on information access management and device and media controls;
  • Develop an enhanced privacy and security awareness training program; and
  • Provide progress reports.

Additionally, CU must also “develop a process to evaluate any environmental or operational changes” that impact the security of ePHI it maintains.

This settlement again highlights the necessity for healthcare organizations and business associates to create and implement Security policies and procedures, and to engage in a security management process that ensures the security of patient data.

For assistance on the HIPAA Security Rule requirements, drafting and implementing Security policies and procedures, or general HIPAA assistance please contact Elana Zana or Jefferson Lin.

 

FDA Releases Report on Health IT Oversight

On April 3, 2014, the Food and Drug Administration (“FDA”), in collaboration with the Office of the National Coordinator for Health Information Technology (“ONC”) and the Federal Communications Commission (“FCC”), released a congressionally mandated report which proposes to clarify oversight of health information technology (“health IT”) based on a product’s function and the potential risk to patients who use it. The full draft report can be viewed here.

Similar to the FDA’s September 2013 guidance on how it would regulate mobile medical apps, this report proposes a strategy based on the premise that risk and corresponding controls should focus on health IT functionality– not the platform(s) on which such functionality resides.  As such, the FDA has identified three categories of health IT: (1) administrative health IT functions (2) health management health IT functions, and (3) medical device health IT functions.  The following table provides examples of the three categories and describes the FDA’s regulatory approach for each:

 

Health IT Category Examples (includes but not limited to) Level of Oversight
Administrative functionality Billing and claims processing, practice and inventory management,  scheduling, general purpose communications, determination of health benefit eligibility, population health management, reporting of communicable diseases to public health agency, quality measure reporting No additional oversight necessary
Health management functionality (sometimes referred to as “clinical software”) Health information and data exchange, data capture and encounter documentation, electronic access to clinical results, most clinical decision support, medication management, electronic communication and coordination, provider order entry, knowledge management, patient identification and matching Not focus of FDA oversight given proposed risk-based framework for health management  health IT
Medical device functionality Computer aided detection/diagnostic software, remote display or notification of real-time alarms from bedside monitors, robotic surgical planning and control Focus of FDA oversight

 

A significant portion of the FDA’s report focuses on the proposed framework for health management health IT functionalities.  Instead of recommending a new or additional area of FDA oversight, the report recommends a limited, narrowly-tailored approach that primarily relies on ONC-coordinated activities and private sector capabilities.  Four key priority areas for health management health IT include: (1) promote the use of quality management principles (2) identify, develop, and adopt standards and best practices (3) leverage conformity assessment tools and (4) create an environment of learning and continual improvement.

The framework also  includes a recommendation for ONC to create a public-private Health IT Safety Center, in collaboration with FDA, FCC, and Agency for Healthcare Research and Quality (“AHRQ”) and other health IT stakeholders. This Center would work on best practices and provide a forum for the exchange of ideas and information focused on promoting health IT as an integral part of patient safety.

What do you think about the FDA’s health IT report?  The FDA is seeking public input on a number of specific questions related to the report’s recommendations– the report is open to public input/comment for 90 days.  For more information about the FDA report or health IT regulatory issues, please contact Jefferson Lin or David Schoolcraft.

 

 

PROTECT Act Seeks to Exclude Health IT Software from FDA Oversight

Last month, Senators Deb Fischer (R-Neb.) and Angus King (I-Maine) introduced proposed legislation, the PROTECT Act (Preventing Regulatory Overreach To Enhance Care Technology) of 2014 (full text available here), which seeks to remove the Food and Drug Administration’s (“FDA”) regulatory authority over certain health information technology (“health IT”) software.

Main Provisions of the PROTECT Act

Specifically, the bill proposes that “clinical software” and “health software” shall not be subject to regulation under the Federal Food, Drug, and Cosmetic Act (“FD&C Act”).  The bill defines “clinical software” as “clinical decision support software or other software (including any associated hardware and process dependencies)…that captures, analyzes, changes, or presents patient or population clinical data or information and may recommend courses of clinical action…and is intended to be marketed for use only by a health care provider in a health care setting.”

The term “health software” means “software (including any associated hardware and process dependencies) that is not clinical software and (a) that captures, analyzes, changes, or presents patient or population clinical data or information; (b) that supports administrative or operational aspects of health care and is not used in the direct delivery of patient care; or (c) whose primary purpose is to act as a platform for a secondary software, to run or act as a mechanism for connectivity, or to store data.”

Both “clinical software” and “health software” would not include software “(a) that is intended to interpret patient-specific device data and directly diagnose a patient or user without the intervention of a health care provider; (b) that conducts analysis of radiological or imaging data in order to provide patient-specific diagnostic and treatment advice to a health care provider; (c) whose primary purpose is integral to the function of a drug or device; or (d) that is a component of a device.”

The PROTECT Act also proposes that the National Institute of Standards and Technology (“NIST”) be the Federal agency that oversees technical standards used by clinical software.  In addition, the Act recommends that NIST, along with the Federal Communications Commission, the National Patient Safety Foundation, and the Office of the National Coordinator for Health Information Technology, collaborate with nongovernmental entities to develop certification processes and promote best practice standards for health IT.

PROTECT Act Supporters Cite FDA’s Overreach and Slow Process

Proponents of the bill argue that, given the FDA’s broad definition of “medical device”, the FDA’s authority to regulate health IT is too extensive and that the FDA’s slow safety review process hurts innovation.  Senator King explained to the Boston Globe, “While blood-glucose monitors, pacemakers, and other high-risk devices must remain under the current FDA regulations, low-risk software like wellness apps and electronic health records need not be subject to burdensome regulations.”

Although the FDA in September 2013 issued non-binding guidance on how the agency would regulate mobile medical applications, some in the health IT industry are uncomfortable with the uncertainty surrounding the FDA’s regulatory discretion.  Along with athenahealth, which issued a document called “In Defense of the PROTECT Act,” supporters of the bill include IBM, Verizon, McKesson, and Software & Information Industry Association.

Critics Raise Patient Safety Concerns

Critics contend that the PROTECT Act’s creation of a regulatory exception for health IT software undermines the FDA’s role in safeguarding the public’s health.  They warn that flaws with digital records systems can lead to dangerous, and even fatal, consequences.  A 2011 Institute of Medicine report found that “dosing errors, failure to detect life-threatening illnesses, and delaying treatment due to poor human-computer interactions or loss of data have led to serious injury and death.” A more recent study of medical malpractice claims confirms that electronic health record-related vulnerabilities such as faulty data entry, unexpected conversions, or incorrect files/fields can lead to medical errors.

PROTECT Act opponents argue that patient safety is an area that the FDA has experience with and should regulate, whereas NIST’s mission is to promote U.S. innovation and industrial competitiveness.  The mHealth Regulatory Coalition, along with other advocacy groups like the National Physicians Alliance, Public Citizen, and the Union of Concerned Scientists have voiced concerns about the PROTECT Act.

Conclusion

Those interested in the future policy and regulatory framework of health IT should keep an eye on this proposed legislation.  In the coming months, the Obama administration also plans to release recommendation on how health IT systems should be regulated for safety.  As the adoption of health IT and electronic health records systems expands and as health IT becomes more sophisticated, the proper role of the FDA in regulating the safety of health IT will continue to be a subject of intense debate.

For more information about the PROTECT Act, FDA regulation or health IT policy issues, please contact Jefferson Lin or David Schoolcraft.

Skagit County Agrees to Pay $215,000 for HIPAA Violations

On March 6, 2014, the U.S. Department of Health and Human Services, Office for Civil Rights (“OCR”) reached a $215,000 settlement with Skagit County in northwest Washington state for violations of the HIPAA Privacy, Security and Breach Notification Rules, according to terms of the Resolution Agreement.  This represents the first OCR settlement with a county government for HIPAA non-compliance. For two weeks in September 2011, the electronic protected health information (“ePHI”) for 1,581 individuals was exposed after the ePHI had been inadvertently moved to a publicly accessible web server maintained by Skagit County.  The accessible files included protected health information about the testing and treatment of infectious diseases.

The OCR investigation revealed that Skagit County failed to provide notification to individuals as required by the Breach Notification Rule and that the county failed to implement sufficient policies and procedures to prevent, detect, contain, and correct security violations. Further, Skagit County failed to provide necessary and appropriate security awareness and training for its workforce members.  As part of the settlement, the county has agreed to enter into a Corrective Action Plan to address deficiencies in various HIPAA compliance areas, including written policies and procedures, documentation requirements, training, and other measures.

This settlement highlights the importance for all covered entities and business associates, whether in the government or private sector, to implement policies and procedures to safeguard ePHI and, in case of a breach, to respond promptly and effectively. For more information about this OCR settlement or for assistance with HIPAA compliance, please contact Jefferson Lin or David Schoolcraft.

Increased OIG Focus on Kwashiorkor Claims

In its recently released 2014 Work Plan, the OIG has announced that it will investigate hospital billing for Kwashiorkor.  Kwashiorkor is a form of severe protein malnutrition that generally affects children living in tropical and subtropical parts of the world during periods of famine or insufficient food supply. This syndrome is characterized by retarded growth, changes in skin and hair pigment, edema, and pathologic changes in the liver.

This extreme form of malnutrition, however, is very rare in the United States, which is why Kwashiorkor billing at hospitals is a target of the OIG. Because a diagnosis of Kwashiorkor on a claim also substantially increases a hospital’s reimbursement from Medicare, the OIG stated it would review Medicare payments based on Kwashiorkor claims to determine whether the diagnosis is adequately supported by documentation in the medical record.

Recently, for example, the OIG found that Wellspan York Hospital incorrectly billed Medicare inpatient claims with Kwashiorkor, resulting in overpayments of $204,000 over two years. The hospital attributed the errors to a misinterpretation of the coding guidelines for malnutrition because of a lack of clarity in the guidance.  Other hospitals, like Mercy Medical Center, have attributed Kwashiorkor errors to encoder software which incorrectly assign diagnoses of protein malnutrition to ICD-9-CM 260 (Kwashiorkor).

In light of the increased OIG focus on Kwashiorkor claims, hospitals should strengthen its controls to ensure that coding software and staff comply with Medicare billing requirements. Additionally, if there is in fact a Kwashiorkor diagnosis, hospitals should ensure that the medical record (e.g. discharge summary) substantiates the use of a Kwashiorkor diagnosis code.

For additional information regarding Kwashiorkor billing or the 2014 OIG Workplan please contact Adam Snyder or Jefferson Lin.

 

High Number of HIPAA Mobile Device Breaches – Time to Use Safe Harbor Encryption

Most breaches of electronic protected health information (ePHI) reported to the Department of Health and Human Services (HHS) have related to the theft or loss of unencrypted mobile devices. These breaches can lead to potentially hefty civil fines, costly settlements and negative publicity (e.g. Stanford and Idaho laptops or APDerm thumb drive). Given the increasing use of mobile devices and the significant costs of breach notification, healthcare organizations and their business associates would be wise to invest in encryption solutions that fall within the “safeharbor” for HIPAA breach notification.

Encryption and the “Safeharbor” for HIPAA Breach Notification

Under HHS guidance, ePHI is not considered “unsecured” if it is properly encrypted by “the use of an algorithmic process to transform data into a form in which there is a low probability of assigning meaning without use of a confidential process or key” and such confidential process or key that might enable decryption has not been breached.  To avoid a breach of the confidential process or key, these decryption tools should be stored on a device or at a location separate from the data they are used to encrypt or decrypt.  Encryption processes “consistent with” (for data at rest) or which “comply, as appropriate, with” (for data in motion) the National Institute for Standards and Technology (“NIST”) guidelines are judged to meet the law’s standard for encryption.  If ePHI is encrypted pursuant to this guidance, then no breach notification is required following an impermissible use or disclosure of the information—this is known as the HIPAA breach notification “safeharbor”. [78 FR 5664]

NIST Guidelines for Data at Rest

The NIST guidelines for data at rest do not provide specific requirements for encryption technology– instead, it describes common storage encryption technologies (full disk, volume, virtual, and file/folder encryption) and offers recommendations for implementing a storage encryption solution. A main takeaway from this guide is that “the appropriate encryption solution for a particular situation depends primarily upon the type of storage, the amount of information that needs to be protected, the environments where the storage will be located, and the threats that need to be mitigated.” Despite the lack of bright-line rules, the NIST guide does offer some key recommendations, such as:

  • When selecting a storage encryption technology, consider solutions that use existing system features (such as operating system features) and infrastructure.
  • Use centralized management for all deployments of storage encryption except for standalone deployments and very small-scale deployments.
  • Select appropriate user authenticators for storage encryption solutions.
  • Implement measures that support and complement storage encryption for end user devices.

Encryption Technology for Apple iOS Devices: A Case Study

The good news is that the technology is available to properly encrypt ePHI without being too burdensome.  For instance, Apple’s popular iPhones and iPads fortunately have their own built-in encryption technology.  Every iOS device has a “dedicated AES (Advanced Encryption Standard) 256 crypto engine built into the DMA (Direct Memory Access) path between the flash storage and main system memory, making file encryption highly efficient.”  Setting a passcode turns on Data Protection, and the passcode becomes a key to encrypting mail messages and attachments (or other apps), using 256-bit AES encryption. Notably, Apple’s encryption technology (CoreCrypto Module and CoreCrypto Kernel Module) has been FIPS (Federal Information Processing Standards) certified, a standard that the NIST guide references and approves.

Based on the NIST guidelines for data at rest, the following are some basic steps for implementing a storage encryption technology solution specifically with Apple iOS devices:

  • Ensure that users have up-to-date devices and operating systems (e.g. iPhone 4 or higher running iOS 4 or higher).
  • Work with an IT administrator or security expert to manage deployment of iPhones.
  • Select appropriate passcode requirements to meet your security needs, including timeout periods, passcode strength and how often the passcode must be changed. The effectiveness of data protection depends on a strong passcode, so it is important to require and enforce a passcode stronger than 4 digits when establishing passcode policies.
  • Store/transmit the minimum amount of ePHI necessary to effectuate communication.
  • Disable access to Notification Center and Alerts from locked screen to prevent display of potentially sensitive data.
  • Revise and document organizational policies as needed to incorporate appropriate usage of the storage encryption solution.
  • Make users aware of their responsibilities for storage encryption, such as physically protecting mobile devices and promptly reporting loss or theft of devices.

For additional guidance on mobile device security, the HHS Office of the National Coordinator for Health Information Technology (“ONC”) has also provided helpful tips in “How Can You Protect and Secure Health Information When Using a Mobile Device?”.

As healthcare becomes more mobile, covered entities, business associates, and health information technology vendors should become familiar with the “safeharbor” for HIPAA breach notification and the NIST guidelines for encryption of data at rest and in transit.  For more information about the HIPAA “safeharbor”, encryption standards, or HIPAA in general, please contact Jefferson Lin, Lee Kuo or David Schoolcraft.

 

Proposed HIPAA Rule to Enhance Criminal Background Check System

On January 7, the U.S. Department of Health & Human Services (HHS) published a notice of proposed rulemaking (NPRM) to revise the HIPAA Privacy Rule expressly permitting certain covered entities to disclose specific information about individuals who are subject to the federal mental health prohibitor to the National Instant Criminal Background Check System (NICS). HHS stated the purpose of this amendment is to help “strengthen the federal background check system to keep guns out of potentially dangerous hands” by removing legal barriers under HIPAA that may prevent reporting relevant information to the NICS.

The NICS is a national system used to conduct background checks on individuals who may be disqualified from purchasing or receiving firearms based on federally prohibited categories or state law. One such category is the federal “mental health prohibitor,” which includes individuals who have been (1) involuntarily committed to a mental institution; (2) found incompetent to stand trial or not guilty by reason of insanity; or (3) determined by a court, board, commission, or other lawful authority to be a danger to themselves or others or to lack the mental capacity to contract or manage their own affairs.

The proposed amendment would permit HIPAA covered entities that perform the commitments or adjudications that make individuals subject to the federal mental health prohibitor, or that act as repositories of NICS records on behalf of a state, to use and disclose certain information for NICS reporting purposes. These select covered entities would be permitted to disclose only  the “individual’s name; date of birth; sex; a code or notation indicating that the individual is subject to the Federal mental health prohibitor; a code or notation representing the reporting entity; and a code identifying the agency record supporting the prohibition.” Covered entities would not be permitted to disclose clinical or diagnostic information, medical records, or other identifiable health information. Covered entities could disclose the information directly to the NICS or to an entity designated by a state as a data repository for NICS reporting purposes.

Because the proposed rule focuses on covered entities that actually are responsible for ordering involuntary commitments or conducting adjudications, or that act as a designated repository of NICS records, it does not affect most treating providers or covered entities that only engage in treatment functions. Further, this modification would permit, not require, the specified covered entities to disclose information.  The proposed amendment would not include any additional notification requirements to individuals whose information was disclosed and would not require covered entities to change their notice of privacy practices.

HHS is seeking comments, which are due on March 10, on various issues addressed in the NPRM, including whether the permission should be broadened to include reporting on individuals subject to state firearms prohibitions and additional (non-clinical) identifying information.

For more information about the proposed rule or HIPAA in general, please contact Jefferson Lin.

UW Medicine Notifies 90,000 Patients of HIPAA Breach

Just before the Thanksgiving holiday, UW Medicine reported a HIPAA security breach, affecting roughly 90,000 patients at Harborview and UW Medical Centers.  In early October, a UW Medicine employee opened an e-mail attachment containing malicious software.  The malware took control of the computer, which had patients’ data stored on it.  The information that was exposed was a subset or extraction of data that was used for billing purposes.  Patient information may have included names, medical record numbers, addresses, phone numbers, dates of service, charge amounts for services received, Social Security numbers or Medicare numbers.

This is the fourth biggest HIPAA security breach this year, according to data from the Department of Health and Human Services.  The other major breaches involved stolen unencrypted computers and laptops (Advocate Health System and AHMC Healthcare) and improper disposal of medical records (Texas Health Harris Methodist Hospital).

The recent UW Medicine incident highlights the need for hospitals, providers, and business associates to monitor and update their virus protection software and firewalls.  Additionally, organizations should implement security awareness and training programs for all workforce members– this may include periodic reminders addressing malicious software or guidance on opening suspicious e-mail attachments, e-mail from unfamiliar senders or hoax e-mail.

For assistance with HIPAA and/or the breach notification rules please contact Elana Zana or Jefferson Lin.

 

Joint Commission Standards for Boarding and Leadership Collaboration with Behavioral Health Community

Effective January 1, 2014, hospitals, accredited by the Joint Commission, will be required to meet the elements of performance (EPs) related to boarding and leadership collaboration for behavioral health patients, as part of The Joint Commission’s revised standard for managing the flow of patients through the emergency department. Overcrowding and patient boarding in the emergency department has drawn considerable attention recently (see e.g., Seattle Times article on psychiatric boarding), and The Joint Commission recognizes that the problems with patient flow may have multiple factors and stem from other areas within and outside the hospital, not just the emergency department.

Under Leadership Standard LD.04.03.11 or the “Patient Flow” Standard, the following EPs will go into effect for hospitals starting next year:

  • EP 6. The hospital measures and sets goals for mitigating and managing the boarding of patients who come through the emergency department. Note: Boarding is the practice of holding patients in the emergency department or another temporary location after the decision to admit or transfer has been made. The hospital should set its goals with attention to patient acuity and best practice; it is recommended that boarding time frames not exceed 4 hours in the interest of patient safety and quality of care.
  • EP 9. When the hospital determines that it has a population at risk for boarding due to behavioral health emergencies, hospital leaders communicate with behavioral health care providers and/or authorities serving the community to foster coordination of care for this population.

The Joint Commission notes that the four-hour time frame referenced in EP 6 serves as a guideline (not a requirement) to help the hospital set a reasonable goal for its institution. Also, the goal of EP 9 is to “facilitate the more efficient use of limited resources, and build leverage to implement more effective systems of care for individuals at risk of psychiatric emergencies.” Though the communication required in EP 9 will vary depending on the nature of the relationship, The Joint Commission advises that “such communication should occur at least annually and may range from conference calls and correspondence to meetings, education forums, and strategic working groups.”

EP 6 and EP 9 are in addition to the revised EPs that went into effect at the beginning of this year on January 1, 2013.  The other revisions address: the use of data and measures to identify, mitigate and manage issues affecting patient flow; the management of emergency department throughput as a system-wide issue; and the environment of care, staffing, assessment, reassessment and care for patients with behavioral health emergencies.

To help organizations implement these requirements, The Joint Commission released an “R3 Report on Patient Flow through the Emergency Department” that provides the requirement, rationale and references for the updated standards.  If you have questions about these accreditation standards, please contact Don Black or Jefferson Lin.