1 Compliance HIPAA Security COMPLIANCE Checklist For Employers All of the following steps must be completed by April 20, 2006 (April 14, 2005 for Large Health Plans) Broadly speaking, there are three major steps to complying with HIPAA Security. I. Identify the appropriate safeguards necessary to protect Electronic Protected Health Information (ephi). II. Create policies and procedures to implement those safeguards and train employees on those policies and procedures. III. Document the policies and procedures as well as the process used to identify the appropriate safeguards. Identify Appropriate Safeguards Important Tip: We strongly recommend that as you work through this checklist you document your analysis and decision making process for each specific Standard and Implementation Specification. This analysis will be the basis for your written documentation required in Step III., above. The HIPAA Security Rules are divided into three broad categories: Administrative Safeguards; Physical Safeguards; Technical Safeguards. Each category consists of a number of Standards. Each Standard consists of a number of Implementation Specifications; these are the actual tasks that must be accomplished to comply with the HIPAA Security Rules. Implementation Specifications are further divided into two types: Required Implementation Specifications as the name suggests, all covered employers must implement all Required Implementation Specifications. Addressable Implementation Specifications Addressable Implementation Specifications only need to be implemented if the employer decides it is reasonable and appropriate to do so. However, if the employer determines it is not reasonable and appropriate to implement an Addressable Implementation Specification, the employer must: i) document why it is not reasonable and appropriate; and ii) implement an equivalent alternative. See Appendix A for more details on implementing an Addressable Implementation Specification.
2 Compliance We will lay out the Safeguards, Standards, and Implementation Specifications in this outline as follows: SAFEGUARD I. Standard 1 Implementation Specification (Required or Addressable) Implementation Specification (Required or Addressable) *** Standard 2 Implementation Specification (Required or Addressable) *** SAFEGUARD II. Standard 1 Implementation Specification (Required or Addressable) ETC.
3 Administrative Safeguards I. ADMINISTRATIVE SAFEGUARDS Standard 1: Security Management Process The security management process standard requires the employer to identify security issues and create and implement policies and procedures to prevent, detect, contain, and correct security violations. The security management process is the foundation upon which all of the other security activities are built. Implementation Specification 1.1.1: Risk Analysis (Required) Conduct an accurate and thorough assessment of the potential vulnerabilities to the confidentiality, integrity, and availability of ephi stored in the employer s systems. A basic risk analysis consists of identifying potential threats ephi, the likelihood of that threat occurring, and the impact of that threat. Although each employer s risk analysis will need to be tailored to fit their specific circumstances, most risk analyses will consist of at least the following steps. 1. A thorough inventory of all information systems that store or transmit ephi, including all hardware, software and electronic delivery systems, e.g. computer hard drives, network servers, removable storage devices, systems, Internet and intranet sites, etc. 2. Identification of potential threats to the confidentiality, integrity, and availability of ephi on each of those systems. Common threats may include hackers, poorly trained employees, unrestricted access to data, lack of passwords, power outages, fires, and natural disasters, etc. Identification of potential threats also includes identifying vulnerabilities in the system. Vulnerabilities may include failure to cancel passwords of terminated employees, employee s sharing passwords, weak or nonexsistent firewalls or antivirus software, failure to implement software patches, outdated computer equipment and/or software. 3. Determination of the likelihood and impact of each identified threat. 4. Identification of the security measures that should be implemented to lessen the threat to reasonable and appropriate levels. Note that this analysis includes a consideration of the costs associated with these security measures, e.g. a high cost security measure designed to eliminate a low impact, low probability threat is probably not reasonable or appropriate; on the other hand, cost is less relevant when considering security measures designed to protect against a high impact, high probability threat. (Essentially this step is accomplished by analyzing and implementing the remainder of the Standards and Implementation Specifications.)
4 Administrative Safeguards A risk-level matrix may be a useful tool when conducting your risk analysis. A basic risk analysis matrix compares the probability of a particular threat with its likely impact. A value is assigned to each probability and impact category and the two numbers multiplied together to come up with an overall ranking of that particular threat. Here is an example of a simple risk-level matrix. Probability Impact Low Score = 1 Medium Score = 2 High Score = 3 Low Score = 1 Total Risk Score 1 Total Risk Score 2 Total Risk Score 3 Medium Score = 2 Total Risk Score 2 Total Risk Score 4 Total Risk Score 6 High Score = 3 Total Risk Score 3 Total Risk Score 6 Total Risk Score 9 In our example, threats with a Total Risk Score of 9 are of greatest importance and require more significant efforts to prevent that threat, regardless of cost. On the other hand, threats with a Total Risk Score of 1 or 2 are of lesser priority and most likely only require cheap, easy to implement security measures. Note that your entire risk analysis process should be documented, including your reasons for choosing to implement or not implement specific security measures. Implementation Specification 1.1.2: Risk Management (Required) Implement the reasonable and appropriate security measures identified in your Risk Analysis. This may include, but not be limited to, writing policies and procedures, training employees, and purchasing and installing necessary hardware and software security measures. Implementation Specification 1.1.3: Sanction Policy (Required) Impose appropriate sanctions for employees who fail to comply with security measures implemented to protect ephi. Note that you can rely on your existing discipline policies and procedures for this Implementation Specification as long as those policies and procedures are effective and adequate to address any violations of your security measures. Implementation Specification 1.1.4: Information System Activity Review (Required) Implement procedures to regularly review records and reports of information system activity, e.g. audit logs, access reports, security incident tracking reports, to ensure that the security measures adopted are working. This may require identification of what reports are available and/or reports that may need to be created to meet this specification.
5 Administrative Safeguards Standard 2: Assign Security Responsibility (No separate Implementation Specifications.) Appoint a security officer who is responsible for the development and implementation of the policies and procedures required by your risk analysis. The security officer must be a single individual, not a department or committee. This person has final responsibility for ensuring that the employer complies with HIPAA Security. The person may be your HIPAA Privacy Officer, IT manager, or other appropriate individual.
6 Administrative Safeguards Standard 3: Workforce Security The purpose of this standard is to ensure that only employees who should have access to ephi as part of their job have such access. The focus of this standard is on who is given authorization to ephi; the next standard (Standard 4: Information Access Management) focuses on how the employer will ensure that only those employees who are given authorization can access ephi. Implementation Specification 1.3.1: Workforce Clearance Procedure (Addressable) This specification requires the employer to ensure that only suitable employees have access to ephi. The intent is that there is a screening process to weed out employees who should not have access to ephi at all and that those employees who do have access only have access that is appropriate to their position and background. The appropriate scope of the screening process for each position will vary based on the nature of the ephi to which the employee has access. So, for example, for a position that is responsible for cutting checks for a flex spending account but does not see the actual claims data, the screening process may consist of nothing more than ensuring that the employee understands the importance of not discussing data they see and no known history of violating confidentiality rules. On the other hand, the screening process for a position that will have access to detailed medical history while reviewing claims appeals on a self-funded health plan may require a criminal background check and demonstrated ability to maintain the confidentiality of sensitive information. Implementation Specification 1.3.2: Authorization and/or Supervision (Addressable) The employer must have procedures in place to ensure that employees who may access ephi or work in locations where ephi may be present are authorized to view that ephi (i.e. they have passed the workforce clearance procedure specified in Implementation Specification 1.3.1) or, if not authorized, are supervised while working around that ephi. For example, an employer s operations and maintenance employees generally will not be authorized to view ephi but may nevertheless work in locations where ephi is present. The employer must have procedures in place to ensure those persons are supervised while working around ephi. Examples of appropriate procedures may include: instructing other employees who are authorized to access ephi to temporarily log off their computer when maintenance personnel are in their workspace; keeping passwords in a secure location where they cannot be casually observed; and/or active monitoring of the maintenance staff and requiring them to sign legally binding confidentiality agreements. Implementation Specification 1.3.3: Termination Procedures (Addressable) This specification requires formal procedures to ensure that an employee s access to ephi is terminated when the employee is terminated, moved into a new position or the employee s current position is changed such that the employee no longer requires access to ephi. This may include shutting off passwords, disabling remote access, collecting or disabling keys/key cards, etc.
7 Administrative Safeguards Standard 4: Information Access Management Implementation Specification 1.4.1: Access Authorization (Addressable) These are the mechanisms, policies, and procedures the employer has put in place to ensure that only authorized employees have access to only that ephi they need to know in order to perform their job duties. Examples may include installing software that can be used to access to ephi only on those workstations that actually require such access; limiting access rights to those network drives where ephi is stored to authorized employees; use of passwords to limit access to ephi; restricting access to transactions within a given program that contain ephi, etc. Implementation Specification 1.4.2: Access Establishment and Modification (Addressable) These are the policies and procedures that ensure that the access authorization policies in Implementation Specification are in fact working. This may include procedures to ensure that passwords are activated and deactivated as needed; revising access rights as positions and the need for access to ephi change; or processes for granting temporary access to ephi for a limited purpose, e.g. an accountant who is responsible of year-end reconciliation of transactions on a flex plan.
8 Administrative Safeguards Standard 5: Security Awareness and Training The purpose of this standard is to ensure that employees are trained and aware of security policies and procedures. The training may be included as part of other regular training, e.g. general IT security or HIPAA Privacy training. Note that this is not intended to be one-time training but ongoing as security needs and procedures change. Implementation Specification 1.5.1: Security Reminders (Addressable) This specification calls for the employer to set policies and procedures regarding the frequency and content of security reminders and updates. This may be as simple as annual security training; to quarterly s security reminders; to security warnings and reminders being displayed every time an employee logs onto their workstation. Implementation Specification 1.5.2: Protection from Malicious Software (Addressable) This specification addresses procedures to guard against, detect, and report malicious software, like viruses and worms. Presumably most employer s existing firewall and antivirus software will satisfy this specification. Training employees on how to avoid such malicious software, for example, not opening suspicious and attachments or not downloading unauthorized software from the Internet, is also part of this specification. Implementation Specification 1.5.3: Login Monitoring (Addressable) This specification addresses procedures to monitor login attempts and report any discrepancies. This may involve the IT department periodically reviewing login reports, receiving automatic notification if there is an unusual pattern of unauthorized login attempts, or training employees to report employees or others who attempt to login into systems and programs they are not authorized to access. Implementation Specification 1.5.4: Password Management (Addressable) This specification addresses policies and procedures for creating, changing, and safeguarding passwords. Examples include password rules and guidelines such as passwords must contain a combination of numbers and letters; instructions to avoid easily guessed passwords like birthdays and children s names; requiring employees to periodically change passwords; policies prohibiting employees from posting their passwords on their workstations; etc.
9 Administrative Safeguards Standard 6: Security Incident Procedures This standard requires the employer to have policies and procedures to respond to security incidents, i.e. attempted or successful unauthorized access, use, disclosure, modification, or destruction of ephi. Note that HIPAA Security guidelines take a very broad view of what constitutes a security incident ; any improper network activity should be treated as a security incident because by definition it represents an improper instance of access to or use of ephi. Many employers IT procedures already include processes for responding to security incidents, which will typically be sufficient to satisfy this standard. Implementation Specification 1.6.1: Response and Reporting (Required) This specification requires the employer to have written policies and procedures to: - Identify security incidents - Respond to suspected and known security incidents - Require reasonable efforts to mitigate the harmful effects that result from a security incident - Document those incidents and their outcomes Note that the reporting referred to in the title of this Implementation Specification is purely internal reporting in order to implement the above requirements; security incidents do not need to be reported to any government agencies.
10 Administrative Safeguards Standard 7: Contingency Plan This standard requires the employer to establish and implement policies and procedures to respond to an emergency (e.g. fire, vandalism, system failure, etc.) that damages the system that contains ephi. Many employers IT procedures will already have a contingency and disaster recovery plan for responding to emergencies, which will be sufficient to satisfy this standard. Implementation Specification 1.7.1: Applications and Data Criticality Analysis (Addressable) This specification requires the employer to evaluate which of its specific applications and data are critical to allow continued operation and security during an emergency. For example, if the employer relies heavily on anti-virus software and firewalls to protect the integrity of data, those applications will be considered more critical and require greater attention to ensure all ephi continues to be protected during an emergency. Implementation Specification 1.7.2: Data Backup Plan (Required) The employer must have a procedure to create and maintain backups that will allow the employer to retrieve exact copies of ephi that may be destroyed or damaged in the event of an emergency. Note that this will generally require not only a backup process but procedures to ensure that those backups themselves are physically secure and access is controlled to minimize security risks and ensure the data is available in the event of an emergency. Implementation Specification 1.7.3: Disaster Recovery Plan (Required) The employer must have policies and procedures to restore any lost data in the event of an emergency. The exact scope of the recovery plan will vary significantly based on the employer s size and the amount of ephi on its system. Implementation Specification 1.7.4: Emergency Mode Operation Plan (Required) The employer must have procedures in place to enable continuation of critical processes designed to protect the security of the ephi while operating during an emergency. Implementation Specification 1.7.5: Testing and Revision Procedures (Addressable) This specification requires appropriate periodic testing of your contingency plans for operating during an emergency. For example, periodic fire drills designed in part to test that ephi is secured during an emergency evacuation is a common form of testing. Other parts of the contingency plan (e.g. how the company would respond to a tornado or other severe weather affecting the computer systems) may be impossible to test.
11 Administrative Safeguards Standard 8: Evaluation (No separate Implementation Specifications.) This standard requires the employer to periodically evaluate the various components of its security procedures to ensure they are still adequate to protect the employer s ephi and document the results of that evaluation, even if no changes are made to the existing procedures. The frequency of this evaluation will vary based on changes in the security environment; for example, installation of new hardware or software will typically require the employer to re-evaluate and update its existing security safeguards.
12 Administrative Safeguards Standard 9: Business Associate Contracts The employer must obtain (or amend) business associate contracts from any business associates who create, receive, maintain or transmit any of the employer s ephi. Common business associates who have access to ephi include: third-party administrators; benefits brokers and consultants; accountants; lawyers; etc. The business associate contract must obligate the business associate to safeguard the employer s ephi by implementing the applicable requirements of the HIPAA security rules. Implementation Specification 1.9.1: Written Contract (Required) The arrangements that the employer has made to ensure that the business associate will safeguard its ephi must be documented in a written contract or other arrangement. See Appendix B for sample Business Associate Contract language.
13 Physical Safeguards II. PHYSICAL SAFEGUARDS Standard 1: Facility Access Controls This standard requires policies and procedures to limit physical access to the employer s information systems where ephi is stored. Many of your existing physical security measures will be sufficient to satisfy this standard. Implementation Specification 2.1.1: Facility Security Plan (Addressable) This specification requires appropriate policies and procedures to protect the physical security of the network from unauthorized physical access, tampering and theft. This may include locking the room that houses network servers and controlling who has the key, card, access code, or can otherwise physically access the room. Other more extreme measures, such as alarms, window locks, motion detectors, fences, guards, etc., may be appropriate for employers with significant amounts of very sensitive ephi. Implementation Specification 2.1.2: Access Control and Validation Procedures (Addressable) This specification requires the employer to ensure that only appropriate personnel have physical access to the network and systems that contain ephi. So, for example, if the employer determines that the network server room should be locked, under this specification, the employer must have processes for determining who will (and will not) be given a key to that room, as well as retrieving those keys or rekeying the lock when access is no longer appropriate, e.g. at termination of employment. Implementation Specification 2.1.3: Contingency Operations (Addressable) This specification requires the employer to have procedures that will allow appropriate members of the workforce to have physical access to facilities in order to perform the functions assigned to them under the contingency plan (see Administrative Safeguard, Standard 7.) Implementation Specification 2.1.4: Maintenance Records (Addressable) This specification requires the employer to document repairs and modifications to the physical components of a facility related to security (for example, when locks are rekeyed or a new alarm is installed).
14 Physical Safeguards Standard 2: Workstation Security (No separate Implementation Specifications.) This standard requires the employer to consider physical safeguards to prevent physical access to workstations that may contain or access ephi. For example, if ephi is stored or accessible on only certain computers in the employer s workplace, it may be appropriate to locate those computers in a locked area that only authorized employees can enter.
15 Physical Safeguards Standard 3: Workstation Use (No separate Implementation Specifications.) This standard requires the employer to consider the physical attributes of the surroundings of a specific workstation that can access ephi in order to safeguard the ephi while the workstation is in use. For example, an employer may conclude that a workstation that has access to ephi should be located in a separate, locked room; positioned in a low traffic area; or at least positioned in a place where physical barriers or the positioning of the workstation prevents easy viewing of ephi displayed on that workstation while it is in use. Note that the standard applies equally to laptops as well as fixed workstations. This may require issuing guidelines to employees who use laptops to be aware of their surroundings to minimize unauthorized persons from seeing ephi on their laptops or physical measures, like privacy screen filters, designed to restrict viewing the laptop screen.
16 Physical Safeguards Standard 4: Device and Media Controls This standard requires the employer to develop methods to track and control the movement of hardware and removable electronic media that may contain ephi. Implementation Specification 2.4.1: Disposal (Required) The employer must have policies and procedures to address the final disposition of ephi and the hardware and electronic media on which it is stored in order to ensure that ephi is removed from all devices before being disposed. In general, merely deleting files or reformatting will not be sufficient to meet this standard as data can still be recovered after such operations. In most cases, secure delete capability with byte-for-byte overwrite or physical destruction of the electronic media will be necessary. Implementation Specification 2.4.2: Media Re-Use (Required) This specification requires the removal of ephi from electronic media before such media is made available for reuse. For example, if an employer transfers a workstation that contained ephi to another employee or location that is not authorized to access ephi, the employer must ensure that ephi has been removed from that workstation before allowing unauthorized employees to access the workstation. Again, merely deleting files or reformatting will generally not be sufficient to meet this standard; secure delete capability with byte-for-byte overwrite is generally required. Implementation Specification 2.4.3: Accountability (Addressable) The employer must maintain a record of the movement of hardware and electronic media that contain ephi and the persons responsible for those devices. For example, if ephi resides on a specific workstation or laptop (as opposed to a network server), the employer must be able to track and account for the location of that laptop or workstation. The same would apply to removable hard drives and other electronic media storage devices that contain ephi. Actually tracking ephi on devices like CD-ROMs, flash memory, and data sticks will likely be extremely difficult. In some settings it may be appropriate to design systems that prevent employees from downloading ephi to such devices but, for many employers, training employees on the importance of protecting ephi stored on such devices may be the only viable option. Implementation Specification 2.4.4: Data Backup and Storage (Addressable) The employer must have a process for creating an exact backup if all ephi stored on a particular device or piece of equipment before that device or equipment is moved. The concern is that data may be lost or the integrity compromised during a physical move and the employer must be able to recover data in such an event.
17 Technical Safeguards III. TECHNICAL SAFEGUARDS Standard 1: Access Control This standard addresses specific technical policies and procedures for limiting access to ephi. Note that often these requirements will overlap with policies and procedures already put in place to satisfy the administrative and physical safeguards previously addressed. Implementation Specification 3.1.1: Unique User Identification (Required) All employees who have access to ephi must be assigned a unique username and/or number that can be used to track that employee s identity while accessing ephi. Most employers already use such unique identifiers as part of their standard computer operating procedures. Implementation Specification 3.1.2: Automatic Logoff (Addressable) This specification requires the employer to implement some sort of process to automatically terminate or lockout an electronic session after some predetermined period of inactivity. Most modern operating systems (e.g. all Windows operating systems after Windows 98) have an automatic lockout feature built into them that can be turned on and will usually be sufficient to satisfy this specification. Implementation Specification 3.1.3: Encryption and Decryption (Addressable) This specification requires the employer to implement appropriate mechanisms to encrypt and decrypt ephi based on the employer s risk analysis. There are often significant financial and technical burdens associated with encryption, which the employer may take into account when determining what level of encryption is appropriate for the ephi it has. Note that this specification deals with encryption of data at rest; a separate standard addresses encryption of data during electronic transmission (see Technical Safeguards, Standard 5.) Implementation Specification 3.1.4: Emergency Access (Required) The employer must have processes in place that will allow access to necessary ephi during an emergency. For example, if power is lost during an emergency, there must be some method of obtaining the necessary power (for example, an emergency generator or moving the necessary equipment to a location where power is available) to access ephi. The type of ephi most employers have will usually not require drastic measures beyond the measures already included in your disaster recovery policy.
18 Technical Safeguards Standard 2: Audit Control (No separate Implementation Specifications.) This standard requires the employer to have hardware, software, and/or procedural mechanisms in place that allow the employer to record and examine activity on computers and systems that store or have access to ephi. While all employers covered by the security rules must have some sort of audit process in place, the level of audit controls will vary significantly from employer to employer. For many, simply being able to determine who has logged into a system that stores ephi will be sufficient. Software designed to record the exact date and time whenever ephi is accessed may be necessary in other circumstances. If there is no other option available, a procedure requiring employees to notate a file every time they access ephi may be the only way to satisfy this standard.
19 Technical Safeguards Standard 3: Integrity This standard requires technical safeguards to protect the employer s ephi from improper alteration and destruction. Implementation Specification 3.3.1: Mechanism to Authenticate Electronic PHI (Addressable) This standard requires the employer to consider appropriate electronic or non-electronic mechanisms that will allow the employer to verify that the ephi in its system has not been altered or destroyed in an unauthorized manner. This standard encompasses a wide range of possible data integrity processes and procedures. Many software applications have some sort of data integrity testing built into them. In other cases, the employer s IT department may be able to implement processes to monitor the integrity of the data. Other more low tech, manual processes may include periodic review of the data to look for unusual or incorrect data and using the audit trail to determine how the data was changed or maintaining paper backups for comparison against electronic data.
20 Technical Safeguards Standard 4: Person or Entity Authentication (No separate Implementation Specifications.) This standard requires procedures to verify that the person or entity seeking access to ephi is who they claim they are. In most cases, this is nothing more than assigning unique usernames and passwords to employees and others who are authorized to access ephi along with policies prohibiting those persons from sharing or divulging their username and password, although there may be other options.
21 Technical Safeguards Standard 5: Transmission Security This standard requires security measures to prevent unauthorized access to ephi that is being transmitted over a network. Implementation Specification 3.5.1: Integrity Controls (Addressable) This standard is intended to address security measures to ensure that ephi is not improperly modified during transmission. Most applications that transmit data electronically have features built in designed to verify the integrity of the data being transmitted. Beyond that it is difficult to envision what other mechanisms an employer might be required to implement to meet this standard. Implementation Specification 3.5.2: Encryption (Addressable) This specification requires the employer to implement encryption of ephi whenever deemed appropriate. There are often significant financial and technical burdens associated with encryption, which the employer may take into account when determining what level of encryption is appropriate for the ephi it is transmitting. This standard does not necessarily require the employer to encrypt its s, although the government agency responsible for HIPAA security encourages that all s and other transmission of ephi over the Internet be encrypted. However, other options may be sufficient to protect ephi during transmission, e.g. when transmitting ephi via , include the ephi in a separate file attachment with password protection rather than in the body of the itself. Note that this specification specifically deals with encryption of data during electronic transmission; a separate standard addresses encryption of data at rest (see Technical Safeguard, Standard 1.)
22 Compliance HIPAA Security COMPLIANCE Checklist Appendix A Evaluating Addressable Implementation Specifications Addressable Implementation Specifications need only be implemented if the employer determines that it is reasonable and appropriate based on its risk analysis and security environment. However, the HIPAA security rules require the employer to follow a specific process if it determines that it is not going to implement a specific addressable Implementation Specification. For each such Implementation Specification, the employer should complete the following steps. Step 1. Determine if the Implementation Specification is reasonable and appropriate in the employer s security environment. In this step, the employer should consider the following questions. What is the risk that the Implementation Specification is intended to address? What is the likelihood that risk will occur? What is the harm that will result if that risk does in fact occur? What specific measures are available to the employer to protect against that risk? How effective are those measures likely to be in preventing the risk? What is the cost of implementing those measures? If the employer determines that the Implementation Specification is reasonable and appropriate, STOP and implement the specification. If the employer determines that the Implementation Specification is NOT reasonable and appropriate GO TO Step 2. Step 2. Document why the Implementation Specification is not reasonable and appropriate. GO TO Step 3. Step 3. Determine if there is a reasonable and appropriate equivalent alternative. Even if the employer determines that the Implementation Specification itself is not reasonable or appropriate, the employer must still consider if some reasonable and appropriate equivalent alternative measure exists that will minimize the risk addressed by the Implementation Specification. When considering equivalent alternatives, the employer should ask the same questions outlined in Step 1. to determine if the alternative measure is reasonable and appropriate.
23 Compliance If the employer determines that the there is a reasonable and appropriate equivalent alternative measure, STOP and implement the alternative measure. If the employer determines that there is no reasonable and appropriate equivalent alternative measure GO TO Step 4. Step 4. Document why no reasonable and appropriate equivalent alternative exists. The employer must document the reasons it has concluded that no reasonable and appropriate equivalent alternative measure exists and how the standard will be met even without an alternative measure. In order for the employer to reach this conclusion, the employer must determine that the Implementation Specification is simply not applicable to their situation and the standard can be satisfied without implementation of an alternative.
Shipman & Goodwin LLP HIPAA Security Alert July 2008 EXECUTIVE GUIDANCE HIPAA SECURITY COMPLIANCE How would your organization s senior management respond to CMS or OIG inquiries about health information
HIPAA Audit Processes Erik Hafkey Rainer Waedlich 1 Policies for all HIPAA relevant Requirements and Regulations Checklist for an internal Audit Process Documentation of the compliance as Preparation for
HIPAA Information Security Overview Security Overview HIPAA Security Regulations establish safeguards for protected health information (PHI) in electronic format. The security rules apply to PHI that is
Health Insurance Portability and Accountability Act (HIPAA) and Health Information Technology for Economic and Clinical Health Act (HITECH) Table of Contents Introduction... 1 1. Administrative Safeguards...
Appendix 4-2: Administrative, Physical, and Technical Safeguards Breach Notification Rule How Use this Assessment The following sample risk assessment provides you with a series of sample questions help
HIPAA/HITECH PRIVACY & SECURITY CHECKLIST SELF ASSESSMENT INSTRUCTIONS Thank you for taking the time to fill out the privacy & security checklist. Once completed, this checklist will help us get a better
goes to great lengths to ensure the security and availability of vcloud Air services. In this effort VMware has completed an independent third party examination of vcloud Air against applicable regulatory
HIPAA Compliance Guide Important Terms Covered Entities (CAs) The HIPAA Privacy Rule refers to three specific groups as covered entities, including health plans, healthcare clearinghouses, and health care
SAMPLE HIPAA/HITECH POLICIES AND PROCEDURES MANUAL FOR THE SECURITY OF ELECTRONIC PROTECTED HEALTH INFORMATION Please Note: 1. THIS IS NOT A ONE-SIZE-FITS-ALL OR A FILL-IN-THE BLANK COMPLIANCE PROGRAM.
HIPAA SECURITY RISK ASSESSMENT SMALL PHYSICIAN PRACTICE How to Use this Assessment The following risk assessment provides you with a series of questions to help you prioritize the development and implementation
Providers Business Name: Providers Business Address: City, State, Zip Acronyms NIST FIPS PHI EPHI BA CE EHR HHS IS National Institute of Standards and Technology Federal Information Process Standards Protected
HIPAA Security S E R I E S Security Topics 1. Security 101 for Covered Entities 2. Security Standards - Administrative Safeguards 3. Security Standards - Physical Safeguards 4. Security Standards - Technical
Introduction Per UCSC's HIPAA Security Rule Compliance Policy 1, all UCSC entities subject to the HIPAA Security Rule ( HIPAA entities ) must implement the UCSC Practices for HIPAA Security Rule Compliance
Brooklyn Community Services Policies and Compliance Guide relating to the HIPAA Security Rule June 2013 Table of Contents INTRODUCTION... 3 GUIDE TO BCS COMPLIANCE WITH THE HIPAA SECURITY REGULATION...
7 Security Standards: Implementation for the Small Provider What is the Security Series? The security series of papers provides guidance from the Centers for Medicare & Medicaid Services (CMS) on the rule
HIPAA Matrix Hardware : 164.308(a)(1) Management Process =Required, =Addressable Risk Analysis The Covered Entity (CE) can store its Risk Analysis document encrypted and offsite using EVault managed software
UNIVERSITY OF PITTSBURGH POLICY SUBJECT: SECURITY OF ELECTRONIC MEDICAL RECORDS COMPLIANCE WITH THE HEALTH INSURANCE PORTABILITY AND ACCOUNTABILITY ACT OF 1996 (HIPAA) DATE: March 18, 2005 I. SCOPE This
An Oracle White Paper December 2010 Leveraging Oracle Enterprise Single Sign-On Suite Plus to Achieve HIPAA Compliance Executive Overview... 1 Health Information Portability and Accountability Act Security
PRIVACY POLICIES AND FORMS FOR BUSINESS ASSOCIATES TABLE OF CONTENTS A. Overview of HIPAA Compliance Program B. General Policies 1. Glossary of Defined Terms Used in HIPAA Policies and Procedures 2. Privacy
Datto Compliance 101 1 Overview Overview This document provides a general overview of the Health Insurance Portability and Accounting Act (HIPAA) compliance requirements for Managed Service Providers (MSPs)
Healthcare Compliance Solutions Let Protected Trust be your Safe Harbor In the Health Information Technology for Economic and Clinical Health Act of 2009 (HITECH), the U.S. Department of Health and Human
ITS HIPAA Security Compliance Recommendations October 24, 2005 Updated May 31, 2010 http://its.uncg.edu/hipaa/security/ Table of Contents Introduction...1 Purpose of this Document...1 Important Terms...1
Health Insurance Portability and Accountability Act State HIPAA Security Policy State of Connecticut Release 2.0 November 30 th, 2004 Table of Contents Executive Summary... 1 Policy Definitions... 3 1.
HIPAA Security Rule Compliance Caryn Reiker MAXIS360 HIPAA Security Rule Compliance what is it and why you should be concerned about it Table of Contents About HIPAA... 2 Who Must Comply... 2 The HIPAA
HIPAA Security and HITECH Compliance Checklist A Compliance Self-Assessment Tool HIPAA SECURITY AND HITECH CHECKLIST The Health Insurance Portability and Accountability Act of 1996 (HIPAA) requires physicians
Privacy Compliance Healthcare Compliance Solutions Trust and privacy are essential for building meaningful human relationships. Let Protected Trust be your Safe Harbor The U.S. Department of Health and
Welcome to part 2 of the HIPAA Security Administrative Safeguards presentation. This presentation covers information access management, security awareness training, and security incident procedures. The
Krengel Technology HIPAA Policies and Documentation Purpose and Scope What is Protected Health Information (PHI) and What is Not What is PHI? What is not PHI? The List of 18 Protected Health Information
Unified Security Anywhere HIPAA COMPLIANCE ACHIEVING HIPAA COMPLIANCE WITH MASERGY PROFESSIONAL SERVICES HIPAA COMPLIANCE Achieving HIPAA Compliance with Security Professional Services The Health Insurance
HIPAA and Mental Health Privacy: What Social Workers Need to Know Presenter: Sherri Morgan, JD, MSW Associate Counsel, NASW Legal Defense Fund and Office of Ethics & Professional Review 2010 National Association
MAX Insight Whitepaper An Effective MSP Approach Towards HIPAA Compliance An independent review of HIPAA requirements, detailed recommendations and vital resources to aid in achieving compliance. Table
HIPAA Compliance Guide Important Terms Covered Entities (CAs) The HIPAA Privacy Rule refers to three specific groups as covered entities, including health plans, healthcare clearinghouses, and health care
Montclair State University HIPAA Security Policy Effective: June 25, 2015 HIPAA Security Policy and Procedures Montclair State University is a hybrid entity and has designated Healthcare Components that
HIPAA: In Plain English Material derived from a presentation by Kris K. Hughes, Esq. Posted with permission from the author. The Health Insurance Portability and Accountability Act of 1996 (HIPAA), Pub.
HIPAA/HITECH: A Guide for IT Service Providers Much like Arthur Dent in the opening scene of The Hitchhiker s Guide to the Galaxy (HHGTTG), you re experiencing the impact of new legislation that s infringing
HIPAA Compliance: Are you prepared for the new regulatory changes? Baker Tilly CARIS Innovation, Inc. April 30, 2013 Baker Tilly refers to Baker Tilly Virchow Krause, LLP, an independently owned and managed
The HIPAA Security Rule Primer A Guide For Mental Health Practitioners Distributed by NASW Printer-friendly PDF 2006 APAPO 1 Contents Click on any title below to jump to that page. 1 What is HIPAA? 3 2
1 HIPAA: Understanding The Omnibus Rule and Keeping Your Business Compliant Introduction U.S. healthcare laws intended to protect patient information (Protected Health Information or PHI) and the myriad
Technical Monograph C.T. Hellmuth & Associates, Inc. Technical Monographs usually are limited to only one subject which is treated in considerably more depth than is possible in our Executive Newsletter.
Heather L. Hughes, J.D. HIPAA Privacy Officer U.S. Legal Support, Inc. firstname.lastname@example.org www.uslegalsupport.com HIPAA Privacy Rule Sets standards for confidentiality and privacy of individually
Joseph Suchocki HIPAA Compliance 2015 Sponsored by Eagle Associates, Inc. Eagle Associates provides compliance services for over 1,200 practices nation wide. Services provided by Eagle Associates address
HIPAA Security Jeanne Smythe, UNC-CH Jack McCoy, ECU Chad Bebout, UNC-CH Doug Brown, UNC-CH What is this? Federal Regulations August 21, 1996 HIPAA Became Law October 16, 2003 Transaction Codes and Identifiers
Technical Safeguards is the third area of safeguard defined by the HIPAA Security Rule. The technical safeguards are intended to create policies and procedures to govern who has access to electronic protected
Policy Title: HIPAA Security Awareness and Training Number: TD-QMP-7011 Subject: HIPAA Security Awareness and Training Primary Department: TennDent/Quality Monitoring/Improvement Effective Date of Policy:
CHIS, Inc. and HIPAA CHIS, Inc. provides services to healthcare facilities and uses certain protected health information (PHI) in connection with performing these services. Therefore, CHIS, Inc. is classified
HIPAA Security S E R I E S Security Topics 1. Security 101 for Covered Entities 2. Security Standards - Administrative Safeguards 3. Security Standards - Physical Safeguards 4. Security Standards - Technical
AMERICAN PSYCHOLOGICAL ASSOCIATION PRACTICE ORGANIZATION Practice Working for You The HIPAA Security Rule Primer Compliance Date: April 20, 2005 Printer-friendly PDF 1 Contents Click on any title below
FINAL May 2005 Guideline on Security Systems for Safeguarding Customer Information Table of Contents 1 Introduction 1 1.1 Purpose of Guideline 1 2 Definitions 2 3 Internal Controls and Procedures 2 3.1
The second section of the HIPAA Security Rule is related to physical safeguards. Physical safeguards are physical measures, policies and procedures to protect and secure a covered entity s electronic information
Procedure Title: TennDent HIPAA Security Awareness and Training Number: TD-QMP-P-7011 Subject: Security Awareness and Training Primary Department: TennDent Effective Date of Procedure: 9/23/2011 Secondary
HIPAA SECURITY RULES FOR IT: WHAT ARE THEY? HIPAA is a huge piece of legislation. Only a small portion of it applies to IT providers in healthcare; mostly the Security Rule. The HIPAA Security Rule outlines
A Technical Template for HIPAA Security Compliance Peter J. Haigh, FHIMSS email@example.com Thomas Welch, CISSP, CPP firstname.lastname@example.org Reproduction of this material is permitted, with attribution,
Security Is Everyone s Concern: What a Practice Needs to Know About ephi Security Mert Gambito Hawaii HIE Compliance and Privacy Officer July 26, 2014 E Komo Mai! This session s presenter is Mert Gambito
Huseman Health Law Group 3733 University Blvd. West, Suite 305-A Jacksonville, Florida 32217 Telephone (904) 448-5552 Facsimile (904) 448-5653 email@example.com use e Health care law firm fighting
BEFORE THE BOARD OF COUNTY COMMISSIONERS FOR MULTNOMAH COUNTY, OREGON RESOLUTION NO. 05-050 Adopting Multnomah County HIPAA Security Policies and Directing the Appointment of Information System Security
Electronic Health Records: Data Security and Integrity of e-phi Worcester, MA Wednesday, 2:15pm 3:30pm Agenda Introduction Learning Objectives Overview of HIPAA HIPAA: Privacy and Security HIPAA: The Security
New Boundary Technologies Financial Modernization Act of 1999 (Gramm-Leach-Bliley Act) Security Guide A New Boundary Technologies GLBA Security Configuration Guide Based on NIST Special Publication 800-68
Information Security Policy Manual Latest Revision: May 16, 2012 1 Table of Contents Information Security Policy Manual... 3 Contact... 4 Enforcement... 4 Policies And Related Procedures... 5 1. ACCEPTABLE
ELECTRONIC HEALTHCARE NETWORK ACCREDITATION COMMISSION (EHNAC) Healthcare Management Service Organization Accreditation Program (MSOAP) For The HEALTHCARE INDUSTRY Version 1.0 Released: January 2011 Lee
University of Illinois at Chicago Health Sciences Colleges Information Technology Group Security Policies Summary This Summary was prepared March 2009 by Ian Huggins prior to HSC adoption of the most recent
I II Compliance Compliance I Compliance II SECTION ONE COVERED ENTITY RESPONSIBILITIES AREA ONE Notice of Privacy Practices 1 Is your full notice of privacy practices given to every new patient in your
CITY OF LINCOLN HIPAA Security Policies and Procedures Updated November 2013 Contents OVERVIEW / OBJECTIVES... 4 DEFINITIONS... 4 GENERAL POLICIES... 6 Hybrid Entity and Key Role Assignments... 6 Security
HEALTH CARE ADVISORY March 2003 FINAL HIPAA SECURITY REGULATIONS RELEASED AT LAST On February 20, 2003, the Department of Health and Human Services (HHS) published the Final Security Rule under the Health
The OCR Auditors are coming - Are you next? What to Expect and How to Prepare On June 10, 2011, the U.S. Department of Health and Human Services Office for Civil Rights ( OCR ) awarded KPMG a $9.2 million
HIPAA Compliance The Time is Now Changes on the Horizon: The Final Regulations on Privacy and Security May 7, 2013 Presenters James Clay President Employee Benefits & HR Consulting The Miller Group firstname.lastname@example.org
HIPAA Security Regulations: Documentation and Procedures The Second National HIPAA Summit Healthcare Computing Strategies, Inc. John Parmigiani Practice Director, Compliance Programs Tom Walsh, CISSP Practice
TODAY S PRESENTERS Why Lawyers? Why Now? New HIPAA regulations go into effect September 23, 2013 Expands HIPAA safeguarding and breach liabilities for business associates (BAs) Lawyer is considered a business
HIPAA Security Training Manual The final HIPAA Security Rule for Montrose Memorial Hospital went into effect in February 2005. The Security Rule includes 3 categories of compliance; Administrative Safeguards,
University of Illinois at Urbana-Champaign BADM 557 Enterprise IT Governance Guide to Vulnerability Management for Small Companies Andrew Tan Table of Contents Table of Contents... 1 Abstract... 2 1. Introduction...
HIPAA Security Education Updated May 2016 Course Objectives v This computer-based learning course covers the HIPAA, HITECH, and MSHA Privacy and Security Program which includes relevant Information Technology(IT)
New Boundary Technologies HIPAA Security Guide A New Boundary Technologies HIPAA Security Configuration Guide Based on NIST Special Publication 800-68 December 2005 1.0 Executive Summary This HIPAA Security
Information Security Policy Policy and Procedures Issue Date February 2013 Revision Date February 2014 Responsibility/ Main Point of Contact Neil Smedley Approved by/date Associated Documents Acceptable
Application Development within University Security Checklist April 2011 The Application Development using data from the University Enterprise Systems or application Development for departmental use security
HIPAA Compliance for Mobile Healthcare Peter J. Haigh, FHIMSS Verizon email@example.com Comply or Context - Privacy & Security under HIPAA Privacy is what you have already promised to do, since 4/14/2003
Hosting for Healthcare: ADDRESSING THE UNIQUE ISSUES OF HEALTH IT & ACHIEVING END-TO-END COMPLIANCE [ Hosting for Healthcare: Addressing the Unique Issues of Health IT & Achieving End-to-End Compliance
Sample Client HIPAA Assessment HIPAA Policy and Procedures Sample Client Prepared by: InhouseCIO, LLC CONFIDENTIALITY NOTE: The information contained in this report document is for the exclusive use of
Department of Defense INSTRUCTION NUMBER 8580.02 August 12, 2015 USD(P&R) SUBJECT: Security of Individually Identifiable Health Information in DoD Health Care Programs References: See Enclosure 1 1. PURPOSE.
WHITE PAPER HIPAA-Compliant Data Backup and Disaster Recovery DOCUMENT INFORMATION HIPAA-Compliant Data Backup and Disaster Recovery PRINTED March 2011 COPYRIGHT Copyright 2011 VaultLogix, LLC. All Rights