Security ICE: PROVIDER'S PERSPECTIVE


Issues, Concerns, and Enforcement of HIPAA Security Compliance From a Provider's Perspective

By Barbara McGowin, Resource Consultant, Connecting Healthcare Organizations with People, Products, and Services to Achieve HIPAA Compliance

Introduction

On August 21, 1996, President Clinton signed into law the Health Insurance Portability and Accountability Act of 1996, Public Law 104-191 (HIPAA). In so doing, the health care industry was given a far-reaching and complex mandate that would impact every aspect of health care in the United States of America. After much debate and a major rewrite of the Notice of Proposed Rule Making (NPRM) the Final Security Rule was published in the Federal Register on February 20, 2003. Covered entities are required to implement reasonable administrative, physical, and technical safeguards to protect the confidentiality, integrity, and availability of electronic protected health information by April 21, 2005. This white paper addresses the issues, concerns, and enforcement of HIPAA security compliance from a provider's perspective.

Issues

One of the more basic issues of achieving compliance with the HIPAA Security Rule is knowing where to start. What are reasonable administrative, physical, and technical safeguards? How do you identify threats? How do you identify vulnerabilities? How do you address incidents? How do you conduct a security risk assessment?

Implementing safeguards to protect the confidentiality, integrity, and availability of ePHI creates the need for new skill sets. Technology does have cost benefits, but it also provides great opportunity for threats for which providers have little or no experience addressing.

The primary mission of providers is ensuring the availability and provision of health care products and services. With their resources limited, the HIPAA security requirements and implementation specifications vague, and differing views on industry "security best practices," many providers find it difficult to budget for this unfunded compliance mandate until clearer guidance is provided.

Concerns

The use of technology varies widely across the spectrum of providers. Many who have created or upgraded their security policies and procedures are finding that it interferes or disrupts the exchange of information electronically with providers that are slow to adopt access control management or use of encryption.

Many system users are suspicious of technical controls and are concerned that access to needed information will be denied or delayed and could interfere with the provision of health care.

Many providers are concerned that their current software version does not have the necessary technical controls to meet the HIPAA security requirements. Those whose vendors have updates or patches may not have the resources required to effectively utilize, maintain, and monitor these security controls within their current environment.

Enforcement

The HHS Office for Civil Rights (OCR) will enforce the HIPAA privacy standards. The CMS Office of HIPAA Standards will enforce the HIPAA security rule. CMS and OCR will work together on outreach and enforcement and on issues that touch on the responsibilities of both organizations - such as application of security standards. Through statements in the Federal Register and through extensive outreach, CMS has stated that it will focus on obtaining voluntary compliance and use a complaint-driven approach for enforcement. Entities will have the opportunity to:

o Demonstrate compliance

o Document their good faith efforts to comply

o Submit a corrective action plan

CMS's approach will utilize the flexibility granted in section 11176(b) of the Social Security Act and may not impose a civil money penalty (CMP) where:

o Failure to comply is based on reasonable cause and is not due to willful neglect

o The failure to comply is cured within a period determined by HHS based on the nature and extent of the failure to comply

Key Concepts and Emerging Technical Assistance

The security standards are based on three concepts:

o Flexibility and scalability - must be applicable from the smallest provider to the largest health plan

o Comprehensive - must cover all aspects of security, behavioral as well as technical (process oriented)

o Technology neutral - as technology changes, standards remain constant

The final HIPAA Security Rule defines the standards in generic terms and provides little guidance on how to implement them. Covered entities must make their own judgments regarding security risks and the most effective mechanisms to reduce those risks and also must determine the reasonable and appropriate nature of an addressable specification. The National Institute of Standards and Technology (NIST) provides guidance on how organizations should develop, document, and implement an organizational wide program to provide information security for the information systems that support its operations and assets. CMS, working with URAC, NIST, and WEDI SNIP, will be providing information on how to integrate NIST guidance in to the HIPAA security compliance initiative to assist covered entities with the security management process.

Security Risk Assessment and Mitigation Planning

HIPAA security compliance is a multi-faceted undertaking that involves the employment and use of well defined system level security requirements and security specifications, well designed information technology component products, sound systems/security engineering principles and practices, appropriate metrics for product/system testing and evaluation, comprehensive system security planning, and life cycle management. It all starts with a security risk assessment. In order to develop effective and sustainable security management, providers should consider doing the following:

1) Contact your local, regional, and national associations and organizations. Ask what is available to assist in HIPAA security compliance.

2) Read the HIPAA Security Rule

(http://www.cms.hhs.gov/hipaa/hipaa2/regulations/security/03-3877.pdf) and seek assistance, if necessary, to understand the spirit and details of the regulations.

3) Collect and organize information such as:

a. Contact information of business associates

b. Contact information of application/system vendors

c. Contact information of third parties such as consultants that provide subject matter expertise on security issues and business processes

d. Key in-house resources that will be involved in security compliance (decision makers, managers, IT administrators, HR, etc.)

e. URLs of web-based informational resources (see Appendix A)

f. Inventory of organization's policies

4) Develop a security checklist (i.e. survey, questionnaire) based on the requirements and implementation specifications of the security rule, your business operations, and known threats (internal and external). If you are unsure what should be included in your security checklist, you may want to consider asking your local organizations or associations if one is available. There are many vendors who have a security checklist included in a HIPAA compliance tool. NIST has developed a generic, non-healthcare related security checklist (NIST SP 800-26 Security Self-Assessment Guide for Information Technology Systems http://csrc.nist.gov/publications/nistpubs/800-26/sp800-26.pdf).

5) Use your security checklist to conduct surveys. The interviewer should have HIPAA subject matter expertise or have access to informational references that will allow the interviewer to answer any questions that the interviewees may have in order to answer the survey questions accurately. Care should be taken to address questions to the appropriate level. For small organizations some of the levels may overlap. The four levels that should be addressed are

a. Organizational

b. Department

c. Facilities (primary focus is physical security controls)

d. Application/System (primary focus would be the availability and use of technical security capabilities)

6) Determine the gap for each item on the Security Checklist. Gaps are vulnerabilities and can be at the organizational, department, facility, or application level. The gap levels would be

a. Policy (Gap Level I)

i. Have policy and is HIPAA compliant

ii. Have policy but needs update

iii. Have no policy

b. Procedure (Gap Level II)

i. Have procedure and is HIPAA compliant

ii. Have procedure but needs update

iii. Have no procedure

c. Training (Gap Level III)

d. Implementation (Gap level IV)

e. Audit (Gap Level V)

7) Determine the impact a breach of confidentiality, integrity, or availability of a system or application would have to your organization. This is defined by NIST as the security categorization of a system (DRAFT FIPS Publication 199 Standards for Security Categorization of Information systems http://csrc.nist.gov/publications/drafts/draft-fips-pub-199.pdf). For an example of a security categorization of an application based on NIST impact levels, see Appendix A, page 4. There are three levels of security categorization. They are:

a. Low

b. Moderate

c. High

8) Once you have determined your gaps or vulnerabilities and the security categorization of your application/system, you have completed your initial risk assessment. You will need to document this, as the results of your initial risk assessment will be your risk assessment baseline.

9) You must determine what you will do to fix the gaps to mitigate your risk. If there are numerous gaps and limited resources you will need to prioritize your tasks. This step is called your mitigation-planning phase. NIST provides guidance on management, operational, and technical security controls or security safeguards that you may want to consider (DRAFT NIST SP 800-53 Recommended Security Controls for Federal Information Systems http://csrc.nist.gov/publications/drafts/draft-SP800-53.pdf). The management security controls are useful for determining the scope and issues you may want to address in the policies that need updating or need to be created. The operational controls can assist with development of procedures and determining physical safeguards to employ. The technical security controls are useful in determining the technical capabilities that your applications and systems may need. These are very useful when considering an upgrade or replacement and preparing an RFI/RFP. NIST provides three levels of security controls. They are:

a. Basic

b. Enhanced

c. Strong

10) The security work plan is the result of your mitigation planning. It is your roadmap to achieving compliance with the HIPAA Security Rule.

Security management is change management. You should schedule periodic risk assessments and mitigate any new gaps that are identified. In your day-to-day operations issues or incidents may arise. These should also be assessed and mitigated. Anytime policies change, business processes change, or technology changes a risk assessment will need to be conducted.

Keys to Success

Senior management's commitment to achieving HIPAA security compliance is critical. To enhance that commitment, the security work plan must be well documented with projected costs. Full support and participation of the IT team will be dependent on their understanding of the organization's policy, training on the security capabilities of the system, and well-written procedures. The risk assessment team must be able to apply the risk assessment methodology to your specific organization, facility, and system to identify mission risks and cost-effective safeguards that meet the needs of the organization. Because technology will change and business processes will change, on-going evaluation and assessment of the IT-related risks are required.

Recognition of Content Influence

The members of the test group for the security module of HIPAA ComplyAssistant were instrumental in providing recommendations for integration of NIST guidance into the HIPAA security compliance initiative. Gerry Blass, creator of HIPAA ComplyAssistant, showed that a logical, consistent approach is the key to achieving compliance and that effective reports and graphs that document progress and illustrate where an entity is, and where they need to be, are crucial to the decision making process, vital in documenting due diligence, and essential for successful project management. Additional perspective was provided from those who volunteered to review the draft.

Test Group Participants
Gerry Blass, President, Blass Consulting, LLC, Colts Neck, NJ
Rob Collins, Director, HIPAA Privacy and Security, Data Warehouse Network USA, Spring Lake, NJ
William H. Dobson, CISSP, IAM, TrustWave Professional Services, Annapolis, MD
Lorraine Doo, Office of HIPAA Standards, Washington, D.C.
Linda Fletcher, Info Security Officer, Sisters of St. Francis Health Services, Inc., Beech Groove, IN
Brian Foley, TCS HIPAA Compliance Manager, St. Joseph's Hospital & Medical Center, Paterson, NJ
Nelson Hazeltine, President, Ivista Group, Chapin, SC
James Holler, CISSP, Sr. Manager, HIPAA Connection
Timothy M. Lyons, CISSP, lyons@digitalvoodoo.org
Barbara McGowin, Resource Consultant, HIT Recruiting, Goose Creek, SC
Joseph Ponnoly, CISM, CISA, CISSP, Information Security Consultant, Columbus, OH
Halbert Thomas, Hamilton County Community Mental Health Board, Cincinnati, OH
Kay Warner, Computer Security Officer, Medical Center Hospital, Odessa, TX

Draft Reviewers
Alan Finger, CISSP, President, Eptrix Solutions, Computer and Information Security, Topsfield, MA
Karen A. Anderson, FLMI, ALHC, IS Regulatory Manager, Methodist Healthcare, Memphis, TN
Edward Higgins, CISSP, CISA/M, GSEC, MCSE, Information Security Practice Executive Director, Appliied Solutions, Inc., Dallas, TX
Elden Hamada, CISSP, Queens Medical Center/ACS, Information Services, Honolulu, HI
Patty Hyatt Pezely, CISM, CISSP, Managing Consultant, Information Security Professional Services, SundGard Availibility Services, Wayne, PA
Clint Laskowski, CISSP, Independent Consultant, Milwaukee, WI
Charlie Mason
Ben Rothke, CISSP, CISM, Senior Security Consultant, ThruPoint, Inc.
Scott Sattler, SecureLabs
Eric D. Scales, CISSP, Harris County Hospital District, Houston, TX
Brad Smith, RN, BS, CISSP, ASCIE, Director, CIR Security
Richard Thomas, ISO, Texas Department of Human Services, Austin, TX
Yury Vayman, CISSP, CSS1, Project Director/Co-Principal Investigator Computer Science Department /Center for Advanced Information Management, Columbia University, NYC, NY