$4 Million Stanford Settlement – Business Associate Pays Majority

Remember the $20 Million class action law suit against Stanford due to the posting of an Excel file online by a Business Associate?  The law suit, driven by California state privacy laws recently settled for $4 Million, with the Business Associate paying the bulk of the settlement.  The class action suit, one of five large Stanford related large HIPAA breaches, stems from a 2010 disclosure of emergency room patient data affecting 20,000 patients. The majority of the settlement fund, $3.3 million will come from Stanford’s business associate. Stanford is contributing $500,000 for a vendor education fund and is paying $250,000 in settlement administrative costs.  Though a significant reduction from the $20 Million original claim, the $4 Million settlement price tag is not a drop in the bucket.

The major lesson to glean from this case is that covered entities should better investigate their vendors before transmitting PHI.  Meaning not just simply executing a Business Associate Agreement with an indemnification and insurance provision (though advisable), but also reviewing/evaluating their current security policies, staff training, use of subcontractors, and encryption standards.  For more information about HIPAA please contact Elana Zana.

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.

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.

 

Upcoming HIPAA Audits Will Include Business Associates

On February 24, 2014, the Department of Health and Human Services (“HHS”) published a notice of its proposed collection of information in connection with its HIPAA audit efforts.  Comments on the proposed collection request must be submitted by April 25, 2014.

The notice indicates HHS’s intent to survey up to 1,200 organizations, including both covered entities and business associates, to determine the organizations’ suitability for HIPAA audits by HHS.  The survey will seek information about an organization’s patient visits, use of electronic information, revenue, and business locations, among other things.  The notice hints that some sort of technology will be used to complete the survey, as HHS’s time estimate of 30-60 minutes to complete the survey includes the time needed to “develop, acquire, install and utilize technology and systems for the purpose of collecting, validating and verifying information…”. The notice does not include details on the criteria HHS will use to select an organization for an audit.

One of the notable items of this notice is HHS’s announcement that this round of HIPAA surveys will include business associates as well as covered entites.  This is a clear signal that HHS is getting serious about HIPAA compliance by all organizations who handle protected health information.

For more information about HIPAA audits and HIPAA enforcement, please contact Lee Kuo.

2014 OIG Work Plan Contains New Priorities Specific to Hospitals

The Department of Health and Human Services, Office of the Inspector General (OIG) recently released its Fiscal Year (FY) 2014 Work Plan.  The Plan contains new priorities specific to Hospitals in areas related to Policies and Practices, Billing and Payments, and Quality of Care and Safety.  For a complete copy of the OIG 2014 Work Plan, please click here.

The OIG Work Plan provides a description of what the OIG will be focusing on in the coming year, giving providers insight into identifying corporate compliance risk areas and providing focus for ongoing efforts relating to compliance program activities, audits, and policy development.  Some of the hospital-specific priority areas identified as ‘New’ include the following:

A.      Policies and Practices

  1.  2 Midnight Rule: As of FY 2014, physicians should admit inpatients where they expect the patient’s care to last at least 2 nights in the hospital.  This modification is due to the OIG’s previous findings of over payments for inpatient stays, inappropriate billings and inconsistent billing practices.  OIG plans to review the impact of this new admission criteria and how billing varies among hospitals.
  2. Defective Medical Devices: OIG will review the increased costs to Medicare resulting from additional services necessitated by the use of defective medical devices.
  3. Comparison of Provider-Based and Free-Standing Clinics:  OIG will compare the payments made in provider-based settings and free-standing clinics with respect to similar procedures to determine the potential impact to the Medicare program for hospitals claiming provider-based status, and presumably, whether providers claiming provider-based status meet the criteria in 42 CFR § 413.65(d).

B.      Billing and Payments

  1.  Outpatient Evaluation and Management Services:  OIG will review payments made for outpatient E/M services to determine if they were appropriately billed as “new” or “established.”  Patients are generally considered “new” unless they were seen as a registered inpatient or outpatient within the past 3 years.
  2. Cardiac Catheterization and Heart Biopsies:  Billings for right heart catheterizations will be reviewed to determine if they were appropriately billed separate and apart from billings for heart biopsies.
  3. Payments for Patients Diagnosed with Kwashiorkor:  Due to the high level of reimbursement, billings for Kwashiorkor will be reviewed to determine whether diagnoses are supported by the medical record.
  4. Bone Marrow or Stem Cell Transplants: OIG will review procedure and diagnosis codes to determine the appropriateness of bone marrow and stem cell transplantation.

C.      Quality of Care and Safety

  1. Pharmaceutical Compounding:  In light of a recent meningitis outbreak resulting from contaminated injections of compounded drugs, OIG will review the oversight and accreditation assessment of pharmaceutical compounding in Medicare-participating acute care hospitals.
  2. Review of Hospital Privileging:  OIG will review how hospitals consider medical staff candidates prior to granting initial privileges, verification of credentials, and review of the National Practitioner Databank.

For additional information regarding the 2014 OIG Workplan or hospital/corporate compliance please contact Adam Snyder.

 

 

Key Lessons Related to Stark Compliant EHR Donation Arrangements

Is your entity thinking about engaging in a Stark/AKS Compliant EHR Donation Arrangement?  If so, check out this list of top 5 issues to consider as you are assessing your options and your health IT alignment strategy.

1.  An EHR donation arrangement is an effective way for hospitals to align with their physicians.

In the world of health information exchange, having the technological ability to seamlessly communicate with a hospital or referring physician is crucial to effective patient care.  It enables physicians and hospitals alike to efficiently obtain patient information and to exchange this information as needed to ensure quality patient care.

2.  There are specific rules – and significant consequences for breaking those rules.

Be careful not to run afoul of the Stark or Anti-Kickback rules.  Ensure that your contracts are compliant with both Stark and Anti-Kickback and that the arrangement is not designed at rewarding referring physicians.  

3.  What is the hospital taking on when it becomes an EHR vendor?  

What are the consequences for a physician practice if the local hospital is also its EHR vendor?  In many arrangements the hospital is the contracting party with the EHR software vendor (i.e. Epic, Cerner, etc.) and owns the relationship.  Physician groups will look to the hospital to obtain necessary service, updates, modules and when the system malfunctions.  The hospital should evaluate if it is able to take on this role.

4.  Physicians need to know what to expect as recipients of an EHR donation.

Often times the physician group is giving up its autonomy in choosing the EHR vendor, configuration or customization and must often defer to the hospital to make appropriate purchase, upgrade and service decisions.  In addition, even though the hospital may be picking up the majority of the costs (no more than 85%) the investment may still be expensive (and will likely exceed the meaningful use incentive dollars).  Items such as hardware, storage, and operating system software are excluded from the donation.    

5.  Before you align, be clear about who will get the “record collection” if things don’t turn out.

Before entering into a donation arrangement the parties should have a clear understanding of what happens if the relationship goes awry.  How will the records be divided, extracted, or migrated into a new system?  Will the physician group be able to maintain a relationship with the software vendor independently?  What are the ramifications of changing vendors and separating from the hospital EHR?

Special thanks to ECG’s Michelle Holmes and OMW attorney David Schoolcraft for composing this list based on their HIMSS14 presentation “Using Stark/Anti-Kickback to Support Hospital/Physician IT Alignment Strategies.

For more information on designing Stark/Anti-Kickback compliant donation arrangements please see the previous posts describing the exception requirements and the 2013 updates.  For assistance in creating a donation arrangement please contact Elana ZanaMichelle Holmes or David Schoolcraft.

 

Understanding Stark/Anti-Kickback Compliant EHR Donation Arrangements

In 2006 and extended in December 2013, CMS issued Stark and Anti-Kickback exceptions/safe harbors permitting EHR technology donation arrangements between hospitals (and other organizations) and physician groups.  This exception permitted hospitals to aid physician groups, who may be referral sources, in acquiring and implementing EHR and other health information technology.  Originally, hospitals had a seven-year window in which to engage in these donation arrangements, though in December 2013 CMS extended the donation arrangements for an additional 7 years through December 31, 2021.

The arrangement may include the non-monetary donation of “items or services in the form of software or information technology and training services.”  Key components of the exception/safe harbor include:

  • The donation is provided from an entity to a physician.
    • Change in 2013 rules, this entity cannot be a lab.
  • The software is interoperable
    • Change in  2013 rules, software is deemed interoperable if it has been certified as “certified EHR technology” as that term is used by the ONC for the meaningful use/EHR Incentive Program.
  • Donor cannot restrict or limit the use or interoperability of the technology with other eRx or EHR systems.
    • Change in 2013 rules, CMS interprets this rule more broadly by providing a non-exclusive list of the types of technologies that are included in this restriction: “health information technology applications, products, or services.”
  • Physician must pay at least 15% of the costs for the technology (which amount cannot be financed by the hospital).
  • Neither the physician nor the physician’s practice makes the receipt of the technology a condition of doing business with the donor.
  • Neither eligibility of the physician nor the amount or nature of the donation is determined in a manner that takes into account the volume or value of referrals or other business generated between the parties.
  • The donation is set forth in writing, signed by the parties, specifies the items to be provided, the donor’s costs and the physician’s contribution, and covers all EHR items and services to be provided by the donor.
  • The donor cannot have knowledge of or disregard the fact that the physician already possesses equivalent items or services.
  • The donor cannot restrict or limit the physician’s right to use the software for any patient.
  • The donation cannot include staffing of physician offices and cannot be used to primarily conduct personal business or business unrelated to the physician’s medical practice.
    • Note the donation may also include other “software and functionality directly related to the care and treatment of individual patients (for example, patient administration, scheduling functions, billing, clinical support software, etc.” (71 FR 45152).
  • The donation arrangement does not violate the Anti-Kickback statute.
  • The exception expires December 31, 2021.

Beyond crafting a donation arrangement that satisfies both the Stark law exception and Anti-Kickback safe harbor, hospitals and physicians should assess overall technology alignment strategies and the goals and framework for such donation arrangements.  Making sure that clear expectations are set in advance, including understanding implementation, roll out and support, data ownership and extraction, and utilizing the EHR technology for government incentive programs, such as meaningful use, are important topics that should be addressed by the arrangement.

For those interested in learning more about this topic and are currently attending HIMSS14, David Schoolcraft, attorney at Ogden Murphy Wallace, and Michelle Holmes, principal at ECG Management Consultants, are presenting on Wednesday at 10 AM on Using Stark/Anti-Kickback To Support Hospital/Physician IT Alignment Strategies.  For further information about designing a compliant arrangement please contact Elana Zana or Dave Schoolcraft.

 

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.

 

HHS Issues HIPAA Guidance For Mental Health

HHS recently issued HIPAA guidance for mental health practitioners, in an effort to help providers wade through complicated decisions of when disclosures of patient information are permissible.  This guidance, set up in a FAQ format, is designed to incorporate common questions related to the intersection of mental health and privacy laws.  The guidance addresses when healthcare providers are permitted to:

  • Communicate with a patient’s family members, friends, or others involved in the patient’s care;
  • Communicate with family members when the patient is an adult;
  • Communicate with the parent of a patient who is a minor;
  • Consider the patient’s capacity to agree or object to the sharing of their information;
  • Involve a patient’s family members, friends, or others in dealing with patient failures to adhere to medication or other therapy;
  • Listen to family members about their loved ones receiving mental health treatment;
  • Communicate with family members, law enforcement, or others when the patient presents a serious and imminent threat of harm to self or others; and
  • Communicate to law enforcement about the release of a patient brought in for an emergency psychiatric hold.

The guidance also addresses FERPA (privacy laws in a school setting), Federal alcohol and drug abuse confidentiality (42 CFR Part 2 Programs) and the rights of parents to have access to a minor child’s information.    Though not addressed in the guidance, those mental health practitioners practicing in Washington State should also be aware of  the new statutes regulating mental health record disclosures which take effect on July 1, 2014.

For assistance in navigating these privacy rules please contact Elana Zana or Dave Schoolcraft.

DOH Issues New Hospital CN Rule & Transparency Requirements

Prior to the end of the year, and in compliance with Governor Inslee’s directive, the Washington Department of Health (DOH) issued new hospital Certificate of Need (CN) rules and transparency requirements for existing hospitals.

Effective January 23rd, hospitals wishing to affiliate with one another (or other types of corporate restructuring) will now have to undergo full CN review.  The new rules modify WAC 246-310-010 and adopt a broad definition of “sale, purchase, or lease” to include affiliations, corporate membership restructuring, “or any other transaction.”  DOH, in response to the over 1,000 public comments received on these new rules (including the transparency rules below) explained:

The purpose of this clarification is to focus on the outcome of these transactions to bring them within CoN review.  CoN evaluation includes review of the reduction or loss of services and the community’s access to alternatives if there is a reduction or loss.

In addition, DOH issued a modification to the hospital licensing requirements.  This modification now requires hospitals to submit to DOH and publish on their own websites (“readily accessible to the public”) the following policies related to access to care:  admission, nondiscrimination, end of life care, and reproductive health care.  Hospitals must comply with this requirement no later than March 24, 2014.  Hospitals that make changes to these policies must also notify DOH of those changes within thirty days.

Since the amendment to the hospital licensing rules require online access to hospitals’ nondiscrimination policies, now is an excellent time for hospitals to review nondiscrimination policies to be sure they are consistent with all applicable laws.  Hospitals are “places of accommodation” under local, state, and federal nondiscrimination laws, which vary by jurisdiction.  For example, federal law prohibits genetic discrimination, which is not covered by Washington state law; state law prohibits discrimination on the basis of marital status, sexual orientation, and gender expression or identity, which are not covered under federal law; and the City of Seattle prohibits discrimination on the basis of political ideology, which is not covered under state or federal law.  Hospital nondiscrimination policies should be tailored to cover all the jurisdictions in which you provide services.  For assistance with drafting a nondiscrimination policy please contact Karen Sutherland.

For more information about the access to care policies or certificate of need generally please contact Elana Zana.