HHS Releases Security Risk Assessment Tool

March 28, 2014 By

Need help performing your HIPAA/Meaningful Use Security Risk Assessment?  Good news, HHS has released a tool to help!  In partnership with the Office of the National Coordinator, HHS created a tool, user guide, software, tutorial, videos and even an iOS App to help HIPAA covered entities and business associates perform the required HIPAA Risk Analysis.

The HIPAA Security Rule specifically requires (this is not an addressable specification) a Security Risk Analysis:

“Risk analysis (Required). Conduct an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of electronic protected health information held by the covered entity or business associate.”  45 CFR 164.308(a)(1)

In addition, those hospitals and eligible professionals seeking to meet meaningful use in order to receive the EHR Incentive dollars or avoid the Medicare payment adjustments must fulfill a HIPAA Security Risk Assessment.

Stage 1

Stage 2
Objective. Protect electronic health information created or maintained by the certified EHR technology through the implementation of appropriate technical capabilities.Measure. Conduct or review a security risk analysis in accordance with the requirements under 45 CFR 164.308(a)(1) and implement security updates as necessary and correct identified security deficiencies as part of its risk management process. Objective. Protect electronic health information created or maintained by the Certified EHR Technology through the implementation of appropriate technical capabilities.Measure. Conduct or review a security risk analysis in accordance with the requirements under 45 CFR 164.308(a)(1), including addressing the encryption/security of data stored in Certified EHR Technology in accordance with requirements under 45 CFR 164.312(a)(2)(iv) and 45 CFR 164.306(d)(3), and implement security updates as necessary and correct identified security deficiencies as part of the EP’s risk management process.

For those hospitals and eligible professionals looking to meet meaningful use, the Security Risk Assessment tool will generate a report that can be provided to auditors.  However, the report alone is likely insufficient because both the auditors and the  meaningful use requirements (above) require the correction of security deficiencies – so merely running a Security Risk Assessment without taking actions to remedy the problem will not suffice.  To read more about meaningful use audits and security risk assessments click here. 

In addition to releasing the Security Risk Assessment tool, HHS has created a helpful true/false statement with the Top 10 Myths of Security Risk Analysis.  This document highlights the misconceptions regarding the risk assessment requirements, including that all covered entities and business associates (regardless of the size) must conduct a risk assessment pursuant to HIPAA.  Importantly, though only eligible professionals & hospitals are eligible for meaningful use incentives and Medicare payment adjustments, business associates must also comply with the HIPAA Security Rule pursuant to the HITECH Act.  Therefore, business associates must also conduct security risk assessments, and per recent guidance from HHS, business associates are likely part of the next round of HIPAA audits.

For more information about HIPAA, security risk assessments, and meaningful use please contact Elana Zana.

Filed Under: Business Associate, Compliance, Health Information Technology, HIPAA, HITECH, Incentive Payments, Meaningful Use Tagged With: , , , , ,

$4 Million Stanford Settlement – Business Associate Pays Majority

March 27, 2014 By

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.

Filed Under: Compliance, Health Information Technology

PROTECT Act Seeks to Exclude Health IT Software from FDA Oversight

March 19, 2014 By

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.

Filed Under: Compliance, FDA, Health Information Technology Tagged With: , ,

Key Lessons Related to Stark Compliant EHR Donation Arrangements

February 26, 2014 By

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 Zana, Michelle Holmes or David Schoolcraft.

 

Filed Under: Anti-Kickback/Stark, Compliance, EHR, Health Information Technology, Stark Tagged With: , ,

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

February 24, 2014 By

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.

 

Filed Under: Breach Notification, Compliance, Health Information Technology, HIPAA, HITECH Tagged With: , ,

HHS Deadline for HIPAA Breach Notification Reporting

February 18, 2014 By

As part of the HITECH revisions to HIPAA, providers are required to report all HIPAA breaches, regardless of the number of individuals affected to HHS on an annual basis.  The deadline for this report is Saturday, March 1st, 2014.  This reporting requirement is pursuant to the Omnibus HIPAA Rule published in January of 2013.  Providers who have had breaches affecting less than 500 individuals can report the HIPAA breaches here.  This report needs to be filled out for each breach that occurred during the 2013 calendar year.  For example, if a covered entity had a breach in April of 2013 affecting three individuals and another breach in December 2013 affecting two individuals the report must be submitted for each breach but not for each individual (a total of two reports would be submitted in this example).  To fill out this form covered entities will need to submit the following information about the breach:

  • General information regarding the covered entity
  • Whether the breach occurred at or by a Business Associate and the associated contact information for that Business Associate
  • Date of the Breach
  • Date of Discovery
  • Approximate number of individuals affected by the Breach
  • Type of Breach (i.e. theft, loss, unauthorized access, etc.)
  • Location of breached information (i.e. laptop, e-mail, etc.)
  • Type of Protected Health Information involved in the Breach (i.e. demographic, financial, etc.)
  • Description of the Breach
  • Safeguards in place prior to the Breach (i.e. firewalls, physical security, etc.)
  • Date individuals were notified of the Breach
  • Whether substitute notice was required (this requirement is described in the rule)
  • Whether media notice was required (this requirement is described in the rule)
  • Actions taken in response to the Breach (sanctions, mitigation, etc.)
  • Any additional actions taken
  • Attestation

For those covered entities that have had a breach which affected more than 500 individuals, this report should have been submitted no later than 60 days following discovery of the breach in accordance with the Breach Notification Rule.

If you have questions regarding filling out this report or on Breach Notification in general please contact Elana Zana or Dave Schoolcraft.

Filed Under: Health Information Technology, HIPAA, HITECH Tagged With: , ,

Medicare EHR Incentive Program Deadline Extended

February 12, 2014 By

CMS announced last week that it has extended the registration and attestation deadline for the Medicare EHR Incentive Programs to March 31, 2014 for eligible professionals.  This month long extension will aid eligible professionals in compiling their meaningful use data from 2013 and filling out the registration process (which can be time consuming).

In addition, CMS is offering to assist eligible hospitals who experienced difficulty with their attestation.  This assistance will allow eligible hospitals to submit their attestation retroactively to avoid the 2015 payment adjustment.  To do so, hospitals must contact CMS by March 15, 2014.  Eligible hospitals are instructed to contact CMS at EH2013Extension@Provider-Resources.com  no later than 11:59 PM EST on Marfch 15, 2014.

  1. Type “EH 2013 EXTENSION” in the subject line of the email note
  2. Include the following information:
    • CCN;
    • hospital name;
    • contact person name;
    • contact person email; and
    • contact person phone number.

CMS will then contact the designated individual to discuss the retroactive extension.

As a reminder, these extensions are for the Medicare EHR Incentive Program only, and do not apply to the Medicaid EHR Incentive Program.  In Washington, the deadline to apply for the Medicaid EHR Incentive Program remains February 28, 2014.

For more information about the EHR Incentive Programs or meaningful use generally please contact Elana Zana.

Filed Under: EHR, Health Information Technology, HITECH, Incentive Payments, Meaningful Use, Medicaid, Medicare Tagged With: ,

Washington Medicaid EHR Incentive Program Webinar

February 11, 2014 By

The Washington State Health Care Authority announced that it will be hosting a webinar to aid in the registration for the Medicaid EHR Incentive Program.  This will help providers who are registering and attesting to both adopt, implement and upgrade and meaningful use.

Topics Include: Navigating the WA ST EHR Attestation Application-eMIPP (MU Stage 1)

  • Attestation
  • Navigating the eMIPP application
  • How to get paid correctly
  • Live Q & A after presentation

To register click here.

The state of Washington has also published helpful tools for registration, including user guides and state specific worksheets (for example the .95 multiplier).

These webinars are very informative and it is recommended that all first time applicants (and those applicants that need a refresher) attend.

Also, note that though the Medicare EHR Incentive Program has extended registration through March 31, 2014, the Washington Medicaid EHR Incentive Program requires registration and attestation by February 28, 2014.

For assistance with registration and attestation for the Medicare or Medicaid EHR Incentive Program please contact Elana Zana.

 

Filed Under: EHR, Health Information Technology, HITECH, Incentive Payments, Meaningful Use, Medicaid, Washington Tagged With: , ,

FDA Releases Guidance For Medical Mobile Apps

October 2, 2013 By

The Food and Drug Administration (FDA) recently released guidance on how the agency intends to regulate mobile applications (“mobile apps”).  This more complete guidance follows the FDA’s May 21“It has come to our attention” letter to Biosense Technologies regarding a mobile app that can conduct urine analysis.  Given the growing expansion and applicability of mobile apps, this recent guidance contains non-binding recommendations aimed to provide clarity and predictability for manufacturers of mobile medical apps.

The FDA intends to focus its regulatory oversight to only those mobile apps that are medical devices (as defined in the FD&C Act) and whose functionality could pose a risk to a patient’s safety if the mobile app were to not function as intended.  Referred to as “mobile medical apps,” these include mobile apps that:

  • Connect to an existing medical device for purposes of controlling the device or displaying storing, analyzing, or transmitting patient-specific medical device data;
  • Transform the mobile platform into a regulated device by using attachments, display screens, or sensors or by including functionalities similar to those of currently regulated medical devices; or
  • Become a regulated medical device (software) by performing patient-specific analysis and providing patient-specific diagnosis or treatment recommendations.

For other health-related mobile apps that pose a low risk to patients, the FDA intends to exercise “enforcement discretion,” meaning the agency does not intend to enforce requirements under the FD&C Act.  These include mobile apps that:

  • Provide or facilitate supplemental clinical care, by coaching or prompting, to help patients manage their health in their daily environment;
  • Provide patients with simple tools to organize and track their health information;
  • Provide easy access to information related to patients’ health conditions or treatments (beyond providing an electronic “copy” of a medical reference);
  • Help patients document, show or communicate to providers potential medical conditions;
  • Perform simple calculations routinely used in clinical practice; or
  • Enable individuals to interact with PHR or EHR systems.

Depending on the classification and the associated regulation for the mobile medical app, a manufacturer would be required to follow a set of regulatory controls. The guidance contains more specific examples of mobile medical app classification and some helpful FAQs.  Specifically, the guidance contains appendices including what the FDA does and does not consider as medical devices and a list of medical devices posing a risk of harming a patients if they malfunction.  For more information regarding FDA guidance on mobile apps specifically, please contact Jefferson Lin.

Filed Under: FDA, Health Information Technology Tagged With: , , ,

Copier Hard Drive Breach Costs Plan $1.2 Million

August 15, 2013 By

Yesterday, HHS announced a new HIPAA related settlement with Affinity Health Plan for $1,215,780 related to PHI maintained on leased copy machines.  This settlement follows an OCR investigation prompted by Affinity’s breach report filed on April 15, 2010.   Affinity became aware of the breach following notice from CBS Evening News.  Apparently, CBS purchased a photocopier previously leased by Affinity as part of an investigative report.  CBS then notified Affinity that the copy machine contained PHI on its hard drive.  Affinity reported that an estimated 344,579 individuals were affected by this breach.

OCR determined that Affinity improperly disclosed PHI when it returned its copy machines to the leasing agents without erasing the data on the copier hard drives.  Additionally, Affinity failed to include the copy machine hard drives in its HIPAA mandated risk analysis required by the Security Rule and failed to implement policies and procedures for wiping the hard drives when returning the photocopiers to its leasing agents.  Affinity also entered into a corrective action plan with the OCR to retrieve all hard drives contained on copy machines previously leased that remain in the possession of the leasing agent.

Covered Entities (and now business associates) need to make sure that all electronic devices, including copy machines, medical equipment computers, mobile phones, tablets, etc. are incorporated into their HIPAA Security Policies and Procedures and are evaluated to ensure that PHI is wiped prior to returning or selling any such devices.  The FTC has issued a report on safeguarding data stored in hard drives of digital copiers and NIST has also issued guidance on media sanitation.

For more information regarding how to comply with the HIPAA Security Rules please contact Elana Zana.

Filed Under: Health Information Technology, HIPAA, HITECH Tagged With: ,
«Previous Page
Next Page»