What is the difference between a HIPAA Gap Analysis and a HIPAA Risk Analysis? Many organizations use these interchangeably, however, they are not correct in doing so. Don?t make the same mistake. We can help you understand the difference.
Office of Civil Rights Requirements
The Office for Civil Rights clearly spelled out the steps and requirements for a HIPAA Security Risk Analysis. As a result, it requires covered entities to conduct an accurate and thorough assessment. It must consider potential risks and vulnerabilities to the confidentiality, integrity and availability of electronic protected health information held by the organization. Furthermore, entities must consider the potential risks, threats and vulnerabilities to all of the covered entities ePHI. This includes all ePHI which is created received, maintained or transmitted, including the source or location of the ePHI
Understanding a HIPAA Gap Analysis
The HIPAA Rule does not require a HIPAA Gap Analysis. The Gap Analysis is usually a limited evaluation of a covered entity or business associate?s organization to reveal whether there are certain policies, controls or safeguards required by the HIPAA. As a result, it is important rules are in place and implemented. The HIPAA Gap analysis should begin with a review of all policies, procedures, processes, practices and systems. It must investigate all facilities that relate to privacy, uses and disclosures of PHI.
Gap Analysis Insufficient for HIPAA Rule
A Gap Analysis does not satisfy the Security Risk Analysis requirement. It does not demonstrate an accurate and thorough analysis. In effect, it must consider all risks, threats and vulnerabilities to all of the ePHI an entity creates, receives, maintains or transmits. Consequently, the gap analysis is not equivalent to the risk analysis as it does not satisfy the rule as specified by 45 C.F.R. ?164.308(a)(ii)(A). It is important to note that OCR expects a covered entity to document and implement all of the necessary regulations of the HIPAA Rule to obtain a Compliant rating.
Therefore, it is important to identify your covered entity?s needs and determine whether you require a Gap Analysis or Risk Analysis. Assure that the vendor you engage is qualified to perform the specific type of analysis that you need.
HIPAA technical safeguards protect PHI and have become a major part of any HIPAA Privacy program. Technical safeguards are important due to constant technology advancements in the health care industry. They are key elements that help to maintain the safety of EPHI as the internet changes. One of the greatest challenges of healthcare organizations face is that of protecting electronic protected health information (EPHI). This would include protection of electronic health records, from various internal and external risks. To best reduce risks to EPHI, covered entities must implement technical safeguards.
The Security Rule
The Security Rule was adopted to implement provisions of the Health Insurance Portability and Accountability Act of 1996 (HIPAA). One of the key facets of the rule are the Technical Safeguards. These are meant to protect EPHI and are a major part of any HIPAA Security plan. The HIPAA Security Rule indicates that technical safeguards are ?the technology and the policy and procedures for its use that protect electronic protected health information and control access to it.? All covered entities and business associates must use technical safeguards to ?reasonably and appropriately implement necessary standards to protect PHI.? All entities must decide which measures are reasonable and appropriate for their organization to accomplish the task.
Cybersecurity is the art of protecting networks, devices and data form unauthorized access or criminal use and the practice of ensuring confidentiality, integrity, and availability of information. Using cybersecurity to protect EPHI is a key feature of Technical Safeguards in the Security Rule of HIPAA. Technical safeguards are key protections due to constant technology advancements in the health care industry. They are key elements that help to maintain the safety of EPHI as the internet changes. One of the greatest challenges of healthcare organizations face is that of protecting electronic protected health information (EPHI). This includes protection of electronic health records, from various internal and external risks. To best reduce risks to EPHI, covered entities must implement Technical Safeguards.
There are many risks, and these come in various forms. Among these are malware erasing your entire system, a cyber-attacker breaching your system and altering files, a cyber-hijacker using your computer to attack others, or an attacker stealing or freezing your data in return for money. There is no guarantee that even with the best precautions you will prevent this, but there are steps you can take to minimize the chances.
Reasonable Safeguards for PHI are precautions that a prudent person must take to prevent a disclosure of Protected Health Information. To protect all forms of PHI,verbal, paper, and electronic, providers must apply these safeguards. They help prevent unauthorized uses or disclosures of PHI. In addition safeguards must be part of every privacy compliance plan. Organizations must share this with all members of the organization.
An organization may face multiple challenges as it attempts to protect EPHI. These issues must all be considered as they may originate from inside or outside the organization. It is important for any organization to perform a full risk analysis to protect the organization from such a variety of threats. We present several examples of cyberthreats in healthcare you must be ready to address. This will help you as you develop your Security Program. First, we must understand Technical Safeguards of the Security Rule.
Define “Technical Safeguards”
Comply with Technical Safeguards
The Security Rule defines technical safeguards in ? 164.304 as ?the technology and the policy and procedures for its use that protect electronic protected health information and control access to it.?
The Security Rule is based on several fundamental concepts. These concepts include:
Therefore, no specific requirements for types of technology to implement are identified. The Rule allows a covered entity to use any security measures that allows it to reasonably and appropriately implement the standards and implementation specifications. A covered entity must determine which security measures and specific technologies are reasonable and appropriate for implementation in its organization based on their size and resources.
Solutions vary in nature depending on the organization. The Security Rule requires that reasonable and appropriate measures must be implemented and that the General Requirements of the rule must be met. That is the most important requirement.
Implementing “The Security Rule”
In the Security Standards under General Rules, Flexibility of Approach, provides the entity with important guidance for focusing on decisions a covered entity must consider when selecting security measures such as technology solutions. Once an organization has completed the required risk analysis and risk managementprocess the entity will be able to make the appropriate informed decisions.
The Rule allows the use of security measures but there is no specific technology that is required. The guidance given is that the entity should reasonably and appropriately implement the Standards and implementation specifications. Each Security Rule standard is a requirement. 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 the requirements of a particular standard.
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 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?s choice must be documented. 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.
In the first safeguard the Security Rule defines access in ? 164.304 as ?the ability or the means necessary to read, write, modify, or communicate data/information or otherwise use any system resource. (This definition applies to ?access? as used in this subpart, not as used in subpart E of this part [the HIPAA Privacy Rule]).?
This first standard is meant to outline the ability or the means necessary to read, write, modify, or communicate data/information or otherwise use any system resource.
It provides users with rights and/or privileges to access and perform functions using programs, files information systems and applications. Ideally it should provide access to the minimum necessary information required to perform a duty within the organization. This access should be granted based upon a set of access rules the covered entity implements as part of ?Information Management Access?outlined in the Administrative Safeguards section of the Rule.
The standard requires a covered entity to:
?Implement technical policies and procedures for electronic information systems that maintain electronic protected health information to allow access only to those persons or software programs that have been granted access rights as specified in Information Access Management.?
There are many different combinations of access control methods and technical controls that can be used to accomplish these objectives. Whatever method is used it should be appropriate for the role and/or function of the workforce member.
There are four implementation specifications:
Unique User identification (Required)
Emergency Access Procedure (Required)
Automatic Logoff (Addressable)
Encryption and Decryption (Addressable)
1. Unique User Identification (Required)
According to this implementation specification, a covered entity is directed to do the following:
?Assign a unique name and/or number for identifying and tracking user identity.?
A user identification is a process used to identify a specific user of an information system, typically by name and/or number. This identifier will allow an entity to track specific user activity when that user is logged into an information system. By doing so It will enable an entity to hold users accountable for functions performed on information systems with EPHI when logged into those systems.
There are no specified formats described by the Rule for identification. A Covered entity must determine the best user identification strategy based on their workforce and their operations.
2. Emergency Access Procedure (Required)
Under this implementation specification the organization is asked to:
?Establish (and implement as needed) procedures for obtaining necessary electronic protected health information during an emergency.?
There must be procedures which are well documented and instructions that will allow an entity to have access to EPHI during emergency situations. An entity must determine the types of situation that would require emergency access to information systems. Examples to consider would be loss of power or hijacking of data.
3. Automatic Logoff (Addressable)
Under this implementation specification the organization is asked to:
?Implement electronic procedures that terminate an electronic session after a predetermined time of inactivity.?
Automatic logoff from a system is a common approach to protecting inadvertent access to workstations. It is an effective way to prevent unauthorized users from accessing EPHI on a workstation left unattended.
4. Encryption and Decryption (Addressable)
Under this implementation specification the covered entity is asked to consider:
?Implement a mechanism to encrypt and decrypt electronic protected health information.?
This is an addressable system and should be put into effect when it is a reasonable and appropriate safeguard for a covered entity. Encryption is a method of converting messages into encoded text using an algorithim. By using this technique there is low probability anyone other than the intended recipient who has the key may read the information. There are many ways to encrypt or technologies to protect data from being inappropriately accessed. It is up to the entity to decide if this is necessary.
When the Security Rule was enacted they recognized the rapid advances in technology. Consequently, it would be very difficult to give guidelines that change regularly. For this reason, they chose not to require specific safeguards. It is up to the organization to do a careful risk assessment. Based on this, they may create the appropriate mechanism to protect ePHI. Presently the use of encryption of ePHI is an effective tool. It is a good safeguard for the safe transmission of email and texts through the cloud. In many cases this has become the standard for the transmission of sensitive data in healthcare and in the business world.
Standard: Audit Controls
Audit controls are key in monitoring and reviewing activity in the system to protect its EPHI.
The standard requires a covered entity to:
?Implement hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain or use electronic protected health information.?
Information systems must have some level of audit control with the ability to provide reports. These controls are useful for auditing system activity in the face of a security violation.
The Security Rule does not identify specific data to be gathered by the audit controls. It is up to the covered entity to consider this after a risk analysis and to determine the most reasonable and appropriate for audit control for their systems that contain EPHI.
Integrity is defined in the Security Rule, as ?the property that data or information have not been altered or destroyed in an unauthorized manner.?
The standard requires a covered entity to:
?Implement policies and procedures to protect electronic protected health information from improper alteration or destruction.?
The reason for this standard is to establish and implement policies and procedures for protecting EPHI from being compromised regardless of the source. It will help prevent work force members from making accidental or intentional changes and thus altering or destroying EPHI. It may also help prevent alterations caused by electronic media errors or failures.
There is one addressable implementation specification.
1. Mechanism to Authenticate Electronic Protected Health Information (Addressable)
If it is reasonable and appropriate a covered entity must:
?Implement electronic mechanisms to corroborate that electronic protected health information has not been altered or destroyed in an unauthorized manner.?
A covered entity must do a risk analysis and determine from this the various risks to the integrity of EPHI. This will help define the security measures necessary to reduce the risks.
Standard: Person or Entity Authentication
Authenticating the individual who has access to the system is very important in the establishment of technical safeguards.
This standard requires a covered entity to:
?Implement procedures to verify that a person or entity seeking access to electronic protected health information is the one claimed.?
This implementation specification requires a system of identification to verify that a person is who they are before getting access to the system. There are many ways of accomplishing this such as passwords, PINs, smart cards, tokens, keys or biometrics.
The mechanism used will depend on the organization. Most organizations rely on a password or PIN. If the credential entered match those of the system, the user is then allowed access.
Standard: Transmission Security
It is important to guard all transmissions of electronic protected health information.
This standard requires a covered entity to:
?Implement technical security measures to guard against unauthorized access to electronic protected health information that is being transmitted over an electronic communications network.?
Once a covered entity has completed a risk analysis they will review and understand the current method used to transmit EPHI. Consider if it is sent by email, internet, a network or texting. Once these methods are reviewed the entity can determine the best way to protect EPHI.
There are two implementation specifications:
1. Integrity Controls (Addressable)
Based on a risk analysis If this is an implementation specification that is reasonable and appropriate, the covered entity must:
?Implement security measures to ensure that electronically transmitted electronic protected health information is not improperly modified without detection until disposed of.?
Integrity in the context of this implementation focuses on making sure the EPHI is not improperly modified during transmission. This may be accomplished by using network protocols that confirm the data that was sent is the data is received.
2. Encryption (Addressable)
After a risk analysis if this implementation specification is a reasonable and appropriate safeguard the covered entity must:
?Implement a mechanism to encrypt electronic protected health information whenever deemed appropriate.?
As mentioned earlier under the Access Control standard, encryption is a method of converting messages into an encoded or unreadable text that is later decrypted into comprehensible text. This is an addressable implementation, similar to that under Encryption and Decryption.
Encryption works only if the sender and receiver are using the same or compatible technology. The Security Rule allows covered entities the flexibility to determine when, with whom and what method of encryption to use.
HIPAA technical safeguards are important due to technology advancements as they help to protect EPHI in today’s environment. It is crucial for all covered entities and business associates who deal with electronic PHI to review their use of Technical Safeguards to be fully in compliance.
Cybersecurity & Technical Safeguards
Using cybersecurity to protect PHI is a key feature of HIPAA. Electronic protected health care information or EPHI is at increased risk from many sources:
Foreign hackers looking for data to sell ? usually on the dark web
Ransomware attacks that lock up data until a ransom payment is received
Phishing schemes that lure the user into clicking a link or opening an attachment to deploy malicious software; and
Spear phishing ?a targeted attack on a specific person that appears to come from a legitimate source usually instructing a transfer of funds.
The internet of Things or IoT will allow the interconnection of devices as a means for virus or malware to enter our systems.
What You Can Do to Protect EPHI
First, know how to spot phishing emails.
Learn how to use strong passwords, two factor authentication and encryption.
Finally, have policies, procedures and safeguards in place to protect EPHI and know who to report an incident to in your organization.
Prepare for Cyberattacks
In the case of a cyberattack or similar emergency an entity must:
Execute its response and mitigation procedures and contingency plans.
Report the time to other law enforcement agencies.
An entity should report all cyber threat indicators to federal and information-sharing and analysis organizations.
Finally, it must report the breach to OCR as soon as possible, but not later than 60 days after the discovery of a breach affecting 500 or more individuals.
The OCR considers all mitigation efforts taken by the entity during in any breach investigation. For instance, such efforts include voluntary sharing of breach-related information with the appropriate agencies. Remember in the event of a cyberattack it is critical to comply with breach reporting requirements.
Texting Protected Health Information
How do you handle texting in your organization?
There are two different types of texting. The first type of texting is what we usually accomplish using our phone and carrier and is also known as Short Message Service (SMS). This is the default app on our phone that many people use to send and receive texts every day and is not secure. It should never be used to send EPHI. The second type is app based and is used by healthcare providers (mostly doctors and nurses) to communicate to one another on patient-related care. It can also be used by providers to communicate with patients and is secure. There are certain requirements that must be met.
To be compliant secure texting needs to meet certain technical standards for HIPAA compliance:
Encryption of message data in transit and at rest
Reporting/auditability of message content
Permissions management capabilities
If safeguards like these are in place, PHI can be sent with a minimum of risk. Because SMS is an unencrypted channel one might presume an entity cannot send PHI. This is actually not true because encryption is not mandated according to the Security Rules. Healthcare organizations must determine whether encryption is reasonable and an appropriate safeguard, in protecting PHI. It is possible to use alternative safeguards If encryption is not deemed reasonable and appropriate by the covered.
This did not clear providers to communicate PHI to one another using unencrypted e-mail. Notably, the rule did not mention anything about SMS, which is somewhat frustrating as SMS is the most widely adopted communication channel. Some interpret the rule as applying to SMS as well because both are unencrypted electronic channels. Others want more clarity.
The Office for Civil Rights or OCR with HIPAA oversight has not produced the long-awaited guidance on texting protected health information. At a Health Information Management Conference in March of 2017 the OCR director said healthcare providers could text message their patients with PHI. However, the provider must warn the patient that it is not secure. In addition, the provider must obtain and document patient authorization to receive texts.
Recent Guidance on Sharing PHI Safely
The Centers for Medicare and Medicaid Services or CMS oversees the Conditions of Participation and Conditions for Coverage. CMS issued a memo on healthcare provider texting protected health information safely on December the 28th of 2017. Most importantly the takeaways are:
Texting Protected Health Information
CMS permits texting of patient information among members of the health care team. Above all, the platform must be secure and encrypted. As a result, it minimizes the risks to patient privacy and confidentiality. Most importantly, HIPAA regulations, the Conditions of Participation and the Condition for Coverage require this as a safeguard.
Texting Patient Orders
Regardless of the platform, CMS prohibits the practice of texting of patient orders. Above all, the provider is not in compliance with the Conditions of Participation or Conditions for Coverage if he or she texts patient orders to a member of the care team.
In December 2016, The Joint Commission, in collaboration with the Centers for Medicare & Medicaid Services (CMS), decided to reverse a May 2016 position to allow secure texting for patient care orders and issued the following recommendations:
All health care organizations should have policies prohibiting the use of unsecured text messaging, also known as short message service, from a personal mobile device for communicating protected health information.
The Joint Commission and CMS agree that computerized provider order entry (CPOE), which refers to any system in which clinicians directly place orders electronically, should be the preferred method for submitting orders, as it allows providers to directly enter orders into the electronic health record (EHR).
In the event that a CPOE or written order cannot be submitted, a verbal order is acceptable on an infrequent basis.
In December 2017, the Joint Commission issued a clarification explicitly stating the use of Secure Texting for patient orders is prohibited. Providers should opt for the use of Computerized Provider Order Entry (CPOE) as the preferred method of order entry. CMS insists that a physician or Licensed Independent Practitioner (LIP) should enter orders into the medical record via a handwritten order or via CPOE. When using this system, orders are immediately downloaded into the provider?s electronic health records (EHR). Moreover, this method is preferred as the order would be dated, timed, authenticated and promptly placed in the medical record.