Disclaimer: CMA/PrivaPlan PrivaGuide: Implementing the Security Rule.
The information provided in this document does not constitute, and is no substitute for, legal or other professional advice. Users should consult their own legal or other professional advisors for individualized guidance regarding the application of the law to their particular situations, and in connection with other compliance-related concerns.
PrivaGuide: Implementing the Security Rule
By David Ginsberg
Introduction
HIPAA requires that each covered entity implement “security standards for the protection of protected health information (PHI).”
This means that PHI must be safeguarded regardless of its form. The privacy rule (and corresponding documents in PrivaPlan) focuses on PHI in any form including paper, oral and electronic. The security rule however, focuses on electronic PHI. Electronic PHI is protected health information that is stored, maintained, accessed or transmitted in an electronic form. This can include PHI in computers, personal digital assistants, or in storage devices and media such as back up disks, tapes, CD ROMs and so forth. In many cases the security rule focuses on certain business processes like data back up and emergency mode operations (being able to continue to operate in the event of a disaster or other interruption). This relates to the core requirement that subject individuals (patients) have access to their PHI!
This PrivaGuide provides detailed instruction on implementing and maintaining security standards for the protection of PHI.
Some (there are 42 different standards or implementation specifications) of the specific tasks the security rule requires include:
- Each entity must conduct a formal risk analysis that balances the cost of security against the expected value of losses.
- Each entity must have a formal risk management process that reduces risk to an acceptable level.
- Each entity must have appropriate sanctions in place to ensure that members of the workforce or business associates follow the security policies.
- Each entity must conduct some form of information system activity review.
- Each entity must analyze its information and applications to find what is critical and what is not.
- Each entity must have a contingency plan in place.
- Each entity must ensure that physical safeguards are in place.
- Each entity must ensure that technical safeguards are in place
- Each entity must ensure that administrative safeguards are in place such as workforce security, access and authorization, incident response and reporting, training and periodic evaluations.
- Each entity must have business associates agreements in place to safeguard electronic PHI used by a business associate.
This list may seem overwhelming at first. In most cases the tasks required are standard security and business continuity measures most businesses should already have in place! Fortunately, HIPAA also provides for flexibility of approach and consideration of what may or may not be reasonable for each organization. However, HIPAA does require that each covered entity review these requirements and document their compliance plan.
This PrivaGuide is designed to walk you through the security rule and make it as simple as possible. This effort can provide you with a good foundation; if subsequently you need additional consulting or support, the effort will be streamlined because of the background work with this PrivaGuide.
How to do this:
This section documents the information necessary to review and a few of the questions to ask in the process of implementing and maintaining the necessary “security standards for the protection of electronic PHI”. “Implementation” relates to the initial tasks and “Maintenance” suggestions relate to on-going risk assessment activities. The implementation policy and procedure documentation should be based upon each organization’s specific needs and how the HIPAA security and privacy regulations apply to each.
As you go through this PrivaGuide, please refer to the Glossary at the end if you see a phrase or word that is unfamiliar. In addition, each term is linked to the glossary explanation as you proceed through this PrivaGuide.
PROCEDURE — Choosing a Security Official
HIPAA requires the identification of a security official who is responsible for the development and implementation of policies and procedures safeguarding electronic PHI. For many organizations, the security official may be the same person as the privacy official (this is especially true of small health care providers).
A complete guide to the security official is contained in the PrivaGuide: Choosing a Privacy and Security Official. Please refer to that document to complete this step.
PROCEDURE-Understand the general rules
The HIPAA security rule begins with general rules for security standards. Understanding these is the second step in your compliance effort.
The general rules outline two specific subjects, general requirements and flexibility of approach. Familiarize yourself with these rules and refer back to them frequently while working on the security rule compliance effort!
Implementation-what is required by the general rules:
- Ensure that electronic PHI:
- is kept confidential
- maintains integrity (is the data accurate and kept accurate–for example if the system “crashes” will the database be corrupted?)
- is kept available (because the privacy rule gives patients or their personal representatives the right to access their PHI it must be kept available, even in the event of a system failure or a natural disaster, and because your business continuity may require access to this information)
- Protect against reasonably anticipated threats or hazards to the security of electronic PHI. For example if your organization is located in a hurricane prone area, you should protect against the hazard of flooding or extended power outages that might make it impossible to continue business. Or, if you have Internet access it is reasonable to anticipate that your system could be hit with a virus or a worm!
- Protect against reasonably anticipated uses or disclosures that are not permitted.
- Ensure that all members of the workforce comply with these security regulations!
- Update your Policies and Procedure Manual. A sample security policy and procedure is provided under Policies and Procedures.
Implementation–Flexibility of approach
Like the privacy rule, the security rule allows for flexibility of approach and the use of reasonableness. Specifically the rule states:
- You must take into account the size, complexity and capabilities of your organization as you consider security measures
- You must take into account the technical infrastructure (do you have someone on staff is familiar with computers and technical matters?), and your hardware and software capabilities
- Costs of security measures are a legitimate factor in determining what measures to adopt
- Probability and criticality of potential risks to electronic PHI. Probability refers to the likeliness that a risk might happen. For example, if your office is located in a tornado prone area, there may be a medium to high likeliness that you could experience a power outage, or physical problem getting to the office in the event of tornado damage. Criticality refers to the importance of a particular application or business process. For example, appointment scheduling and billing are far more critical than being able to stay current with email!
Taking these into account, you can then adopt reasonable and applicable measures for your organization.
Some health care provider examples can be seen in this illustration:
INSERT TABLE HERE
Implementation: “Required” vs. “Addressable” Implementation Specifications
The security rule contains components that are either “standards” or “implementation specifications”. Implementation specifications are a subset of the standards, and are categorized as either “required” or “addressable.” If the measure is required you must implement it (taking into account the “flexibility of approach” discussed above). In other words, you have to determine a method of implementing a required specification.
If a measure is addressable, your obligations are:
- Assess if the measure is reasonable and appropriate for your organization. For example, an alarm system and a security guard may be reasonable to protect against unauthorized access and theft in a hospital, but not reasonable or appropriate for a small practice. Or a solo practice might find that different “role” passwords for different job functions and computer programs are not reasonable if the few staff members present do every job!
- Once you have determined the measure is reasonable and appropriate, implement it.
- If your assessment determines the measure is not reasonable and appropriate, document why and describe an equivalent alternative measure that accomplishes the same end. Using the above example a solo practice might find that different role based passwords are not reasonable; however, it does use basic user log on passwords and a password for the practice management software that is different and secret for each staff member. This could be an equivalent alternative.
- If you determine that there is no need to implement an addressable measure (neither the measure nor the alternatives are “reasonable or appropriate”), you must document why this is so and how your practice will nonetheless meet the basic security requirement at issue
Remember, you must document that you considered each addressable measure or standard and your determination as described above.
Just as you will find in the regulation, we have also indicated when the rule specifies if a criterion is required or addressable by including “required” or “addressable” at each step. When a criterion is not listed as required or addressable it generally represents a “standard” from the security rule. In those cases assume that the standard is required.
PROCEDURE-Administrative Safeguards
HIPAA requires a security management process. This relates to administrative and management policies and procedures that prevent, detect, contain, and correct security violations.
Security Risk Management Process
Implementation: Risk analysis (Required) [This is part of “Security Management Process]
This may be the most important step in your security compliance effort! The risk analysis is an accurate and thorough assessment of the potential risks and vulnerabilities to electronic PHI—including the risks to the availability (for example during a disaster), the integrity and confidentiality.
We have created a Risk Analysis Tutorial to assist you with a good overview of how to complete a risk analysis. Please review this document, which is under the Training section.
Because this step is so important, we have created a PrivaGuide of its own. Please go to the PrivaGuide: Risk Analysis to complete this step.
Note: It is essential that every organization complete their risk analysis. This will provide you with the foundation necessary to implement appropriate safeguards and measures. It may also save you significant cost since you can make purchasing and resource decisions that are appropriate to your situation!
Implementation: Risk management (Required)
Once you have completed your risk analysis, you must implement security measures “sufficient” to reduce the risks and vulnerabilities you identified in the analysis. The risk analysis PrivaGuide and the corresponding Risk Analysis Tracking form will provide some instruction on the measures. In addition, completing the remaining implementation and maintenance steps of this PrivaGuide will give additional instruction.
Implementation: Sanction policy (Required)
The rule requires that you apply sanctions against workforce members who fail to comply with the security policies and procedures.
- Review Stat # 5 which discusses workforce issues.
- Review the Workforce Training PrivaGuide. Ensure that all staff and workforce are trained and understand the security policies and procedures. Some organizations use a separate computer use policy (these may include computer use, laptop computer use, email and Internet use) form that alerts employees to your specific policies. We have included sample templates in the Document Template folder.
- Review your existing sanctions for HIPAA privacy violations in your Privacy Policy and Procedure Manual. These may need to be updated to include security violations. Be sure the sanction is appropriate to the violation and would demonstrate that you are serious about correcting any violation. For example, many offices implement progressive discipline, which can range from a warning for a minor violation, to as serious as immediate termination should it be appropriate. If you do not currently have sanctions in place for privacy violations immediately develop these and educate all workforce on their existence! At the same time, add security violation to the sanction list.
- Ensure that your employee manual or other documentation is updated to include sanctions.
- If you are unsure of how to impose sanctions or their legality, seek guidance from legal counsel. If you maintain a human resources department they will have specific guidance on this matter; if you maintain an employee practices insurance policy seek guidance from your carrier. Definitely consider seeking guidance from your professional liability carrier as well.
- Update your policies and procedures to document the sanctions. These are located under the Policies and Procedures section.
Maintenance: Keep sanctions up to date
If you change your sanction policies or specific sanctions, be sure to revise your written policies and update the employee manual.
Implementation: Information system activity review (Required)
This refers to a regular review of information so you can determine if there are new threats or problems. Types of information that can help you include:
- Access reports that indicate who logged into the system and the time of day. This could be looked at periodically to identify a suspicious log in-for example someone logging in at 3 am might raise concern.
- Access or audit reports that indicate log in attempts with incorrect passwords. This could indicate if a terminated employee was trying to gain access.
- Firewall reports. If you have a software or hardware firewall in place it may provides reports indicating who tried to (or succeeded in) accessing your system.
- Incident reports. These are described later as a separate task. Incident reports define specific suspected or actual security problems. They should be reviewed and acted on promptly.
- Update your Policies and Procedure Manual to include procedures for obtaining these reports. Sample security policy and procedures are provided in the Policies and Procedures section.
Isolating clearinghouse functions.
The access management measure has a specific required step if a health care clearinghouse is part of a larger organization. In this case, the clearinghouse must have policies and procedures to keep the larger organization from accessing the clearinghouse’s electronic PHI. Generally this applies to health plans and institutional providers. However, some large provider practices maintain an “MSO” and a billing service. The billing service might be a clearinghouse. If this is the case check with your legal counsel to determine if this measure applies. A sample procedure for this is included in the Procedure manual.
Implementation: Workforce security (Addressable)
As an administrative and management process, you must implement policies and procedures to ensure that all workforce have appropriate access to electronic PHI and to prevent those who don’t have access from obtaining access.
Note: Remember these are addressable measures. This means you must assess these measures and determine if they are reasonable and appropriate for your organization–if so, they must be implemented. If not, determine an equivalent measure and implement that or document that no workforce security measure is reasonable or necessary for your organization to effectively manage its workforce security process. In all cases, your process must be documented!
The following addressable measures should be reviewed and assessed.
- Authorization and/or supervision. Be sure that you have procedures in place that authorize or supervise workforce members who access electronic PHI. In a small practice with few staff there may be no effective way to supervise especially if everyone has access. But in a larger organization you may determine that certain individuals work under direct supervision and are authorized only to do certain computer functions. Remember your Job Responsibilities with Respect to PHI form? This form can be used to document the authorization for each staff member in your office. Some organizations use a form to request access for new staff or to change existing access.
- Clearance procedures. To determine if access by a staff member is appropriate, you may want to do a background check or some other kind of clearance like reference checks upon hiring. Determine the most appropriate clearance procedure for your organization and document this in the Procedure Manual.
- Termination procedures. It is very important to terminate a workforce member’s access rights when they are no longer employed. This is an area that many organizations delay or overlook. Termination procedures should include removal of physical access (for example return of facility keys, changing alarm codes and so forth) as well as revocation of technical access. For example, disabling a network user ID, network passwords, passwords to software applications, disabling or forwarding email accounts and so forth. If the employee held a high level position you may need to change admin level access and password codes! Make sure this is documented in your Procedure Manual.
Remember, workforce refers to those individuals under your control. It can also include locum tenens, temporary staff, part time staff, and even some independent contractors who perform their services in your office.
Maintenance: keep up to date
If you implement these measures, be sure that they are kept up to date with new employees and changes in employee status. The Job Responsibilities with Respect to PHI is an excellent form to track authorization and changes.
California covered entities should remember SB1386!
Senate Bill 1386 went into effect July 1, 2003. It requires notification of law enforcement as well as, in some circumstances, patients (customers) if there was a breach of data systems and you determine that ePHI in an unencrypted form likely was accessed by an unauthorized person and the ePHI contained information that could be used for identity theft (that is, name and social security number,California driver’s license or identification card or information which would permit access to an individual’s financial account).
If this is the case, there are specific steps to take to comply with California law! Be sure you update your procedure manual! We have included a copy of the bill in the HIPAA Reference Material folder.
Implementation: Access management (addressable)
Access management deals with the policies and procedures for authorizing access to electronic PHI.
- Access authorization. These are policies and procedures for granting access to a specific computer or workstation (user or log on names and passwords) or specific programs and functions. Completing the risk analysis will help you understand if you need to have this level of control in place. For example, a mid-sized practice with an appointment scheduling software and a practice management/billing software might want to restrict the receptionist/scheduler to only the appointment system.
- Access establishment and modification. These are procedures to keep the access authorization up to date. In the example above, if the receptionist was asked to collect co-payments and outstanding balances, you might want to grant them access to the billing system.
- Update your Policies and Procedure Manual to include any of the access management procedures you choose to use. A sample security policy and procedure is provided under Policies and Procedures.
Implementation: Security awareness and training
As with the privacy rule, awareness and training are an important measure; HIPAA is specific that management must be included in the training and awareness process. This means physicians and providers (or other senior management/owners) should always be included!
- Complete the tasks defined in Stat # 10 and the Workforce Training PrivaGuide.
- Determine if security reminders are reasonable and appropriate (this is an addressable measure.) This is an addressable measure. Periodic updates can be done in regular staff meetings, by in-office memorandum, or any other method practical.
- Consider procedures to protect against “malicious” software (this is an addressable measure.) Examples of malicious software are viruses and worms. Your procedures should include protection, detection, and reporting. This can usually be done with anti-virus software that protects your data, notifies you of an infected file, and creates reports. This is an addressable measure; however, even small organizations can find an inexpensive and easy to use software solution. Even occasional dial up connections are “vulnerable and should be protected.” Remember malicious software also includes spyware!
- Log in monitoring (this is an addressable measure.) This measure is designed to alert you to suspicious log in attempts and discrepancies–perhaps during off hours. Depending on your organization and the risk analysis you completed, you may want to implement these procedures. Some operating systems like Microsoft Windows 2000 or XP have options that can create an audit report. You can use the tutorial or help feature of the operating system to implement these, or consult your IT vendor or consultant. Hardware and software firewalls may also have the ability to provide a log or alert.
- Password management (this is an addressable measure.) This is another addressable measure that almost everyone should implement. Password management includes procedures for creating, changing and safeguarding passwords. Examples of these procedures might include an office policy that passwords are never shared or kept in an accessible place and that they are changed every 60 days and immediately deleted when a workforce member is terminated. Each password should be “complex,” with at least six characters including letters and numbers. Many organizations have policies in place that restrict password composition—for example they can’t include parts of social security numbers or dates of birth. Policies may also restrict how passwords are changed—to ensure they don’t contain excerpts of existing passwords!
Maintenance suggestion: stay up to date!
Awareness is an ongoing task. Stay up to date with regular workforce communication and alerts, as well as conducting steps 1-5 above. Be sure that your systems support password management (for example you can configure some operating systems or application software to require frequent password changes).
Implementation: Security incident procedures (required)
Policies and procedures are needed to address security incidents. This includes documentation of the incident and your follow-up actions. The security incident process is similar to the complaint process for the privacy rule. For additional reference review the Complaint PrivaGuide as well as the sample complaint forms.
- Customize the Security Incident form
- Train members of your workforce to complete the incident form whenever a suspected or actual security incident has occurred. Be sure to provide examples of security incidents to help staff understand what a security incident is. Also be sure to that members of the workforce understand the procedure for reporting and communicating an incident (as well as providing sufficient copies of the form).
- Review the risk analysis you completed, the risk analysis tracking form, the electronic PHI inventory, and evaluate the possible ways you could correct any incident.
- Whenever an incident is reported, promptly investigate the incident and, if a violation has occurred, immediately correct the breach and implement procedures to minimize a future incident.
Sample security incidents:
- Office manager/security official is on vacation and the daily back up was not done.
- Back up tapes are left in the car and damaged by heat.
- A recently fired employee tries to log into the computer late at night.
- An employee brings a music CD they “burned” at home and loads it onto their desktop.
- An employee fails to heed the update notice on their workstation and never installs the updates.
- An employee opens an email attachment that has a virus in it which infects the system.
- The computer system seems to take longer to start up or other processes run slower (can be a sign of spyware or other malicious software.)
- The front desk receptionist shares her password with a temporary agency worker who is filling in.
- A power outage occurs and the system reports the database has been corrupted.
- A laptop is stolen.
- The office security alarm is not armed by the last person leaving.
Implementation: Contingency plan HIPAA requires policies and procedures for responding to an emergency or situation that damages systems containing electronic PHI (or interrupts the ability to access electronic PHI).
- Data back up plan (Required). Each organization must establish procedures to create and maintain data back ups (“retrievable exact copies of electronic PHI”). Work with your applications software vendors (for example, your practice management vendor) to implement this. Most likely their software has a back up utility. Using your risk analysis, define the other software programs you operate and develop a back up program for them as well. This could include email, electronic medical records, appointment scheduling, accounting software, and even your correspondence files. In some cases you may need to involve your computer hardware or network vendor who can assist you with obtaining and using the appropriate back up devices. Back up plans are only good if the back up data is kept safe—usually off site. Incorporate procedures to rotate back up media, take it offsite, and routinely verify that the media does indeed contain the data. Depending on the risk analysis, you can also consider off site storage of back up data either by a company that collects and stores the back up devices or by back up to a remote computer using a data vault service.
- Disaster recovery plan (Required). Implement procedures for restoring any loss of data. For example, document how the back up tape would be retrieved (if the most recent tape is kept offsite with an employee) and restored into the system. Occasionally practice restoring a tape or data file to be sure you understand the process.
- Emergency mode operations (Required). Determine which software must be kept operational in the event of a disaster or other event that would interrupt operations. Use the risk analysis you completed earlier to define these “critical” applications. Typically this would apply to applications where you maintain and update electronic PHI-for example billing software, appointment scheduling and electronic medical records. Accounting (bookkeeping) software might be less critical. Once you have identified the critical applications, work with your vendor to determine how you can restore operations during an emergency. For example, you might plan on maintaining a version of your practice management software on a home computer (be sure that you purchase the appropriate licenses for additional uses, if necessary), or you may be able to use a location provided by your vendor.
- Testing and revision procedures (addressable). This is an addressable measure to periodically test the contingency plan and revise it if necessary–the equivalent of a fire drill. Determine if this is reasonable and appropriate for your organization.
- Application and data criticality analysis (addressable). This is an addressable measure to identify which applications (programs) are needed in support of your contingency plan. For example, if you determine that the electronic medical record is a highly critical application, you will also need to determine how the back up data is available during emergency mode operations. Refer to the risk analysis completed earlier.
- Update your Policies and Procedure Manual. A sample security policy and procedure is provided under Policies and Procedures.
Implementation: Evaluation. Perform periodic evaluations of all administrative, physical and technical security rule (both technical and non-technical) measures in place. The purpose of this evaluation is to periodically “test” the effectiveness of your measures and safeguards and whether or not your organization follows the policies and procedures you have established. Since changes often occur, this kind of audit or evaluation is relevant. For example you may have added new hardware or software, modified your facility security or done renovations, changed staff and access and so forth.
There are many ways to conduct a periodic evaluation. Some organizations may choose to hire an outside consultant or service for this purpose. You can also use PrivaPlan as a way to accomplish this:
- Remain attentive to changes in your environment that might affect security measures. When these occur use this as a basis to review your measures.
- Redo the risk analysis as part of your evaluation. If there are changes in your ePHI or risks. This will be evident in the risk analysis.
- Review the Audit PrivaGuide for guidance on routine audits and follow the steps suggested.
- Review each policy and procedure. Interview staff and review documentation and systems in place to be sure you are following these procedures.
Implementation-Business associates
Business associate agreements are necessary with any outside firm or entity that uses electronic PHI to perform a service on your behalf. If you have completed PrivaPlan already for the privacy rule, you should have business associate agreements in place. Please refer to Stat # 9 as well as the Business Associate PrivaGuide. Please be sure to utilize the most current version of the Business Associate Agreement template that contains language for the security rule.
Maintenance suggestion:
Periodically review all possible business associates and ensure that a valid Business Agreement is in place. Existing business associates who have not signed an agreement containing the security rule language should be asked to sign an addendum (a sample template can be found in the Document Template folder).
Examples of when emergency mode operations may be needed.
An emergency mode can result from different events:
Hazards–Natural (like earthquakes or storms) and man made (arson or power failures) events that either destroy your facility, or the electronic PHI, or restrict your access to your operations.
Deliberate and malicious acts–For example a virus infects your system and you must erase all data files and restore. Or a theft removes computers or vandalizes them.
Unintentional actions–A critical process is interrupted by a staff member and the data base is corrupted and must be rebuilt.
PROCEDURE—Physical Safeguards
Both the privacy and security rule require physical safeguards. Specifically, the security rule requires policies and procedures to limit physical access to information systems (computers) and the facility in which they are housed. In addition, the physical safeguards must ensure that only properly authorized access is allowed.
Implementation: Review the Physical Security PrivaGuide.
Review the Physical Security for Small Organizations PrivaGuide and ensure that all steps are completed. If your organization is mid-sized or larger review the Physical Security for Large Organizations PrivaGuide as well.
Facility Access Controls. Access controls ensure that only those persons with proper authorization have access to the physical site or facility that houses electronic PHI. These controls are policies and procedures that are followed to achieve this.
Implementation: Contingency operations (Addressable)
- Review the contingency plan developed earlier. Determine how you can gain access to your facility to support the disaster recovery plan or the emergency mode operations plan. For example, if you cannot physically get to the office (i.e. a severe flood has stopped all transportation) but power and communications are still available, perhaps you can remotely access your computer systems.
- If you have identified an alternate site for emergency mode operations, determine how you will access those facilities. For example, if you decide to use the physician’s home computer as an emergency mode system do you have a procedure in place to gain access?
- Determine if these measures are reasonable and appropriate: if so implement, if not document an equivalent alternative.
- Document these in your policies and procedures.
Implementation: Facility security plan (Addressable)
This step is covered in detail in the Physical Security for Small Organizations PrivaGuide. Ensure you have policies and procedures to safeguard your facility and the computer equipment from theft, unauthorized access or tampering.
- Determine if you need better security systems–for example, an alarm system or a swipe card system that documents the individual entering the office, the time and can be programmed to restrict access to certain areas.
- Determine if specific areas need additional access controls (for example a secondary door lock or key pad to enter the server room).
- Using your risk analysis determine if there are other entrances that pose a vulnerability-for example employee entrances that are left open during the day.
- Determine if these measures are reasonable and appropriate; if so implement, if not document an equivalent alternative.
- Document these in your policies and procedures.
Note: Remember that electronic PHI can be stored on devices you may not consider a computer. For example, a clinical laboratory device, an ultrasound, or EKG often stores patient identity information along with the test results!
Implementation: Access control and validation (Addressable)
This step is also covered in the Physical Security PrivaGuide. Be sure you have:
- Reviewed how you allow access and validate access. Be sure to review the risk analysis done earlier.
- Consider access control such as a visitor log and sign in sheet.
- Consider how your staff verifies the identity of visitors–checking badge numbers, looking at company employment cards, and so forth.
- Determine if you need to limit access to your own workforce. For example this is not reasonable and appropriate in a small health care practice, but certainly reasonable in a hospital (i.e. nursing staff should not have access to the computer room).
- Determine if you need better identification for your own staff. Larger organizations may benefit from picture ID badges since even members of your own workforce may not recognize new employees and be able to distinguish them from visitors or unauthorized persons.
- Ensure that software vendors and consultants have appropriate access for the testing and revision of software.
- Determine if these measures are reasonable and appropriate; if so implement, if not document an equivalent alternative.
- Document these in your policies and procedures.
Implementation: Maintenance records (Addressable)
Implement policies and procedures to document repairs and modifications to the office related to its security. For example, repairs to the doors or locks.
- Review how you supervise these kinds of repairs. Do you use bonded and licensed contractors? Be sure to review the risk analysis done earlier.
- Consider access control such as a visitor log and sign in sheet.
- Identify the kind of repairs that could affect the physical security of the office.
- Determine how you would supervise and document such repairs.
- Determine if these measures are reasonable and appropriate; if so implement, if not document an equivalent alternative.
- Document these in your policies and procedures.
Implementation: Workstation use and security
Your terminal or desktop computer must be secure, even from visitors, patients, or other unauthorized people who could see electronic PHI by looking over your shoulder or who might actually gain physical access to the machine! We now have specific policies and procedures for Computer and Internet Use, and for Laptops, Portable Devices, and Remote Use in the Policies and Procedures section.
- Determine the physical location and orientation of workstations. Are they exposed so that visitors can easily see information?
- Determine if the workstations are accessed only by staff or sometimes by visitors (for example repair people or cleaning services who may be nearby.
- Determine the safeguards needed to restrict this access–such as automatic log off and screen savers.
- Determine if certain devices are vulnerable to easy removal–such as laptops or personal digital assistants.
- Implement appropriate procedures (such as desktop locks that secure a laptop) to protect the workstations.
- Document these in your policies and procedures.
Implementation: Device and Media controls
The security rule requires policies and procedures governing the receipt and removal of hardware and media (storage media like CD ROMs and diskettes) that contain electronic PHI. These policies and procedures must cover movement in and out of your office as well as within the office.
- Procedures for receiving hardware. Be sure that hardware is not installed without reviewing its security first–for example, a physician may want to plug his laptop into the office network. Be certain the laptop or its files are not infected with a virus. This is a required measure.
- Disposal (Required.) Whenever hardware or back up media is disposed, it must be free of electronic PHI! Have procedures to ensure this such as using software that “cleans” or formats a disk drive on a computer you are discarding, or software that reformats a back up tape. This is a required measure. Remember, that the “delete” function on most computers does not actually delete the data or contents–it simply frees up that disk space for re-use. Only reformatting or specific “wipe clean” software reliably deletes data! Specifically be sure that whenever you recycle or donate hardware all ePHI is deleted. This even applies to service and repair when a disk drive is replaced!
- If you plan on re-using media (for example a CD-RW (read write) ROM), have procedures that ensure any electronic PHI is removed before it is re-used. This is a required measure.
- Accountability (Addressable.) This measure entails maintaining a written log or record whenever hardware or media is received or removed. The log would also include the person who is responsible for the movement. This applies to any movement–not just disposal. For example, installing new workstations or moving computers from one office to another. This is an addressable measure. Determine if it is reasonable and appropriate and if so, implement. If not document an equivalent alternative.
- Data backup and storage (Addressable.) This is an addressable measure in support of item 4–if needed, you should back up all data before moving computer equipment (in the event the equipment is damaged during the move.)
PROCEDURE—Technical safeguards
The security rule requires technical policies and procedures to safeguard electronic PHI. These technical safeguards include access controls, audit controls, integrity controls, person authentication and transmission security measures for electronic information systems to maintain electronic PHI that allow access only to those persons (or even other software programs) that have been granted rights to the PHI. Access Controls regulate how access to electronic PHI is controlled and limited.
What is the difference between administrative, physical and technical safeguards?
Administrative safeguards are administrative actions, policies and procedures related to security measures—including the conduct of the workforce. These are described in Stat # 5.
Physical safeguards are physical measures, policies and procedures to protect electronic information systems (computers) and related buildings and equipment from natural and environmental hazards and unauthorized intrusion. These are described in Stat # 3 and the PrivaGuide on Physical Security for Small Organizations.
Technical safeguards are the technological measures and policies and procedures that protect electronic PHI and control access to it (such as passwords and user ID’s). These are described in Stat # 4 and this PrivaGuide.
Implementation: Access controls. These are technical policies and procedures to ensure access only to those persons or programs that have been granted or authorized this access. Technical policies and procedures can include the use of technology such as tokens or digital certificates.
Implementation: Unique user identification (Required)
- This task is straightforward. Assign a unique name or number to identify and track users. This can be done with a user log on ID as well as passwords for specific programs. If other software programs automatically access your computer they should also have a specific identifier when the log on (for example a remote program that accesses your computer system to automatically back up data or periodically review security).
- Use the risk analysis completed earlier to determine the kind of user identification needed.
- Keep a log of these assignments either electronically or on paper so that you can keep track of access codes. Sometimes the particular system you are working with will automatically keepthis log and provide access to a person with appropriate access level.
- Document your policies and procedures in your policies and Procedure Manual.
Implementation: Emergency access procedure (Required)
- Determine how you will obtain the necessary electronic PHI during an emergency. For example, how the most recent back up data can be located.
- Determine who maintains an up to date list of passwords and log in codes and how these can be made available during an emergency. For example, if a system crash occurs while the administrator or IT supervisor is on vacation will another person be able to access the system or assist the repair personnel?
- Document your procedure in your Procedure Manual.
Implementation: Automatic logoff (Addressable)
- This is an addressable measure. Determine if it is reasonable and appropriate to have an automatic logoff for “sessions” (that is each user’s log on session) after a predetermined amount of time with no activity. Use the risk analysis to determine if this is reasonable and appropriate. This can readily be accomplished with most operating systems. Remember an automatic logoff is not a screen saver! Screen savers generally bring the display back up with the tapping of any key. A logoff on the other hand requires the user to log in again with user ID and password (preferably).
- Document any procedure that you determine is appropriate in the Procedure Manual; and the Computer and Internet Use Policy document.
Implementation: Encryption and decryption (Addressable)
- Encryption is a way of scrambling electronic data so it cannot be read without the appropriate “key” or decryption tools. Most of the data on our computers resides in files that are easy to read and open with very basic software. Using the risk analysis, determine if you need to encrypt electronic PHI. Some measures are very simple, such as using Windows NT, 2000 or XP NTFS (a way to encrypt the entire disk, or certain files and folders). It is important that you determine if encryption is needed for data at rest as well as back up devices. Back up tapes or disks are vulnerable if the data they contained can be easily read! If you email PHI you may also want to encrypt the email. This is covered under “transmission security” below.
- Document any procedure that you determine is appropriate in the Procedure Manual, see the Computer and Internet Use Policy document.
HIPAA states that encryption of email is an “addressable” requirement.
This means you must evaluate the risks associated with emailing PHI for your organization and consider appropriate protection or safeguards. HIPAA does not require encryption, but ultimately this provides the safest protection. Consider encryption and safeguards if email is used for any of the HIPAA covered transactions or for other open Internet transmissions of PHI. For example, if you communicate PHI by email in connection with claims or authorizations for treatment, you must decide whether to comply with this requirement or use an alternative means. You can use the encryption capability of Microsoft Outlook for email encryption. You may also need to look into other encryption software to accomplish the task. Dialup lines are slightly less vulnerable than high speed access (DSL, cable or T-1 lines) and the risk is lower that the transmission will be intercepted since the line is “open” only at certain times.
Implementation: Audit controls
- These are controls that record and allow you to examine computer and information system activity. Use the risk analysis to determine what systems should be recorded and how this should be done. You can use hardware, software, or even written procedures to accomplish this.
- The easiest method is to use software that records user activity, by time and software function. Again, using the risk analysis determine if this is appropriate for your organization. Most application programs that create, store, maintain or transmit PHI (for example billing software or electronic records software) have built in audit logs (this should be a consideration when you purchase such software). Audit controls often require the expertise of an information system expert–your network administrator, vendor, or consultant can help with this. If you use a Windows based system you may be able to enable its audit tools yourself (Windows Event viewer). Use the help feature of the on line manual to determine if this is possible.
- Be sure to document any procedure that you determine is appropriate in the Procedure Manual.
Implementation: Integrity and authentication
- Implement policies and procedures to protect electronic PHI from improper alteration or destruction. To some degree, you should already have covered this with the administrative and physical safeguards discussed earlier. This is a technical measure. For example, you may define certain files as “read only” to protect them from alteration.
- Use the risk analysis to help you determine which electronic PHI should have integrity controls. Then, work with your vendor to identify the best way to implement these. Often the software system has the ability to define read/write/delete privileges by user.
- Determine if you need additional software protection. For example maintaining up to date antivirus software and periodically running system scans (that look for corrupted files, the presence of spyware or viruses etc.).
- The vendor can also help you implement mechanisms to corroborate that electronic PHI has not been altered or destroyed in an unauthorized manner. This is an addressable measure.
- Document any procedure that you determine is appropriate in the Procedure Manual.
Implementation: Person or entity authentication
- This relates to electronic measures to verify that a person or entity seeking access to electronic PHI is the one claimed. Using the risk analysis, determine if this is applicable. (For example if your system only has a dial up line and you occasionally transmit claims just to a clearing house you may be able to document that authentication controls are accomplished because there are only a few people with access to the system and PHI is sent only to the Clearinghouse.). Consider solutions such as a digital certificate (CMA/PrivaPlan users should consider obtaining a MEDePass from CMA. www.medepass.com). A digital certificate can authenticate the user as the person who they claim to be!
- Implement appropriate authentication. Authentication may also include smart cards (newer technology can use the same swipe card used to gain physical access as a way to authenticate and access the computer) or tokens that verifies the user is who they clam to be. It can also include new biometric technology such as fingerprint mouse controls that verify the identity prior to allowing access.
- Document any procedure that you determine is appropriate in the Procedure Manual.
Implementation: Transmission security
- Electronic PHI being transmitted over the Internet or other electronic networks is particularly vulnerable. Your risk analysis will have identified the functions and programs used where this is a risk.
- Determine if you use email to send PHI. We strongly caution against using email to send PHI unless you have appropriate encryption. You may need to encrypt both the files you send as attachments as well as the email message itself. An excellent tool is the California Medical Association’s MedePass which is a digital certificate. It allows for an electronic signature as well as a secure way to send email. It is designed for physician use however there are other systems available for non physicians.
- Technical measures to guard against unauthorized access during transmission include encryption or the use of a secure Internet connection.
- Your vendor can provide advice or assistance. Also, ensure that the claims clearing house you transmit to provide a secure transmission method. If you transmit directly to individual payers, ensure that they provide such secure methods as well. Again, CMA’s MedePass can provide excellent security of transmissions between your office and other entities!
Implementation: Integrity controls may be necessary. This is an addressable measure to ensure that the transmitted electronic PHI is not improperly modified without detection. For example, some clearing houses or payers will indicate that the file transmitted was received intact and without change.
Implementation: Encryption. This is another addressable measure. If reasonable and appropriate, encrypt electronic PHI that is transmitted. Use the risk analysis to determine the kind of PHI this is applicable to. For example you might determine that claims data be encrypted whereas email requests for an appointment don’t need to be encrypted. See above for guidance on using email.
GLOSSARY
Administrative Security – The typically manual activities and management constraints, operational procedures, accountability procedures, and other supplemental controls established to provide protect sensitive information. With particular regard to HIPAA, protected health information.
Archive – A copy of a file made to create more space on the primary computer storage devices. The copy is typically saved on a diskette, CD, tape or other type of information storage media.
Audit Log – A set of records that collectively provides documentary evidence of system resources accessed by specific users, groups, processes or other components of a network. The audit logs helps people to trace original transactions forward and backward to see who was involved with accessing a particular information file, or was involved with a specific computer transaction. Audit logs can also be created manually; for example, a log of everyone who has signed into a clinic, or a log of everyone who has looked at a particular patient file folder. These audit logs will help to enable the reconstruction, review and examination of each activity and event involved with a specific transaction or piece of information.
Audit Trail – The same as an audit log; see the definition of ‘audit log’.
Authentication – The act of identifying or verifying the identity or eligibility of a person, workstation, or other type of entity to access specific types of information, such as protected health information.
Computer Viruses – Computer code that can reproduce itself and spread, attaching to various types of other computer files, without the consent, and often knowledge, of the people sending or receiving the files. Viruses are often hostile code that can possible modify or destroy other computer files, or even result in making the computer unusable. Vendors of anti-virus (AV) software have identified approximately 50,000 known viruses.
Contingency Plan – Planning ahead with great detail for how to respond to the sudden loss, unavailability or other types of computer systems or information malfunctions, to quickly return the system or information back to a secure, functioning and operational state. These are plans for emergency response, backup operations, and post-disaster recovery maintained by organizations with computer information processing capabilities as a part of their security programs.
Data Criticality Analysis – Reviewing and analyzing your information to determine the confidentiality and priority of each piece of information. Data criticality analyses often determine criticality and/or classification by prioritizing the information based upon five security requirements: confidentiality of the information, the integrity importance of the information, the necessary availability of the information, the need for some type of non-repudiation (the ability to prevent the denial that a transaction occurred), and the importance of time with regard to information and associated transactions.
De-identified – Health information that has had key pieces of information removed so that it does not identify a specific individual, and for which there is no reasonable basis to believe that the information can be used to identify an individual. In effect, de-identifying information makes it anonymous information.
Denial of Service Attacks – Attacks to a computer network that result in making the network unusable for brief, or extended, period of time. For instance, sending large numbers of email at the same time to one email account, or one email server, may flood the computer network with so much email traffic that it results in bringing down the network. There are many ways in which denial of service attacks may be launched.
Encrypt – Scrambling information, through the computerized use of mathematical algorithms, to make it unreadable by anyone who does not know how to decrypt the information.
File Integrity – When information can be assured that it has not been changed or destroyed in any type of unauthorized manner.
Hackers – Persons who break into computer systems for which they are not authorized to use. Some hackers break into systems for a challenge, and other break in to get access to confidential information that they can then use for their own, often monetary, purposes. Such types of information targeted often include credit card numbers, social security numbers, and if specific people are targeted, there have been instances when medical records have been obtained.
Hot Site – These are locations with computer equipment that are located geographically away from the business computer facilities. Hot sites are fully equipped, ready-to-run computer centers that are used when an authorized person declares that a computer disaster has occurred.
Information Access Controls – The process of allowing only authorized users, programs, or other computer systems (for example, networks, specific computer workstations, and so on) to access the information resources of a computer system.
Intranet – An intranet is a private network of multiple computer desktop workstations, fileservers, applications servers, and other components, that is connected to the Internet at a single point, or just a very few points. The whole intranet looks to anyone on the Internet as a single Internet participant. It requires only a single, or a few, IP addresses at the Internet side, while internally it can provide all Internet services to all the people and other resources that use the network.
Network – A collection of a few to many computer systems and peripherals that are integrated and communicate with each other.
Open Network – A computer environment in which systems and network access is not controlled by the people who own the electronic files, or who put the electronic files on the network. An example of an open network would be one on which multiple businesses and/or corporations are connected and use to share information between organizations.
Personal Digital Assistants (PDAs) – Handheld computing devices that typically fit in the palm of a person’s hand and are noticeably smaller than laptop computers. PDA users can also often use PDAs to talk to others (as a cell phone), or send email or photos to others through the Internet or connect to a wireless network. PDAs are becoming very popular and pose very significant security threats to protected health information because of the ease with which wireless transmissions can be intercepted, and because the high incidence of PDA losses.
Physical Security – Protection of physical computer systems and hard copy information (such as paper files) and related buildings, facilities and equipment from fire and other natural and environmental hazards, as well as from intrusion. Physical security also covers the use of locks, keys, and administrative measures used to control access to computer systems and facilities.
Public Networks – Networks that are used by multiple entities and organizations. The Internet is the most widely known public network. However, other public networks include the public telephone network, frame relay connections, dial-up subscription services, the cable system, and many unsecured wireless networks. Sending information through public networks is a very risky activity. There are numerous opportunities for private information to be obtained on these networks by unauthorized persons. Measures must be taken (such as encrypting information) to help protect the information sent through public networks.
Sanctions – Organizations must have policies and procedures regarding disciplinary actions (sanctions), which are communicated to all employees, agents and contractors. For example, verbal warning, notice of disciplinary action placed in personnel files, removal of system privileges, and termination of employment and contract penalties. In addition to enterprise sanctions, employees, agents, and contractors must be told the civil and/or criminal penalties for misuse or misappropriation of health information. Employees, agents and contractors, must be made aware that violations may result in notification to law enforcement officials and regulatory, accreditation and licensure organizations.
Security Incident – Any type of compromise of any critical or sensitive data, including protected health information. Security incidents may be isolated, but many times they are not; they can include attacks on laptops or PDAs that appear to be global against an organization, rather than attacks against just one workstation. Often security incidents are considered incidents of opportunity; the intruder or perpetrator finds a weakness in the computer system, or with information handling practices, and exploits these weaknesses to gain access to confidential information, systems resources, or to render the network unusable. Security incidents include, but are not limited to, the following examples:
- Any attack on your monitoring, logging, or auditing systems or data
- Successful, or potentially successful, attack on your Internet firewall
- Successful, or potentially successful, attack on core financial, marketing, production, or development systems
- Successful, or potentially successful, attack on your protection or security systems at any level (information, logical, or physical, such as security or protective systems.)
Separation of duties – Separating responsibilities and authorization capabilities to ensure that no single person or department has total control over the information and validation process. Lack of separation of duties would enable someone to enter or conceal an error that is intended to defraud the organization or commit other harmful acts. An example would be not allowing the same individual to establish vendors to an authorized vendor file, and then also be capable of authorizing payments to a vendor.
Social Engineering – Attempts, sometimes successful and sometimes unsuccessful, to influence a person(s) into either revealing information or acting in a manner that would allow an intruder unauthorized access, unauthorized use, or unauthorized disclosure, to information, an information system, network or systems resources.
System Integrity – The current state of a computer network or systems component that reduces the risk to the network resources, and helps to ensure the continued confidentiality, integrity and availability of systems resources. Integrity depends greatly upon the reduction of risks to a level that is acceptable to allow successful business functioning.
Technical Security – The technical and automated processes that are put in place to guard against unauthorized access to information and systems components on a computer network. The processes implemented protect information and also control and monitor individual access to information. For example, automatically produced audit logs, login authentication processes, and encryption solutions are all examples of technical security methods.
Vulnerability Assessment – The formal steps and methodology used to identify weaknesses in network and computer systems that could potentially be exploited to allow unauthorized access and information modification within a systems. A vulnerability assessment should identify risks that to systems and information safety, security, reliability, availability, integrity, non-repudiation, legal compliance, and so on.