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.
Compliance We will lay out the Safeguards, Standards, and Implementation Specifications in this outline as follows: SAFEGUARD I. Standard 1 Implementation Specification 1.1.1 (Required or Addressable) Implementation Specification 1.1.2 (Required or Addressable) *** Standard 2 Implementation Specification 1.2.1 (Required or Addressable) *** SAFEGUARD II. Standard 1 Implementation Specification 2.1.1 (Required or Addressable) ETC.
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, e-mail 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.)
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.
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.
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.
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 1.4.1 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.
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 emails 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 email and email 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.
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.
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.
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.
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.
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).
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.
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.
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.
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.
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.
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.
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.
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 e-mails, although the government agency responsible for HIPAA security encourages that all e-mails 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 e-mail, include the ephi in a separate file attachment with password protection rather than in the body of the e-mail 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.)
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.
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.