HIPAA Compliance Certification FAQ

Question 1 : How will we know if our organization and our systems are compliant with the HIPAA Security Rule's requirements?

The purpose of the final rule is to adopt national standards for safeguards to protect the confidentiality, integrity, and availability of electronic protected Health information (EPHI) that is collected, maintained, used or transmitted by a covered entity. Compliance is different for each organization and no single strategy will serve all covered entities.

Covered entities should look to § 164.306 of the Security Rule for guidance to support decisions on how to comply with the standards and implementation specifications contained in §§ 164.308, 164.310, 164.312, 164.314, and 164.316. In general, this includes performing a risk analysis; implementing reasonable and appropriate security measures; and documenting and maintaining policies, procedures and other required documentation.

Compliance is not a one-time goal, it must be maintained. Compliance with the evaluation standard at § 164.308(a)(8) will allow covered entities to maintain compliance. By performing a periodic technical and nontechnical evaluation of the information security environment, a covered entity will be able to better ensure the security of EPHI.

Question 2 : In the final Security Standards Rule published in the Federal Register on February 20, 2003, what is the difference between addressable and required specifications?

If an implementation specification is described as “required”, the specification must be implemented. The concept of “addressable implementation specifications” was developed to provide covered entities additional flexibility with respect to compliance with the security standards.

In meeting standards that contain addressable implementation specifications, a covered entity will do one of the following for each addressable specification: (a) implement or the addressable implementation specifications; (b) implement one or more alternative security measures to accomplish the same purpose; (c) not implement either an addressable implementation specification or an alternative.

The covered entity must decide whether a given addressable implementation specification is a reasonable and appropriate security measure to apply within its particular security framework. This decision will depend on a variety of factors, such as, among others, the entity’s risk analysis, risk mitigation strategy, what security measures are already in place, and the cost of implementation. The decisions that a covered entity makes regarding addressable specifications must be documented.

Question 3 : What is the purpose of the HIPAA Security Standards rule and why were security standards needed as published in the Federal Register on February 20, 2003?

The purpose of this Security Standards rule is to adopt national standards for safeguards to protect the confidentiality, integrity, and availability of electronic protected health information. They were needed because there were no standard measures existing in the health care industry that addressed all aspects of the security of electronic protected health information while it is in use, in storage, or during the exchange of that information between entities. HIPAA mandated security standards to protect an individual’s health information while permitting the appropriate access and use of that information by health care providers, clearinghouses, and health plans.

Question 4 : What does the HIPAA Security Rule require a covered entity to do to comply with the Security Incidents Procedures standard?

45 CFR § 164.304 defines security incident as the attempted or successful unauthorized access, use, disclosure, modification, or destruction of information or interference with system operations in an information system. The Security Incident Procedures standard at § 164.308(a)(6)(i) requires a covered entity to implement policies and procedures to address security incidents. The associated implementation specification for response and reporting at § 164.308(a)(6)(ii) requires a covered entity to identify and respond to suspected or known security incidents, mitigate, to the extent practicable, harmful effects of security incidents that are known to the covered entity, and document security incidents and their outcomes.

In order to maintain a flexible, scalable and technology neutral approach to the Security Rule, no single method is identified for addressing security incidents that will apply to all covered entities. As stated in the preamble to the Security Rule, 68 Fed. Reg. 8350, an entity should be able to rely upon the information gathered in complying with the other security standards, for example, its risk assessment and risk management procedures and the Privacy Rule standards, to determine what constitutes a security incident in the context of its business operations.

In addressing the security incident procedures standard, a covered entity may consider some of the following questions: what specific actions would be considered security incidents; how will incidents be documented and reported; what information should be contained in the documentation; how often and to whom should incidents be reported; what are the appropriate responses to certain incidents; and whether identifying patterns of attempted security incidents is reasonable and appropriate.

When taking into consideration the requirements of §§ 164.306(a) and (b), and its risk analysis, the covered entity may decide that certain types of attempted or successful security incidents or patterns of attempted or successful incidents warrant different actions. For example, a covered entity may decide that a “ping” (a request-response utility used to determine whether a specific Internet Protocol (IP) address, or host, exists or is accessible) on the communications network initiated from an external source would require the following actions to comply with the standard; (1) minimal, if any, response; (2) no mitigation actions since no harmful effects were caused by the incident; and (3) brief documentation of the security incident and outcome, such as, a recording of aggregate statistical information. Based on its analysis, the entity may also determine that other types of incidents, such as suspicious patterns of “pings” on the communications network initiated from an external source or a specific malicious security incident would require a more detailed response, mitigation steps, and more detailed documentation of the incident and outcome.

While internal reporting of security incidents is an inherent part of security incident policies and procedures, the Security Rule generally does not require a covered entity to report incidents to outside entities. However, 45 CFR §§ 164.314(a)(2)(i)(C) and 164.314(b)(2)(iv) require contracts between a covered entity and a business associate, and plan documents of a group health plans, respectively, to include provisions that require business associates and plan sponsors to report to the covered entity any security incidents of which they become aware. (Note that in certain circumstances a group health plan may not be required to amend its plan documents. See § 164.314(b)(1).)

Question 5 : Who will enforce the HIPAA standards?

The Department of Health and Human Services (HHS) has determined that CMS will have responsibility for enforcing the transactions and code set standards, as well as security and identifies standards, including the Employer Identification Number (EIN) and the National Provider Identifier (NPI). The Office for eHealth Standards and Services within CMS is responsible for all enforcement activities for the above-mentioned rules, while the Office for Civil Rights in HHS is responsible for enforcing the HIPAA privacy rule.

Question 6 : What will the HIPAA enforcement process look like?

Enforcement of the transactions and code sets, security, and unique identifier standards of the Health Insurance Portability and Accountability Act of 1996 (HIPAA) will be primarily complaint-driven. Upon receipt of a complaint, CMS will notify the filed against covered entity of the complaint, and provide them with an opportunity to demonstrate compliance, or to submit a corrective action plan. If the covered entity does neither, CMS will have the discretion to impose civil monetary penalties.

Question 7 : What is the difference between Risk Analysis and Risk Management in the HIPAA Security Rule?

Risk analysis is the assessment of the risks and vulnerabilities that could negatively impact the confidentiality, integrity, and availability of the electronic protected health information (EPHI) held by a covered entity, and the likelihood of occurrence.

The risk analysis may include inventorying of all systems and applications that are used to access and house data, and classifying them by level of risk. A thorough and accurate risk analysis would consider all relevant losses that would be expected if the security measures were not in place, including loss or damage of data, corrupted data systems, and anticipated ramifications of such losses or damage.

Risk management is the actual implementation of security measures to sufficiently reduce an organization’s risk of losing or compromising its (EPHI) and to meet the general security standards.

Question 8 : Are small providers exempt from HIPAA?

The term “small providers” originates in the Administrative Simplification Compliance Act (ASCA), the law which requires those providers/submitters who bill Medicare to begin submitting only electronic claims to Medicare on October 16, 2003, in the HIPAA format. However, ASCA does provide an exception to the Medicare electronic claims submission requirements to “small providers”. ASCA defines a small provider or supplier as a provider of services with fewer than 25 full-time equivalent employees or a physician, practitioner, facility or supplier (other than a provider of services) with fewer than 10 full-time equivalent employees.

It is important to keep in mind that this provision does not preclude providers from submitting paper claims to other health plans. In addition, if a provider transmits any of the designated transactions electronically, it is subject to the HIPAA Administrative Simplification requirements regardless of size.

Question 9 : What is the purpose of the National Provider Identifier (NPI)? Who must use it, and when?

The purpose of the National Provider Identifier (NPI) is to uniquely identify a health care provider in standard transactions, such as health care claims. NPIs may also be used to identify health care providers on prescriptions, in internal files to link proprietary provider identification numbers and other information, in coordination of benefits between health plans, in patient medical record systems, in program integrity files, and in other ways. HIPAA requires that covered entities (i.e., health plans, health care clearinghouses, and those health care providers who transmit any health information in electronic form in connection with a transaction for which the Secretary of Health and Human Services has adopted a standard) use NPIs in standard transactions by the compliance dates. The compliance date for all covered entities except small health plans was May 23, 2007; the compliance date for small health plans was May 23, 2008. As of the compliance dates, the NPI is the only health care provider identifier that can be used for identification purposes in standard transactions by covered entities.

Question 10 : How could a small provider implement the security standards as published in the Federal Register on February 20, 2003?

The security standards regulation allows any covered entity (including small providers) to use any security measures that allow the covered entity to reasonably and appropriately implement the standards. In deciding what security measures to use, a covered entity can take into account its size, capabilities, and costs of security measures.

A small provider who is a covered entity would first assess their security risks and vulnerabilities and the mechanisms currently in place to mitigate those risks and vulnerabilities. Following this assessment, they would determine what additional measures, if any, need to be taken to meet the standards; taking into account their capabilities and the cost of those measures.

Question 11 : Is mandatory encryption in the HIPAA Security Rule?

No. The final HIPAA Security Rule made the use of encryption an addressable implementation specification. See 45 CFR §§ 164.312(a)(2)(iv) and 164.312(e)(2)(ii). Covered entities use open networks such as the Internet and e-mail systems differently, and no single interoperable encryption solution for communicating over open networks exists. Setting a single encryption standard could have placed an unfair financial and technical burden on some covered entities. The encryption implementation specification is addressable, and must therefore be implemented if, after an assessment, the entity has determined that the specification is a reasonable and appropriate safeguard in its environment. If the entity decides that the addressable implementation specification is not reasonable and appropriate, it must document that determination and implement an equivalent alternative measure, presuming that the alternative is reasonable and appropriate, or if the standard can otherwise be met, the covered entity may choose to not implement the implementation specification or any equivalent alternative measure.

Question 12 : What does the HIPAA Security Rule require a covered entity to do to comply with the Security Incidents Procedures standard?

45 CFR § 164.304 defines security incident as the attempted or successful unauthorized access, use, disclosure, modification, or destruction of information or interference with system operations in an information system. The Security Incident Procedures standard at § 164.308(a)(6)(i) requires a covered entity to implement policies and procedures to address security incidents. The associated implementation specification for response and reporting at § 164.308(a)(6)(ii) requires a covered entity to identify and respond to suspected or known security incidents, mitigate, to the extent practicable, harmful effects of security incidents that are known to the covered entity, and document security incidents and their outcomes.

In order to maintain a flexible, scalable and technology neutral approach to the Security Rule, no single method is identified for addressing security incidents that will apply to all covered entities. As stated in the preamble to the Security Rule, 68 Fed. Reg. 8350, an entity should be able to rely upon the information gathered in complying with the other security standards, for example, its risk assessment and risk management procedures and the Privacy Rule standards, to determine what constitutes a security incident in the context of its business operations.

In addressing the security incident procedures standard, a covered entity may consider some of the following questions: what specific actions would be considered security incidents; how will incidents be documented and reported; what information should be contained in the documentation; how often and to whom should incidents be reported; what are the appropriate responses to certain incidents; and whether identifying patterns of attempted security incidents is reasonable and appropriate.

When taking into consideration the requirements of §§ 164.306(a) and (b), and its risk analysis, the covered entity may decide that certain types of attempted or successful security incidents or patterns of attempted or successful incidents warrant different actions. For example, a covered entity may decide that a “ping” (a request-response utility used to determine whether a specific Internet Protocol (IP) address, or host, exists or is accessible) on the communications network initiated from an external source would require the following actions to comply with the standard; (1) minimal, if any, response; (2) no mitigation actions since no harmful effects were caused by the incident; and (3) brief documentation of the security incident and outcome, such as, a recording of aggregate statistical information. Based on its analysis, the entity may also determine that other types of incidents, such as suspicious patterns of “pings” on the communications network initiated from an external source or a specific malicious security incident would require a more detailed response, mitigation steps, and more detailed documentation of the incident and outcome.

While internal reporting of security incidents is an inherent part of security incident policies and procedures, the Security Rule generally does not require a covered entity to report incidents to outside entities. However, 45 CFR §§ 164.314(a)(2)(i)(C) and 164.314(b)(2)(iv) require contracts between a covered entity and a business associate, and plan documents of a group health plans, respectively, to include provisions that require business associates and plan sponsors to report to the covered entity any security incidents of which they become aware. (Note that in certain circumstances a group health plan may not be required to amend its plan documents. See § 164.314(b)(1).)

Question 13 : What are some examples of threats that covered entities should address when conducting their risk analysis in order to comply with the Security Rule?

The risk analysis process will identify potential security risks to electronic protected health information (EPHI), also called threats. The threats a covered entity decides to address will depend on which threats would affect the confidentiality, integrity, and/or availability of EPHI. Threats may affect information (data) and systems. The National Institute for Standards and Technology (NIST) provides information security guidance materials for federal agencies. Some NIST documents may not be relevant to small organizations, as they are intended more for large, governmental organizations. One such document, Special Publication (SP) 800-30, Risk Management Guide for Information Technology Systems categorizes threats into three common categories: Human, Natural, and Environmental. The list below is adapted from this NIST SP and is not comprehensive, but rather a sampling of possible threat categories and associated threats.

1. Natural: Floods, earthquakes, tornadoes, landslides, avalanches, electrical storms, and other such events.
2. Human: Events that are either enabled by or caused by human beings, such as unintentional acts (inadvertent data entry) or deliberate actions (network based attacks, malicious software upload, unauthorized access to confidential information).
3. Environmental: Long-term power failure, pollution, chemicals, and liquid leakage.

An example of a natural threat is the occurrence of a hurricane. Depending on the geographic location of the entity, the likelihood of that occurrence could be low, medium, or high, and one of the risks of the occurrence may be that the power could fail and the information systems could be unavailable. Based on the assessment conducted, the organization should develop a strategy to deal with the potential threat.

Question 14 : Are we required to "certify" our organization's compliance with the security standards?

No, there is no standard or implementation specification that requires a covered entity to “certify” compliance. The evaluation standard § 164.308(a)(8) requires covered entities to perform a periodic technical and nontechnical evaluation that establishes the extent to which an entity’s security policies and procedures meet the security requirements.

The evaluation can be performed internally by the covered entity or by an external organization that provide evaluations or “certification” services. A covered entity may make the business decision to have an external organization perform these types of services. It is important to note that HHS does not endorse or otherwise recognize private organizations’ “certifications,” and such certifications do not absolve covered entities of their legal obligations under the Security Rule. Moreover, performance of a “certification” by an external organization does not preclude HHS from subsequently finding a security violation.