Health IT and Electronic Health Activate your FREE membership today |  Log-in

Pabrai on HIPAA/HITECH Compliance


July 2, 2010  11:38 AM

Cyber Threats



Posted by: Pabrai

According to the FBI, cybercrime is now more widespread than narcotics. The targets of cybercrime are a lot more focused than ever before. The average organization’s information infrastructure is attacked nearly 60,000 times every day. Let me repeat that attacks on business computing infrastructure are now close to 60,000 times each day.

 

The volume of created content is expected to quintuple in the next two years – to more than 2.5 zettabytes. Seventy of the content created is done by individuals with no responsibility to secure it. However, most of the content produced – 85% – is in environments and organizations with responsibility to secure this information.

There have been over 354 million reported data privacy breaches over the past five years in the USA alone.

 

California recently fined five hospitals $675,000 in penalties for failing to prevent unauthorized access to patient medical information. The healthcare industry is a growing target of threats.

 

Today, just about all industries must meet federal and state mandates for information privacy and security. FISMA impacts federal government agencies, HIPAA and HITECH are critical requirements for the healthcare industry and those that process or manage cardholder data must meet PCI DSS requirements. These regulations establish the minimal (floor and not the ceiling) capabilities that organizations must establish to secure sensitive information.

 

As I often share with my clients, our approach for information security in 2010 and beyond must result in capabilities to “bake in” security mechanisms and ensure that controls are not “bolted on”.

 

How prepared is your organization in preventing the compromise of sensitive client and customer information as well as protecting vital assets from these sustained attacks?

July 1, 2010  1:42 PM

Rising California Fines for Data Breaches



Posted by: dspilka
Data privacy, HIPAA, Privacy, Security

The California Department of Public Health (CDPH) recently announced that several California hospitals were assessed penalties and fines totaling $675,000 after a determination that the facilities failed to prevent unauthorized access to confidential patient medical information. The hospitals that received penalties included:

1. Community Hospital of San Bernardino, San Bernardino, San Bernardino County

The hospital was assessed a $250,000 fine after the facility failed to prevent unauthorized access of 204 patients’ medical information by one employee.

2. Community Hospital of San Bernardino, San Bernardino, San Bernardino County

The hospital was assessed a $75,000 fine after the facility failed to prevent unauthorized access of three patients’ medical information by one employee.

3. Enloe Medical Center, Chico, Butte County

The hospital was assessed a $130,000 fine after the facility failed to prevent unauthorized access of one patient’s medical information by seven employees.

4. Rideout Memorial Hospital, Marysville, Yuba County

The hospital was assessed a $100,000 fine after the facility failed to prevent unauthorized access of 33 patients’ medical information by 17 employees.

5. Ronald Reagan UCLA Medical Center, Los Angeles, Los Angeles County

The hospital was assessed a $95,000 fine after the facility failed to prevent unauthorized access of one patient’s medical information by four employees.

6. San Joaquin Community Hospital, Bakersfield, Kern County

The hospital was assessed a $25,000 fine after the facility failed to prevent unauthorized access of three patients’ medical information by two employees.

In 2009 CDPH received close to 2,500 complaints related to inappropriate and unauthorized access to patient information. This number is expected to rise. The risk to organizations in not preventing unauthorized access to patient medical information is not insignificant when a breach occurs.

So how prepared is your organization in preventing unauthorized access to patient medical information?


June 25, 2010  11:53 AM

Learning from PCI Access Control Mandate



Posted by: Pabrai

The objective of PCI DSS Requirements 7, 8, and 9 is for organizations to implement strong access control measures. Just about all regulations – including the HIPAA Security Rule, as well as FISMA, and PCI DSS is no exception – emphasize the area of access control. As you look for your organization to meet compliance mandates for HIPAA or FISMA or State regulations in the area of access control, do review closely the information included in this PCI DSS requirement.

For example, PCI DSS Requirement #7 – Restrict Access to Cardholder Data by Business Need to Know – requires that :

organization’s must ensure that critical data can only be accessed by authorized personnel, systems and processes must be in place to limit access based on a need to know and according to job responsibilities. “Need to know” is when access rights are granted to only the least amount of data and privileges needed to perform a job.

This is fairly similar to the requirement in HIPAA in the area of Minimum Necessary. The associated HIPAA Security Rule Access Control Standard is resulting in organizations addressing the area of Role Based Access Control (RBAC) – which identifies all valid job roles and associated system and application privileges. Given the emphasis in the HITECH Act’s Data Breach Notification mandate, you will find the access control requirement and associated guidance provided in the PCI DSS standard to be valuable in establishing your organization’s minimal capabilities in this area.

So when is the last time that the RBAC matrix was updated by your organization? You must ensure that Human Resources (HR) and the Information Technology (IT) departments or business units work closely in updating this area of growing significance for compliance and information security.


June 21, 2010  1:51 PM

Why PCI DSS is a Valued Reference



Posted by: Pabrai

The Payment Card Industry’s Data Security Standard (PCI DSS) requirements – and there are 12 specific requirements – that impacted organizations must comply with – is one of the most specific standards in the field of information security. Take for example the PCI DSS requirement # 10.7 in the area of “Regularly Monitor and Test Networks”:

Retain audit trail history for at least one year, with a minimum of three months immediately available for analysis (for example, online, archived, or restorable from back-up).

This Requirement is supported with the following guidance to comply:

Retaining logs for at least a year allows for the fact that it often takes a while to notice that a compromise has occurred or is occurring, and allows investigators sufficient log history to better determine the length of time of a potential breach and potential system(s) impacted.

By having three months of logs immediately available, an entity can quickly identify and minimize impact of a data breach. Storing back-up tapes off-site may result in longer time frames to restore data, perform analysis, and identify impacted systems or data.

Your organization may be impacted by multiple regulations such as HIPAA, HITECH and State mandates. Researching the specific requirements of PCI DSS could be valuable to you as you try to establish standards in areas such as audit control and information system activity review to address compliance mandates. PCI DSS is fairly specific in several areas in establishing minimal capabilities required for managing cardholder information. There is no reason why the same cannot be applied to other sensitive or confidential information, such as PHI or EPHI, processed by your organization.

So is your organization required to comply with the PCI DSS mandate? Even if it is not, I would highly recommend you read and understand the PCI DSS standard. You will find an invaluable resource that will have a positive impact in the development of your security plans, policies and procedures. I would highly recommend the PCI DSS standard as required reading for all information security professionals and executives.


June 18, 2010  1:49 PM

Getting to Know FIPS 200



Posted by: Pabrai

All U.S. federal agencies must be compliant with FIPS 200. FIPS 200 – developed by NIST – establishes the Minimum Security Requirements for Federal Information and Information Systems. FIPS 200, the second of the mandatory security standards for FISMA compliance, specifies minimum security requirements for information and information systems supporting the executive agencies of the federal government and a risk-based process for selecting the security controls necessary to satisfy the minimum security requirements.

Security professionals should be familiar with FIPS 200 as it is a valuable reference – together with FIPS 199 and NIST SP 800-53 – and may have an impact in further enhancing the scope, definition and requirements associated with your organization’s information security plan or strategy. I know I have found FIPS 199 and NIST SP 800-53 to be significant works of value that have helped to enhance the quality of information security policies of several organizations.

The minimum security requirements cover seventeen security-related areas with regard to protecting the confidentiality, integrity, and availability of systems and the information processed, stored, and transmitted by those systems. The security-related areas include:

  1. Access control
  2. Awareness and training
  3. Audit and accountability
  4. Certification, accreditation, and security assessments
  5. Configuration management
  6. Contingency planning
  7. Identification and authentication
  8. Incident response
  9. Maintenance
  10. Media protection
  11. Physical and environmental protection
  12. Planning
  13. Personnel security
  14. Risk assessment
  15. Systems and services acquisition
  16. System and communications protection
  17. System and information integrity

A new (#18) security-related area was added recently in NIST SP 800-53 (Rev 3), Program management. This new addition requires the development of an organization-wide information security program plan.

So if you are not already familiar with FIPS 200, take a look at it. The minimal security requirements for federal information and federal information systems should be influencing the minimal requirements for sensitive, confidential client information that your organization is trusted with.

What are the minimal areas you have established in your organization’s information security program?


June 15, 2010  4:06 PM

Why You Should Follow FIPS 199?



Posted by: Pabrai

FIPS 199 published by the NIST is a FISMA mandate. Just because it may not be called out by other regulations, this is an important work that security professionals and management must be aware of and familiar with. So what is so special about FIPS 199? The FIPS 199 publication establishes security categories for both information and information systems. Compliance mandates require organizations to meet requirements such as contingency planning and conducting a Business Impact Analysis (BIA). The application of FIPS 199 categorization – is required by the FISMA regulation – and one that I would highly encourage healthcare organizations – covered entities as well as business associates – to conduct on a regular schedule.

The security categories defined within FIPS 199 are based on the potential impact on an organization should certain events occur which jeopardize the information and information systems needed by the organization to accomplish its assigned mission, protect its assets, fulfill its legal responsibilities, maintain its day-to-day functions, and protect individuals. Security categories are to be used in conjunction with vulnerability and threat information in assessing the risk to an organization.

FIPS 199 defines three levels of potential impact on organizations or individuals should there be a breach of security (i.e., a loss of confidentiality, integrity, or availability).  

  1. The potential impact is LOW if the loss of confidentiality, integrity, or availability could be expected to have a limited adverse effect on organizational operations, organizational assets, or individuals.
  2. The potential impact is MODERATE if the loss of confidentiality, integrity, or availability could be expected to have a serious adverse effect on organizational operations, organizational assets, or individuals
  3. The potential impact is HIGH if the loss of confidentiality, integrity, or availability could be expected to have a severe or catastrophic adverse effect on organizational operations, organizational assets, or individuals.

The generalized format for expressing the security category, SC, of an information  type is:

SC information type = {(confidentiality, impact), (integrity, impact), (availability, impact)}, where the acceptable values for potential impact are LOW, MODERATE, HIGH, or NOT APPLICABLE

So get familiar with FIPS 199 – if you are not already – and apply it to categorize assets within your organization.


June 11, 2010  1:59 PM

Have You Completed a BIA?



Posted by: Pabrai

A Business Impact Analysis (BIA) is a key step in establishing the requirements of an IT contingency plan. The BIA enables an organization to characterize the system components, supported mission/business functions, and interdependencies. The BIA’s purpose is to correlate the system with the critical mission/business processes and services provided, and based on that information, characterize the consequences of a disruption.

An organization can use the BIA results to determine contingency planning requirements and priorities. Results from the BIA should be appropriately incorporated into the analysis and strategy development efforts for the organization’s various documents related to the contingency plan, such as a Disaster Recovery Plan and an Emergency Mode Operations Plan.

The BIA must be inclusive of all key departments and business units within the organization. Incorporating FIPS 199 categorization helps to ensure that the BIA accounts appropriately for the level of risk to the organization.

The result of a BIA exercise is a report that establishes priorities for a contingency plan. The NIST Special Publication SP 800-34 Rev 1 outlines three steps that are typically involved in accomplishing the BIA:

1. Determine mission/business functions and recovery criticality. Mission/Business functions supported by the system are identified and the impact of a system disruption to those functions is determined along with outage impacts and estimated downtime. The downtime should reflect the maximum time that an organization can tolerate while still maintaining the mission.

2. Identify resource requirements. Realistic recovery efforts require a thorough evaluation of the resources required to resume mission/business functions and related interdependencies as quickly as possible. Examples of resources that should be identified include facilities, personnel, equipment, software, data files, system components, and vital records.

3. Identify recovery priorities for system resources. Based upon the results from the previous activities, system resources can be linked more clearly to critical mission/business processes and functions. Priority levels can be established for sequencing recovery activities and resources.

So when is the last time you conducted a formal and thorough BIA exercise?


June 9, 2010  11:04 AM

Is Your IT Contingency Plan Updated and Current?



Posted by: Pabrai

The NIST Special Publication 800-34 Rev 1 defines a seven-step IT contingency planning process that an organization may apply to develop and maintain a viable contingency planning program for their information systems. Contingency Plan is a Standard defined in the HIPAA Security Rule – and like any Standard in the regulation it must be met. The seven-steps outlined for an IT contingency plan in the NIST 800-34 Rev 1 publication are:

1. Develop the contingency planning policy statement. A formal policy provides the authority and guidance necessary to develop an effective contingency plan.

2. Conduct the business impact analysis (BIA). The BIA helps identify and prioritize information systems and components critical to supporting the organization’s mission/business functions.

3. Identify preventive controls. Measures taken to reduce the effects of system disruptions can increase system availability and reduce contingency life cycle costs.

4. Create contingency strategies. Thorough recovery strategies ensure that the system may be recovered quickly and effectively following a disruption.

5. Develop an information system contingency plan. The contingency plan should contain detailed guidance and procedures for restoring a damaged system unique to the system’s security impact level and recovery requirements.

6. Ensure plan testing, training, and exercises. Testing validates recovery capabilities, whereas training prepares recovery personnel for plan activation and exercising the plan identifies planning gaps; combined, the activities improve plan effectiveness and overall organization preparedness.

7. Ensure plan maintenance. The plan should be a living document that is updated regularly to remain current with system enhancements and organizational changes.

It all starts with first creating a policy that establishes the scope of your IT contingency plan. The NIST SP 800-34 Rev 1 is an excellent reference to use as you look to create or update your contingency plans.

So when is the last time you reviewed and updated your IT contingency plan? Is it an actionable plan that has been tested?


June 4, 2010  1:15 PM

Updating HIPAA & HITECH Policies with PII



Posted by: Pabrai

The Policies and Procedures (§ 164.316(a)) requirement in the HIPAA regulation states that organizations will implement reasonable and appropriate policies and procedures to comply with the standards, implementation specifications, or other requirements of the regulation. An organization may change its policies and procedures at any time, provided that the changes are documented and are implemented in accordance with regulation mandates.

The HITECH Act includes requirements for policies and procedures for complying with the Data Breach notification provision. In addition your organization – be it a covered entity or a business associate – may be required to also comply with State mandates for personal data or personal information of a resident of the State whose information you may manage or process.

Beyond PHI

As you review and update policies to comply with HIPAA, HITECH and State mandates, I would encourage you to not limit the scope of your policies to EPHI, or PHI. Go beyond and ensure that your policies address all Personally Identifiable Information (PII) that your organization comes into contact with or manages.

Reasonable and Appropriate

The NIST 800 66 Revision 1 document is an excellent place to start to better understand requirements for complying with HIPAA policies and procedures. Questions you need to address include:

  • Are reasonable and appropriate policies and procedures to comply with the standards, implementation specifications, and other requirements of the HIPAA Security Rule in place?
  • Are policies and procedures reasonable and appropriate given:
    • The size, complexity, and capabilities of the covered entity;
    • The covered entity’s technical infrastructure, hardware, and software security capabilities;
    • The costs for security measures; and
    • The probability and criticality of potential risks to EPHI?
    • Do procedures exist for periodically reevaluating the policies and procedures, updating them as necessary?

NIST 800 122 – A Critical Reference for Policies

As you look to revise and update your policies, you should also reference the NIST Special Publication NIST SP 800 122 which is focused on Personally Identifiable Information (PII). Given the multitude of information privacy and security regulations that covered entities and business associates have to comply with, it is best to set the dial tone in organizational policies to not be limited to EPHI, or PHI, but to cover all PII.

So when is the last time you updated your policies? Did you update it to address PII?


June 1, 2010  9:11 PM

Guidance from OCR on HIPAA Security Risk Analysis



Posted by: Pabrai

 

The very first implementation specification in the HIPAA Security Rule is Risk Analysis. The Office for Civil Rights (OCR) recently published a (draft) guidance document to assist organizations in identifying and implementing the most effective and appropriate administrative, physical, and technical safeguards to protect the confidentiality, integrity, and availability (CIA) of EPHI.

The First Step

Conducting a risk analysis is the first step in identifying and implementing safeguards – your countermeasures or controls – that comply with and carry out the standards and implementation specifications in the HIPAA Security Rule. Given the requirements of the HIPAA Privacy Rule and the HITECH Act, organizations should look at all PHI it processes or manages, and not limit the analysis to EPHI.

HIPAA Security Rule

All EPHI created, received, maintained or transmitted by an organization is subject to the HIPAA Security Rule. The Security Rule requires entities to evaluate risks and vulnerabilities in their environments and to implement reasonable and appropriate security measures to protect against reasonably anticipated threats or hazards to the security or integrity of EPHI. As your organization – be it a covered entity or a business associate – looks to comply with the HITECH Act and the HIPAA Security Rule – keep in mind that the risk analysis implementation specification is the first step in that process.

Critical Questions to Address

Critical questions that every covered entity and business associate impacted by the HIPAA regulation must address in the scope of the risk analysis activity – on a regular basis – include:

  • Have you identified the EPHI as well as PHI within your organization? This includes PHI that you create, receive, maintain or transmit.
  • What are the external sources of PHI? For example, do vendors or consultants create, receive, maintain or transmit PHI or EPHI?
  • What are the human, natural, and environmental threats to information systems that contain EPHI and PHI?

More than ever, the Boards of Directors at hospitals, health systems, business associates and others are taking notice and asking an important question – “is the organization compliant with HIPAA and HITECH mandates?” Have you completed the first step – Risk Analysis?


Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to: