The Three Exceptions to A Breach

Categories:

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

Don’t Take The Bait

Categories:

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!

My EMR Makes Me HIPAA Compliant, Right?

Categories:

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.

IS YOUR BACKUP DATA SECURED?

Categories:

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
  • Addresses
  • Phone numbers
  • Driver’s license numbers
  • Social Security number
  • Medical record numbers
  • Account numbers
  • Physician’s names
  • Diagnosis and conditions
  • Lab test results
  • Medications

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.

Are Your Audit Controls Enabled? (Are you reviewing the reports?)

Categories:

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