OIG Blasts CMS on HIPAA Security Gaps; Guidance for ASC Compliance

The OIG recently completed its review of CMS's oversight with regard to HIPAA Security, and the result is alarming. OIG had some harsh words for CMS's efforts, saying it has taken "limited actions," resulting in little oversight or enforcement, and that it has "no effective mechanism to ensure that covered entities [are] complying … or that electronic protected health information [is] being adequately protected." CMS agreed with OIG that it needs to step up oversight, specifically the conducting of compliance reviews.

Would your facility be ready if CMS came knocking? Although this report primarily covers hospitals, we all know that ASCs face greater scrutiny. And in a bureaucratic double-standard, any breach of HIPPAA Security in an ASC would be further ammunition for the anti-ASC establishment would use it for maximum effect.

The HIPAA Security Rule requires any entity that uses any form of electronic protected health information (EPHI) to implement measures to ensure that EPHI is not lost, stolen or accessed by unauthorized persons either inside or outside the practice or facility. Entities were required to be in compliance no later than April 2005. Here's a vastly simplified HIPAA Security breakdown intended to help you understand the keys to compliance.

Three categories of standards
1. Administrative — mostly policies, procedures, training, etc.; however, even though these are primarily paper documents and manuals, they are extremely important to have in place.

2. Physical — mostly tangible/physical procedures to protect EPHI. This includes housing critical server and data storage systems inside a locked cabinet in a locked room that has limited, controlled access. A chart room or a supply room is not sufficient. Access to this area is to be both limited and monitored.

3. Technical — automated and manual technical tools/systems designed to protect EPHI. These primarily cover the kind of IT tools and techniques that are beyond the skill set of most IT employees or even IT contractors.

Standards and implementation specifications
There are 18 standards and 42 implementation specifications, and they fall into two categories: 20 required items that must be done by every entity, regardless of size and complexity, and 22 addressable items that may or may not apply, depending on the circumstances of each facility. All facilities must assess the applicability of addressable items; for items that do not apply, reasons that this is the case must be documented. So in essence, even the “addressable” ones are in fact “required” – all entities are required to assess and address the relevance of all 42 standards and specifications.

Detailed audits
All entities must complete a detailed audit of their operations, including the following: hardware software and network systems (this must include everything, not just the things you think you have); documentations, policies and procedures (operations, training and staff issues); and trading partners, vendors and external interfaces.

Upgrades as needed
All entities are required to remediate their systems as necessary to bring them into compliance. This includes hardware, software and network systems (substantial upgrades are often required), and policies and procedures (operations, training and staff issues).

Day-to-day maintenance Ongoing requirements include security incident reporting; ongoing/periodic audits and changes/updates as necessary; training and procedures; and records retention.

Red flags
If any of the following automatic non-starters is present, it represents non-compliance for your facility:

1. Workstations with anything other Windows 2000 (Service Pack 4) or XP Pro (Service Pack 3), Vista Business. Windows 98, Me, NT Workstation, XP Home, Vista Home, etc., are non-compliant.

2. Weak or shared logins/passwords, such as "staff," "billing," or "front desk." Frequently this is done to short-cut licensing costs. This not only puts the facility at risk from litigation from their software provider, it violates HIPAA Security.

3. No formal employee acceptable-use policy (AUP) covering IT systems. Most IT issues are caused by users, either attempting to do something they don’t understand, or using the system for something it was not intended.

4. No written security incident reporting policy (and about 10 other written policies and practices).

The HIPAA Security rules are not all bad — in fact, for the most part, HIPAA Security Rule compliance involves implementing many processes and procedures that any business should be doing as a matter of course to protect vital business data. So, unlike HIPAA Privacy, which is completely different from HIPAA Security, and many would argue contains a lot of unnecessary administrative overhead, the HIPAA Security Rule represents industry best practices from a technology standpoint. Again, this guidance is intended as an overview. For further HIPAA Security inquiries, contact Marion Jenkins at Marion.Jenkins@QSETech.com.

Download OIG Audit A-04-07-05064, the Nationwide Review of the Centers for Medicare & Medicaid Services Health Insurance Portability and Accountability Act of 1996 Oversight.

Dr. Jenkins is the CEO of QSE Technologies, a premiere IT systems integrator serving the ambulatory healthcare industry for more than five years. Read more about QSE.

© Copyright ASC COMMUNICATIONS 2019. Interested in LINKING to or REPRINTING this content? View our policies by clicking here.

 

Top 40 Articles from the Past 6 Months