Patients are looking for easy ways to communicate with their providers that don’t require a phone call. Hold times and constraining office hours to make an appointment, request records, pay a bill, and other patient communications are often cited as frustrations by your patients. To help resolve this, you look to technology to streamline your patient communications.
Technology is a perfect solution to solve many of these more tedious communications. Technology can make your patients and your staff a lot happier. Patients can send communication requests at their convenience and your staff isn’t tied up on the phone to respond to them.
How we deal with technology to make our patients our own lives easier, is where it can get really sticky. The temptation is to create a communication page on our websites. This is totally acceptable, so long as, we keep HIPAA in mind when doing so. We have to ensure that the communication page for the patient to make these requests is SECURE. What this means is that we have to enable an encryption method on that communication page to make sure that the transmission of the request is coming to us without being seen by an unauthorized viewer.
There are several ways we can handle this problem. The first method is through our Electronic Health Record’s patient portal. Patient portals were designed to allow patients to communicate with their providers in a number of ways. By creating a link to your patient portal on your website, your patients now have the option to communicate with your staff at their convenience.
The patient portal option only works if you have a patient portal and if your patients are registered for it. A lot of practices are solving the problem with putting a communication form directly on their website to take communication requests from potential new patients as well as patients that are not yet registered for the patient portal. To make this communication form secure can be a bit trickier, but is still doable.
To secure your website communication forms, you have a few options. The easiest option is to purchase a Secure Socket Layer (SSL) for your website. Your website will then display as secure (HTTPS) for your web visitors. Another option if encrypting your entire site is not an option for you, is to purchase a secure web communication tool to embed on your website. A quick Google search for HIPAA compliant web communication forms will give you several options to choose from.
Apart from the website, we also have to ensure the communication is coming to us securely. The most common way web communication forms are delivered is through email. The email account associated with the web communication form needs to be encrypted. You will also need to make sure you are limiting access to that email account to only the necessary staff within your clinic. The email account will need to follow your practices security policies regarding backup as well.
If you are using your website as a communication tool for your patients, you will need to make sure that your website and its supporting systems (including the content management system and hosting) is included on your risk analysis, information system activity review, and other security evaluations your have in place to meet the Security Rule requirements.
Taking these few steps will help your practice avoid a costly breach due to insecure web communication.
For more information, contact us! 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.
Whether you back up your data with a cloud service provider, on your local server, or a physical hard drive, the question of whether to secure it via encryption should be answered. We begin with the basic premise that the HIPAA Security Rule requires you as a Covered Entity or a Business Associate to protect the confidentiality, integrity, and availability of the Protected Health Information in your possession. This responsibility also extends to your backed-up data.
Under the Technical Safeguards and access control standard of the rule, you are asked to determine if encryption and decryption should be implemented to allow access only to those persons who are authorized to view the PHI. Although this is an addressable implementation specification, you must still determine if encryption is reasonable and appropriate, and if not, consider an alternative equivalent. It would be difficult to conclude that some methodology to secure the backup PHI is not reasonable and appropriate. This question should be answered during your risk analysis and the following event demonstrates the importance of seriously considering this standard and ultimately securing your backed-up data.
On January 11, 2017, a Covered Entity from Texas learned that an “unencrypted” external hard drive was stolen from the clinic on or about December 29, 2016. The external computer hard drive was used by the clinic to back-up or store patient information from the Clinic’s electronic health records. Subsequently, the hard drive was stolen from a locked closet within the Clinic. The theft was reported to law enforcement and an investigation is currently ongoing. The stolen data consisted of the following sensitive information:
- Patient’s name
- Dates of birth
- Phone numbers
- Driver’s license numbers
- Social Security number
- Medical record numbers
- Account numbers
- Physician’s names
- Diagnosis and conditions
- Lab test results
The patient data spanned a period between 2009 and 2016 (seven years). Notifications are going out to the affected individuals as well as an offer for credit monitoring.
One can argue the organization could not reasonably anticipate this theft as a threat to the security and integrity of the PHI. After all, the hard drive was in a closet in the clinic. However, one can also argue the PHI was not protected from insiders who did not have a “need to know” access to the information since it was not secured via encryption. The investigation is ongoing as reported by the Covered Entity so we don’t know if a risk analysis was conducted or if this specific piece of equipment was on the inventory and known to exist by the security team or the IT department. What we do know is that backup data should be viewed like all data and securing it should be part of your effort to protect the confidentiality, integrity, and availability of PHI in your possession.
On January 13, 2017, OCR published a Cyber Awareness Newsletter about understanding the importance of audit controls. OCR stated Covered Entities (CE) and Business Associates (BA) should make sure that they appropriately secure audit trails, and they use the proper tools to collect, monitor, and review those audit trails. Not safeguarding audit logs and audit trails can allow hackers or malevolent insiders to hide their electronic tracks and cause harm to your organization.
The HIPAA Security Rule under the Audit Controls standard, requires the CE and BA to implement hardware, software, and/or procedural mechanisms that record activity in the electronic systems. Most systems offer some level of audit controls that can provide a report. OCR explains that application audit trails normally monitor and log user activities in the application. System-level audit trails capture successful or unsuccessful log-on attempts to include ID/username, date, and time. Finally, user audit trails monitor and log user activity in an e-PHI system.
Audit controls allow for reviewing inappropriate access, tracking unauthorized disclosures, detecting potential intrusions, and providing forensic evidence during an investigation of security incidents and breaches. System activity review is a required standard under the rule, but if you don’t have your audit controls enabled on your systems, you won’t have any activity to review, and you can’t protect your organization from nefarious activity.
You may have your audit functions enabled, but the follow up question is “are you reviewing them”? Are you periodically checking the reports? Do you know who is accessing your electronic information systems, EHR/EMR, or your e-PHI? The following case demonstrates what happens if you fail to regularly review records of information systems activity (audit logs and audit trails) on the applications that maintain e-PHI. On February 16, 2017, Memorial Healthcare Systems (MHS) out of south Florida, paid Health and Human Services (HHS) $5.5 million dollars to settle potential HIPAA violations. Individuals had their information impermissibly accessed by MHS employees and impermissibly disclosed to an affiliated physician’s office staff. Specifically, the login credentials of a former employee of the affiliated physician’s office had been used to access the e-PHI maintained by MHS on a daily basis without detection from April 2011 to April 2012, affecting 80,000 individuals. The information impermissibly accessed consisted of the individual’s names, dates of birth, and social security numbers. HHS found that Memorial Healthcare Systems failed to regularly review records of information system activity on applications that maintained e-PHI.
This recent event demonstrates the importance of having your audit controls enabled and conducting an audit of the reports themselves. Therefore, ensure the audit controls are enabled, the controls can’t be disabled by your staff, and the reports are being reviewed periodically. For instance, you may add “Audit Report Review” to your compliance plan so the review is conducted periodically at a frequency that best supports your organization. One more thing; only authorized individuals should have access to the audit trails and their reports. Use this link to view the full Cyber Awareness Newsletter from OCR: Newsletter Issue #12 – PDF . Use this link to view the full $5.5 million settlement against Memorial Healthcare Systems: https://www.hhs.gov/about/news/2017/02/16/hipaa-settlement-shines-light-on-the-importance-of-audit-controls.html
The HIPAA security rule asks covered entities (CE) to conduct a risk analysis under the security management plan. However, there is some confusion as to how often this analysis should be accomplished and to what level. For the purposes of this article, lets stipulate that the term risk assessment means the same as risk analysis since the two terms are often interchanged.
Per the HHS website, the security rule does not specify how frequently to perform the risk analysis a part of a comprehensive risk management process. The Security Management Process standard in the Security Rule requires organizations to implement policies and procedures to prevent, detect, contain, and correct security violations. Risk analysis is one of four required implementation specifications that provide instructions to implement the Security Management Process standard.
Section 164.308(a)(1)(ii)(A) of the security rule reads:
RISK ANALYSIS (Required).
Conduct an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of electronic protected health information held by the [organization].
How often you perform the risk analysis will be based on the circumstances of the organization. Some conduct it annually, while others wait two or three years. Yet, others conduct a “review only” each and every year. Again, this is up to your organization and its current circumstances such as a stable infrastructure, no serious security incidents, and level of risks, etc. In addition to conducting the risk analysis for the security rule, you also must conduct it when meeting the Meaningful Use program.
There are some myths that persist many years after implementation of the security rule in April 2005 as well as for the Meaningful Use Program. Let’s look at a few and determine the truth.
Myth: Small practices do not have to be concerned with a risk analysis.
False: Small practices were given an extra year to comply with the rule and needed to comply by April 2006. Small practices must conduct an initial risk analysis and continuously monitor. If you have not conducted a risk analysis by this point, this should become your top priority, as you are not in compliance with the Rule.
Myth: The risk analysis needs only to be accomplished once.
False: Although the security rule does not provide a frequency for how often it should be done, the Office of National Coordinator (ONC) recommends that it should be accomplished once a year or when changes to your practice or electronic systems occur.
Myth: A checklist is good enough for a risk analysis.
False: A checklist cannot provide a systematic security risk analysis.
Myth: There is only one specific way to conduct a risk analysis.
False: A risk analysis can be accomplished in many ways. HHS does not prescribe a specific manner. However, OCR has issued a Guidance on Risk Analysis Requirements of the Security Rule which provides steps on how to conduct a thorough analysis. You can also look at NIST Publication 800-30, Guide for Conducting Risk Assessment.
Myth: Simply by installing a certified EHR/EMR, a practice is meeting the risk analysis requirement.
False: Even if you install a certified EHR/EMR, you must accomplish a risk analysis to address all electronic protected health information, not just that which is in your EHR/EMR.
Myth: My EHR/EMR vendor took care of all my privacy and security.
False: Your vendor is only responsible for installing your electronic records system and will provide information about the security aspects of the product. You are still responsible for conducting a risk analysis.
Myth: Each year you have to redo your risk analysis for Meaningful Use.
False: You must perform a risk analysis initially for Meaningful Use. Afterwards, you may conduct a review during the reporting period.