Kimberly Shutters

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.

10 Requirements to Include in Your Business Associate Agreement The HIPAA Privacy, Security, and Breach Notification Rule require Covered Entities and their third-party vendors, referred to by the Department of Health and Human Services as Business Associates (BAs), are required to obtain a signed Business Associate Agreement (BAA) from each vendor, and their subcontractors, to ensure appropriate safeguards are implemented to protect Protected Health Information (PHI) and electronic PHI (ePHI). The BAA serves as a contract to clarify and limit the use or disclosure of PHI only as permitted or required by law. Put it in the Business Associate Agreement Healthcare third-party vendors are required to comply with the HIPAA Privacy and Security Rules to appropriately safeguard protected health information (PHI). One of those requirements is a current and signed contract, referred to as a Business Associate Agreement (BAA), for each third-party vendor. Four things third-party vendor contract do: Serves to clarify and limit the allowable uses and disclosures of PHI by the vendor. Identifies how a third-party vendor may use or disclose PHI only as permitted or required by its contract or as required by law. That a third-party vendor is directly liable under the HIPAA Rules and subject to civil and, in some cases, criminal penalties for making uses and disclosures of PHI that are not allowed in the contract or required by law. A third-party vendor is directly liable and subject to civil penalties for failing to safeguard electronic protected health information in accordance with the HIPAA Security Rule. Something to Ponder … Business Associates can and have been held directly liable and subject to civil and, in some cases, criminal penalties for making uses and disclosures of PHI that were not authorized. 10 Business Associate Agreement Requirements The written contract between a CE and a BA must: Determine when and how the third-party vendor is allowed to use or disclose PHI. Require that the third-party vendor will not use or disclose PHI other than what has been permitted by the contract or required by law. Establish what safeguards will be put in place to prevent unauthorized PHI disclosure. This includes implementing HIPAA requirements surrounding electronic PHI. This effort is intended to help reduce and eliminate Medical Records Snooping!! Require the third-party vendor to report to the provider any use or disclosure of PHI not covered by the contract, including incidents or breaches of unsecured PHI. Ensure the third-party vendor will disclose PHI as specified in the contract to satisfy a provider ‘s obligation with respect to individuals’ requests for copies of their PHI. PHI should be available for amendments as well. To the extent the third-party vendor is to carry out a provider ‘s obligation under HIPAA, require that the third-party vendor comply with the requirement relevant to the obligation. Ensure internal practices, books and records relating to the use and disclosure of PHI by the third-party vendor will be made available to the Department of Health and Human Services to determine the provider ‘s HIPAA compliance. Require that the third-party vendor return or destroy all PHI received from, or created or received by the third-party vendor on the provider ‘s behalf, upon termination of the contract. Require that third-party vendor enter agreements with their subcontractors that may have access to PHI. Allow the provider to terminate the contract if the third-party vendor violates a material term of the contract. HHS provides a sample BAA to help CEs and BAs more easily comply with the BA contract requirements. Helpful Tips for Third-Party Vendor Contract Management Here are four tips to incorporate into your third-party vendor contract management activities:  Keep all contracts/agreements in a centralized location that can be accessed anytime. Know when third-party vendor contracts expire. Ensure all third-party vendor contract are signed. Continually monitor third-party vendor compliance by issuing assessments and include third-party vendors when performing your risk analysis.

Documentation That’s What It’s All About Today I am breaking down the Documentation standard, 45 §164.316(b)(1), from the HIPAA Security Management Process into byte-size portions to help you understand how they are significant to your organization. Before I can break down today’s topic, I first should set the document stage. When it comes to auditors, lawyers and the Department of Health and Human Services (HHS) it’s all about your documentation. It’s the first thing they will ask for when they come to visit. If you don’t have it – it will be as if it was never done.  That is why the Documentation of your risk analysis and HIPAA-related policies, procedures, reports, and activities is a requirement under the HIPAA Security Rule.  Documentation provides the how (or why) and the decisions and/or actions were made. Some of those actions may include: Performed your security risk analysis Implemented safeguards to mitigate identified risks Provided training Security reminders Over time, your security documentation folder will become a tool that helps your security procedures be more efficient. These records will be essential if you are ever audited for compliance with the HIPAA Rules or an EHR Incentive Program. Breaking Down the Documentation Standard The Documentation standard 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.” The standard has three implementation specifications, they are: Time Limit (Required) Availability (Required) Updates (Required) Time Limit The Time Limit implementation specification requires CEs and BAs to: “Retain the documentation required by paragraph (b)(1) of this section for 6 years from the date of its creation or the date when it last was in effect, whichever is later.” This six-year period must be considered the minimum retention period for required documentation under the Security Rule. Note: Some organizations may choose to keep their documentation longer based on state law, requirements of accreditation organizations, or other business reasons. Availability The Availability, 45 § 164.316(b)(2)(ii), implementation specification requires regulated entities to: “Make documentation available to those persons responsible for implementing the procedures to which the documentation pertains.” Organizations often make documentation available in printed manuals and/or on their websites. Updates The Updates, 45 § 164.316(b)(2)(iii), implementation specification requires regulated entities to: “Review documentation periodically, and update as needed, in response to environmental and/or operational changes affecting the security of the electronic protected health information (ePHI).” The need for periodic reviews and updates will vary based on the regulated entity’s documentation review frequency and/or the volume of environmental or operational changes that affect the security of ePHI. Creating a HIPAA Documentation Master File To help you contain all the documents you will generate, I recommend creating a HIPAA Documentation Master File. Some of the documentation should include, but not be limited to: HIPAA Security Risk Analysis Policies and Procedures Reports and activities as it relates to PHI Your documentation should include how you conducted the security risk analysis and implemented safeguards to address the risks identified during your risk analysis. Examples of What to Keep Your HIPAA Documentation Master File should include, and not limited to, the following: • Your policies and procedure• Completed security checklists• Training materials presented to staff and volunteers; any associated certificates of completion• Updated BA agreements• Security risk analysis reports• Electronic Health Record (EHR) audit logs that show both utilization of security features and efforts to monitor users’ actions• Risk management action plans or other documentation (that shows appropriate safeguards are in place throughout your organization), implementation timetables, and implementation notes• Any security incidents and breach information Over time, your security documentation folder is one of the tools in your toolbox to help you become more efficient. These records are essential if you are audited for compliance with the HIPAA Rules. YOUR security risk analysis process is an opportunity for you to learn as much as possible about health information security. Do not ignore YOUR need to be HIPAA compliant! ANY device or media that contains ePHI needs to be properly protected – HIPAA is not system or hardware specific – it applies to all! Regulated entities must periodically review and update its documentation in response to environmental and/or organizational changes that affect the security of ePHI. Healthcare organization 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 Administrative Safeguards Today I am breaking down the Administrative Safeguards of the HIPAA Security Rule, 45 CFR § 164.308, 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 Administrative Safeguards comprise over half of the HIPAA Security Rule require healthcare regulated entities to implement measures to meet the security standards. These include things such as, assignment or delegation of security responsibility to an individual and security training requirements. Administrative Safeguards Definition Actions, policies and procedures, to manage the selection, development, implementation, and maintenance of security measures to protect ePHI and to manage the conduct of the CE’s or BA’s workforce in relation to the protection of that information.” As with all the standards in the HIPAA Security Rule, compliance with the Administrative Safeguards requires CEs and BAs perform an evaluation of the security controls already in place, an accurate and comprehensive risk analysis, and a series of documented risk management solutions derived from a number of factors unique to each CE and BA. What are the Administrative Safeguards? An important step in protecting electronic PHI in your organization is to implement reasonable and appropriate Administrative Safeguards intended to set the foundation for your security program. Administrative safeguards are administrative actions, policies, and procedures to prevent, detect, contain, and correct security violations. Administrative safeguards involve the selection, development, implementation, and maintenance of security measures to protect ePHI and to manage the conduct of workforce members in relation to the protection of that information. A central requirement is that you perform a security risk analysis which identifies and analyzes risks to ePHI and then implement security measures to reduce those identified risks. The Administrative Safeguards and their implementation specifications are:Note: (R) = Required      (A) = Addressable Security Management Process Security Management Process – 45 CFR § 164.308(a)(1) • Risk Analysis (R)• Risk Management (R)• Sanction Policy (R)• Information System Activity Review (R) Assigned Security Responsibility Assigned Security Responsibility – 45 CFR § 164.308(a)(2) Workforce Security Workforce Security – 45 CFR § 164.308(a)(3) • Authorization and/or Supervision (A)• Workforce Clearance Procedure (A)• Termination Procedures (A) Information Access Management Information Access Management – 45 CFR § 164.308(a)(4) • Isolating Healthcare Clearinghouse Functions (R)• Access Authorization (A)• Access Establishment and Modification (A) Security Awareness and Training Security Awareness and Training – 45 CFR § 164.308(a)(5) • Security Reminders (A)• Protection from Malicious Software (A)• Log-in Monitoring (A)• Password Management (A) Security Incident Procedure Security Incident Procedures – 45 CFR § 164.308(a)(6) • Response and Reporting (R) Contingency Plan Contingency Plan – 45 CFR § 164.308(a)(7) • Data Backup Plan (R)• Disaster Recovery Plan (R)• Emergency Mode Operation Plan (R)• Testing and Revision Procedures (A)• Applications and Data Criticality Analysis (A) Evaluation Evaluation – 45 CFR § 164.308(a)(8) Business Associate Contracts and Other Arrangements Business Associate Contracts and Other Arrangements – 45 CFR § 164.308(b)(1) • Written Contract or Other Arrangement (R) Vulnerabilities and Security Mitigation Examples The following table contains a list of possible Security Components, Examples of Vulnerabilities and Examples of Security Mitigation Strategies for the Administrative Safeguards. In general, these are the administrative functions that should be implemented to meet the security standards. These include security management processes, assignment or delegation of security responsibility to an individual, and workforce security training requirements. All of the standards and implementation specifications found in the Administrative Safeguards section refer to administrative functions, such as policy and procedures that must be in place for the management and execution of security measures. These include performance of your security management processes, assignment or delegation of security responsibilities, training requirements and evaluation and documentation of all decisions. Remember: Security is not a one-time project, but rather an on-going, dynamic process that will create new challenges as technologies change. Healthcare organization and third-party vendors should understand patients are entrusting them with their most private and intimate details, they expect it to remain secure.