HIPAA: How to Stay Ahead of Current and Future Security Regulations
How to Achieve True Healthcare Data Security and Stay Ahead of HIPAA Compliance
Even if you’ve already taken the necessary measures to ensure HIPAA security compliance, can you be sure that your patient information and all of your operational data is truly secure?
Unfortunately, emerging trends and disturbing facts point to the serious risks that many healthcare providers, insurers, and vendors face, and the latest figures are cause for concern for any healthcare entity.
In The Ponemon Institute’s Fifth Annual Benchmark Study on Privacy and Security in Healthcare Data, researchers found that nearly 45% of all data breaches in healthcare are now caused by criminal activity such as cyberattacks and hacking. This marks the first time that criminal activity has surpassed employee error in healthcare data breaches, and criminal data breaches in healthcare have grown by 125% during the past five years.
Given these alarming developments, are you completely confident that your solutions for HIPAA compliance are enough to protect your organization from potential disaster? Are you sure that your current security solutions and procedures will ensure compliance and protect your organization from potential data breaches and subsequent fines and penalties?
Can you be sure that your healthcare organization will not only be protected now but also prepared for future regulations and data security requirements?
Thankfully, while true healthcare data security can seem elusive and the constant threat of cyberattacks can seem overwhelming and impossible to address, there are next-generation technologies with advanced cryptography that can give you complete assurance against any form of cyber threat and provide forward-thinking advantages that will position your organization for ongoing and future compliance.
At SecSign Technologies, we’ve prepared a this article to further clarify and summarize the current HIPAA security requirements, recommend best practices, and provide clear guidance on how covered entities and business associates can leverage emerging technologies and data security solutions to achieve revolutionary levels of unbeatable protection.
We describe the latest developments in HIPAA two-factor authentication and how they can physically eliminate the threats of hacking, malware, and phishing for all covered entities. And we also explain how advanced encryption can protect healthcare data at every moment of transmission and storage.
1. Understanding HIPAA Privacy and Security Standards
-
A Quick HIPAA Overview
-
What is Protected PHI?
-
What are the Requirements of the HIPAA Security Rule?
-
General Rules
-
Administrative Safeguards
-
Physical Safeguards
-
Technical Safeguards
-
Organizational Requirements
-
Policies and Procedures and Documentation Requirements
-
-
Additional Security Requirements in the Omnibus Final Rule
2. How to Achieve HIPAA Security Compliance and Stay Ahead of Regulations
-
The Benefits of Exceeding Current and Future Security Compliance Standards
-
Best Practices to Meet Current HIPAA Security Standards
-
Access
-
Storage
-
Transmission
-
Retention
-
Contingency Planning
-
-
Integrating Next-generation Security Technology to Meet and Exceed Current and Future Compliance Requirements
-
HIPAA Two-factor Authentication for Access Control
-
Understanding HIPAA Compliance Requirements for Access Control and Authentication
-
HIPAA Authentication Requirements
-
Why Passwords Should Never Be Used in Authentication
-
Why Telephone Callbacks, SMS Codes, and Hardware Tokens are Not Secure
-
Why PIN and Biometric Methods Provide the Best Possible Security
-
Achieving and Exceeding HIPAA Access Control Compliance with HIPAA Two-factor Authentication
-
Compliance without Sacrificing Usability
-
Ensuring Automatic Logoff Security
-
Advantages of On-premise HIPAA Two-factor Authentication
-
-
-
Encrypted Data Storage and Transmission
-
Using Encryption to Meet and Exceed Security Standards for Integrity and Transmission
-
The Power of AES-256 Encryption and How Encryption Keys Are Generated
-
Integrating a Third Party Solution for On-premise Encryption and Storage
-
Meeting the HIPAA Security Standard for Audit Controls
-
Implementing Integrity Controls with Digital Signatures
-
Applying Secure Technology for Documentation Retention
-
Getting Expert Consultation and Implementation Support
-
-
Getting Expert Consultation and Implementation Support
1. Understanding HIPAA Privacy and Security Standards
A Quick HIPAA Overview
The Health Insurance Portability and Accountability Act of 1996 (HIPAA) is the federal statute that governs the protection, privacy, and security of patient information. Compliance with HIPAA regulations is vitally important for healthcare providers and any other entities that are covered under the statute, and severe fines and penalties have been issued for the failure to meet and maintain compliance.
Subsequent legislation and rulings have further expanded, strengthened, and clarified HIPAA standards and requirements. In 2009, the American Recovery and Reinvestment Act (ARRA) provided billions of dollars in funding to accelerate the adoption of electronic medical records (EMR). This legislation also established new requirements for privacy and security, along with aggressive enforcement and increased penalties for violations—including punitive measures for failures of third-party vendors that maintain or store patient information for covered entities.
These developments sparked widespread changes in the healthcare industry, including rapid adoption of EMR and many data security technologies designed to ensure the privacy and security of protected health information (PHI).
Recently, the U.S. Department of Health and Human Services (HHS) released the HIPAA Omnibus Final Rule. This rule replaces the HHS Interim Rules that were in place previously, and it ensures that HIPAA regulations conform to the HITECH Act, which mandated the strengthening of privacy protections and data security for electronic health records and information.
Understanding HIPAA requirements and the subsequent Omnibus Final Rule is now a fundamental responsibility of healthcare leaders and healthcare information technology (HIT) personnel within covered organizations, and it is also the responsibility of third-party vendors with whom they contract. A complete summary text of all current HIPAA regulations is available in the HIPAA Administrative Simplification document from HHS.
At SecSign Technologies, we’ve prepared this white paper to further simplify and summarize the current HIPAA security requirements, and we also outline clear guidance on how covered entities can leverage emerging technologies and data security solutions to not only ensure HIPAA compliance but also meet and exceed current and future regulations.
What is Protected Health Information (PHI)?
PHI includes any information about a patient’s health status, type of care, or payments related to care. It is a broad definition that generally includes all information contained in a patient’s medical record and payment history. When this information is in electronic form, it is usually referred to as electronic protected health information or e-PHI.
What are the Requirements of the HIPAA Security Rule?
Prior to HIPAA, there were no generally accepted security standards or requirements for protecting health information in the healthcare industry. Nonetheless, new technologies were emerging, and the industry began to transition from paper-based processes to a much greater use of technology and electronic information systems to pay claims, answer eligibility questions, provide health information, and conduct other administrative and clinical functions.
Since then, the dramatic shift toward healthcare information technology (HIT) has continued, motivated in part by new requirements for privacy and security in the 2009 American Recovery and Reinvestment Act (ARRA), along with extensive funding that was made available in this legislation to speed the adoption of HIT. ARRA established a 2015 deadline for healthcare providers to demonstrate meaningful use of electronic records or potentially face lower Medicare reimbursement payments, and it provided $19.2 billion in funding to help providers achieve this goal. The law also expanded existing requirements for privacy and security of health information, and it stipulated other provisions related to HIT.
As a result of these sweeping changes over the past 20 years, electronic applications such as computerized physician order entry (CPOE), electronic health records (EHR), and radiology, pharmacy, and laboratory systems are commonplace in the healthcare industry. Health plans are also providing electronic access to claims and care management along with many self-service software applications for members. These changes have allowed healthcare delivery to be much more efficient, streamlined, and mobile, but the increased adoption of HIT has also introduced potential security risks.
A major goal of the HIPAA Security Rule is to address these risks and to protect the privacy of electronic e-PHI while allowing covered entities to adopt new technologies to improve the quality and efficiency of patient care. Importantly, in recognizing that the healthcare industry is a varied and diverse landscape, the Security Rule is designed to be flexible and scalable so that a covered entity can implement policies, procedures, and technologies that are appropriate for its particular size, organizational structure, and relative risks to e-PHI.
General Rules
Adapted from http://www.hhs.gov/ocr/privacy/hipaa/understanding/srsummary.html
-
The HIPAA Security Rule requires covered entities to maintain reasonable and appropriate administrative, technical, and physical safeguards for protecting e-PHI.
A HIPAA covered entity must:
-
Ensure confidentiality, integrity, and availability of all e-PHI that it creates, receives, maintains, or transmits;
-
Identify and protect e-PHI against reasonably anticipated security or integrity threats;
-
Protect against impermissible use or disclosure that is reasonably anticipated; and
-
Ensure HIPAA compliance by its workforce.
“Confidentiality” is defined by the Security Rule to mean that e-PHI is not accessible by or disclosed to unauthorized persons. These confidentiality requirements support the Privacy Rule's restrictions against improper use and disclosure of PHI. The Security Rule also establishes goals of maintaining the integrity and availability of e-PHI. “Integrity” means that e-PHI is not altered or destroyed in an unauthorized way. “Availability” means that e-PHI is accessible and usable, on demand, by authorized persons.
Since covered entities can range in size from small providers to very large health organizations or multi-state health plans, the Security Rule is flexible and scalable. This allows covered entities to analyze their own needs and implement solutions that are well-suited and appropriate for their specific characteristics and environments.
When a covered entity is deciding which security measures and protections to implement, the Rule does not dictate specifics but simply requires the covered entity to consider:
-
Its size, complexity, and capabilities
-
Its technical, hardware, and software infrastructure
-
The costs of security measures
-
The likelihood and possible impact of potential risks to e-PHI
As a covered entity’s environment changes, it must review and modify their security measures to continue protecting e-PHI.
-
The Administrative Safeguards in the Security Rule require covered entities to conduct risk analysis as part of their security management processes. The provisions for risk analysis and management are addressed separately because, by helping to determine which security measures are reasonable and appropriate for a covered entity, risk analysis affects the implementation of all safeguards contained in the Security Rule.
-
A risk analysis includes, but is not limited to, the following:
-
Evaluate the likelihood and impact of potential risks to e-PHI;
-
Implement appropriate security measures to address the risks identified in the risk analysis;
-
Document the chosen security measures and, where required, the rationale for adopting those measures; and
-
Maintain continuous, reasonable, and appropriate security protections.
-
-
Risk analysis should be an ongoing process. A covered entity should regularly review its records to track access to e-PHI and detect security incidents; periodically evaluate the effectiveness of its security measures; and regularly re-evaluate potential risks to e-PHI.
Administrative Safeguards
-
Security Management Process. A HIPAA covered entity must identify and analyze potential security risks to e-PHI. It must also implement security measures that address risks and vulnerabilities and reduce them to a reasonable and appropriate level.
- Security Personnel. A HIPAA covered entity must designate a security official who is responsible for the development and implementation of its security policies and procedures.
- Information Access Management. Consistent with the Privacy Rule that limits usage and disclosure of PHI to the "minimum necessary," a covered entity must implement policies and procedures to authorize access to e-PHI only when such access is appropriate based on the user or recipient's role (role-based access).
- Workforce Training and Management. A covered entity must appropriately authorize and supervise members of its workforce who work with e-PHI. A covered entity must provide training for all workforce members to ensure the proper understanding and application of security policies and procedures, and it must have appropriate sanctions and apply them against workforce members who violate these policies and procedures.
- Evaluation. A covered entity must periodically assess itself to determine how well its security policies and procedures meet the requirements of the Security Rule.
Physical Safeguards
-
Facility Access and Control. A HIPAA covered entity must secure and limit physical access to its facilities while ensuring that authorized access is allowed.
- Workstation and Device Security. A covered entity must implement policies and procedures to specify the proper use of and access to workstations and electronic media. It must also put into place policies and procedures regarding the transfer, removal, disposal, and re-use of electronic media. This helps ensure the appropriate protection of e-PHI.
Technical Safeguards
-
Access Control. A covered entity must implement technical security policies and procedures to ensure that only authorized persons can access e-PHI.
- Audit Controls. A HIPAA covered entity must implement hardware, software, and/or procedural mechanisms to record, examine, and review user access and other activity in information systems that contain or use e-PHI.
- Integrity Controls. A HIPAA covered entity must put in place policies and procedures to ensure that e-PHI is not improperly altered or destroyed.
- Transmission Security. A covered entity must implement technical security measures and safeguards to protection against unauthorized access to e-PHI while it is being transmitted over an electronic network.
Required and Addressable Implementation Specifications
-
Covered entities are required to comply with every Security Rule "Standard." However, certain implementation specifications within those Security Rule standards are "addressable," while others are "required." The "required" implementation specifications must be implemented. The "addressable" designation does not mean that an implementation specification is optional. However, it permits covered entities to determine whether the addressable implementation specification is reasonable and appropriate for that covered entity. If it is not, the Security Rule allows the covered entity to adopt an alternative measure that achieves the purpose of the standard, if the alternative measure is reasonable and appropriate.
Organizational Requirements
-
Covered Entity Responsibilities. If a HIPAA covered entity is aware of an activity or practice of a business associate that constitutes a material breach or violation of the associate’s HIPAA obligations, the covered entity must take reasonable steps to cure the breach or end the violation. These potential violations include the failure to implement security procedures and safeguards that reasonably and appropriately protect e-PHI.
- Business Associate Contracts. HHS has developed regulations relating to business associate obligations and business associate contracts under HIPAA and the HITECH Act of 2009. For more information, see our section below entitled “Additional Security Requirements in the Omnibus Final Rule”.
Policies and Procedures and Documentation Requirements
-
A covered entity must adopt and maintain reasonable and appropriate policies and procedures to comply with the Security Rule. A HIPAA covered entity must maintain written security policies and procedures and written records of required actions, activities or assessments. And this records must be maintained until six years after the later of the date of their creation or their last effective date. This is widely known as the HIPAA retention requirement but should not be confused with any state or other compliance regulations that require retention of e-PHI. The HIPAA retention requirement applies only to the documentation of procedures, written records, and all required actions, activities, and assessments related to compliance with the Security Rule.
- Updates. A covered entity must periodically review and update its documentation based on organizational or environmental changes that affect the security of e-PHI.
State Law
-
Preemption. In general, State laws that are contrary to the HIPAA regulations are preempted by the federal requirements, which means that the federal requirements will apply instead. In this context, “Contrary” means that it would be impossible for a covered entity to comply with both the state and federal requirements, or that the provision of state law is an obstacle to accomplishing the full purposes and objectives of the Administrative Simplification provisions of HIPAA.
Enforcement and Penalties for Noncompliance
-
Compliance. The HIPAA Security Rule establishes a set of national standards for confidentiality, integrity, and availability of e-PHI. The Department of Health and Human Services (HHS), Office for Civil Rights (OCR) is responsible for administering and enforcing these standards, in concert with its enforcement of the Privacy Rule. And it may conduct complaint investigations and compliance reviews.
-
You can learn more about enforcement and penalties in the Privacy Rule Summary and on OCR's Enforcement Rule page.
Additional Security Requirements in the Omnibus Final Rule
The HIPAA Omnibus Final Rule and the American Recovery and Reinvestment Act of 2009
The HIPAA Omnibus Final Rule, which went into effect on March 26, 2013, implemented a number of provisions from the HITECH Act to strengthen privacy and security protections for e-PHI, grant patients new rights to their personal health information, and bolster enforcement provisions. Covered entities and third party vendors were given 180 days from the effective date to achieve compliance with this final rule.
Summary of Omnibus Final Rule
-
Expands the definition of healthcare business associates to include vendors that create, receive, maintain or transmit PHI.
-
Requires healthcare business associates to enter a written contract that contains specific provisions required by HIPAA. Vendors that only transmit PHI and do not store or maintain it are considered a “conduit exception” and are not required to enter a business associate agreement.
-
Identifies new and expanded individual rights to PHI.
-
Updates the factors that determine civil monetary penalties for privacy and security failures. Also implements an increased and tiered penalty structure for civil monetary damages.
-
Replaces the “harm threshold” in the Breach Notification Rules with a more objective standard.
-
Requires healthcare providers to respond to patients’ written requests for copies of their PHI within 30 days. This eliminates the previous 60-day timeframe for records that are maintained offsite.
-
Allows patients to request that providers withhold information about their care if the patient pays for these services out-of-pocket.
THE HIPAA SECURITY RULE HAS BEEN STRENGTHENED
The Security Rule was considerably strengthened with the release of the Omnibus Rule. These changes apply to covered entities as well as their business associates. The Security Rule requires covered entities and their business associates to protect the confidentiality, integrity and availability of e-PHI in three general ways:
-
Administrative safeguards. These include operational processes and procedures such as training, workflow processes, and processes for releasing information. And all of these must be documented.
-
Physical safeguards. For on-site systems and infrastructure, physical controls such as locks, access to keys, restricted areas, and supervision must be implemented to protect electronic information systems and e-PHI from unauthorized physical Access.
-
Technical safeguards. This broad definition includes database security, network protection and user authentication that protects and controls access to e-PHI. Many of these requirements typically require investment in technology, training, and supervision, which is why it is critical to implement security solutions and procedures that not only offer the strongest possible protection but actually simplify security procedures for employees and make protecting e-PHI more affordable and cost-effective.
2. How to Achieve HIPAA Compliance and Stay Ahead of Regulations
The Benefits of Exceeding Current and Future Compliance Standards
The current HIPAA rules contain a number of required procedures and policies to ensure the security of PHI, but they also outline a number of “addressable” provisions. While these provisions do not constitute firm requirements at this stage, future revisions to HIPAA regulations will almost certainly convert many of these into legal requirements. Future HIPAA developments will likely also include additional new rules for compliance that will require more advanced protections in the ongoing effort to address emerging healthcare information security risks.
By implementing next-generation security technologies and procedures, healthcare providers can stay ahead of HIPAA and other state and federal regulations, and they can achieve levels of privacy and security that will not only ensure current compliance but virtually guarantee compliance with future security requirements.
In taking the proper steps now, healthcare providers and health plans can potentially avoid the future headaches and costs of compliance when standards are updated and strengthened. And, most importantly, by deploying the strongest possible data security technologies and implementing best practices in the protection of PHI, healthcare providers and vendors can protect the privacy and security of their patient’s health information and avoid costly and damaging data security breaches.
Best Practices to Meet Current HIPAA Security Standards
Storage
When patient information is at rest and not actively being used, it needs to be stored safely with access controls that will ensure that only authorized personnel have access to it and that there are no lapses in protection or data losses. Some key best practices in storing paper and electronic records include:
-
Deploy physical access controls such as locked facilities with video monitoring
-
Equip your storage facilities and data centers with alarm systems and intrusion detection
-
Ensure that your facilities have environmental controls including fire detection and suppression
-
Encrypt electronic information with AES-256 encryption on all levels and at every moment of storage
-
Implement access controls for electronic storage, including two-factor authentication and next-generation identity access management (IAM) that eliminates the severe risks of passwords and other outdated authentication schemes
-
Make sure that your data centers have redundant infrastructure to ensure accessibility and backup for disaster recovery
-
Ensure that your systems make data integrity checks to detect corrupted data and files
-
Assign personnel resources and systems to monitor security
-
Manage your data archiving and disaster recovery to meet recovery time and recovery point objectives (RTO and RPO).
Retention
Patient information that is no longer needed for care and no longer required by law must be properly deleted or destroyed. To implement a records disposal program to mitigate risks and reduce potential liabilities, follow these best practices:
-
Establish retention schedules and policies in accordance with state and federal law
-
Maintain and enforce consistent policies and procedures for information disposal
-
Document proof of employee training, ongoing communications, enforcement, and program monitoring
-
When shredding paper and hard copy records, ensure that secure shredding is used
-
Create and maintain clear audit trails to document and prove that physical and electronic records have been successfully deleted or destroyed to the point of non-recovery
-
Establish a secure chain of custody for any paper records that may be transported for destruction
-
Destroy electronic records securely and in accordance with retention policies
Transmission
Protected patient information is at greater risk when it is no longer in passive storage but is physically transported or transmitted electronically. Best practices in this area require stringent security measures and ongoing tracking, monitoring, and review to ensure protection. These best practices include:
Physical Records
-
Secure physical information before transporting it
-
Ensure that physical records are not damaged during transportation
-
Make sure that physical records are packaged and wrapped with opaque materials
-
Ensure that vehicles are secured and that there are process controls and driver screening to prevent information loss
-
Have a complete chain of custody for all patient information, covering the entire end-to-end process of securing, transporting, and then storing physical records
Electronic Records
-
Use next-generation authentication with public key cryptography to protect access to records for potential transmission. This means using two-factor authentication that requires at least two distinct authentication factors with one being physical possession of a private software key and the other being a knowledge factor, such as a PIN, or a biometric factor, such as a mobile fingerprint scan.
-
Ensure that AES 256-bit encryption is used at all levels and that it is applied at every moment of information transmission.
-
Use encryption architecture with a shared secret mechanism to protect access to encryption keys. This ensures that your encryption keys will only be accessible with the simultaneous approval of at least three authorized administrators.
Access
Of course, with physical patient records, access can typically be secured through administrative and physical safeguards. For protecting e-PHI, however, there are a number of extremely important best practices to keep in mind:
-
HIPAA two-factor authentication. Always require users to verify their identity with at least two distinct authentication factors when logging into HIT systems and accessing e-PHI. With a proper HIPAA two-factor authentication procedure, a physical authentication factor, such as possession of an encrypted private key on a mobile device, should always be required; and the second factor should be either a knowledge factor, such as a PIN, or a biometric factor, such as a mobile fingerprint scan.
-
Never use HIPAA two-factor authentication or any other authentication technologies that require passwords to be used on the login screen. Passwords are no longer a safe method of identity verification, and any security procedure that requires the entry of passwords or sensitive credentials into the login screen is extremely dangerous. This includes HIPAA two-factor authentication schemes that rely on one-time SMS text codes or telephone codes that must be entered into the login. Any of these credentials can easily be stolen or redirected in a cyberattack, and using password-based authentication automatically makes your login server a prime target for cybercriminals.
-
Always make sure that identity verification and authentication take place separately from the user login. By requiring that users verify identity and authenticate through an out-of-band channel that is separate from the login mechanism, this physically removes any opportunity for unauthorized users or attackers to use hacking, malware, or phishing to compromise your user logins. Quite simply, by using out-of-band authentication and properly engineered HIPAA two-factor authentication, it becomes physically impossible for your login mechanism to ever be compromised.
-
Never use USB or other hardware tokens for authentication. USB connected devices create enormous security risks for healthcare organizations by potentially introducing viruses, firmware vulnerabilities, and many other opportunities for unauthorized users or attackers to gain access to systems and e-PHI. Moreover, hardware security tokens like these typically also require the entry of passwords into the login mechanism as part of the authentication process, and this is not only highly unsafe but is rapidly becoming obsolete for data security with the advent of password-free authentication technologies. For these reasons, USB devices and hardware tokens are simply too easily exploitable to be relied upon for any level of identity security.
-
Assign an HIT administrator to supervise, monitor, and audit user accounts and user access to e-PHI.
Contingency Planning
Contingency planning is required so that covered entities have a plan and procedures for recovering health records and restoring services in the event of an emergency, disaster, or data loss. HIPAA regulations require that covered entities conduct a formal risk analysis and develop an appropriate and reasonable disaster recovery plan. This plan must address risks with policies and procedures in place to cover backup, storage, and recovery. These compliance requirements also serve a vital purpose in potentially providing a foundation for overall business continuity and preparedness for disaster.
Here are some basic requirements for contingency planning:
-
Establish Recovery Time Objectives (RTO) and Recovery Point Objectives (RPO) that meet the service level and budget requirements of your organization
-
Store backup records securely offsite
-
Use redundant failover servers and backup data centers that are geographically separate from your primary IT infrastructure. This will help ensure that your stored data and your archives can be recovered from available and reliable backups.
-
Your backup data centers should not rely on the same infrastructure as your primary site.
In addition to these best practices, you should regularly and frequently test your contingency plans. Make sure to test your plans to ensure that you can successfully complete a recover operation and that you can achieve business continuity during an emergency or after a disaster. “Full deployment” tests should be performed at least once per year and should cover all of your plans, processes, personnel, and infrastructure for disaster recovery and business continuity.
Integrating Next-generation Security Technology to Meet and Exceed Current and Future Compliance Requirements
Achieving and exceeding HIPAA security regulations, particularly for electronic PHI, begins with proper access controls and HIPAA two-factor authentication for persons or entities accessing e-PHI. Implementing next-generation technology and best practices in these areas will meet current HIPAA requirements, meet additional requirements that are currently “addressable” with flexibility in their potential implementation, and place your healthcare organization far ahead of any anticipated regulations in the coming years.
In fact, the right technologies will position your organization as an industry leader and will likely ensure compliance with future data security requirements before they are ever published. Most importantly, HIPAA two-factor authentication and additional security procedures will ensure the strongest possible protection for your patients’ health information and prevent costly and damaging compliance violations and data breaches.
In this section, we explore the HIPAA requirements for access controls and person or entity authentication, analyze the vulnerabilities and weaknesses of most authentication methods, and identify a HIPAA two-factor authentication solution that not only meets but exceeds HIPAA standards and makes it virtually impossible for anyone to gain unauthorized access to health information.
HIPAA Two-factor Authentication for Access Control: Understanding HIPAA Compliance Requirements for Access Control and Authentication
The requirements for person or entity authentication can be found in Security Standards for the Protection of Electronic Personal Health Information: Technical Safeguards – § 164.312 of the amended U.S. Health and Human Services Regulations as of January 2013.
Two subsections of the Technical Safeguards focus specifically on access control and secure authentication to protect electronic health information:
HHS Security Regulations as Amended January 2013
Security Standards for the Protection of Electronic PHI: Technical Safeguards - § 164.312
A covered entity or business associate must, in accordance with § 164.306:
a)
-
Standard: Access control. 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 § 164.308(a)(4).
-
Implementation specifications:
-
Unique user identification (Required). Assign a unique name and/or number for identifying and tracking user identity.
-
Emergency access procedure (Required). Establish (and implement as needed) procedures for obtaining necessary electronic protected health information during an emergency.
-
Automatic logoff (Addressable). Implement electronic procedures that terminate an electronic session after a predetermined time of inactivity.
-
Encryption and decryption (Addressable). Implement a mechanism to encrypt and decrypt electronic protected health information.
Also in § 164.312, HIPAA requires authentication to verify that anyone accessing PHI is who that person or entity claims to be.
d) Standard: Person or entity authentication. Implement procedures to verify that a person or entity seeking access to electronic protected health information is the one claimed.
In the case of access control for e-PHI, this is a standard element of data security and means that access to electronic protected health information will be restricted through a login and authentication method. Thus, a login mechanism is used to secure and control access to information, and only persons who have been granted the required access rights can log into information systems containing the protected data.
There are four HIPAA implementation specifications for access control, and the first two are required for compliance:
-
Unique user identification. Assign a unique user name or number for identifying and tracking user identity. This is a core component of virtually any login and authentication method. Quite simply, this simply means assigning each user with a user ID for access to electronic systems and PHI.
-
Emergency access procedure. Establish emergency access procedures for accessing PHI during the case of an emergency. This means that covered entities must draw up procedures and have mechanisms in place to enable access to e-PHI during an emergency, such as an electrical power outage or damage to systems due to a natural or manmade disaster. This may mean having redundant backup storage and servers in other locations, having emergency backup power generation capabilities, and having specific procedures to access or recover information in the case of emergencies.
The next two implementation specifications are not currently required by HIPAA, but they are considered “addressable” and they were given careful consideration as possible requirements before the final HIPAA regulations were published. Thus, covered entities should be thinking about implementing these additional elements to prepare for future HIPAA changes that may convert them into requirements. More importantly, meeting these addressable specifications will dramatically strengthen protection for e-PHI and bolster your overall data security.
-
Automatic logoff. Here, it is recommended that a covered entity implement procedures that will automatically terminate a login session after a predetermined time of inactivity. Thus, if a user is logged into a system that grants access to e-PHI but has been inactive for a certain length of time, the system will automatically terminate that access as a security precaution.
This is to ensure that access is still secured in cases when someone may walk away from a computer or system, thus creating an opportunity for an authorized user to use that same workstation or interface to access protected information.
-
Encryption and decryption. HIPAA recommends that covered entities implement a mechanism to encrypt and decrypt electronic protected health information. In this case, file encryption is considered an acceptable method of denying access to information in a particular file and not as a mean of controlling user access to information systems more generally. With a proper encryption and decryption scheme, e-PHI can be completely protected at rest, thus preventing any unauthorized individual or any attack from accessing or damaging the file and its contents.
HIPAA Authentication Requirements
Another core component of HIPAA compliance is person or entity authentication. The regulations call for covered entities and business associates to implement procedures that verify that a person or entity seeking access to electronic protected health information is the one claimed. This means that a system must provide a means of identity verification and corroborate the identity of the person or entity that is attempting to access protected data.
Originally, HHS had proposed four specific verification methods that would be included with this requirement:
-
A biometric identification system (e.g. fingerprint scanning)
-
A password system
-
A personal identification number (PIN)
-
Telephone callback or a token system that uses a physical device for user authentication.
In its final rule, however, HHS provided only a general requirement and did not stipulate these specific methods as requirements or as the only methods that might ensure compliance.
This offers covered entities and business associates freedom in selecting and choosing their preferred authentication methods, but that does not mean that the method you choose will ensure compliance or avoid serious risks and vulnerabilities.
Any security breach through an authentication method’s failings or vulnerabilities could place a covered entity or business associate at serious risk of fines and sanctions from HHS and create legal liabilities from the exposure of patient information to unauthorized parties.
The specific verification methods were originally proposed because they generally strengthen information security and help prevent unauthorized access and data breaches. However, password systems and telephone callback or token-based verification are now considered obsolete by forward-thinking data security experts, so these should not be part of any healthcare organization’s authentication procedures.
The only way to truly ensure that the identities of authorized users are properly verified and that access to e-PHI is protected by the strongest possible security is by deploying what might be called HIPAA two-factor authentication. To understand why HIPAA two-factor authentication is so important to current and future compliance and how it meets the originally proposed verification standards, it is essential to understand the critical weaknesses of authentication methods that might meet the current HIPAA standards but create massive data security risks.
Why Passwords Should Never Be Used in Authentication
Unfortunately, any password-based method for identity verification is highly insecure. The use of passwords and other sensitive credentials for authentication opens up covered entities to a host of potential cyberattacks that can compromise systems and e-PHI.
Hacking, malware, phishing schemes, man-in-the-middle attacks, and SQL injections have all been used to successfully defeat password-based login methods across a wide range of industries, and even in cases involving Swiss banks, who are otherwise known for having some of the strongest cybersecurity in the world.
Moreover, the continued use of passwords and other sensitive login credentials invites attacks because one of the primary incentives for cybercriminals is the prospect of compromising a user account and using it to gain unauthorized access to systems and deploy tools that can be used to steal entire databases of user information and sensitive data from servers. This is what happened recently in the infamous data breach at Anthem Inc.
If passwords are used during the entry of login information, are transmitted to the server to verify identity, or are stored on the server for any reason, then they can easily be stolen or will inevitably be a potential target for cyberattacks.
Why Telephone Callbacks, SMS Codes, and Hardware Tokens are Not Secure
Telephone callback systems provide another means of potential user authentication, but, if users use smartphones for this purpose, it may rely on the security of mobile networks, which is never a certainty. It would also require access to a mobile network, which is not always possible inside certain buildings or structures or when traveling overseas. As an alternative, the user may use a land line telephone, but this could be a shared line and may not be completely private or secure.
Some forms of two-factor authentication require that the user receive a one-time SMS code via mobile text messaging and then enter this into the login mechanism. However, while requiring that a user have a mobile device to receive an SMS access code is better than relying on a password alone, SMS transmissions have already been exploited by attackers through multiple methods. And, much like telephone callbacks, access to a mobile network is required to receive the message. More importantly, since the code must be re-entered through the login screen, this means that these code entries can be intercepted through man-in-the-middle attacks.
In the case of token-based two-factor authentication methods, a USB device or other hardware token must be connected to a system as a physical requirement for user authentication. But this usually means that an ID and password combination are still used in the login process, thus perpetuating the risks and problem associated with password-based methods.
Hardware tokens also pose huge risks to HIT systems by potentially introducing firmware vulnerabilities, viruses, and other threats. And the requirement of a password entry into the login mechanism means that HIT logins and servers will be prime targets for credential theft, interception, or redirection.
Beyond the security flaws of hardware tokens, a USB-based token is also often unusable for access to information systems through mobile devices such as tablets or smartphones. Since mobile devices are typically not equipped with the standard USB ports required for hardware token authentication, this method is limited and can potentially be a significant obstacle to Access.
Why PIN and Biometric Methods Provide the Best Possible Security
In contrast, a PIN and/or biometric method offers a better option and creates powerful HIPAA two-factor authentication because it relies on security principles that are similar to those used in smartcard technologies. In the case of smart cards, a PIN typically protects access to a private key that is stored on a microchip implanted on the card. The entry of the PIN requires the user’s knowledge, and this, combined with physical possession of the card, confirms identity and rightful ownership of the smartcard. This allows the card to digitally sign an authentication challenge, and the successful completion of this challenge allows the secured system to grant Access.
In the case of mobile software for HIPAA two-factor authentication, the user’s knowledge of a PIN and/or the user’s biometric identifier, like a fingerprint, can be combined with something that only the user possesses, like a mobile device, to verify identity. Just as knowledge and possession verify identity for the purposes of completing an authentication challenge with a smartcard, the combination of knowledge and possession or knowledge and biometrics, or the combination of all three, can be used to confirm identity and authorize access to protected health information.
As data security experts and IT industry leaders have declared the death of the password and called for a move into newer and more secure authentication methods, such as two-factor authentication, these principles of knowledge, possession, and biometrics are now leading the way, and the solutions that rely on these factors will likely become the standard requirements for compliance with a wide range of data security regulations.
Achieving and Exceeding HIPAA Access Control Compliance with HIPAA Two-factor Authentication
Using the principles of knowledge, possession, and biometrics, HIPAA two-factor authentication can be deployed using public key infrastructure (PKI) with mobile technology that supports access from all devices, eliminates the use of passwords or other sensitive credentials during the login process, and makes it physically impossible for attackers to compromise user accounts. Using this approach, covered entities and business associates can be assured that they are not only meeting HIPAA compliance requirements but even exceeding them and staying ahead of future developments in data security.
With mobile HIPAA two-factor authentication based on PKI, no password or sensitive credential is entered during a login, transmitted, or stored on a server. So there are physically no credentials for cybercriminals to steal, and thus they cannot use stolen credentials to gain access to user accounts, deploy malicious tools, or gain unauthorized access to protected health information.
With PKI authentication, users can verify identity using a PIN or passcode that is entered into a mobile app that is used for authentication. The PIN or passcode verifies rightful ownership of a 2048-bit encrypted private key that is stored on the mobile device using a patented SafeKey mechanism that prevents brute force attacks.
Optionally, users can use a biometric method to verify their ownership of their private key using Apple’s Touch ID fingerprint scanning technology. Or, for added security, this biometric can be combined with the PIN or passcode to create a truly multi-factor authentication method.
For more details on PKI authentication, how it compares to other authentication methods, and how it can be implemented and integrated with existing systems, websites, networks, and services, please see our blog post, “Choosing the Best and Safest Two-factor Authentication Method”.
Compliance without Sacrificing Usability
Of course, in implementing data security, usability is also important. A method that delivers strong access and authentication security but imposes burdens on authorized users is not the right solution. It must still provide quick and convenient access to health information whenever and wherever it is needed.
So the key is to implement access controls that deliver powerful security but are still simple and easy to use.
Thankfully, with mobile HIPAA two-factor authentication and PKI security principles, users can log in and authenticate their identity in seconds with a smartphone, tablet device, or even an Apple Watch. Only one entry into the login screen is required, and authentication is completed with just a few taps on their mobile device.
Best of all, passwords and sensitive credentials are never required or used for logins or authentication, and this also means that users no longer have to remember or use long, complicated passwords.
Users can self-enroll and use a single user ID and authentication account to securely log in and authenticate for any service protected by this method. It can easily be deployed as a single sign-on across all applications, networks, websites, and other services.
This type of HIPAA two-factor authentication can also be integrated in the cloud or as an on-premise solution that operates on an entity’s own infrastructure, behind its own firewall, with centralized administration, auditing, and reporting.
Ensuring Automatic Logoff Security
Automatic logoff security is a critical requirement for proper HIPAA access control because it can help protect e-PHI and access to HIT systems when employees walk away from a workstation or otherwise leave logged in devices and accounts unattended.
With HIPAA two-factor authentication powered by PKI security, an on-site authentication server can be configured to automatically log off users after a pre-defined period of time. This period of time can be set by the designated security administrator, and the authentication server can discontinue the authorized login session for any service protected by this form of HIPAA two-factor authentication.
To log in again, an authorized user can simply enter the required user ID through your login mechanism and then completely secure authentication again on a mobile device, using the powerful combination of possessing an encrypted private key on the mobile device and verification of a PIN and/or fingerprint to complete authentication.
This procedure protects systems and e-PHI in the event that workstations, devices, or other access points are left unattended. But it also protects against another common problem with automatic logoff when password-based authentication is used. Many users will save their passwords in their browser or in an application in order to make future access easier, but this potentially allows an unauthorized user or attacker to gain access to e-PHI, even after a session is automatically logged off, because the user’s ID and password are saved and already populated in the login screen for entry. With a simply click or tap of a button, someone could use those credentials to access the system and e-PHI.
With the unique PKI approach to HIPAA two-factor authentication, no such attack or unauthorized use is possible. Only the authorized user can authenticate due to the requirement of two distinct authentication factors, the elimination of passwords from the login process, and the use of an out-of-band authentication procedure.
Advantages of On-premise HIPAA Two-factor Authentication
By installing and integrating HIPAA two-factor authentication with PKI security procedures, a covered entity can operate its own access control technology and does not have to rely on a public cloud service. This is particularly important for healthcare organizations, health plans, and business associates that do not want to trust e-PHI to a cloud service where authentication servers may be shared.
Also, an on-premise configuration means that covered entities can have trust center identity access management (IAM) in-house, with full administration and control of all user accounts. And this IAM can be configured as a single sign-on and connected directly to active directory systems to operate authentication within a closed network. It can also be integrated with other applications and systems so that the same powerfully secure yet fast and simple authentication can be used to protect and control access to any login.
With on-site deployment and on-premise administration, along with the tremendous flexibility of properly engineered cryptography, covered entities can enjoy total control and security for e-PHI with a single HIPAA two-factor authentication procedure.
Encrypted Data Storage and Transmission
To provider further access controls for stored PHI and to meet security requirements for the transmission of PHI, encrypted storage and transmission of data is vitally important.
The right encryption and storage solution will not only satisfy current HIPAA requirements but will also provide a solution for addressable specifications and place any healthcare provider well ahead of current and anticipated future regulations.
The relevant standards from the HIPAA Technical Safeguards are outlined below:
HHS Security Regulations as Amended January 2013
Security Standards for the Protection of Electronic PHI: Technical Safeguards - § 164.312
-
Standard: Integrity. Implement policies and procedures to protect electronic protected health information from improper alteration or destruction.
-
Implementation specification: Mechanism to authenticate electronic protected health information (Addressable). Implement electronic mechanisms to corroborate that electronic protected health information has not been altered or destroyed in an unauthorized manner
-
-
Standard: Transmission security. Implement technical security measures to guard against unauthorized access to electronic protected health information that is being transmitted over an electronic communications network.
-
Implementation specifications:
-
Integrity controls (Addressable). Implement security measures to ensure that electronically transmitted electronic protected health information is not improperly modified without detection until disposed of.
-
Encryption (Addressable). Implement a mechanism to encrypt electronic protected health information whenever deemed appropriate.
-
-
Using Encryption to Meet and Exceed Security Standards for Integrity and Transmission
To meet the integrity and transmission standards, access controls, such as the PKI authentication method mentioned in the previous section, will help to ensure that unauthorized users can never access PHI and alter or destroy it. And strong encryption can protect health information from improper access, alteration or destruction while it is stored at rest or even while it is being transmitted.
With an on-premise data storage solution that operates on your own infrastructure and applies AES-256 encryption to health information at every moment, your stored data, folders, files, and even messages can be protected against any form of intrusion, alteration, or destruction.
The encryption scheme means only authorized users who can successfully verify their identity and complete a PKI authentication requirement will be able to access e-PHI and download it to their systems or into your other solutions for viewing in a decrypted form. Unauthorized users will be unable to access e-PHI, and, even if they could, this powerful encryption would prevent them from viewing or altering it in decrypted form.
The Power of AES-256 Encryption and How Encryption Keys Are Generated
The key proper encryption is to use the Advanced Encryption Standard (AES), which is a symmetric block cipher used by the U.S. government to protect classified information and that is also used in software and hardware throughout the world to encrypt sensitive data.
A 256-bit AES encryption key provides powerful encryption and security, and it can be produced by generating 32 random bytes with a random number generator that employs the Micali Schnorr algorithm. These 32 bytes and a UTF-8 encoded string are then used as the input of a SHA256 hash computation. The result of the computation is used as an AES 256-bit encryption key in cipher block chaining mode (CBC), which means that a sequence of bits can be encrypted as a single unit or block with a cipher key applied to the entire block.
Thus, PHI can be encrypted with AES 256-bit protection in CBC, and this will ensure that the data can never be accessed or decrypted while it is at rest. As an additional benefit, the same encryption can be applied during transmission of the data to ensure that it can never be accessed, altered, or destroyed while it is in transit over a network or between systems.
This means that, at every moment of transfer and storage, e-PHI can be completely protected and secure from any form of attack or intrusion, and it will be secure from any attempt to alter or destroy it in its decrypted form.
Integrating a Third Party Solution for On-premise Encryption and Storage
Thankfully, while the cryptography behind AES-256 encryption is incredibly powerful and sophisticated, there are existing solutions that can be deployed on your own servers and that will automatically generate encryption keys and encrypt e-PHI and other health information for you.
In fact, highly encrypted data storage, file sharing, and even messaging is available as a private cloud solution that can be installed on your own architecture and operated easily with a user-friendly web interface and full administrative tools and controls. This gives administrators the ability to manage the solution according to unique needs and to access centralized reporting and administrative features to manage accounts and monitor and audit security.
This type of solution can fit perfectly into your HIPAA compliance program, policies, procedures, and overall strategy for ensuring privacy and securing e-PHI. And it can even be integrated with your EHR and other HIT systems through convenient APIs and plugins that allow these systems to transmit and store data through your secure and highly encrypted on-premise portal.
The end result is that you can not only meet the current HIPAA regulatory standards for integrity and transmission, but you can even implement solutions for addressable standards and keep your healthcare organization well ahead of future developments and requirements.
Meeting the HIPAA Security Standard for Audit Controls
Another HIPAA requirement in its Technical Safeguards is the audit controls standard, and ideally any data security solution you use should provide features and functionality to support these auditing requirements. HIPAA outlines the audit controls standard as follows:
HHS Security Regulations as Amended January 2013
Security Standards for the Protection of Electronic PHI: Technical Safeguards - § 164.312
-
Standard: Audit controls. Implement hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain or use electronic protected health information.
If you choose a data security solution that enables encrypted storage, transmission, and sharing of e-PHI with PKI authentication for access controls, the same system should also provide audit controls for tracking and analyzing access to your solution and to all data and information that it contains.
Since a private cloud solution or secure portal for e-PHI will usually be equipped with convenient and comprehensive administrative tools, it is a relatively simple proposition to ensure that these tools also include auditing capabilities. Since user access to your data portal can be strictly controlled through PKI authentication, all attempts to access the system can be logged and tracked.
The same can be said for accessing, uploading, and downloading any files or messages. A properly engineered system will track all such activity and provide reports and detailed history so that authorized administrators can conduct reviews and ensure that all e-PHI has been protected and handled according to HIPAA compliance requirements and each covered entity’s policies and procedures.
Implementing Integrity Controls with Digital Signatures
To meet HIPAA requirements for integrity controls, digital signature technology can be implemented to validate the authenticity and integrity of documents, messages, and any type of data containing e-PHI. Digital signatures involve advanced mathematical techniques that provide evidence of the origin, identity, and status of an electronic document, message, or transaction. They can also acknowledge informed consent by the signer.
In exactly the same way as the PKI authentication procedure explained earlier, digital signatures use asymmetric cryptography and mathematical algorithms to generate two keys that are mathematically linked. One is a public key used by the digital signer for authentication, and the other is a private key that is used to verify the identity of an authorized user.
To create a digital signature, signing software, such as a secure portal for encrypted e-PHI, creates a one-way hash of the electronic data to be signed, and an authorized user’s private key is used to encrypt the hash.
The value of the hash is unique to the hashed data, and any change in the data results in a different value, even if only a single character of data is changed. Thus, the hash value allows covered entities to validate the integrity of the data by using the portal’s public key to decrypt it. If the decrypted hash matches a second computed hash of the same data, then this proves that the data hasn’t changed since it was last signed.
If the two hashes don’t match, then this is evidence that the data has been improperly modified or that it may have been improperly accessed because the latest signature may have been created by a public key that doesn’t match the signer’s private key.
Ultimately, by applying the same, powerful security principles of PKI authentication, a secure portal for encrypted data storage, file sharing, and messaging can protect and verify the integrity of e-PHI. It can provide the powerful security of digital signatures through a simple front-end software interface that makes it simple and easy to audit and verify the integrity of e-PHI.
Applying Secure Technology for Documentation Retention
As part of the HIPAA compliance requirements, covered entities are also required to document all privacy and security policies and procedures and to keep copies of these documents for six years. Any changes to policies and procedures must also be documented, and any updates to documentation must also be retained as part of the six-year requirement. There must also be an audit trail so that access and updates to documentation can be monitored and reviewed.
This HIPAA requirement does not apply to retention of PHI, but it is important to note that each state typically has its own regulations for securely retaining PHI for specified periods of time.
To satisfy either requirement, a secure data portal with encryption, access controls, and audit controls is an ideal solution to store and retain documentation. Whether you are simply storing, auditing, and retaining documents for HIPAA policies and procedures or you need to retain patient records for a particular length of time, an on-premise data security, storage, and collaboration solution is a highly recommended choice.
Getting Expert Consultation and Implementation Support
To help you understand HIPAA security requirements and how to implement next-generation security technologies that will help ensure current and future compliance, free expert consultation and support is available.
SecSign Technologies is a sister company of SecCommerce Informationssysteme GbmH, a pioneer of cryptography solutions with more than 16 years of experience in developing public key infrastructure (PKI), electronic signature, and smart card technologies. Our security experts and cryptography engineers have developed, deployed, and maintained systems that have successfully protected confidential data and user access for major government agencies, insurance providers, and numerous major corporations, including Johnson & Johnson, IBM, Siemens, Fujitsu, T-Systems, BMW, and Audi.
Our security engineers can provide insight and assistance in deploying HIPAA two-factor authentication to protect you as a covered entity or business associate under HIPAA compliance requirements. Contact us today to request a free consultation and to learn more about our SecSign ID and SecSign Secure Portal solutions, which provide powerful, compliant, and cost-effective security for e-PHI.
To request your consultation, please contact me, via Linkedin or visit our web page and submit a contact request.
PhD in Physics and material science
9yNice job...
CIO of PriceSmart, the only operator of membership warehouse clubs in Central America, the Caribbean, and Colombia
9yThanks for a great summary!