•

» Healthcare IT security

Inspector General Takes ONC to Task Over Lack of General Security Controls

Posted on May 18, 2011 by Dan Berger in Main | 1 Comment

We wouldn’t be so bold as to say “I told you so,” but for months Redspin has been publicly calling on the ONC to beef up the security controls and measures in the “meaningful use” EHR incentive plan, the Federal Strategic Health IT Plan, and the HIPAA Security Rule itself. In fact just two weeks ago, we offered the following public comments on the Strategic Plan:

“Next, the “security risk analysis” identified as Core Measure 15 should be defined as more than compliance with the HIPAA security rule. Effective security is a process-driven cycle of regularly-scheduled assessments, validation, remediation, and reporting that deliver continuous and durable improvements in information security and help develop a culture of security awareness within organizations.” (Public Comments on Federal Strategic Health IT Plan, 2011-2015)

Now this week, we learn the HHS Inspector General has audited HIT Standards, privacy protection under HIPAA, and other security measures at CMS and the ONC. Their conclusion? “OIG found weaknesses in the two HHS agencies entrusted with keeping sensitive patient records private and secure.”  Such weaknesses included lax oversight and insufficient standards for healthcare providers.

The CMS audit examined seven hospitals across the country and found 151 “vulnerabilities” in systems and controls that are designed to safeguard electronic protected health information. Those lapses included 124 “high impact vulnerabilities” such as unencrypted laptops and portable drives containing sensitive personal health information, outdated antivirus software and patches, unsecured networks, and the failure to detect rogue devices intruding on wireless networks. As a result, CMS had limited assurance that controls were in place and operating as intended to protect electronic protected health information, thereby leaving ePHI vulnerable to attack and compromise.”

This is exactly why Redspins’ HIPAA Risk Analysis and Security Assessments go well beyond the requirements laid out by the CMS and ONC. And why hospitals, health systems and large provider practices should carefully consider which vendor they select to perform their assessment service. This is not “check the box” type of audit work. This is not something you can entrust to one-man consulting shops.  There are serious implications to leaving ePHI vulnerable to attack and compromise. Sure the ONC should be more specific in regard to specific preventative controls or standards in the regulations. But whether stated in the regulations or not, you as a hospital or business associate bear the ultimate responsibility for data breach. We urge you to hold any outside security assessment vendor (including Redspin) to a higher standard. Don’t settle for competence; seek out excellence.

 

Building Assurance through HIPAA Security, Washington D.C., May 10th-11th

Posted on May 15, 2011 by Dan Berger in Main | Leave a comment

Last Monday night, I boarded a “red-eye” flight from LAX to Dulles to attend the OCR/NIST HIPAA Security Conference. I landed at 6:15AM, did a quick change into my business attire, grabbed some coffee, rented a car, and found my way to the Ronald Reagan Building at 1600 Pennsylvania Avenue, 3 blocks from The White House. I thankfully arrived just before the breakfast buffet ended and took a seat at the back of the conference ballroom.

The room was packed with 400+ attendees – literally standing room only until the conference organizers could arrange for more chairs to be brought in. The congregation included providers, government policy-makers, healthcare lawyers, academics, vendors, and consultants.  From the start of the conference at 9AM Tuesday morning to well after 4PM Wednesday afternoon, there was a sense of purpose in the air. Healthcare IT transformation is well underway and IT security will play a major role in whether or not we, collectively, succeed as an industry, as a major part of the U.S. economy and as a country.

While I gained a wealth of information and education from this conference, I want to summarize a few of the most important “take-away” items here.

-   The development of Stage 2 “meaningful use” requirements is well underway.  Security will remain a key focus. New providers will be expected to conduct a HIPAA security risk analysis (SRA) and Stage 1 qualifiers will be ask to “update and re-assess” the previous SRA they completed in order to meet Stage 1 attestation.

-  While still likely stopping short of mandating encryption, Stage 2 meaningful use will also “shine a spotlight” on the security of data at rest, according to Deven McGraw, co-Chair of the HIT Policy Committee “Tiger Team” and Director of the Health Privacy Project at the Center for Democracy and Technology.

-  A batch of final regulations dealing with healthcare privacy and security issues will be issued in one “Omnibus” package to be released this year and likely within months, if not within weeks. This will include:

  • HITECH Act modifications to the HIPAA privacy, security and enforcement rules.
  • The final version of the breach notification rule, replacing the current interim version.
  • Formalizing privacy provisions under the Genetic Information Nondiscrimination Act that forbids use of genetic information for insurance underwriting and categorizes such use as a violation of both privacy and non-discrimination regulations.

-  Sue McAndrew, Deputy Director for Health Information Privacy at the Office of Civil Rights (OCR) called the HIPAA security risk analysis provision a foundational element of HITECH, along with updating the SRA regularly and implementing reasonable and appropriate safeguards.

-  Ms. McAndrew further confirmed and clarified that business associates and their subcontractors will have the same obligations as covered entities under the HIPAA Security Rule and therefore must conduct their own HIPAA security risk assessments. Within 12 months from the issuance of the Omnibus NPRM, business associates will be directly liable for the breach of protected health information (PHI) under HITECH Act sections 13401 and 13404.  She went on to describe this extension of directly liability to business associates “a sea change” in the regulations.

-  Stepped-up enforcement of the HIPAA security and privacy provisions is on the way. Federal enforcement training of State Attorneys Generals offices was done in Texas this past April, and will be conducted in Atlanta and Washington D.C. by end or May and in San Francisco in early June.

 

Public Comments on The Federal Health IT Strategic Plan, 2011-2015

Posted on May 6, 2011 by Dan Berger in Main | Leave a comment

One of the ONC’s key responsibilities is to provide strategic leadership to the public and private sector. Mandated under the HITECH Act of 2009, the ONC must publish and update its strategic plan for improving healthcare through the use of information technology.

The Federal Health IT Strategic Plan, 2011-2015, first released in draft form in March 2011, paints a rapidly evolving health IT landscape. It sets 5 overriding goals for “unlocking the vast promise of electronic health information to improve decision making, help individuals better manage their health, and improve the health system’s capacity for rapid learning.”

Making this plan public and in fact, inviting public comment, is helpful to the cause. It gives the ONC a vehicle to communicate priorities, solicit input, guide efforts and influence allocation of resources.

With the close of the public comment period today (5/6/2011) and in advance of next week’s NIST/OCR HIPAA Security Rule Conference in Washington, D.C., I felt this was an opportune time to publicly self-publish my public comments! Here goes:

The Blumenthal era smartly focused success around the concept of “meaningful use,” first as a measure of electronic health record (EHR) adoption and usage, and later as a rallying cry for IT health transformation in general.

Usage is, after all, tantamount to success. And the converse is also true. “No one knows how many computer-based applications designed at great cost of time and money are abandoned or expensively overhauled because they were unenthusiastically received by the intended users.” (“Power, Politics, and MIS Implementation,” M. Lynne Markus,  M.I.T. June 1983)

This is a critical point. The draft Health IT Strategic Plan has, as its ultimate end-goal, improved patient outcomes. This goal cannot be achieved without widespread public adoption of EHR’s. But does the Strategic Plan do enough to address the potential pitfalls and impediments that could undermine EHR usage?

In my opinion, no. Security and privacy requirements must be made more prominent both in the plan and in practice, with more stringent, regular testing and reporting.  Although security and privacy are one of the 5 primary goals of the Plan, the topic commands only 6 pages of the 80-page document (pp 29-35). Also by being listed as Goal number 3 out of 5, the implication is these critcial issues are third in priority or third in time sequence.

While perhaps an unintended impression, it still conveys the wrong message. Privacy and security are not simply goals; they are foundational to adoption and usage. Thus they are necessary conditions for achievement of all of the other 4 primary goals, and of any continued advancements of the health IT agenda.

Even the language used in describing “Goal III” is tepid (“stepping up protections,” “discussing major investment in education and outreach”). Notably absent are calls to action that inspire real commitment to regular monitoring and measuring, self-enforcement, and driving continuous improvement.

Perhaps the ONC believes that more stringent breach notification requirements and increased financial penalties will act as “an invisible economic hand” that guides healthcare providers to implement reasonable and appropriate measures to safeguard ePHI. But a fully comprehensive strategic plan must also include contingency planning – what if breaches continue to increase despite strict breach notification rules and more costly penalties?

And how does the ONC address the inherent incongruity of requiring public breach notifications for large incidents (500 records or more), while aiming to “inspire confidence and trust in health IT.” How can the health care industry combat the undermining of public trust by being forced to publicize its biggest failures? Personal notification for those impacted is an obvious necessity but is there a cumulative psychological impact to frequent breach PR’s, a repetitive stress injury to the ultimate goal if you will.

We suggest immediately elevating privacy and security to a higher plane. Rather than a goal, make it as foundational an element as meaningful use, the bedrock of the strategic plan. At Redspin, we suggest calling it “Meaningful Healthcare IT Security.” In fact, we’ve applied to trademark the tagline, not for any proprietary purpose, but to make a point. (We’ll gladly license its use to the ONC for free).

So what is “Meaningful Healthcare IT Security?” First, it’s an acknowledgement of the complex challenges healthcare organizations face in meeting the sophisticated levels of privacy and security necessary to protect the public. This will not simply materialize out of the “carrot and stick” approach of incentive payments and breach penalties. Second, privacy and security need to be understood as pre-conditions to meaningful use not just a “part of.”

Next, the “security risk analysis” identified as Core Measure 15 should be defined as more than compliance with the HIPAA security rule. Effective security is a process-driven cycle of regularly-scheduled assessments, validation, remediation, and reporting that delivers continuous and durable improvements in information security and helps develop a culture of security awareness within organizations.

We want to help meet the ONC’s ultimate goal of improving patient outcomes “by unlocking the vast promise of electronic health information.”  But we don’t want to leave any doors unlocked that should be protecting privacy and security.

To Audit Or Not To Audit: If A Business Associate Is In Violation Of The HIPAA Security Rule And No One Knows, Does It Matter?

Posted on April 1, 2011 by John Abraham in Main | Leave a comment

There has been some debate as to the extent that a covered entity (CE) should audit a business associate (BA) to ensure that they are compliant with the HIPAA Security Rule and adequately safeguarding customer PHI. While I don’t offer up the answer to that question, I thought it made sense to explore some of the surrounding issues.

Some of the key factors that come to mind are:

Monetary Penalties

The HITECH Act creates “several categories of violations that reflect increasing levels of culpability” for HIPAA violations. There are four tiers of fines: $100 (“did not know”), $1,000 (“reasonable cause”), $10,000 (“willful neglect – corrected”), $50,000 (“willful neglect – not corrected”) per violation. In each tier there is a minimum fine of $50,000 per incident and a maximum fine of $1,500,000 per calendar year. As these fines are calculated per violation, with each record exposed, in the case of a data breach for example, counting as a violation, the fines can be significant. Of course, the actual fine amount is a function of the culpability. According to the HITECH Act: “in the case of a violation where it is established that a covered entity did not know of the violation and would not have known through the exercise of reasonable diligence” the lowest tier of $100 would apply.

If minimizing monetary penalty risk is a primary objective, then performing “reasonable diligence” might be the recommended approach. Though defining “reasonable” is another question.

Security

If security is your objective and protecting your client data is an important ideal, then you might define reasonable in another way. For example, if most of your patient records are accessible by one particular BA then it could be that the bulk of the CEs data security risk is really encapsulated in a single BA – and perhaps extra care might be taken to ensure the BA has an effective information security program in place. In this case you might call for the BA to perform some type of security assessment or HIPAA Risk Analysis.

Practical Business Management

Another issue is the case of a BA with the following attributes: they provides a critical business function for the CE, they have extensive access to PHI and they are difficult to swap out with another vendor. In this case it’s a question of – do I really want to know if they are in non-compliance? This is a tough question. In the best case you’d identify a critical area of security risk or non-compliance, notify the BA and then they’d fix it. But what if they don’t fix it?

Pure Capitalism

Besides the monetary fines, how else might a security incident impact revenue? Well that depends on the extent that the CE is commoditized. In the banking sector, for example, it is very easy for a customer to move from one institution to another, so a security breach can cause a wave of customer defections. If you are the only hospital in town, for example, then perhaps this is less of a risk. Other brand damage due to a security breach is more difficult to quantify.

Summary (AKA what is “reasonable”)

So perhaps its all about “reasonable due diligence”. This will depend on how each individual CE prioritizes how a security breach impacts their business and compliance responsibilities. And it will surely be the subject of extensive interpretation by both the courts and BAs (when contract liability is being litigated).

The Federal Health IT Strategic Plan and the Final Four

Posted on March 28, 2011 by Dan Berger in Main | Leave a comment

I just finished reading the ONC’s (Office of the National Coordinator for Health Information Technology) draft document The Federal Health IT Strategic Plan (“the Plan”) while watching the Butler-Florida game in the quarterfinals the 2011 NCAA Championships.

One of the ONC’s key responsibilities is to provide strategic leadership to the public and private sector. Mandated under the HITECH Act of 2009, the ONC is must publish and update its strategic plan for improving healthcare through the use of information technology. Making this plan public and in fact, inviting public comment, is helpful to the cause. It gives the ONC a vehicle to communicate priorities, guide efforts and influence allocation of resources. What’s not quite clear is how frequently the ONC is required to update the plan. The last plan was dated June 3, 2008 and covered the 5 year period 2008-2012. This latest plan is intended to cover 2011-2015. Is that sufficient? Let’s turn to basketball for a moment. .

While watching Butler beat Florida, I noticed how frequently the TV commentators used the word “adjustment” to describe mid-game coaching decisions. At this level of competition, both teams clearly started the game with a strategy for winning. So did these adjustments or tactical maneuvers reflect changes in their strategy? No. Theoretically, the development of a comprehensive strategy should include contingency planning (e.g. If X happens, do Y; if A occurs early, respond with B). Butler’s strategic plan to win the game included limiting Florida’s ability to score from the 3-point range. Yet, even having achieved that, they were losing by 11 points with 9 minutes left in the game. Contingency time. Since star player Matt Howard was in no danger of fouling out of the game, Butler could risk having him play very aggressively during the games final minutes. The strategy with contingency plan was successful. Game won.

How is this relevant to The Federal Health IT Strategic Plan? Last published in 2008, I’ll give the updated plan points for “adjusting” to the rapidly changing landscape of health IT. The past few years were marked by truly major legislation – the HITECH Act and the Patient Affordable Care Act have galvanized  organizations throughout the industry; each mapping out their own specific organizational goals and initiatives.  We are now on the verge of dramatic changes. With that, the ONC’s new 5-year plan builds on the foundation of meaningful use (both as a rallying cry and as a measure of electronic health record (EHR) adoption and information exchange), with the ultimate goal of improving health care outcomes.

The Strategic Plan sets 5 overriding goals for “unlocking the vast promise of electronic health information to improve decision making, help individuals better manage their health, and improve the health system’s capacity for rapid learning.” These goals are listed below:

  • Goal I, the health information exchange strategy focuses on first fostering business models that create health information exchange, supporting exchange where it is not taking place, and ensuring that information exchange takes place across different business models.
  • Goal II, we discuss how integral health IT is to the National Health Care Quality Strategy and Plan that is required by the Affordable Care Act.
  • Goal III, we highlight efforts to step up protections to improve privacy and security of health information, and discuss a major investment in an education and outreach strategy to increase the provider community and the public’s understanding of electronic health information, how their information can be used, and their privacy and security rights under the HIPAA Privacy and Security rules.
  • Goal IV, we recognize the importance of empowering individuals with access to their electronic health information through useful tools that can be a powerful driver in moving toward more patient-centered care.
  • Goal V, we have developed a path forward for building a “learning health system,” that can aggregate, analyze, and leverage health information to improve knowledge about health care across populations.

Admirable. But is it a winning strategy? Since the ONC has asked for public comment, I’m going to give it. In the 80-page document, only 6 pages are dedicated to privacy and security (pp 29-35), nowhere near sufficient. Also, efforts to improve privacy and security are listed as Goal #3 on a list of 5. This gives this very important topic the imprimatur of being either third in priority or third in time sequence. Even if an unintended impression, it is at best misleading as privacy and security are necessary conditions for achievement of all of the other 4 goals. Also to be fully comprehensive, the ONC’s Strategic Plan must address contingencies – what if breaches continue to increase despite more stringent breach notification rules and more costly penalties? How can the industry combat the undermining of public trust by publicizing its failures?

I’d suggest elevating privacy and security to a higher plane. Rather than a goal, make it as foundational an element as meaningful use. I’m be submitting my more formal comments by the April 22 deadline via the HSS ONC Health IT Buzz Blog – accessible at http://www.healthit.gov/buzz-blog/from-the-onc-desk/hit-strat-plan/#comment Meanwhile I’d love to hear your thoughts on how we can make privacy and security the bedrock of the strategic plan. Perhaps we can borrow from the “Butler Way,” and agree that the mission to transform healthcare IT “demands commitment, denies selfishness, accepts reality yet seeks improvement every day, while putting the team above self.” This is a game we can’t afford to lose. Go Bulldogs!

8 “Simple” Rules for Protecting PHI

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

In the popular TV series: “8 Simple Rules for Dating My Teenage Daughter,” the rules may have been a bit exaggerated but they sure made their point. (Rule #1: Use your hands on my daughter and you’ll lose them after). Likewise, my “8 Simple Rules for Protecting PHI” strike a similar chord – no threats to bodily harm, but certain transgressions may be bad enough to result in personnel sanctions or even loss of employment. This is serious stuff.

And as with the dating commandments, my 8 rules for safeguarding PHI are not simple but they are doable – provided you can engender operational discipline throughout your enterprise and extend that influence over important business partners. This always requires a 100% commitment to security at the highest level of your organization. But that really shouldn’t be an issue. After all, breach notification rules are strict and the monetary penalties high enough that survival of your business may literally depend on it.

Rule #1: Maintain a comprehensive PHI inventory within your organization and your business associates. You need to know everywhere under your direct and indirect control where protected health information “lives.” This includes both structured and unstructured data in ePHI, records replicated in multiple places, paper files etc.

Rule #2: Establish a data classification model and assign levels of sensitivity. While many government agencies use a 5-level model (or even more), a 2 or 3-tiered system should be sufficient to start with.

Rule #3: Map how ePHI travels during normal workflow. Ensure that compatible security controls exist at both ends of each data transfer. Then do an additional exercise looking at how ePHI might need to be transferred during exceptional events or in crisis management situations. Apply the same safeguards.

Rule #4: Develop access control policies balancing “need to know” without compromising patient care. Then implement and enforce those policies and controls systematically so that software applications, database rules, and personnel restrict access to sensitive information to only people and/or other software programs that have been specifically granted access rights.

Rule #5: Monitor and audit all access to ePHI (include read-only, data changes, privileged activity such as changes to data structures and changes to user access rights).

Rule #6: Conduct internal vulnerability testing and an assessment of current security measures (controls testing). These are components of the risk analysis process that everyone should be working on. If you don’t have the skill set in house, bring in a qualified outside vendor. Expert security firms can add more technical depth to your analysis. Establish a regular, repeatable, ongoing security assessment process that enables you to adapt to new changes in technology, people, systems, business relationships and workflows. Make certain the process maintains historical data so that management can see progress over time.

Rule #7: Implement an ongoing security awareness campaign and regular training program that fits your culture, yet ensures employees understand their role in safeguarding PHI. Conduct social engineering testing on your employees to measure the effectiveness of the training.

Rule #8: Encrypt all ePHI stored on any device that can be carried out of your office (desktops, laptops, hard drives, backup tapes, iPads/tablets, smart phones, and other portable media).

We understand that this is one of the most significant undertakings facing healthcare organizations today. But there really isn’t a choice. A single individual’s healthcare involves multiple practitioners, facilities, diagnostic labs, administrators, payers, ancillary service providers, etc. The very benefits that electronic health records promise can only be realized if the security challenges are met. We’re here to help. It’s 11PM. Do you know where your PHI is?

Healthcare Web Applications – The Security Achilles Heel (Part 2)

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

Last June, one of my colleagues at Redspin blogged about his concern that security flaws in software applications that house ePHI (electronic protected health information) represent a big threat. We had just completed a security assessment for a client and had found it relatively easy to access their customer portal using a common SQL injection technique. ePHI  records represent tempting targets for cyber crime as they typically include a wealth of personal info (name and address, SSN’s, credit card numbers, DOB and more).

The healthcare industry is currently very motivated to deploy EHR systems, increase interconnectivity via HIE’s, and launch new web applications. As data is made more accessible to more audiences, the risk of a breach increases too. The scope of a HIPAA Risk Analysis should include software applications but be sure to hire a company with specific application penetration testing expertise. Make sure your provider is competent, has relevant experience and applies best practices, starting with the Top 10 Web Application Vulnerabilities list as outlined by the Open Web Application Security Project (OWASP).

Another area of focus should be your internal patch management process. Effective maintenance of your current day-to-day IT operating systems and applications is essential but be sure to conduct an inventory of older applications as well. They may have been developed by people who are no longer with your organization.  Some may perform tasks that are very mundane, highly specialized and/or are rarely used. At Redspin we often uncover these “out-of-sight, out-of-mind” applications in our HIPAA Risk Analysis process. Fortunately we have an application penetration testing methodology that is applicable to both web applications and non-web applications

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 | Leave a 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.

1 2   Next »