•

» meaningful use

Increased Penalties for Healthcare Privacy and Security Violations? Batten Down the Hatches!

Posted on February 23, 2011 by Dan Berger in Main | 1 Comment

The 2009 HITECH Act authorized the Health and Human Resources Office for Civil Rights (HHS OCR) to add teeth to existing security and privacy regulations, and they’ve obviously taken the responsibility seriously.

On the same day that HHS OCR imposed a whopping $4.3 million dollar fine on Maryland-based Cignet Health for violating a provision of the HIPAA Privacy Rule, we also learned that HHS OCR intends to tighten healthcare data breach regulations further and to increase financial penalties across the board for privacy and security violations.

The Cignet Health fine was the first civil fine issued specifically under the existing provision of the Privacy Rule which requires covered entities to provide copies of patients’ health records within 30 days of request. As you may know, as covered entities (CE) and eligible professionals (EP) move to electronic health records (EHR), the time limit for responding to a patient’s request for access will become even shorter. To qualify for meaningful use incentives, an EP must provide EHR access within 4 business days. More recently, OCR suggested that, if patients request copies of the protected health information (PHI) and it is not readily available in the format requested, they must be directed to their EHR.

A senior OCR health IT and privacy advisor spoke at HIMMS11 this week. In addition to confirming that the final privacy, security and breach notification rules will be issued simultaneously in 2011, he got everyone’s rapt attention by announcing increases in financial penalties for privacy and security violations. This raises the security stakes considerably. The penalty for a single violation will be increased to $50,000 with a maximum penalty per year of $1.5 million per each provision of the rules. Since many breach incidents can include multiple violations, the corresponding fines could be huge.

Further, OCR is expanding the requirements for business associates. They will now assume direct liability for adhering to privacy and security rules 240 days after the final rules are issued. Subcontractors will also be held to the same standard as business associates. Currently business associates can only be found directly liable under the breach notification rule.

While it’s been publicly reported that over 220 organizations have suffered large data breaches (each impacting >500 individuals), we also got the stunning details that the OCR has been notified of more than 14,000 smaller breaches of PHI (each affecting <500 individuals).

As we noted in Redspin’s 2010 Protected Health Information Breach Report, theft or loss of portable devices such as laptops caused >65% of large breaches. But portable media is here to stay. Instead of trying to restrict where sensitive data is taken, adopt a more data driven view and protect it where it is stored. Solutions like Imation’s Defender product line (encrypted storage: flash, external hard drive and optical) may be right for your organization.

Clearly OCR also understands that business associates are data rich targets and will likely encounter an increase in malicious activity. At present, covered entities must extend their oversight of their business associates IT environment and security posture. This should be included in the CE’s HIPAA Risk Analysis. And with the impending extensions of direct liability to business associates, those organizations should also start preparing to conduct security assessments of their own. And sooner not later.

Of course, at Redspin we think every organization that handles ePHI should have a process in place for external security testing, remediation, validation and retesting. As security consultants, you may think our view is self serving but we consider it an issue in the common interest. After all, even security consultants are healthcare patients at one time or another! We’re all in the same boat – when malevolent storms or hackers strike, we want to avoid data leakage and protect our privacy. So “batten down the hatches – quick men!” (Chambers Journal, 1883)

Unreal Repeal: Healthcare Reform and HITECH

Posted on January 24, 2011 by Dan Berger in Main | 2 Comments

Last Wednesday, Republicans in the House of Representatives (+3 Democrats) voted to repeal the health-care reforms signed into law by President Obama less than 1 year ago. Although the 245-189 vote made good on a GOP mid-term election promise, it was largely symbolic. The Senate is not likely to consider (much less pass) the bill, nor would it ever get past an Obama veto.

Yet, reform of reform is in the air. Spending cuts as the path to deficit reduction are mentioned in every news cycle. It’s possible that congressional budget maneuvering will decrease or delay funding for some of the provisions of Obama’s Health Plan (The Patient Protection and Affordable Care Act).

Thus, it’s not surprising that some healthcare IT professionals wonder if the potential $29 billion in EHR meaningful use incentive payments promised under the HITECH Act are secure. During our January 20th webinar “Assessing HIPAA/HITECH Risks:  What You Need to Know,” I was asked this question several times.

My response? I believe that the HITECH Act will proceed as planned with full funding. Here’s why:

1)      HITECH was passed as part of the American Recovery and Reinvestment Act (ARRA) and not part of Obama’s healthcare reform initiative. It had broad bi-partisan support. As Allscripts Healthcare Solutions CEO Glen Tullman told the Wall Street Journal Health Blog, “Healthcare IT is a nonpartisan issue.”

2)      The goal of HITECH was to create jobs and begin a massive overhaul of the US healthcare system. Right after the mid-terms, Politico healthcare reporter Jennifer Haberkorn addressed a HIMSS press briefing and said cutting back HITECH was “not on the radar. The attitude on [Capitol] Hill is that health IT funding is creating jobs.”

3)      In addition to creating jobs, HITECH provides the foundation for an even broader national economic goal: increasing the efficiency and competitiveness of the U.S. healthcare system in one of the worlds’ largest and fastest growth industries (over $2.2 trillion dollars in expenditures per year).

For these reasons and others, I think HITECH funding is safe for now. That said, I urge covered entities to make achieving Stage 1 “meaningful use” of electronic health records, including conducting a HIPAA Risk Analysis, among their highest priorities. The best guarantee for “staying the course” is the success of the program itself.

Business Associates: The HITECH Act requires BAs to be compliant with the HIPAA Security Rule – that’s a good thing.

Posted on January 17, 2011 by John Abraham in Main | 1 Comment

Managing vendors and business partners is hard in any industry, but when the data is sensitive ePHI, you are trying to achieve EHR meaningful use and there are penalties like the HITECH Act’s breach notification requirements, it can be even more daunting.

Fortunately, one aspect of the HITECH Act can minimize security risk and facilitate managing Business Associates (BAs). Under the HITECH Act Business Associates need to be compliant with the HIPAA Security Rule. According to the HITECH Act Section 13401(a):

“Sections 164.308, 164.310, 164.312, and 164.316 of title 45, Code of Federal Regulations, shall apply to a business associate of a covered entity in the same manner that such sections apply to the covered entity.“

This means that a Business Associate is required to comply with the administrative, physical and technical requirements of the HIPAA Security Rule as well as with the HIPAA policy, procedure and documentation requirements. This is a good thing because it provides a defined set of standards for BAs to follow. This also provides better criteria for a covered entity to evaluate if the BA is effectively protecting ePHI. Prior to the HITECH Act managing security of ePHI fell upon the covered entity in the form of a Business Associate agreement. The HHS sample template for Business Associate agreements shows how ill-defined this could be

“Business Associate agrees to use appropriate safeguards to prevent use or disclosure of the Protected Health Information.“

The problem with this approach is that, while it sets some contractual expectations of protecting PHI, it does not:

  • set standards as to how that data is protected, and it does not
  • provide a baseline for validating if Business Associate are actually following the standards.

In our experience as security auditors doing health IT security assessments and risk analysis, we understand that both setting standards and validating to ensure these standards are met, are necessary. The reason is that, while it is easy to specify minimum control standards, actually living up to these standards is much harder. Here are some practical examples of how the documented security standard within an organization can be quite different than the actual security provided, even for the most basic controls:

Example 1: encryption of ePHI

If you poll your Business Associates and ask: are you using full-disk encryption for all laptops? Most likely, they’ll answer yes. However, during an assessment, if you dig a little deeper, you will find, for example, that many laptops are in sleep mode, rather than turned off, so the disks are not necessarily encrypted during travel. Furthermore many laptops will use directory level encryption instead of full-disk, which is just fine in theory, however, when you analyze them, you will find that ePHI is stored outside of the encrypted directory.

Example 2: virus protection

Ask a Business Associate – are you using virus protection? – and they’ll all say yes – because of course they are… everybody is these days. However, if you dig a little deeper, you will find many workstations that are not using up to date virus signatures because the user inadvertently turned off the auto-updating or the anti-virus client is not synced to the correct update server.

Example 3: patch management

Ask any health IT professional that works at a Business Associate about system patching? – and they’ll say yes of course we patch everything so all of our software is up to date. However, some in depth analysis will often show that, while operating system patching is fairly consistent, there is a significant lack of patching for 3rd-party applications on servers, workstations and laptops alike.

Other common examples of controls that exist but are not as effective as intended include: wireless networks, mobile devices, and network segmentation (such as attempts to partition ePHI via DMZs and internal firewalls). Now the discrepancy between the existence of these controls and the effectiveness of the controls does not imply some malicious intent by the Business Associates. To the contrary, they most likely have implemented these controls with the best of intentions. However, as anyone who works in a health IT environment knows, there are limited IT resources and too many things to do, and sometimes there is not enough resource cycles left to verify that controls are working as intended. So the upside of the HITECH Act requiring Business Associates to comply with the HIPAA Security Rule is that it will provide a more defined set of standards by which covered entities can evaluate Business Associates, and also for Business Associates to evaluate their own internal security.

In the end this could mean:

  • better protection of ePHI,
  • improved compliance with the “protecting electronic health information” core objective of meaningful use, and
  • reduced chance of a breach notification event under the HITECH Act.

These are good objectives for everyone!

Download a Business Associate Questionnaire to insure your BAs are effectively protection ePHI

REDSPIN CHIMES IN ON MEANINGFUL USE

Posted on January 14, 2011 by Dan Berger in Main | Leave a comment

A few days ago, members of the College of Healthcare Information Management Executives (CHIME) testified before a federal panel in Washington, D.C. The hearing was entitled “Real World Experience Working with Meaningful Use.” The panel consisted of members of the Implementation Workgroup of the HIT Standards Committee, who in turn report to David Blumenthal, M.D., HIT’s national coordinator.

CHIME representatives shared their direct experiences mainly to convey the challenges hospitals are facing in meeting the HITECH requirements for achieving “meaningful use” of electronic health records. Not coincidentally, the meeting was assembled about a week after the January 3rd registration opening for the Medicare and Medicaid electronic health record (EHR) incentive programs. The money is now available and qualifying healthcare entities could start receiving payments as early as April or May.

Shortly after becoming HIT’s national coordinator Dr. Blumenthal reinforced that achieving the vision of “an interoperable, national health information system” will require unprecedented collaboration between the public and private sector. Last week’s CHIME meeting panel meeting was an attempt at doing just that.  Think of it as “Policy, meet real world. Real world, meet policy.”  CHIME is an executive organization that serves CIO’s and other senior healthcare IT leaders. In includes more than 1,400 CIO members and over 70 healthcare IT vendors and professional services firms. In meeting with HIT Workgroup, the CHIME delegation hoped that by bringing real word experience with EHR to the committee, they will have some impact on the final qualifying criteria for approving “early adopters” of meaningful use (translation: “please lower the bar, particularly for those organizations that have already spent significant time and resources to achieve the goal.”)

Summarizing CHIME’s input:

1.       Revamp meaningful use reporting: The current reporting requirements for achievement of objectives and quality measures are onerous, difficult and time-consuming.

2.       Create a different achievement-level criteria for smaller facilities who typically have smaller IT staffs and/or need to rely on outside vendors to provide services the incentive qualifications consider to be full time positions.

3.       Take into consideration the balance between autonomy and collaboration, particularly when it comes to the requirement to provide for “HIE use cases” showing EMR has been built into physicians workflow. At the individual physician office level, many want to choose their own technologies, but then also expect to be able to send and receive data at will. There is a definite IT knowledge gap here as many physicians don’t actually understanding what’s necessary to ensure all of these systems can “talk” to each other.

At Redspin, we were pleased to see that CHIME did not call the security provisions of meaningful use “onerous, difficult and time-consuming.” In fact, they did not mention security. We’ll take that as full support of its necessity or at least tacit acceptance. Thus, those early adopters should be moving urgently to perform a security risk analysis in accordance with the requirements of 45 CFR 164.308(a)(1). The rule also requires implementation of security updates as necessary and correcting identified security deficiencies as part of its risk management process. From Redspin’s experience with other regulatory compliance areas, we know there will be some lee-way regarding the corrective aspect of the requirement. But at a minimum, healthcare organizations who want to qualify for Stage 1 and start receiving incentive payments as early as possible must: a) identify security risks, b) have remediation efforts underway, and c) put in place an ongoing risk management process. A HIPAA Risk Analysis is the only way to start this process.

HIPAA / HITECH Act – A Practical Approach to Meaningful Use Risk Analysis

Posted on January 10, 2011 by John Abraham in Main | Leave a comment

With the federal EHR incentive program kicking off, is your organization scrambling to achieve meaningful use criteria for your EHR systems? Given all the questions we’ve been hearing about how healthcare organizations can effectively address the meaningful use requirements, I thought I would share a practical approach to addressing the core objective: protect electronic health information.

In order to meet the requirements, its important to first understand the specific criteria defined by the CMS. As we noted previously, to meet the criteria to protect electronic health information, a healthcare organization must:

  1. perform a security risk analysis in accordance with the requirements under 45 CFR 164.308(a)(1) and
  2. implement security updates as necessary and correct identified security deficiencies as part of its risk management process.

Good news, bad news; the bad news is that these two requirements in essence state that an entity must have both identified AND mitigated all of their security risk around ePHI / EHR – a herculean task for any organization. The good news is that the CMS leaves plenty of latitude in how to achieve these requirements. In fact, while they provide guidance in the form of references to the HIPAA Security Rule, they make clear their intent: to identify security risk to ePHI in terms of confidentiality, integrity and availability,  and implement controls to mitigate risk. Fortunately, these are key ingredients of any successful information security program.

By focusing on the spirit and intent of the requirements and understanding that they really just define the most basic elements of widely accepted “best practice” information security process, healthcare entities can systematically achieve  a number of objectives concurrently, including:

  • meaningful use core objectives,
  • HIPAA Security Rule compliance, and
  • systematically reduce security risk  - i.e. protect ePHI so you don’t land on the HHS HITECH Act Data Breach Notification website (per section 13402(e)(4) of the HITECH Act).

In fact, you can achieve these objectives cost-effectively if you focus on a systematic information security process. Here is what we recommend to meet both the intent and letter of the requirement. Focus on these core steps to achieve an effective HIPAA Risk Analysis:

  • Gap Analysis: Analyze how your processes, policies and procedures measure up to the standards defined the Security Rule of the Administrative Provisions set forth in Title II of HIPAA. Specific tasks associated with benchmarking your organization to the Security Rule are documented here.
  • IT Security Assessment: Provide a comprehensive analysis of your IT infrastructure and operating environment to determine how well your policy and technical controls are working and identify potential vulnerabilities which could put protected information at risk.

By focusing on key areas of risk and HIPAA Security Rule deficiencies, your organization can focus on the most important factors that achieve security and compliance with the “protect electronic health information” requirement. With diligent focus on the most important issues, many health IT teams should find compliance – still daunting perhaps – but achievable.

Meaningful Use, Risk Analysis and Protecting Electronic Health Information

Posted on January 4, 2011 by John Abraham in Main | 1 Comment

Registration begins this week for the Medicare and Medicaid Electronic Health Records (EHR) incentive programs. With the programs contingent on “meaningful use” of certified EHR technology, the big question now is how to achieve meaningful use. According to a mid-november survey by the College of Health Information Management Executives (CHIME) released on December 9, 2010, this won’t be easy:  “The vast majority of CIOs– 82 percent – report that they still continue to have concerns related to meeting meaningful use objectives and qualifying for stimulus funding.”

The Centers for Medicare & Medicaid Services (CMS) which administers the programs for the U.S. Department of Health & Human Services, will phase into meaningful use by defining 3 sets of criteria for achieving meaningful use over the next 5 years. The requirements for Stage 1 of meaningful use are defined by the CMS. While these vary for eligible professionals or eligible hospitals and critical access hospitals (CAHs), protecting electronic health information is a core objective that must be met to achieve EHR meaningful use for any entity.

CMS defines this core objective as follows:

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.

A risk analysis is called out in 45 CFR 164.308 (a)(1)(A) as follows:

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.

HHS has provided some guidance on Risk Analysis which allows for some interpretation for compliance as noted in the following excerpts:

The guidance is not intended to provide a one-size-fits-all blueprint for compliance with the risk analysis requirement.

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

The upside of the latitude provided is that if the spirit and intent of the Risk Analysis is maintained as an objective, a healthcare entity can leverage practical and cost effective approaches to achieving HIPAA Security Rule compliance, meaningful use, as well as minimize the risk of a HITECH Act data breach notification.

Here are a couple of resources for effective approaches to addressing the Risk Analysis requirement for meaningful use:

The diagram below adds some perspective to the Security Rule and Risk Analysis as it relates to HIPAA.


Patient Consent Policy Guidelines to Support Meaningful Use of Stage 1 Data Exchange

Posted on August 27, 2010 by John Reno in Main | Leave a comment

Last week the ONC privacy and security tiger team for the healthcare IT committee provided guidance on patient consent policy. Summary slides of their recommendations can be found here and the full documentation can be found here. These guidelines are important because the recommendations apply to electronic exchange of patient identifiable health information among known entities to meet Stage I of meaningful use — the requirements by which health care providers and hospitals will be eligible for financial incentives for using health information technology. This includes the exchange of information for treatment and care coordination, certain quality reporting to the Centers for Medicare & Medicaid Services (CMS), and certain public health reporting.

The requirements for supporting meaningful use of stage 1 data exchange consist of both core set and menu set transactions as outlined below:

1. Provide patients an electronic copy of their ambulatory, ED or inpatient summary of care record.

2. Transmit prescriptions.

3. Exchange clinical information among care providers and patient authorized entities.

4. Report clinical quality measures.

Menu Set

5. Incorporate clinical lab tests results into EHRs as structured data.

6. Provide summary of care record for patients referred or transition to another provider or setting.

7. Capability to submit data to immunization registries, provide surveillance and lab data to public health agencies.

Hopefully these national guidelines will reduce duplication of work that has been occurring at the state and regional level and accelerate the meaningful use of HIT and most significantly ensure that patient privacy is protected.

The final rule on meaningful use – an opportunity for healthcare process improvement and security program development

Posted on July 17, 2010 by John Reno in Main | Leave a comment

Earlier this week the CMS and ONC released the final Standards Rule for meaningful of electronic health records. This culminates a process in which the ONC received thousands of comments and struggled to reach a balance between specificity (presumed to make certification and implementation a simpler task) and generalization (which can enable more rapid innovation).

An analysis of the requirements can be daunting. For those who choose to go through the details of the requirements, key resources can be found at the Federal Register. Specifically, the Federal Register publication of the Meaningful Use regulation and the Federal Register publication of the Standards regulation. I have found the most useful summary in a recent article in the New England Journal of Medicine by David Blumenthal and Marilyn Tavenner. This reference includes a table with a summary overview of meaningful use objectives and their respective measures. This is a concise and useful description of the 15 core requirements for Eligible Professionals and the corresponding 14 core requirements for hospital organizations as well as the 10 discretionary requirements (of which 5 must be chosen). I have also put together a presentation regarding meaningful use that you may find helpful. Feel free to download it here.

From a security, privacy and compliance standpoint the implications of the final Standards Rule are quite significant. One of the core requirements sets a specific goal: implement systems to protect the security and privacy of patient data in the EHR. The corresponding measure calls for organizations to conduct a security risk analysis, implement security updates and correct identified security deficiencies.

A closer look at the security and privacy rules shows that the most prescriptive requirements involve transport layer security, message integrity and auditing/logging. Key highlights from the regulations are outlined below:

Encryption and decryption requirements for use of electronic health information

Usage guidelines – Any encryption algorithm identified by the National Institute of Standards and Technology (NIST) as an approved security function in Annex A of the Federal Information Processing Standards (FIPS) Publication 140-2.

Record actions related to electronic health information

The date, time, patient identification, and user identification must be recorded when electronic health information is created, modified, accessed, or deleted; and an indication of which action(s) occurred and by whom must also be recorded.

Verification that electronic health information has not been altered in transit

Standard – A hashing algorithm with a security strength equal to or greater than SHA-1 (Secure Hash Algorithm (SHA-1) as specified by the National Institute of Standards and Technology (NIST) in FIPS PUB 180-3 (October, 2008)) must be used to verify that electronic health information has not been altered.

Record treatment, payment, and health care operations disclosures

The date, time, patient identification, user identification, and a description of the disclosure must be recorded for treatment, payment, and health care operations, as these terms are defined at 45 CFR 164.501.

Now, let’s look at what this will mean in the healthcare community with a focus primarily on security, privacy and compliance programs. By now, I think most vendors and providers in the healthcare industry segment realize that the transition to widespread adoption and meaningful use of electronic health records is an opportunity for a major overhaul and upgrade of their workflow processes and the IT systems that support those processes. Many people in the healthcare community that I have talked with view this as similar to the challenges faced in the 80’s and 90’s when businesses transitioned to ERP systems. The transition can be a source of major disruption and pain, but ultimately a source of competitive advantage and business agility.

The transition should also be viewed as an opportunity for major enhancements to security, privacy and compliance programs. Information security stakeholders at healthcare organizations need to look at the transition to meaningful use of electronic health records not simply as a set of requirements that call for risk analysis, encryption and auditing/logging, but an opportunity to modernize their information security programs, revitalize governance mechanisms and institute risk management as a core, ongoing process. Pragmatically, healthcare organizations must also realize that for the next 12 to 18 months EMR vendors will be focusing on certification as their number one priority. Certification is a necessity for meeting the requirements of the meaningful use rule and a business driver for the EMR vendor community. Realistically, this means that security will not be the priority that it should be. As a result, more of the burden of systems and application security will fall on the shoulders of deploying organizations.

In summary, the transition to meaningful use of electronic health records is a very ambitious program. The most successful organizations will look to set their own goals and invigorate their security, privacy and compliance programs.

« Previous   1 2