Chapter 14. Regulatory Compliance for the Healthcare Sector

The genesis of healthcare security–related legislation is the Health Insurance Portability and Accountability Act of 1996 (HIPAA, Public Law 104-191). The original intent of the HIPAA regulation was to simplify and standardize healthcare administrative processes. Administrative simplification called for the transition from paper records and transactions to electronic records and transactions. The Department of Health and Human Services (HHS) was instructed to develop and publish standards to protect an individual’s electronic health information while permitting appropriate access and use of that information by healthcare providers and other entities. On August 14, 2002, the Standards for Privacy of Individually Identifiable Health Information, known as the HIPAA Privacy Rule, was published. The Privacy Rule set limits and conditions on the use and disclosure without patient authorization, and gave patients control over their health information, including the right to examine and obtain a copy of their health records, and to request corrections. The Privacy Rule applies to all formats of protected health information (PHI; for example, paper, electronic, oral). On February 20, 2003, the Security Standards for the Protection of Electronic Protected Health Information, known as the HIPAA Security Rule, was published. The Security Rule required technical and nontechnical safeguards to protect electronic health information. The corresponding HIPAA Security Enforcement Final Rule was issued on February 16, 2006. Since then, the following legislation has modified and expanded the scope and requirements of the Security Rule:

2009 Health Information Technology for Economic and Clinical Health Act (known as the HITECH Act)

2009 Breach Notification Rule

2013 Modifications to the HIPAA Privacy, Security, Enforcement, and Breach Notification Rules under the HITECH Act and the Genetic Information Nondiscrimination Act; Other Modifications to the HIPAA Rules (known as the Omnibus Rule)

In this chapter, we will examine the components of the original HIPAA Security Rule, the HITECH Act, and the Omnibus Rule. We will discuss the policies, procedures, and practices that entities need to implement to be considered HIPAA compliant. We will conclude the chapter with a look at incident response and breach notification requirements.

A healthcare provider is defined as a person or organization that provides patient or medical services, such as doctors, clinics, hospitals, out-patient services and counseling, nursing homes, hospices, pharmacies, medical diagnostic and imaging services, and durable medical equipment providers.

A health plan is defined as an entity that provides payment for medical services such as health insurance companies, HMOs, government health plans, or government programs that pay for healthcare such as Medicare, Medicaid, military, and veterans’ programs.

A healthcare clearinghouse is defined as an entity that processes nonstandard health information it receives from another entity into a standard format.

Business associates were initially defined as persons or organizations that perform certain functions or activities that involve the use or disclosure of PHI on behalf of, or provide services to, a CE. Business associate services include legal, actuarial, accounting, consulting, data aggregation, management, administrative, accreditation, and financial. Subsequent legislation expanded the definition of a business associate to a person or entity that creates, receives, maintains, transmits, accesses, or has the potential to access PHI to perform certain functions or activities on behalf of a CE.

Confidentiality is the protection of information from unauthorized people, resources, and processes.

Integrity is the protection of information or processes from intentional or accidental unauthorized modification.

Availability is the assurance that systems and information are accessible by authorized users when needed.

The framers of the regulations were realists. They understood that these regulations were going to apply to organizations of various sizes and types throughout the country. They were careful not to mandate specific actions. As a matter of fact, many in the healthcare sector have criticized the DHHS for being too vague and not providing enough guidance. The rule says that a CE may use any security measures that allow it to reasonably and appropriately implement the standards and implementation specification, taking into account the following:

The size, complexity, and capabilities of the CE.

The CE’s technical infrastructure, hardware, and software capabilities.

The costs of security measures.

The probability of potential risks.

The standards were meant to be scalable, meaning that they can be applied to a single-physician practice or to a hospital system with thousands of employees. The standards are technology neutral and vendor nonspecific. CEs are expected to choose the appropriate technology and controls for their unique environment.

The Department of Justice was given the authority to bring criminal action against CEs that wrongly disclose ePHI. Criminal penalties for knowing violations are up to $50,000 and one year in prison, violations committed under false pretenses are up to $100,000 and five years in prison, and offenses committed for commercial or personal gain are up to $250,000 and ten years in prison.

Administrative safeguards are the documented policies and procedures for managing day-to-day operations, the conduct, and access of workforce members to ePHI, as well as the selection, development, and use of security controls.

Physical safeguards are the controls used to protect facilities, equipment, and media from unauthorized access, theft, or destruction.

Technical safeguards focus on using technical security measures to protect ePHI data in motion, at rest, and in use.

Organizational requirements include standards for business associate contracts and other arrangements.

Documentation requirements address retention, availability, and update requirements related to supporting documentation, including policies, procedures, training, and audits.

A required implementation specification is similar to a standard, in that a CE must comply with it.

For addressable implementation specifications, CEs must perform an assessment to determine whether the implementation specification is a reasonable and appropriate safeguard for implementation in the CE’s environment.

“Addressable” does not mean optional, nor does it mean the specification can be ignored. For each of the addressable implementation specifications, a CE must do one of the following:

Implement the specification if reasonable and appropriate, or

If the entity determines that implementing the specification is not reasonable and appropriate, the entity must document the rationale supporting the decision and either implement an equivalent measure that accomplishes the same purpose or be prepared to prove that the standard can be met without implementing the specification.

Risk management is defined as the implementation of security measures to reduce risk to reasonable and appropriate levels to ensure the CIA of ePHI, protect against any reasonably anticipated threats or hazards to the security or integrity of ePHI, and protect against any reasonably anticipated uses or disclosures of ePHI that are not permitted or required under the HIPAA Security Rule. The determination of “reasonable and appropriate” is left to the discretion of the CE. Factors to be considered are the size of the entity, the level of risk, the cost of mitigating controls, and the complexity of implementation and maintenance. Per DHHS guidance, the risk management process includes the following activities:

Analysis

Identify the ePHI that the organization is responsible for protecting.

Document potential threats and vulnerabilities.

Determine the likelihood of threat occurrence.

Determine the potential impact of threat occurrence.

Determine the level of risk.

Management

Develop and implement a risk management plan.

Implement security measures.

Maintain continuous, reasonable, and appropriate security protections.

The Security Rule does not dictate a specific risk assessment methodology. However, DHHS implementation and training materials refer to using NIST SP 800-30: Risk Management Guide for Information Technology Systems as a guide.

CEs must implement sanction policies for security violations in regard to ePHI. Specially, CEs must have a written policy that clearly states the ramifications for not complying with the Security Rules as determined by the organization.

Implied in this requirement is a formal process to recognize and report security violations. The policy needs to apply to all employees, contractors, and vendors. Sanctions might range from a reprimand to termination. Again, this is left to the discretion of the organization. It is also implied that all employees have not only been made aware of the sanction policy but have been trained and understand what is expected of them in regard to security behavior.

An integral component of risk management is continuous monitoring, review, and evaluation. The expectation here is that the CE has a mechanism in place to review information system activity and that these reports are reviewed regularly. System activity includes network, application, personnel, and administrative activities. Before a review can be implemented, three basic questions must be addressed:

1. What system activity is going to be monitored? The short answer: audit logs, access reports, and security incident–tracking reports are the most common methods of tracking system activity.

2. How is this going to be accomplished? Generally, using built-in or third-party monitoring/audit tools for operating systems, applications, and devices, as well as incident reporting logs.

3. Who is going to be responsible for the overall process and results? This is usually assigned to the security officer. Realistically, the security officer may not have the technical skills to interpret the reports, in which case it needs to be a combination of information technology (IT) staff (either internal or outsource) and the security officer.

It is important to select a person who can assess effective security and who can serve as a point of contact for security policy, implementation, and monitoring. It should be pointed out that responsibility for compliance does not rest solely with the security officer. Management is still accountable for the actions of the CE. The entire organization is expected to engage in compliance-related activities. The goal is to create a culture of security and compliance.

In Chapter 3, we defined authorization as the process of granting users and systems a predetermined level of access to information resources. In this case, the specification refers to determining who should have access to ePHI and the level of access. Implied in this specification is that the organization has defined roles and responsibilities for all job functions. Larger CEs would be expected to document workforce access, including type of permission, under what circumstances, and for what purposes. A small medical practice may specify that all internal staff need access to ePHI as a normal part of their job.

CEs need to address whether all members of the workforce with authorized access to ePHI receive appropriate clearances. The goal of this specification is that organizations establish criteria and procedures for hiring and assigning tasks—in other words, ensuring that workers have the necessary knowledge, skills, and abilities to fulfill particular roles and that these requirements are a part of the hiring process. As a part of this process, CEs need to determine the type of screening required for the position. This can range from verification of employment and educational references to criminal and credit checks. It was not the intent of Congress to mandate background checks, but rather to require reasonable and appropriate screening prior to access to ePHI.

When an employee’s role or a contractor’s role in the organization changes or their employment ends, the organization must ensure that their access to ePHI is terminated. Compliance with this specification includes having a standard set of procedures that should be followed to recover access control devices (ID badges, keys, tokens), recover equipment (laptops, PDAs, pagers), and deactivate local and remote network and ePHI access accounts.

Once an organization has decided what roles need access and who will be filling the roles, the next step is to decide how access will be granted to ePHI. In this standard, we are approaching the question from a policy perspective. Later on we will revisit this question from a technology perspective. The first decision is at what level or levels will access be granted. Options include hardware level, operating system level, application level, and transaction level. Many organizations will choose a hybrid approach. The second decision is the defined basis for granting access. Options here include identity-based access (by name), role-based access (by job or function), and group-based access (by membership). Larger organizations may gravitate toward role-based access because the job may be very well defined. Smaller entities will tend to use identity-based or group-based access because one person may be tasked with multiple roles.

Assuming the organization has made its decisions on access authorization, the next step is to develop policies and procedures to establish, document, review, modify, and, if necessary, terminate a user’s access rights to a workstation, transaction, program, or process. What is expected is that each user’s rights can be clearly identified. To do so, every user must have a unique identification. Assigned user roles and group membership must be documented. As discussed in Chapter 6, “Human Resources Security,” throughout the workforce lifecycle, there needs to be a defined user-provisioning process to communicate changes in status, role, or responsibility.

A security awareness program is designed to remind users of potential threats and their part in mitigating the risk to the organization. According to NIST, the purpose of awareness presentations is simply to focus attention on security. Awareness presentations are intended to allow individuals to recognize IT security concerns and respond accordingly. Security awareness should be an ongoing campaign. Suggested delivery methods include posters, screen savers, trinkets, booklets, videos, email, and flyers. The campaign should be extended to anyone who interacts with the CEs’ ePHI. This includes employees, contractors, and business partners. Security awareness programs are an essential component of maintaining a secure environment. Even the most security conscious federal agency has posters prominently displayed as you walk through a locked door reminding you to check that no one else entered with you and to verify that the door clicked shut behind you!

The implementation specification includes three training topics: password management, login procedures, and malware. These are important topics because the associated threats can be mitigated by user behavior. Users need to understand the importance of safeguarding their authentication credentials (passwords, tokens, or other codes) and the immediacy of reporting a suspected password compromise. Users should also be taught to recognize anomalies related to authentication, including an unusually slow login process, credentials that work intermittently, and being locked out unexpectedly, and to report anomalies even if they seem minor. As we’ve discussed in earlier chapters, malware (short for malicious software) is one of the most significant threats faced by all Internet-connected organizations. Users need to be trained in how to disrupt the malware delivery channel, how to respond to suspicious system behavior, and how to report suspicious incidents.

Security incident reporting is the foundation of a successful response and recovery process. A security incident reporting program has three components: training users to recognize suspicious incidents, implementing an easy-to-use reporting system, and having staff follow through with investigations and report back their findings to the user. Covered entities are required to have documented procedures in place to support a security incident reporting program.

Incident response procedures address by whom, how to, and within what timeframe an incident report should be responded to. Procedures should include an escalation path based on the criticality and severity of the incident. This should include when to contact law enforcement and forensics experts as well as when it is appropriate to contact patients regarding a security breach. All incidents should be documented. This information should then be incorporated into the ongoing risk management process.

The data and criticality analysis specification requires CEs to identify their software applications (data applications that store, maintain, or transmit ePHI) and determine how important each is to patient care or business needs, in order to prioritize for data backup, disaster recovery, and/or emergency operation plans. For example, access to electronic medical records would be critical to providing care. On the other hand, claims processing, while important to the financial health of the entity, does not in the short term affect patient care. In Chapter 12, we referred to this process as a business impact analysis.

The data backup specification requires that CEs establish and implement procedures to create and maintain retrievable exact copies of ePHI. This means that all ePHI needs to be backed up on a scheduled basis. The implementation mechanism is left up to the organization. However, the procedures to back up (and restore) the data must be documented and the responsibility to run and verify the backup must be assigned. In addition to verification that the backup job ran successfully, test restores should be conducted regularly. Testing both verifies the media and provides a training opportunity in a low-stress situation. There are few situations more nerve-wracking than that of learning how to restore data in a crisis situation. Backup media should not remain onsite. It should be securely transported offsite. The location where it is stored needs to be secured in accordance with the organization’s security policy.

The disaster recovery specification specifically requires that CEs be able to restore any data that has been lost. The initial interpretation is the ability simply to restore data. In actuality, the process is much more complex. Organizations must consider worst-case scenarios. What if the building was not accessible? What if equipment was destroyed? What if the communications infrastructure was unavailable? What if trained personnel were unavailable? A disaster recovery plan should be developed that addresses the recovery of critical infrastructure, including information systems and communications (phone, data, and Internet) as well as restoration of data.

The emergency mode operation specification requires that ePHI (and by extension, the network) be protected from harm during adverse circumstances such as a disaster or emergency situation.

The testing and revision procedures specification requires that organizations implement procedures for periodic testing and revision of contingency plans. As discussed in Chapter 12, plans and procedures are purely theoretical until they are tested. The objective of a testing program is to ensure that plans and procedures are accurate, relevant, and operable under adverse conditions. As important as demonstrating success is uncovering inadequacies.

There is not a formal certification or accreditation process for HIPAA compliance. There is no organization or person who can put an “official” stamp of approval on the compliance program. The process is one of self-certification. It is left to the organization to determine if its security program and compliance activities are acceptable. If challenged, the organization will need to provide thorough documentation to support its decisions.

CEs share ePHI for a variety of reasons. The standard states that a CE may permit a business associate to create, receive, maintain, or transmit ePHI on a CE’s behalf only if the CE obtains satisfactory assurances that the business associate will appropriately safeguard the information. Services provided by business associates include claim processing or billing, transcription, data analysis, quality assurance, practice management, application support, hardware maintenance, and administrative services.

The required implementation specification requires CEs to document the satisfactory assurances required through a written contract or other arrangement with the business associate that meets the applicable requirements. Implied in this standard is that the CE will establish criteria and procedures for measuring contract performance. Procedures may range from clear lines of communication to onsite security reviews. Of particular importance is a process for reporting security incidents relative to the relationship. If the criteria aren’t being met, then a process needs to be in place for terminating the contract. Conditions that would warrant termination should be included in the business associate agreement as well as in performance contracts.

The facility security plan specification requires that the safeguards used by the entity to secure the premise and equipment from unauthorized access, tampering, and theft be documented. The most basic control that comes to mind are door locks. Implied in this specification is the need to conduct a risk analysis to identify vulnerable areas. The risk analysis would focus on the building perimeter, interior, and computer room/data centers. Areas that would be examined include entry points such as doors, windows, loading docks, vents, roof, basement, fences, and gates. Based on the outcome of the risk assessment, the facility security plan may include controls such as surveillance monitoring, environmental equipment monitoring, environmental controls (air conditioning, smoke detection, and fire suppression), and entrance/exit controls (locks, security guards, access badges).

Access control and validation procedures specification focuses on the procedures used to ensure facility access to authorized personnel and visitors and exclude unauthorized persons. Facility access controls are generally based on their role or function. These functional or role-based access control and validation procedures should be closely aligned with the facility security plan.

The maintenance records implementation specification requires that CEs document such facility security repairs and modifications, such as changing locks, routine maintenance checks, and installing new security devices. Organizations that lease space should require the owner to provide such documentation.

The establishing contingency operations implementation specification is an extension of the contingency plan requirement in the Administrative Safeguards section. An entity needs to establish procedures to ensure authorized physical access in case of emergency. Generally, these procedures are manual overrides of automated systems. The access control system for a computer room may have been designed to use a swipe card or biometric identification. If the facility were to lose power, these controls would be useless. Assuming that entry into the computer room is required, a contingency or alternate plan would be necessary.

The objective of the maintaining accountability for hardware and electronic media implementation specification is to be able to account at all times for the whereabouts of ePHI. Implied is that all systems and media that house ePHI have been identified and inventoried. The goal is to ensure that ePHI is not inadvertently released or shared with any unauthorized party. This is easy to understand if you envision a paper medical record (chart). Before the record is allowed to leave the premises, it must be verified that the request came from an authorized party. The removal of the chart is logged and a record kept of the removal. The logs are reviewed periodically to ensure that the chart has been returned. This specification requires the same type of procedures for information stored in electronic form.

The developing data backup and storage procedures specification requires that before moving or relocating any equipment that contains ePHI, a backup copy of the data be created. The objective is to ensure that in case of damage or loss, an exact, retrievable copy of the information is available. Concurrent with this action is the implied requirement that the backup media will be stored in a secure location separate from the original media. This specification protects the availability of ePHI and is similar to the data backup plan implementation specification for the Contingency Plans standard of the Administrative Safeguards, which requires CEs to implement procedures to create and maintain retrievable exact copies of ePHI.

The implementing disposal policies and procedures specification requires that there be a process that ensures that end-of-life electronic media that contains ePHI be rendered unusable and/or inaccessible prior to disposal. As discussed in Chapter 7, “Physical and Environmental Security,” options for disposal include disk wiping, degaussing, and physical destruction.

Instead of disposing of electronic media, entities may want to reuse it. The implementing reuse policies and procedures specifications require that there be a process to sanitize the media before reuse or reassignment. Often overlooked are hard drives in workstations or printers that are being recycled either within or outside of the organization. Don’t assume that because a policy states that ePHI isn’t stored on a local workstation that the drive doesn’t need to be cleaned. ePHI is found in the most unexpected of places, including hidden, temporary, cached, and Internet files as well as in metadata.

Technical safeguards include access controls, audit controls, integrity controls, authentication controls, and transmission security. There is a wide range of technology solutions that organizations can choose from to meet the implementation specifications. 45 CFR §164.306(b), the Security Standards: General Rules, Flexibility of Approach, clearly states that entities may take into account the cost of various measures in relation to the size, complexity, and capabilities of the organization. However, it is not permissible for entities to use cost as the sole justification for not implementing a standard.

The required unique user identification implementation specification mandates that each user and process be assigned a unique identifier. This can be a name and/or number. The naming convention is at the discretion of the organization. The objective of this specification is accountability. A unique identifier ensures that system activity and access to ePHI can be traced to a specific user or process.

The objective of establishing emergency access procedures is to ensure continuity of operations should normal access procedures be disabled or become unavailable due to system problems. Generally, this would be an administrator or super user account that has been assigned override privileges and cannot be locked out.

The objective of the implementing automatic logoff procedures specification is to terminate a session after a predetermined time of inactivity. The assumption here is that users might leave their workstations unattended, during which time any information their accounts have permission to access is vulnerable to unauthorized viewing. Although the implementation standard incorporates the term “logoff,” other mechanisms are acceptable. Examples of other controls include password-protected screen savers, workstation lock function, and disconnection of a session. Based on the risk analysis, it is up to the organization to determine both the “predetermined time of inactivity” as well as the method of termination.

The addressable specification to encrypting and decrypting data at rest is intended to add an additional layer of protection over and above assigned access permissions. NIST defines data at rest as data that resides in databases, file systems, flash drives, memory, and/or any other structured storage method. Encryption can be resource intensive and costly. The decision to encrypt data at rest should be based on the level of risk as determined by a thorough risk analysis. Regardless, there is no question that mobile devices and media should always be encrypted because the potential for loss, theft, or unauthorized access is high. Both the HITECH Act and the Omnibus Rule refer to unencrypted data as “unsecure data” and require that a breach or potential breach of unsecure data be disclosed.

Organizations must have the means available to monitor system activity in order to determine if a security violation has occurred. Audit controls can be automatic, manual, or a combination of both. For example, system logs may run continuously in the background while audit of a specific user activity may need to be manually initiated as the need arises. Most operating systems and applications have at least a minimum level of auditing as part of the feature set. The market is replete with third-party options. The Security Rule does not identify data that must be gathered by the audit controls or how often the audit reports should be reviewed. It is the responsibility of the entity to determine reasonable and appropriate audit controls for information systems that contain or use ePHI.

The earlier Access Control standard required identification for accountability. The Authentication standard requires identification for verification. As we discussed in Chapter 9, “Access Control Management,” the process of authentication requires the subject to supply identification credentials. The credentials are referred to as factors. There are three categories of factors: knowledge (something the user knows), possession (something a user has), and inherence (something the user is). Single-factor authentication is when only one factor is presented. The most common method of single-factor authentication is the password. Multifactor authentication is when two or more factors are presented. Multilayer authentication is when two or more of the same type of factors are presented. It is up to the CE to decide the appropriate approach. In all cases, users should receive training on how to protect their authentication credentials.

The HIPAA Rules generally require that covered entities and business associates enter into contracts with their business associates to ensure that the business associates will appropriately safeguard PHI. Contracts between a covered entity and its business associates must include the following criteria:

Establish the permitted and required uses and disclosures of PHI by the business associate.

Provide that the business associate will not use or further disclose the information other than as permitted or required by the contract or as required by law.

Require the business associate to implement appropriate safeguards to prevent unauthorized use or disclosure of the information, including implementing requirements of the HIPAA Security Rule with regard to ePHI.

Require the business associate to report to the CE any use or disclosure of the information not provided for by its contract, including incidents that constitute breaches of unsecured PHI.

Require the business associate to disclose PHI as specified in its contract to satisfy a CE’s obligation with respect to individuals’ requests for copies of their PHI, as well as make available PHI for amendments (and incorporate any amendments, if required) and accountings.

To the extent the business associate is to carry out a CE’s obligation under the Privacy Rule, require the business associate to comply with the requirements applicable to the obligation.

Require the business associate to make available to DHHS its internal practices, books, and records relating to the use and disclosure of PHI received from, or created or received by the business associate on behalf of, the CE for purposes of DHHS determining the CE’s compliance with the HIPAA Privacy Rule.

At termination of the contract, if feasible, require the business associate to return or destroy all PHI received from, or created or received by the business associate on behalf of, the covered CE.

Require the business associate to ensure that any subcontractors it may engage on its behalf that will have access to PHI agree to the same restrictions and conditions that apply to the business associate with respect to such information.

Authorize termination of the contract by the CE if the business associate violates a material term of the contract. Contracts between business associates and business associates that are subcontractors are subject to these same requirements.

A CE will be considered out of compliance if the entity knew of a pattern of an activity or practice of a business associate that constituted a material breach or violation of the business associate’s obligations, unless the CE took reasonable steps to cure the breach or end the violation. If such steps are unsuccessful, the CE must terminate the contract or arrangement, if feasible. If not feasible, the problem must be reported to the DHSS Secretary.

The other arrangements implementation specification is an exception and provides for alternatives to the contractual obligation requirement when both the CE and the business associate are government agencies. Provisions include a memorandum of understanding (MOU) and recognition of statutory obligations.

The policies and procedures must be sufficient to address the standards and implementation specifications and must accurately reflect the actual activities and practices of the CE, its staff, its systems, and its business associates. A CE may change its policies and procedures at any time, provided the changes are documented and implemented in accordance with the Documentation standard.

CEs are required to retain all documentation related to the Security Rule for a period of six years from the date of creation or the date it was last in effect, whichever is later. This requirement is consistent with similar retention requirements in the Privacy Rule.

Documentation must be easily accessible to all persons responsible for implementing the procedures to which the documentation pertains. This would include security professionals, systems administrators, human resources, contracts, facilities, legal, compliance, and training.

Documentation must be reviewed periodically and updated as needed in response to operational, personnel, facility, or environmental changes affecting the security of ePHI. Particular attention should be paid to version control.

The Modifications to the HIPAA Privacy, Security, Enforcement, and Breach Notification Rules under the HITECH Act and the Genetic Information Nondiscrimination Act; Other Modifications to the HIPAA Rules (known as the Omnibus Rule) was published January 25, 2013 with a compliance date of September 23, 2013. The Omnibus Rule finalizes the Privacy, Security, and Enforcement Rules that were introduced in HITECH, modifies the Breach Notification Rule, and expands the definition of “business associates.”

Prior to HITECH and the Omnibus Rule, the government had little authority to enforce the HIPAA regulations. Complicating matters was the fact that entire industry segments that stored, processed, transmitted, and accessed ePHI were not explicitly covered by the law. The 2013 Final Omnibus Rule made significant changes in coverage, enforcement, and patient protection in the following ways:

Expanding the definition of “business associates.”

Extending compliance enforcement to business associates and subcontractors of business associates.

Increasing violation penalties with potential fines, ranging from $25,000 to as much as $1.5 million.

Including provisions for more aggressive enforcement by the federal government and requiring the DHHS to conduct mandatory audits.

Granting explicit authority to state Attorneys General to enforce HIPAA Rules and to pursue HIPAA criminal and civil cases against HIPAA CEs, employees of CEs, or their business associates.

Defining specific thresholds, response timelines, and methods for security breach victim notification.

As reported in the January 23, 2013 Federal Register, the DHHS estimates that in the United States there one to two million business associates and an unknown number of subcontractors. Expanding the number of businesses subject to HIPAA regulations is so significant that it could alter the American security landscape.

The HITECH Act did not change the criminal penalties that may be assessed for violations of the Privacy and Security Rules. Those penalties remain $50,000 and one year in prison for knowing violations, $100,000 and five years in prison for violations committed under false pretenses, and $250,000 and ten years in prison for offenses committed for commercial or personal gain. Under the HITECH Act, criminal actions may be brought against anyone who wrongly discloses PHI, not just CEs or their employees. Also, the Act gives the DHHS OCR (in addition to the Department of Justice) the authority to bring criminal actions against these individuals.

The Act also allowed for prosecution of business associates. In January 2012, Minnesota Attorney General Lori Swanson became the first to charge a business associate with a HIPAA violation. On July 30, 2012 her office announced a settlement that required Accretive Health to stop doing business in Minnesota for two years and to pay approximately $2.5 million to the state, a portion of which will be used to compensate patients.

ePHI has been rendered unusable, unreadable, or indecipherable using an NIST-approved encryption method.

The decryption tools are stored on a device or at a location separate from the data they are used to encrypt or decrypt.

If a CE or business associate “secures” ePHI, as noted, and an unauthorized use or disclosure is discovered, the breach notice obligations do not apply. This exception is known as the Safe Harbor Provision. The term secure ePHI is specific to the Safe Harbor Provision and does not in any way modify an entity’s obligation to comply with the HIPAA Security Rule.

The nature and extent of the PHI involved, including the types of identifiers and the likelihood of re-identification.

The unauthorized person who used the PHI or to whom the disclosure was made, whether the PHI was actually acquired or viewed.

The extent to which the risk to the PHI has been mitigated.

Breach notification is not required if a CE or business associate concludes through a documented risk assessment that a low probability exists that the PHI has been compromised. Risk assessments are subject to review by federal and state enforcement agencies.

A description of the breach, including the date of the breach and date of discovery

The type of PHI involved (such as full name, social security number, date of birth, home address, or account number)

Steps individuals should take to protect themselves from potential harm resulting from the breach

Steps the CE is taking to investigate the breach, mitigate losses, and protect against future breaches

Contact procedures for individuals to ask questions or receive additional information, including a toll-free telephone number, email address, website, or postal address

CEs must notify DHHS of all breaches. Notice to DHHS must be provided immediately for breaches involving more than 500 individuals and annually for all other breaches. CEs have the burden of demonstrating that they satisfied the specific notice obligations following a breach, or, if notice is not made following an unauthorized use or disclosure, that the unauthorized use or disclosure did not constitute a breach.

The legislation was groundbreaking, yet many viewed it as another unfunded government mandate. Since adoption, the need to protect ePHI has become self-evident.

The HIPAA Security Rule and subsequent legislation applies to covered entities (CEs). CEs include healthcare providers, health plans, healthcare clearinghouses, and certain business associates. The Security Rule is organized into five categories: administrative safeguards, physical safeguards, technical safeguards, organizational requirements, and documentation requirements. Within these five categories are standards and implementation specifications. In this context, a standard defines what a CE must do; implementation specifications describe how it must be done. The rule says that a CE may use any security measures that allow it to reasonably and appropriately implement the standards and implementation specification, taking into account the size, complexity, and capabilities of the CE, the cost of the security measures, and the threat environment. The standards were meant to be scalable, meaning that they can be applied to a single-physician practice or to an organization with thousands of employees. The standards are technology neutral and vendor nonspecific. CEs are expected to choose the appropriate technology and controls for their unique environments.

There was minimal enforcement power associated with the original regulations. Subsequent legislation (HITECH and the Omnibus Rule) included provisions for aggressive civil and criminal enforcement by the Department of Health and Human Services (DHHS) and the Department of Justice. Fines were increased to up to $1.5 million dollars annually per violation category. Authority was granted to State Attorneys General to bring civil actions and obtain damages on behalf of state residents for violations of HIPAA Privacy and Security Rules. Recognizing the right of patients to know when their information was compromised, the Omnibus Rule codifies required incident response and breach notification requirements.

The HIPAA/HITECH/Omnibus requirements mirror information security best practices. Implementations benefit both providers and patients. Providers are protecting valuable information and information assets. Patients have peace of mind knowing that their trust is being honored.

A. The intent of the initial HIPAA legislation was to simplify and standardize the healthcare administrative process.

B. The intent of the initial HIPAA legislation was to lower healthcare costs.

C. The intent of the initial HIPAA legislation was to encourage electronic record sharing between healthcare providers.

D. The intent of the initial HIPAA legislation was to promote the continued use of paper-based patient records.

2. Which of the following statements best describes the intent of the Security Rule published in 2003?

A. The intent of the Security Rule was to detail privacy practices.

B. The intent of the Security Rule was to establish breach notification procedures.

C. The intent of the Security Rule was to publish standards to protect ePHI.

D. The intent of the Security Rule was to assign enforcement responsibilities.

3. In addition to healthcare providers, HIPAA/HITECH regulations apply to __________.

A. medical insurance companies

B. pharmacies

C. business associates

D. All of the above

4. Which of the following statements is not true?

A. HIPAA is technology neutral.

B. HIPAA is vendor specific.

C. HIPAA documentation must be saved for six years.

D. HIPAA is scalable.

5. Which of the following federal agencies is responsible for HIPAA/HITECH administration, oversight, and enforcement?

A. Department of Health and Human Services

B. Department of Energy

C. Department of Commerce

D. Department of Education

6. Which of the following is not a HIPAA/HITECH Security Rule category?

A. Documentation

B. Compliance

C. Physical

D. Technical

7. Which of the following statements is true?

A. All implementation specifications are required.

B. All implementation specifications are optional.

C. Implementation specifications are either required or addressable.

D. Addressable specifications are optional.

8. Which of the following statements best defines a business associate?

A. A business associate is a person or organization that creates, stores, processes, accesses, or transmits data on behalf of the CE.

B. A business associate is a healthcare provider with whom patient information is shared in the course of treatment.

C. A business associate is an employee who creates, stores, processes, or transmits data on behalf of the CE.

D. A business associate is a person or organization that provides any service to the CE.

9. In the context of HIPAA/HITECH, which of the following is not a factor to be considered in the determination of “reasonable and appropriate” security measures?

A. Size of the CE

B. Level of risk

C. Geographic location of the CE

D. Complexity of implementation

10. The Security Rule does not dictate a specific risk assessment methodology; however, the Department of Health and Human Services implementation and training guidance references which of the following methodologies?

A. NIST 800-30: Risk Management Guide for Information Technology Systems

B. OCTAVE

C. FAIR

D. ISO 27002:2013

11. Which of the following statements is true of the role of a HIPAA Security Officer?

A. The role of a HIPAA Security Officer is optional.

B. The role of a HIPAA Security Officer can be performed by a committee.

C. The role of a HIPAA Security Officer is accountable by law for compliance.

D. The role of a HIPAA Security Officer must be assigned to a designated individual.

12. Which of the following statements best defines authorization?

A. Authorization is the process of positively identifying a user or system.

B. Authorization is the process of granting users or systems a predetermined level of access to information resources.

C. Authorization is the process of determining who accessed a specific record.

D. Authorization is the process of logging the access and usage of information resources.

13. Which of the following statements is false?

A. Identity-based access is granted by username.

B. Role-based access is granted by job or function.

C. Group-based access is granted by membership.

D. Clinical-based access is granted by patient name.

14. Which of the following would be considered an optional topic for workforce security training?

A. Malware protection

B. Login procedures

C. Organizational HIPAA compliance penalties

D. Password management

15. Users should be trained to recognize and _________ a potential security incident.

A. report

B. contain

C. recover from

D. eradicate

16. Which of the following statements is true of HIPAA compliance?

A. HIPAA certification is granted by DHHS.

B. HIPAA accreditation is granted by the Joint Commissions for Hospital Accreditation (JCAHO).

C. There is no formal HIPAA/HITECH certification or accreditation process.

D. CEs must complete an annual self-assessment and submit it to the Centers for Medicare and Medicaid Services (CMS).

17. Which of the following statements is true of a business associate’s HIPAA/HITECH compliance requirements?

A. A business associate’s HIPAA/HITECH compliance requirements are the same as a healthcare provider.

B. A business associate’s HIPAA/HITECH compliance requirements are limited to what is in the BA agreement.

C. A business associate’s HIPAA/HITECH compliance requirements are not as stringent as those of a healthcare provider.

D. A business associate’s HIPAA/HITECH compliance requirements are exempt if the organization’s annual gross revenue is less than $500,000.

18. According to the workstation security standard, when users leave their workstation unattended, they should _____________.

A. do nothing

B. lock the workstation

C. log out

D. turn off their monitor

19. Which of the following is not an acceptable end-of-life disposal process for media that contains ePHI?

A. Permanently wipe it

B. Shred it

C. Recycle it

D. Crush it

20. Granting the minimal amount of permissions necessary to do a job reflects the security principle of ___________.

A. Need-to-know

B. Deny all

C. Allow some

D. Least privilege

21. Both the HITECH Act and the Omnibus Rule refer to “unsecure data,” which means data __________.

A. in motion

B. with weak access controls

C. that is unencrypted

D. stored in the cloud

22. Which of the following protocols/mechanisms cannot be used for transmitting ePHI?

A. SSL

B. SFTP

C. Encrypted email

D. HTTP

23. HIPAA-related documentation must be retained for a period of ______ years from the date of creation or the date it was last in effect, whichever is later.

A. two

B. four

C. six

D. eight

24. Which of the following changes was not introduced by the Omnibus Rule?

A. The Omnibus Rule expanded the definition of a business associate.

B. The Omnibus Rule explicitly denied enforcement authority to State Attorneys General.

C. The Omnibus Rule increased violation penalties.

D. The Omnibus Rule defined breach notification requirements.

25. Effective September 2013, subcontractors of business associates _____________.

A. are considered business associates

B. are granted limited liability

C. are not considered a covered entity

D. are exempt from HIPAA/HITECH regulations if they are considered a small business

26. Which of the following is not a Security Rule violation category?

A. Did not know

B. Did not cause

C. Willful neglect – corrected

D. Willful neglect – not corrected

27. The “safe harbor” provision applies to __________.

A. encrypted data

B. key management

C. dual control

D. de-identified data

28. Which of the following is not required to be included in a breach notification?

A. A description of the breach

B. The type of ePHI involved

C. Contact information for questions pertaining to the incident

D. Who was responsible for the breach

29. A HIPAA standard defines what a covered entity must do; implementation specifications ___________________________.

A. describe the technology that must be used

B. describe how it must be done and/or what it must achieve

C. describe who must do it

D. describe the tools that must be used

30. Subsequent legislation increased the maximum fines for HIPAA/HITECH violations to ______________________.

A. up to $50,000 annually per violation category

B. up to $100,000 annually per violation category

C. up to $1,000,000 annually per violation category

D. up to $1,500,000 annually per violation category

1. Explain the difference between the intent of the HIPAA Privacy and HIPAA Security Rules.

2. Which of the security principles—confidentiality, integrity, and/or availability—does the Privacy Rule apply to?

3. Which of the security principles—confidentiality, integrity, and/or availability—does the Security Rule apply to?

Exercise 14.2: Understanding Covered Entities

1. In your geographic area, identify a healthcare provider organization that is subject to HIPAA Security Rule regulations.

2. In your geographic area, identify a business associate that is subject to HIPAA Security Rule regulations.

3. In your geographic area, identify either a health plan or a healthcare clearinghouse that is subject to HIPAA Security Rule regulations.

Exercise 14.3: Identifying Key Factors for HIPAA/HITECH Compliance

1. Explain why it is important to maintain an inventory of ePHI.

2. Explain why it is important to conduct HIPAA-related risk assessments.

3. Explain why it is important to obtain senior management support.

Exercise 14.4: Developing Security Education Training and Awareness

1. Senior leadership needs to be educated on HIPAA/HITECH requirements. Research and recommend a conference they should attend.

2. A HIPAA security officer needs to stay informed on compliance issues. Research and recommend a peer organization to join, a publication to subscribe to, or an online forum to participate in.

3. The workplace needs to be trained on login monitoring, password management, malware, and incident reporting. Research and recommend an online training program.

Exercise 14.5: Creating Documentation Retention and Availability Procedures

1. All HIPAA-related documentation must be retained for a minimum of six years. This includes policies, procedures, contracts, and network documentation. Assuming you will revise the documentation, devise a standard version control procedure.

2. Recommend a way to store the documentation.

3. Recommend a secure, efficient, and cost-effective way to make the documentation available to appropriate personnel.

You have been tasked with designing a HIPAA security program manual.

1. Write a manual for any one of the following CEs:

A 100-bed hospital in a metropolitan location.

A consortium of three nursing homes. The nursing homes share administrative and clinical staff. They are all connected to the same network.

A multi-specialty medical practice consisting of 29 physicians.

2. Write an introduction to the manual explaining what the HIPAA Security Rule is and why compliance is required.

3. Design a table of contents (TOC). The TOC should correspond to the regulations.

4. For each entry in the TOC, assign development of the corresponding policy or procedure to a specific role in the organization (for example, human resources, building maintenance).

Project 14.2: Assessing Business Associates

A business associate is a person or entity that creates, receives, maintains, transmits, accesses, or has the potential to access PHI to perform certain functions or activities on behalf of a CE.

1. How did HITECH and the Omnibus Rule impact business associates?

2. Identify a “business associate” organization either online or locally. Locate any policies or statements that lead you to believe that they recognize their regulatory obligations. What type of due diligence should a CE conduct in order to ascertain HIPAA/HITECH compliance?

3. Find an example of business associate organizations that were charged by either the FTC or a State Attorney General with a HIPAA/HITECH violation.

Project 14.3: Developing a HIPAA Training Program

HIPAA requires that all workforce members receive annual training related to safeguarding ePHI. You have been tasked with developing an instructor-led training module. Your topic is “Disrupting the Malware Distribution Channel.”

1. Develop and deliver a training presentation (and post-training quiz) on the topic. The presentation should be at least ten minutes long. It should be interactive and engage the attendees.

2. Have participants complete the quiz. Based on the results, evaluate the effectiveness of the training.

3. Prepare a security awareness infographic about malware and incident reporting. The purpose of the infographic is to reinforce the training lesson.

“45 CFR Parts 160 and 164 (19006-19010): Breach Notification Guidance,” Federal Register, Vol. 74, No. 79, April 27, 2009, Department of Health and Human Services.

“Modifications to the HIPAA Privacy, Security, Enforcement, and Breach Notification Rules 45 CFR Parts 160 and 164 Under the Health Information Technology for Economic and Clinical Health Act and the Genetic Information Nondiscrimination Act; Other Modifications to the HIPAA Rules; Final Rule,” Federal Register, Vol. 78, No. 17, January 25, 2013.

“2 – Security Standards, Administrative Safeguards,” HIPAA Security Series, Department of Health and Human Services, Volume 2 / Paper 2, Rev 3/2007.

“3 – Security Standards, Physical Safeguards,” HIPAA Security Series, Department of Health and Human Services, Volume 2 / Paper 3, Rev 3/2007.

“4 – Security Standards, Technical Safeguards,” HIPAA Security Series, Department of Health and Human Services, Volume 2 / Paper 2, Rev 3/2007.

“6 – Basics of Risk Analysis and Risk Management,” HIPAA Security Series, Department of Health and Human Services, Volume 2 / Paper 6, Rev 3/2007.

“Addressing Encryption of Data at Rest in the HIPAA Security Rule and EHR Incentive Program Stage 2 Core Measures,” Healthcare Information and Management Systems Society, December 2012.

Alston & Bird, LLP. “Overview of HIPAA/HITECH Act Omnibus Final Rule Health Care Advisory,” January 25, 2013, accessed 09/2013, www.alston.com/advisories/healthcare-hipaa/hitech-act-omnibus-finalrule.

“Certification and HER Incentives, HITECH ACT,” accessed 09/2013, www.healthit.gov/policy-researchers-implementers/hitech-act-0.

“Guide to Privacy and Security of Health Information,” Office of the National Coordinator for Health Information Technology, Version 1.2, 060112.

Foley Lardner, LLP, “ Minnesota Attorney General Reaches First Settlement with Business Associate Under HITECH Act,” Legal News: Health Care, August 2, 2012, accessed 9/2013, www.foley.com/minnesota-attorney-general-reaches-first-settlement-with-business-associate-under-hitech-act-08-02-2012/.

“HHS Strengthens HIPAA Enforcement,” accessed 09/2013, www.hhs.gov/news/press/2009pres/10/20091030a.html.

“HIPAA Omnibus Final Rule Information,” accessed 09/2013, http://hipaa-hitech-center.com/hipaa-omnibus-final-rule/.

“HIPAA Omnibus Rule Summary,” accessed 09/2013, http://www.hipaasurvivalguide.com/hipaa-omnibus-rule.php.

“HIPAA Security Rule: Frequently asked questions regarding encryption of personal health information,” American Medical Association, 2010.

“HIPAA Timeline,” accessed 10/2013, www.hipaaconsultant.com/hipaa-timeline.

McDermott Will & Emery, LLP. “New HIPAA Regulations Affect Business Associates and Subcontractors,” February 11, 2013, accessed 09/2013, www.mwe.com/New-HIPAA-Regulations-Affect-Business-Associates-and-Subcontractors-02-11-2012/.

Monegain, Bernie. “Connecticut AG sues Health Net over security breach,” Healthcare IT News January 12, 2010, accessed 09/2013, www.healthcareitnews.com/news/connecticut-ag-sues-health-net-over-security-breach.

McDermott Will & Emery, LLP. “OCR Issues Final Modifications to the HIPAA Privacy, Security, Breach Notification and Enforcement Rules to Implement the HITECH Act,” February 20, 2013, accessed 10/2013, www.mwe.com/OCR-Issues-Final-Modifications-to-the-HIPAA-Privacy-Security-Breach-Notification-and-Enforcement-Rules-to-Implement-the-HITECH-Act.

Monegain, Bernie. “Connecticut AG fines Health Net $250,000 for data security violations,” Healthcare IT News, July 7, 2010, accessed 09/2013, www.healthcarefinancenews.com/news/connecticut-ag-fines-health-net-250000-data-security-violations.

“The HITECH ACT,” accessed 09/2013, www.hipaasurvivalguide.com/hitech-act-summary.php.

“The Privacy Rule,” U.S. Department of Health and Human Services, accessed 09/2013, www.hhs.gov/ocr/privacy/hipaa/administrative/privacyrule.