WHAT HAPPENS WHEN THE AUDIT ALARM GOES OFF…
The obvious business case beyond regulatory compliance with the HIPAA Security Rule is the professional responsibility to protect each patient’s personal health information as you would your own. Real and damaging repercussions to your organization for inadvertent or intentional breaches of protected health information drive the need to implement an effective risk management program.
Health information data breaches are increasing in number and in magnitude. The fraudulent use or sale of personal health information is also on the rise. PHI breaches can cause significant harm, both to the individuals whose information was breached and to the organizations responsible for protecting it.
Every covered entity and their business associates must comply with administrative, technical , and physical controls that are mandated by the HIPAA Security Rule.
At a minimum, there is a requirement to: assess current security controls & security risks, to identify security gaps, develop an implementation plan to close security gaps, & notify the Secretary of Health and Human Services if a breach of PHI for more than 500 patients occurs in your organization or by one of your business associates.
Whether intentional or unintentional, significant breaches result in audits, financial penalties and loss of reputation in the community. The clock is ticking. Isn’t worth your time to make security risk management a priority in your organization?
KeySys Health will help you achieve your HIPAA Compliance requirements for Meaninful Use attestation & create an adaptive Risk Management program to your practice.
“Let KeySys Health assist you in developing and implementing HIPAA compliant policies, procedures & plans”
It is an understatement to say that Healthcare has experienced a massive amount of change over the past several years. With recent legislation providing incentives to move to a complete electronic environment many covered entities are taking advantage. One thing is for certain the environment for exposure to risk for a covered healthcare entity is rising with the changes occurring. That is why recent legislation has been reinforcing and expanding the requirements previously adopted in the HIPPA Security Rule.
- Online blueprint of activities reduces complexity, confusion, and guess work of HIPAA/HITECH compliance
- Library of remediation activities, policies and procedures jumpstarts your risk management program
- Built-in security, privacy and data breach requirements provide a foundation that supports on-going compliance
- Automate workflows and manage reports on compliance status for audit readiness
In working with covered entity clients and their business associates, who are also subject to the HIPAA Privacy and Security Rules, it is evident that there is a lot of misunderstanding about which standards and specifications must be implemented to comply with HIPAA. This snapshot is an excerpt from the CMS web site that clarifies the requirements. Some phrases and sentences are bolded for emphasis. Now that the HIPAA Omnibus Final Rule has been published, clearly business associates must implement all the same requirements as covered entities.
“To understand the requirements of the Security Rule, it is helpful to be familiar with the basic concepts that comprise the security standards and implementation specifications. The Security Rule is divided into six main sections – each representing a set of standards and implementation specifications that must be addressed by all covered entities. Each Security Rule standard is a requirement: a covered entity must comply with all of the standards of the Security Rule with respect to the EPHI it creates, transmits or maintains.
Many of the standards contain implementation specifications. An implementation specification is a more detailed description of the method or approach covered entities can use to meet a particular standard. Implementation specifications are either required or addressable.
- A required implementation specification is similar to a standard, in that a covered entity must comply with it. For example, all covered entities including small providers must conduct a “Risk Analysis” in accordance with Section 164.308(a)(1) of the Security Rule.
- For addressable implementation specifications, covered entities must perform an assessment to determine whether the specification is a reasonable and appropriate safeguard in the covered entity’s environment. After performing the assessment, a covered entity decides if it will implement the addressable implementation specification; implement an equivalent alternative measure that allows the entity to comply with the standard; or not implement the addressable specification or any alternative measures, if equivalent measures are not reasonable and appropriate within its environment.
Covered entities are required to document these assessments and all decisions. For example, all covered entities including small providers must determine whether “Encryption and Decryption” is reasonable and appropriate for their environment in accordance with Section 164.312(a)(1) of the Security Rule.
- Factors that determine what is “reasonable” and “appropriate” include cost, size, technical infrastructure and resources. While cost is one factor entities must consider in determining whether to implement a particular security measure, some appropriate measure must be implemented.
An addressable implementation specification is not optional, and the potential cost of implementing a particular security measure does not free covered entities from meeting the requirements identified in the rule.
Information Source :: Download Newsletter