By now you are well into developing your Emergency Preparedness Plan for your Rural Health Clinic (RHC) or Federally Qualified Health Center (FQHC). You conducted an all-hazards approach to your risk assessment. That is, you identified all probable hazards and developed response procedures for each type of hazard which include natural, man-made, and/or facility emergencies. Additionally, as you conducted your risk assessment, you took a facility-based approach. You concentrated on risks specific to your facility and your region; for instance, you developed plans for a blizzard in Colorado or a tidal wave in Hawaii. You may have also decided to use a community-based risk assessment where you use plans developed by other entities such as public health and emergency management agencies, or regional health care coalitions. All the while, you reviewed your current HIPAA policies to look for overlaps or areas of commonality so you can use what you have already developed and have in place. Your next step for your Emergency Preparedness is to implement your plan in policies and procedures.
Centers for Medicare and Medicaid Services (CMS) requires you to develop policies and procedures and review and update them if needed at least annually. The policies and procedures must align with the risk assessment and hazards identified during the risk assessment. You can choose to make them part of your facility’s Standard Operating Procedures or Operating Manual, however, CMS recommends you have a central place to house your emergency preparedness program documents. This will make it easy for CMS to review them should they conduct a survey.
There are four key issues CMS asks you address in your policy and procedures:
1. Safe evacuation
2. Shelter in place
3. Preserve Medical Documentation
4. Using Volunteers
1. Safe Evacuation: CMS wants you to develop an evacuation plan which considers the care and treatment needs of evacuees. The plan should also spell out staff responsibilities, transportation needs, and identify locations that will be used for evacuation. The evacuation protocols should address where the evacuees will go but also where the staff members go as many times the evacuation location for the two are different. What will your transportation needs look like? How many vehicles do you have? Will you use vehicles of opportunity to evacuate your patients and staff? If you are an RHC or FQHC, you must also place exit signs to guide patients and staff in the event of an evacuation from your facility.
2. Shelter in Place: CMS wants you to develop a plan to shelter in place for your patients, staff, and volunteers. Not every emergency allows you to evacuate your facility. The most common threat that requires a shelter in place decision is probably a tornado. Your policy and procedures should identify the criteria for determining which staff and patients will shelter in place before an evacuation. When developing your plan, don’t forget to consider the ability of your building to survive a disaster as well as what proactive steps you can take prior to a situation that requires you to shelter in place. These are critical decisions that need to be well thought out before an actual emergency occurs.
3. Preserve Medical Documentation: CMS requires that you establish a system of medical documentation that preserves patient information, ensure patient records are secure and kept confidential, and readily available to support continuity of care during and after an emergency. Your policy and procedures should explain how you will accomplish this as well as stay in compliance with the HIPAA privacy and security rule. That is to say, your procedures must show how you will protect the privacy and security of individual’s personal health records whether you have electronic or paper medical records.
4. Using Volunteers: CMS wants you to develop policy and procedures to use volunteers in an emergency and other staffing strategies. Your procedures should explain how you will use volunteers with different skill levels. For instance, you may have healthcare professionals who volunteer during an emergency. How will you provide privileging and credentialing process in an emergency that ensures the volunteers can perform services within their scope of practice and training? You will have to look at your state laws and regulations for guidance. You also have federal teams that may volunteer in an emergency and are federally designated health care professionals such as the Public Health Service (PHS) staff, National Disaster Medical System (NDMS) medical teams, Department of Defense (DOD) Nurse Corps, or the Medical Reserve Corps (MRC). Your policy and procedures should also spell out how you will use non-medical volunteers. These individuals will perform non-medical tasks during your emergency.
CMS requires you to develop policies and procedures and review them annually. This allows you to update them if needed. The policies and procedures must align with the risk assessment and hazards identified during your risk assessment and address safe evacuation of your patients and staff, sheltering in place, preserving medical documentation, and how you will use both medical professional and non-professional volunteers. CMS recommends you have a central place to house your emergency preparedness program documents. And remember to review your current HIPAA policies for areas where there is commonality or where you have already addressed some of the requirements of the Emergency Preparedness Plan.
We know many of you are currently rushing to meet the November 16, 2017 deadline for developing your Emergency Preparedness Plan for your Rural Health Clinic (RHC) or Federally Qualified Health Center (FQHC). As you do so, the Centers for Medicare & Medicaid Services (CMS) wants you to keep in mind these three key essentials for maintaining access to healthcare during disasters and emergencies;
- Safeguarding human resources
- Maintaining business continuity
- Protecting physical resources
In addition, your emergency preparedness plan will be made up of these four sections;
- Emergency Plan (including risk assessment)
- Policies and Procedures
- Communication Plan
- Training and Testing Program
In developing your emergency plan, you must first conduct a facility based risk assessment. You may already have some or most of this accomplished because you conducted the HIPAA security rule’s risk analysis and implemented a risk management plan. Nevertheless, CMS wants your risk assessment to take an all-hazards approach. An all-hazards approach looks at all possible emergencies and disasters and spells out the response procedures for each. You can’t depend on procedures for responding to one type of emergency to provide sufficient response for a different type of emergency. For instance, your procedures for an active shooter in your facility will not help you respond to a ransomware attack of your electronic health records. Makes sense, right? Your risk assessment and subsequent plan should identify and include procedures for natural, man-made, and/or facility emergencies. It should;
- Identify all business functions essential to the facility’s operations that should be continued during an emergency
- Identify all risks or emergencies that the facility may reasonably expect to confront
- Identify all contingencies for which the facility should plan
- Consider the facility’s geographic location
- Assessment of the extent to which natural or man-made emergencies may cause the facility to cease or limit operations
- Determination of what arrangements may be necessary with other health care facilities, or other entities that might be needed to ensure that essential services could be provided during an emergency
CMS uses the term “facility-based” to mean the risk assessment and emergency preparedness program is specific to your facility. This is important as this approach will more clearly identify as well as eliminate, natural disasters for your facility and area. For instance, an RHC in Florida should consider preparedness actions in the face of an approaching hurricane as opposed to an RHC in South Dakota which should consider capabilities after a three-day winter blizzard, which is more reasonable to expect. On the other hand, both RHCs should assess and develop plans to respond to a power outage which was not caused by a natural disaster, yet does require immediate response to continue operations. For instance, do you have backup generators and fuel to run the generators, thereby providing the power needed to run essential operations?
CMS allows you as an RHC to use a community-based risk assessment developed by other entities, such as public health agencies, emergency management agencies, and regional health care coalitions or you can use theirs while conducting your own facility-based assessment. If you use a community- based risk assessment and plan, you need to have a copy of it and you need to work with the organization that developed it to ensure it meets the needs of your facility’s emergency plan.
Again, you may have already addressed these emergencies and hazards while implementing your HIPAA plan and policies, so a review of your plan may only require additional considerations. We at HIPAAtrek believe that many of the CMS requirements are already addressed by the HIPAA security rule. We are currently putting together an Emergency Preparedness Plan and HIPAA security rule cross-walk so you don’t have to reinvent the wheel; so be on the lookout for it. Until then, review your current HIPAA security plan for similarities that meet the CMS Emergency Preparedness Plan requirements and/or begin to document your all-hazards risk assessment.
Soon after implementation of the HIPAA privacy rule, some staff members would conclude that a violation had occurred because a doctor and a nurse were overheard speaking about a patient’s PHI, or a technician called out a patient by their actual name in the waiting room, or a white board at a nursing station contained PHI of patients on the Intensive Care Unit. Staff had yet to learn about the “Incidental Disclosure” rule that allows for incidental uses and disclosures that occur as a by-product of a use or disclosure permitted by the privacy rule, as long as reasonable safeguards are in place.
The same can be said today about breaches. There are still some staff members and some privacy officers that conclude that a breach has occurred when in fact the incident itself falls under an exception to the breach rule. With the implementation of the Omnibus rule on January 25, 2013, significant modifications to the breach notification rule were made to include three distinct exceptions to a breach. The definition of a breach remains the same and reads as follows: “a breach is defined as the acquisition, access, use, or disclosure of protected health information (PHI) in a manner not permitted under the privacy rule which compromises the security or privacy of the protected health information”. However, if the incident falls under one of these three exceptions, no breach has occurred. Let’s take a closer look at each of these exceptions as described by the breach notification rule.
The first exception to a breach involves any unintentional acquisition, access, or use of PHI by a workforce member or other person acting under the authority of the CE or BA, if the acquisition, access, or use was made in good faith and within the scope of authority and does not result in further use or disclosure in a manner not permitted by the privacy rule. For this exception to apply, the access must be unintentional and in good faith which can occur when a workforce member accessess the wrong patient’s chart. This exception would not apply if a technician is purposely “snooping” through electronic health records as this is not unintentional and certainly not in good faith. Additionally, the unintentional access would have to occur while the technician is conducting her duties for which she is authorized to do. Finally, after the unintentional access, the PHI cannot be further disclosed in a manner not allowed by the privacy rule. For instance, if the information is further disclosed for a treatment activity, this exception would apply. However, if the information garnered through the unintentional access is shared for “gossip” purposes, this first exception to a breach would not apply. In summary, the unintentional acquisition, access, or use must have been done in good faith, as part of the workforce member’s official duties, and not further disclosed in a manner not allowed by the privacy rule.
The second exception to a breach involves any inadvertent disclosure by a person who is authorized to access PHI at a CE or BA to another person authorized to access PHI at the same CE or BA, or organized healthcare arrangement in which the CE participates, and information received as a result of such a disclosure is not further used or disclosed in a manner not permitted by the privacy rule. For this exception to apply, the disclosure must be inadvertent. For example, a nurse on the B Ward inadvertently e-mails Dr. Serrano the wrong lab results. Dr. Serrano views the results noting that they belong to another patient and notifies the nurse who then sends him the correct lab results. Dr. Serrano deletes the e-mail and does not further disclose the lab results to anyone else in a manner not allowed by the privacy rule. Both the nurse and the doctor are authorized to access PHI, they both work at the same CE, and Dr. Serrano did not further disclose the PHI in a manner not allowed by the rule, thus this exception applies.
The third and final exception involves a disclosure of PHI where a CE or BA has a good faith belief that an unauthorized person to whom the disclosure was made would not reasonably have been able to retain the information. The preamble to the HIPAA rule uses the example of a CE, due to lack of reasonable safeguards, sends a number explanations of benefits (EOBs) to the wrong individuals and a few of the EOBs are returned by the post office, unopened, as undeliverable, therefore the CE can conclude that the improper addressees could not reasonably have retained the information. However, the EOBs that were not returned as undeliverable, and that the CE knows were sent to the wrong individuals, should be treated as potential breaches. The key for this exception to apply is whether the unauthorized person is able to retain the information. For example, sometimes pharmacies handout a wrong prescription bag to a patient. If the patient walks to the exit, discovers it is the wrong medication, and quickly returns it to the pharmacy, the pharmacy can make an on the spot assessment as to whether the patient (unauthorized person) was able to retain any of the demographic information belonging to the wrong prescription, i.e., name, DOB, etc. If the patient has not retained any of the information, this exception to a breach will apply.
In conclusion, the framers of the HIPAA privacy rule were aware of instances where unintentional or inadvertent uses or disclosures within a CE or BA, or disclosures to unauthorized individuals that could not reasonably retain the PHI, would pose little to no threat of compromise to a patient’s PHI. As a result, these three exceptions were created. When your next potential breach surfaces at your organization, don’t jump to conclusions. First gather all the facts and then determine if an exception applies. If so, document the incident and the exception you applied, and retain in your appropriate log or files. If none of the exceptions apply, proceed with the four-factor breach assessment to determine if there is a low risk of compromise to the PHI. The steps for the assessment are provided here: https://www.hhs.gov/hipaa/for-professionals/breach-notification/index.html
Phishing is the name of a method which entices you to give up your personal or financial information to people or organizations masquerading as a legitimate source. The bait is the request from a source you are familiar with, but is in fact, a replication or a phony. Phishing attacks may occur to your personal account, or they may involve your medical organization. In any event, knowing how to recognize them and not take the bait is the key to preventing a successful phishing attack.
Phishing attacks try to obtain valuable information from you such as your:
- Credit card number
- Bank account number
- Social security number
- Online account logins and passwords
The pilfered information is used to steal your money or in the case of your organization, carry out identity theft or introduce malware into your information systems.
Phishing attacks are carried out primarily in two main ways. First, attackers use phishing emails which look very similar to what you normally see in your daily e-mails. Second, attackers use links to websites that look similar to other organizations, companies, and/or banks that you visit frequently. Phishing e-mails and websites have the following characteristics:
- They all ask for you to provide personal information. Most legitimate organizations, and including all banks, will not ask you to provide personal information whether it be your credit card number or your login password.
- There is usually a sense of urgency. The phishing emails request immediate action and they use this technique to get you to bite quickly. This is the same technique you see on TV ads for a product whereby your quick response for “acting right now”, will get you a discount or a second item at half price. Or the e-mail will be emotional and pull at your “heart strings” in order to entice you to act.
- Most phishing emails have a generic “hello” for the greeting. The e-mail does not use your name since it is the same phishing e-mail sent to millions.
- The e-mails may contain attachments which are most likely malware and the moment you click on it, you invite malware (malicious code) into your system which will begin to destroy or copy your hard drive and its contents.
- The e-mails may also contain a phony link to a phony website. The link is masked so what you see looks correct, but the actual hyperlink is set up to go to the phony site. Hover your mouse over the link to see what is truly behind it.
- Many times, the e-mails contain poor grammar. Remember, hackers come at all levels with some that are very good at what they do, and others with poor writing skills.
- Legitimate websites use Secure Sockets Layer (SSL) for protecting the information you enter into the site; look for https:// instead of http:// in the URL. The added “s” means the site is secured.
Phishing attacks have increased over the years as hackers have gotten smarter and more clever. However, there are preventive steps you or your staff can take to survive the attacks with little to no damage. Consider the following:
- Your IT department should consider installing robust spam filters which can identify these e-mails and send them to the spam folder instead.
- If the e-mail looks suspicious, don’t trust it. Instead, pick up the phone and call the organization to determine if they sent the e-mail in question.
- If the link looks suspicious, don’t click on it. Instead, manually type the organizations real URL into your browser and provide the information after you have confirmed it was the organization that contacted you.
- Your IT department should consider adopting a URL scanner which will check the authenticity of any website you visit.
- If your organization uses Internet Explorer, ask your IT department to turn on the SmartScreen filter which will help you discover if a website is a phishing site.
- Unlike your browser at home, your organization determines what browser you will use at work, and it is most likely a newer browser which is supported with patches by the manufacturer. Nonetheless, your IT department could consider installing a security toolbar to alert you when visiting known phishing sites.
While the above technical steps will help minimize the effects of a phishing attack or help avoid them altogether, the ultimate defense lies with the user or employees themselves. It is the human factor that contributes to the large cases of successful phishing attacks since employees are ultimately tricked to open the link and/or respond to the e-mail. However, the more your workforce is educated regarding phishing, the more likely they will recognize an attack when it occurs. Some organizations have conducted “phishing simulations” to determine how many individuals will fall prey to the fake phishing attack. Afterwards, those individuals are provided additional training. This can be a great way to provide training and practice recognizing phishing attacks, but organizations need to make sure no punitive action is taken. Instead, consider an organization wide contest such that the department with the lowest number of tricked employees wins some prize or recognition.
Phishing attacks will continue and become more elaborate. The best defense is to employ technical safeguards to help detect them as well as to train your staff how to recognize them and not take the bait.
Happy HIPAA trekking!
No, having an EMR/EHR does not make your organization HIPAA compliant. This is a compliance mistake many organizations unknowingly make. As I visit facilities and ask the privacy officer how their HIPAA compliance program is working, they often respond that all is well because they have an EMR/EHR that keeps them compliant. The truth is the EMR/EHR itself may be HIPAA compliant, but that has no bearing on the compliance level of the entire organization. Let’s dig deeper into this issue to understand what I am saying.
When a vendor implements an EMR/EHR solution, all the compliance activities surround the EMR/EHR solution only. For instance, the vendor will set the EMR/EHR to force the staff to change their password the first time they log in and to use the password every time thereafter. By doing so, the EMR/EHR is helping the organization implement and use unique user identifications as required by the Access Control standard in the security rule. Another example involves the automatic logoff feature. The EMR/EHR’s electronic session is set to automatically logoff after a predetermined time of inactivity. Again, this is another requirement under the Access Control standard of the security rule. Finally, most EMR/EHRs allow the security officer to partition off areas in the EMR/EHR using an individual’s role in the organization, such as nurses, technicians, and doctors. This feature allows the organization to meet the “minimum necessary principle” of the privacy rule where the staff member only has access to the PHI required to do their job. In summary, the EMR/EHR vendor develops privacy and security safeguards into the EMR/EHR that allows the EMR/EHR to be used in a compliant manner.
However, although you have an EMR/EHR that is HIPAA compliant, the rest of your organization needs to meet the requirements of the security and privacy rule as well. The two security features of unique user identification and automatic logoff needs to be implemented in all of the organization’s information systems that process or maintain ePHI, not just the EMR/EHR. Privacy concerns such as accounting of disclosures, requests for restrictions, business associate management, providing a notice of privacy practices, answering HIPAA complaints, or security concerns such as conducting risk analysis, developing contingency plans, facility security plan, and security awareness and training, happen outside the EMR/EHR and thus must be implemented independently of the EMR/EHR for the organization to be HIPAA compliant. So, to summarize, it is incorrect to say you are HIPAA compliant because your EMR/EHR does it all for you. A compliant EMR/EHR is just a fraction of the organizations total efforts to meet the HIPAA security and privacy Rule.