HIPAA Security

Why You Need A Current HIPAA Risk Analysis Conducting a HIPAA risk analysis is the first step in identifying the risks in your organization. The Department of Health and Human Services (HHS) requires healthcare organizations and their third-party vendors that create, receive, maintain or transmit identify risks and vulnerabilities that effects electronic protected health information (e-PHI).  Once the risks have been identified it is imperative to implement reasonable and appropriate security measures to protect against reasonably anticipated threats or hazards to the security or integrity of e-PHI. Failure to implement the appropriate security measures leaves your organization vulnerable and that’s not a good place to be. https://youtu.be/QWRn2r5R7ts HIPAA Risk Analysis Audit Results In December 2020, HHS Office of Civil Rights released their 2016 – 2017 HIPAA Audit Industry Report. The audit included 150 healthcare organizations (55% were provider) and 41 third-party vendors (14% were billing & claims). The results for healthcare [organizations and third-party vendors audited were:  Security Risk Analysis – OCR found less than 20% fulfilled their regulatory responsibilities to safeguard electronic PHI (ePHI) through risk analysis activities.  Risk Management Standards – OCR found that because both healthcare providers and their third-party vendors failed to conduct appropriate risk analyses, they were then unable to connect their security plans to the management of identified risks. An overwhelming percentage of healthcare providers (94%) and third-party vendors (88%) failed to implement appropriate risk management activities. Clues Found in the Audit Report OCR found that both providers and third-party vendors failed to implement effective risk analysis and risk management activities to safeguard ePHI. As a result of these findings likely to draw closer scrutiny from investigators during breach and individual complaint investigations. Providers and third-party vendors should consider the following takeaways from OCR’s audit findings:  Conduct a security risk analysis of the potential risks and vulnerabilities to ePHI – Providers and their third-party vendors are responsible for maintaining an appropriate and current risk analysis consistent with policies, procedures, and changes in their environment, operations, or security incidents.  Implement appropriate risk management strategies – providers and their third-party vendors must focus on their security risk analysis findings to inform and link their security plans to the management of identified risks.  Why Does It Matter? Your HIPAA Risk Analysis helps you measure the impact of threats and vulnerabilities that pose a risk to the PHI in your organization. While there is no single method or “best practice” that guarantees compliance; however, most HIPAA Risk Analysis and risk management processes have these steps in common. Your HIPAA Risk Analysis should include, but is not be limited to, the following activities: Evaluate the likelihood and impact of potential risks to your ePHI. Implement appropriate security measures to address the risks identified in your HIPAA Risk Analysis. Implement appropriate security measures to address the risks you identified in your HIPAA Risk Analysis. Document the chosen security measures and, where required, the rationale for adopting those measures. Maintain continuous, reasonable, and appropriate security protections. The results of your HIPAA Risk Analysis will be used to determine reasonable and appropriate security measures for your organization. Remember: ANY change made to the hardware, software and/or medical devices used to create, receive, maintain, or transmit, an organization’s PHI requires an update to the HIPAA Risk Analysis.

Third-Party Vendors Size Doesn’t Matter That’s right folks – if you are a healthcare third-party vendor size doesn’t matter when it comes to HIPAA compliance. Healthcare third-party vendors that create, receive, maintain, and/or transmit protected health information is required by law to comply with the regulations.  Did You Know? A healthcare third-party vendor, referred to by the Department of Health and Human Services (HHS) as a business associate (BA), were invited to the HIPAA party in February 2013. Even after all this time, HIPAA compliance still remains a challenge for many Covered Entities (CEs) and their third-party vendors alike. From Then Until Now As reported by HIPAA Journal in their August 25, 2017, blog post, “HIPAA Business Associate Compliance”: “In late 2016 – almost four years after the Final Omnibus Rule was enacted – the California Healthcare Foundation funded research into HIPAA Business Associate compliance. In the compilation of the “Business Associate Compliance with HIPAA” report, researchers conducted telephone interviews with sixteen Covered Entities ranging in size from small physician offices to large integrated health systems. The researchers focused on the number and size of contracted third-party vendors, the types of services performed by third-party vendors, the “sophistication levels” of BAs, and the Covered Entities efforts to conduct due diligence on BAs and oversee HIPAA Business Associate compliance. It is important to note that, in California, BAs may also be covered by the state´s Confidentiality of Medical Information Act (CMIA).” Sadly, even after almost ten years third-party vendors remain unaware of their responsibilities and/or unsure how to comply with the HIPAA Security Rule in their environment. Why Does It Matter? Simple, third-party vendors can and have been held directly liable to civil and, in some cases, criminal penalties for making uses and/or disclosures of PHI that were not authorized. In 2018, there were 71 healthcare breaches that affected 5.4 million patients.  It is important that Covered Entities and their third-party vendors understand patients are entrusting them with their most private and intimate details. They do expect the provider and third-party vendors to comply with the HIPAA rules and keep their information secure!

HIPAA Audit Controls and Audit Logs Today I am breaking down the one of the Technical Safeguard standards,  Audit Controls, 45 § 164.312(b), into byte-size portions to help you understand how it is significant to your organization. Audit Logs are  The HIPAA Security Rule provision on requires regulated entities to: Implement hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain or use electronic protected health information. Audit Controls – What Are They?   The majority of information systems provide some level of audit controls with a reporting method, such as audit logs. These controls are useful for recording and examining information system activity which also includes users and applications activity. Audit controls that produce audit reports work in conjunction with audit logs and audit trails. Audit logs and trails assist regulated entities with reducing risk associated with: reviewing inappropriate access; tracking unauthorized disclosures of ePHI; detecting performance problems and flaws in applications; detecting potential intrusions and other malicious activity; and providing forensic evidence during investigation of security incidents and breaches. As part of this process, regulated entities should consider which audit tools may best help them with reducing non-useful information contained in audit records, as well as with extracting useful information. Audit Logs and Audit Trails – What Are They? According to the National Institute of Standards and Technology (NIST), audit logs are records of events based on applications, users, and systems, and audit trails involve audit logs of  applications, users, and systems. Audit trails’ main purpose is to maintain a record of system activity by application processes and by user activity within systems and applications. Regulated entities should make sure that they appropriately review and secure audit trails, and they use the proper tools to collect, monitor, and review audit trails. Protecting audit logs and audit trails prevent intruders from tampering with the audit records and protecting their integrity. Not safeguarding audit logs and audit trails can allow hackers or malevolent insiders to cover their electronic tracks, making it difficult for regulated entities to not only recover from breaches, but to prevent them before they happen.   The HIPAA Security Rule does not identify what information should be collected from an audit log or trail or how often the audit reports should be reviewed. When determining reasonable and appropriate audit controls for information systems containing or using ePHI, regulated entities must consider their risk analysis results and organizational factors, such as: Technical infrastructure Hardware Software security Audit Trails Examples Different types of audit trails your practice should consider, including: Application audit trails – Normally monitor and log user activities in the application. This includes the application data files opened and closed, and the creating, reading, editing, and deleting of application records associated with ePHI. System-level audit trails – Usually capture successful or unsuccessful log-on attempts, log-on ID/username, date and time of each log-on/off attempt, devices used to log-on, and the application the user successfully or unsuccessfully accessed. User audit trails – Normally monitor and log user activity in a ePHI system or application by recording events initiated by the user, such as all commands directly initiated by the user, log on attempts with identification and authentication, and access to ePHI files and resources. It is important to point out that although the HIPAA Security Rule does not identify data that must be gathered by the audit controls or how often the audit reports should be reviewed.  A regulated entity must consider its risk analysis and organizational factors, such as current technical infrastructure, hardware and software security capabilities, to determine reasonable and appropriate audit controls for information systems that contain or use ePHI. Is Anyone Looking at the Audit Logs? There are several reasons to implement and monitor audit controls. Over the last few weeks I’ve shared several of them, here are two: Doctor accessed medical records without authorization AND gave some of that PHI to an ATTORNEY!! Nurse viewed 13,000 patients’ medical records without authorization for 15 Months!! How do you know if, or who, is snooping in your medical records? . . Audit Logs! . . But it Doesn’t End There!   Regulated entities should review and secure audit logs/trails, and use proper tools to collect, monitor, and review audit logs/trails. But, the HIPAA Security Rule does not identify what information should be collected in an audit log/trail or how often the audit reports should be reviewed. Each regulated entity must consider their complete and thorough risk analysis results and organizational factors, such as their current technical infrastructure, hardware, and software security capabilities. The majority of information systems provide some level of audit controls with a reporting method, such as audit reports. These controls are useful for recording and examining information system activity which also includes users and applications activity. It is important to protect your audit logs and trails to prevent intruders from tampering with the audit records and protecting their integrity. Not safeguarding audit logs and audit trails can allow hackers or insider threats to cover their tracks electronically, making it difficult for regulated entities to not only recover from incidents or breaches, but to prevent them before they happen. Add Your Heading Text Here Understanding the Importance of Audit Controls The HIPAA Security Rule provision on Audit Controls (45 C.F.R. § 164.312(b)) requires regulated entities to apply hardware, software, and/or procedural mechanisms that record and examine activity within information systems that contain or use electronic protected health information (ePHI). Audit controls produce audit reports which work in conjunction with audit logs and audit trails. Audit logs and audit trails assist CEs and BAs in reducing associated risks by: → Tracking inappropriate access → Tracking unauthorized disclosures of ePHI → Detecting performance problems and flaws in applications → Detecting potential intrusions and other malicious activity → Providing forensic evidence during security incidents and breach investigations   It is imperative for regulated entities to review their audit trails regularly, both particularly after security incidents or breaches, and during real-time operations. Regular review of information system activity should promote awareness of any information system activity that could suggest a security incident or breach. Access to audit trails should be strictly restricted, and should be provided only to authorized personnel. Covered Entities

Breaking Down the HIPAA Security Rule Physical Safeguards Today I am breaking down the Physical Safeguards of the HIPAA Security Rule, 45 CFR § 164.310, into byte-size portions to help you understand how they are significant to your organization. The Physical Safeguards are physical measures, policies, and procedures to protect a regulated entity’s electronic information systems and related buildings and equipment from natural and environmental hazards, and unauthorized intrusion. Physical Safeguards Definition The HIPAA Security Rule defines Physical Safeguards as: “Physical measures, policies and procedures to protect a CE’s and BA’s electronic information systems and related buildings and equipment, from natural and environmental hazards, and unauthorized intrusion.” What are the Physical Safeguards? An important step in securing electronic protected health information (ePHI) is to implement reasonable and appropriate physical safeguards for information systems and related equipment and facilities. When evaluating and implementing the standards, a regulated entity must consider all physical access to ePHI. This may extend outside of an actual office, and could include workforce members’ homes or other physical locations where they access ePHI. As with all the standards in the HIPAA Security Rule, compliance with the Physical Safeguards standards requires regulated entities to perform a complete and thorough evaluation of their security controls already in place and a series of documented solutions derived from a number of factors unique to their organization. The Physical Safeguards and their implementation specifications are:Note: (R) = Required      (A) = Addressable Facility Access Controls – 45 CFR § 164.310(a)(1) Contingency Operations (A) Facility Security Plan (A) Access Control and Validation Procedures (A) Maintenance Records (A) Workstation Use – 45 CFR § 164.310(b) Workstation Security – 45 CFR § 164.310(c) Device Media Controls – 45 CFR § 164.310(a)(1) Disposal (R) Media Re-use (R) Accountability (A) Data Backup and Storage (A) Security Area to Consider The following table contains a list of possible Security Area to Consider and Examples of Potential Security Measure for the Physical Safeguards. Although the Physical Safeguard standard specifically references “workstations,” this is defined in the HIPAA Rules as: “A computing device, for example a laptop or desktop computer, or any other device that performs similar functions and electronic media stored in its immediate environment.” Portable electronic devices are included in this definition which includes tablets, smart phones, and similar portable electronic devices (and easily portable Thumb Drives). You should know physical security controls are often the simplest and least expensive forms of protection to secure PHI. Some physical security controls may even have no cost incurred to implement – such as ensuring portable electronic devices (laptop computers, portable storage devices, and pen drives) are locked away when they are not in use. Another method is to limit the amount of PHI they contain. Remember: Security is not a one-time project, but rather an on-going, dynamic process that will create new challenges as CEs’ & BAs’ organizations and technologies change. It is NOT a sprint, but instead a MARATHON!! Healthcare organizations and third-party vendors should understand that patients are entrusting them with their most private and intimate details, they do expect it to remain secure.

HIPAA Security Rule Technical Safeguards Today I am breaking down the Technical Safeguards of the HIPAA Security Rule, 45 CFR § 164.312, into byte-size portions to help you understand how they are significant to your organization. The HIPAA Security Rule establishes security standards for protecting all electronic protected health information (ePHI).  The Technical Safeguards require regulated entities and their third-party vendors, to implement measures to meet the security standards. These include things such as, implement access controls, audit controls, integrity, person or entity authentication, and transmission security requirements. HIPAA Security Rule Technical Safeguards Definition The HIPAA Security Rule defines Technical Safeguards as, 45 CFR § 164.304: The technology and the policies and procedures for its use that protect ePHI and control access to it. What are the HIPAA Security Rule Technical Safeguards? Technical safeguards are becoming increasingly more important due to technology advancements in the health care industry. As technology improves, new security challenges emerge. Healthcare organizations face challenges every day in their effort to secure electronic PHI from various internal and external risks. To reduce risks to electronic PHI, regulated entities must implement Technical Safeguards. Implementation of the Technical Safeguards standards represent good business practices for technology and associated technical policies and procedures within a covered entity.  The Technical Safeguards and their implementation specifications are: Note: (R) = Required      (A) = Addressable Access Control – 45 CFR 164.312(a)(1) Unique User Identification – (R) Emergency Access Procedure – (R) Automatic Logoff – (A) Encryption and Decryption – (A) Audit Controls – 45 CFR 164.312(b) Integrity – 45 CFR 164.312(c)(1) Mechanism to Authenticate ePHI – (A) Person or Entity Authentication – 45 CFR 164.312(d) Transmission Security – 45 CFR 164.312(e)(1) Integrity Controls – (A) Encryption – (A) Technical Safeguards Security Area to Consider The following table contains a list of possible Security Components, Examples of Vulnerabilities and Examples of Security Mitigation Strategies for the Technical Safeguards. The Security Rule does not require specific technology solutions. Determining which measure to implement is a decision regulated entities must make based on what is reasonable and appropriate for their specific organization, given their own unique characteristics, as specified in § 164.306(b) the Security Standards: General Rules, Flexibility of Approach. Some solutions may be costly, especially for smaller regulated entities. While cost is one factor regulated entities may consider when deciding on the implementation of a particular security measure, it is not the only factor. The Security Rule is clear that reasonable and appropriate security measures must be implemented, see 45 CFR 164.306(b), and that the General Requirements of § 164.306(a) must be met. Together with reasonable and appropriate Administrative and Physical Safeguards, successful implementation of the Technical Safeguards standards will help ensure that regulated entities will protect the confidentiality, integrity and availability of ePHI. Remember: Security is not a one-time project, but rather an on-going, dynamic process that will create new challenges as regulated entities organizations and technologies change. Healthcare organizations and third-party vendors should understand that patients are entrusting them with their most private and intimate details, they do expect it to remain secure. 

Understanding the HIPAA Policies and Procedures Today, I am diving a little deeper into the HIPAA Security Rules Administrative Safeguards, 45 CFR § 164.316 to break down the Policies and Procedures into byte-size portions to help you understand how they are significant to your organization. The standard requires regulated entities, Covered Entities (CEs) and their third-party vendors, to implement and maintain reasonable and appropriate written policies and procedures and documentation necessary to comply with the provisions of the Security Rule. Specifically, it requires regulated entities to: “Implement reasonable and appropriate policies and procedures to comply with the standards, implementation specifications, or other requirements of this subpart, taking into account those factors specified in § 164.306(b)(2)(i), (ii), (iii), and (iv) [the Security Standards: General Rules, Flexibility of Approach]. This standard is not to be construed to permit or excuse an action that violates any other standard, implementation specification, or other requirements of this subpart. Regulated entities may change their policies and procedures at any time, provided that the changes are documented and are implemented in accordance with this subpart.” What is the Difference Between Policy and Procedure?  Procedures describe how the organization carries out that approach, setting forth explicit, step-by-step instructions that implement the organization’s policies. The Policies and Procedures requirement include:Note: (R) = Required      (A) = Addressable Policies and Procedures – 45 CFR 164.316(a) Documentation – 45 CFR 164.316(b)(1) Time Limit – (R) Availability – (R) Updates – (R) The following table contains a list of possible Security Areas to Consider & Examples of Potential Security Measure: The following table contains a list of possible Security Components, Examples of Vulnerabilities, and Examples of Security Mitigation Strategies for the Organizational Safeguards. Policies and Procedures While this standard requires regulated entities to implement policies and procedures, the Security Rule does not define either “policy” or “procedure.” To help you understand the difference between the two I have included their Oxford Learner’s Dictionaries definition for both below. Policy – a plan of action agreed or chosen by a political party, a business, etc.  Generally, policies define an organization’s approach. For example, most business policies establish measurable objectives and expectations for the workforce, assign responsibility for decision-making, and define enforcement and consequences for violations. Procedure – a way of doing something, especially the usual or correct way. Your policies and procedures (P & P’s) should reflect the mission and culture of your organization; thus, the Security Rule enables each regulated entity to use current standard business practices for policy development and implementation. P & P’s required by the Security Rule may be modified as necessary to meet the changing needs of the organization, as long as the changes are documented and implemented in accordance with the Security Rule. The P & P’s standard is further explained and supported by the Documentation Requirement. Documentation The Documentation Requirement requires regulated entities to: “(i) Maintain the policies and procedures implemented to comply with this subpart in written (which may be electronic) form; and (ii) if an action, activity or assessment is required by this subpart to be documented, maintain a written (which may be electronic) record of the action, activity, or assessment.” A regulated entity must maintain, for a period of six years after the date of their creation or last effective date (whichever is later), written security policies and procedures and written records of required actions, activities, or assessments. A regulated entity must periodically review and update its documentation in response to environmental or organizational changes that affect the security of electronic protected health information (PHI). Remember: Security is not a one-time project, but rather an on-going, dynamic process that will create new challenges as regulated entities organizations and technologies change. Healthcare organization and third-party vendors should understand patients are entrusting them with their most private and intimate details, they do expect it to remain secure.