Free EMR Newsletter Want to receive the latest news on EMR, Meaningful Use, ARRA and Healthcare IT sent straight to your email? Join thousands of healthcare pros who subscribe to EMR and HIPAA for FREE!!

2.7 Million Reasons Cloud Vendors and Data Centers ARE HIPAA Business Associates

Posted on July 25, 2016 I Written By

The following is a guest blog post by Mike Semel, President of Semel Consulting.
Cloud backup
Some cloud service providers and data centers have been in denial that they are HIPAA Business Associates. They refuse to sign Business Associate Agreements and comply with HIPAA.

Their excuses:

“We don’t have access to the data so we aren’t a HIPAA Business Associate.”

“The data is encrypted so we aren’t a HIPAA Business Associate.”

Cloud and hosted phone vendors claim “We are a conduit where the data just passes through us temporarily so we aren’t a HIPAA Business Associate.”

“We tell people not to store PHI in our cloud so we aren’t a HIPAA Business Associate.”

Wrong. Wrong. Wrong. And Wrong.

2.7 million reasons Wrong.
Lawsuit
Oregon Health & Science University (OHSU) just paid $2.7 million to settle a series of HIPAA data breaches “including the storage of the electronic protected health information (ePHI) of over 3,000 individuals on a cloud-based server without a business associate agreement.”

Another recent penalty cost a medical practice $750,000 for sharing PHI with a vendor without having a Business Associate Agreement in place.

The 2013 changes to HIPAA that published in the Federal Register (with our emphasis) state that:

“…we have modified the definition of “business associate” to generally provide that a business associate includes a person who “creates, receives, maintains, or transmits” protected health information on behalf of a covered entity.

…an entity that maintains protected health information on behalf of a covered entity is a business associate and not a conduit, even if the entity does not actually view the protected health information.  We recognize that in both situations, the entity providing the service to the covered entity has the opportunity to access the protected health information.  However, the difference between the two situations is the transient versus persistent nature of that opportunity.  For example, a data storage company that has access to protected health information (whether digital or hard copy) qualifies as a business associate, even if the entity does not view the information or only does so on a random or infrequent basis.” 

A cloud service doesn’t need access to PHI – it just needs to manage or store it– to be a Business Associate. They must secure PHI and sign Business Associate Agreements.

The free, consumer-grade versions of DropBox and Google Drive are not HIPAA compliant. But, the fee-based cloud services, that utilize higher levels of security and for which the vendor will sign a Business Associate Agreement, are OK to use. DropBox Business and Google Apps cost more but provide both security and HIPAA compliance. Make sure you select the right service for PHI.
Encrypted
Encryption
Encryption is a great way to protect health information, because the data is secure and the HIPAA Breach Notification Rule says that encrypted data that is lost or stolen is not a reportable breach.

However, encrypting data is not an exemption to being a Business Associate. Besides, many cloud vendors that deny they have access to encrypted data really do.

I know because I was the Chief Operating Officer for a cloud backup company. We told everyone that the client data was encrypted and we could not access it. The problem was that when someone had trouble recovering their data, the first thing our support team asked for were the encryption keys so we could help them. For medical clients that gave us access to unencrypted PHI.

I also know of situations where data was supposed to be encrypted but, because of human error, made it to the cloud unencrypted.

Simply remembering that Business Associates are covered in the HIPAA Privacy Rule while encryption is discussed in the Breach Notification Rule is an easy way to understand that encryption doesn’t cancel out a vendor’s status as a Business Associate.
27864148 - it engineer or consultant working with backup server. shot in data center.
Data Centers
A “business associate” also is a subcontractor that creates, receives, maintains, or transmits protected health information on behalf of another business associate.

Taken together, a cloud vendor that stores PHI, and the data centers that house servers and storage devices, are all HIPAA Business Associates. If you have your own servers containing PHI in a rack at a data center, that makes the data center a HIPAA Business Associate. If you use a cloud service for offsite backups, or file sharing, they and their data centers are Business Associates.

Most data centers offer ‘Network Operations Center (NOC) services,’ an on-site IT department that can go to a server rack to perform services, so you don’t have to travel (sometimes across the country) to fix a problem.  A data center manager was denying they had access to the servers locked in racks and cages, while we watched his NOC services technician open a locked rack to restart a client server.

Our client, who had its servers containing thousands of patient records housed in that data center, used the on-site NOC services when their servers needed maintenance or just to be manually restarted.
37388020 - pushing cloud computing button on touch screen
Cloud-Based and Hosted Phone Services
In the old days, a voice message left on a phone system was not tied to computers. Faxes were paper-in and paper-out between two fax machines.

HIPAA defines a conduit as a business that simply passes PHI and ePHI through their system, like the post office, FedX, UPS, phone companies and Internet Service Providers that simply transport data and do not ever store it. Paper-based faxing was exempt from HIPAA.

One way the world has changed is that Voice Over Internet Protocol (VOIP) systems, that are local or cloud-based, convert voice messages containing PHI into data files, which can then be stored for access through a portal, phone, or mobile device, or are attached to an e-mail.

Another change is that faxing PHI is now the creation of an image file, which is then transmitted through a fax number to a computer system that stores it for access through a portal, or attaches it to an e-mail.

Going back to the Federal Register statement that it is the persistence of storage that is the qualifier to be a Business Associate, the fact that the data files containing PHI are stored at the phone service means that the vendor is a Business Associate. It doesn’t matter that the PHI started out as voice messages or faxes.

RingCentral is one hosted phone vendor that now offers a HIPAA-compliant phone solution. It encrypts voice and fax files during transit and when stored, and RingCentral will sign a Business Associate Agreement.

Don’t Store PHI With Us
Telling clients not to store PHI, or stating that they are not allowed to do so in the fine print of an agreement or on a website, is just a wink-wink-nod-nod way of a cloud service or data center denying they are a Business Associate even though they know they are maintaining PHI.

Even if they refuse to work with medical clients, there are so many other types of organizations that are HIPAA Business Associates – malpractice defense law firms, accounting firms, billing companies, collections companies, insurance agents – they may as well give it up and just comply with HIPAA.

If they don’t, it can cost their clients if they are audited or through a breach investigation.

Don’t let that be you!

About Mike Semel
Mike Semel is the President of Semel Consulting, which specializes in healthcare and financial regulatory compliance, and business continuity planning.

Mike is a Certified Security Compliance Specialist, has multiple HIPAA certifications, and has authored HIPAA courseware. He has been an MSP, and the CIO for a hospital and a K-12 school district. Mike helped develop the CompTIA Security Trustmark and coaches companies preparing for the certification.

Semel Consulting conducts HIPAA workshops for MSPs and has a referrals program for partners. Visit www.semelconsulting.com for more info.

An Alternate Way Of Authenticating Patients

Posted on July 5, 2016 I Written By

Anne Zieger is a healthcare journalist who has written about the industry for 30 years. Her work has appeared in all of the leading healthcare industry publications, and she's served as editor in chief of several healthcare B2B sites.

Lately, I’ve been experimenting with a security app I downloaded to my Android phone. The app, True Key by Intel Security, allows you to log in by presenting your face for a scan or using your fingerprint. Once inside the app, you can access your preferred apps with a single click, as it stores your user name and passwords securely. Next, I simplified things further by downloading the app to my laptop and tablet, which synchs up whatever access info I enter across all devices.

From what I can see, Intel is positioning this as a direct-to-consumer play. The True Key documentation describes the app as a tool non-techies can use to access sites easily, store passwords securely and visit their favorite sites across all of their devices without re-entering authentication data. But I’m intrigued by the app’s potential for enterprise healthcare security access control.

Right now, there are serious flaws in the way application access is managed. As things stand, authentication information is usually stored in the same network infrastructure as the applications themselves, at least on a high-level basis. So the process goes like this, more or less: Untrusted device uses untrusted app to access a secure system. The secure system requests credentials from the device user, verifies them against an ID/PW database and if they are correct, logs them in.

Of course, there are alternatives to this approach, ranging from biometric-only access and instantly-generated, always-unique passwords, but few organizations have the resources to maintain super-advanced access protocols. So in reality, most enterprises have to firewall up their security and authentication databases and pray that those resources don’t get hacked. Theoretically, institutions might be able to create another hacking speed bump by storing authentication information in the cloud, but that obviously raises a host of additional security questions.

So here’s an idea. What if health IT organizations demanded that users install biometrically-locked apps like True Key on their devices? Then, enterprise HIT software could authenticate users at the device level – surely a possibility given that devices have unique IDs – and let users maintain password security at their end. That way, if an enterprise system was hacked, the attacker could gain access to device information, but wouldn’t have immediate access to a massive ID and PW database that gave them access to all system resources.

What I’m getting at, here, is that I believe healthcare organizations should maintain relationships with patients (as represented by their unique devices) rather than their ID and password. While no form of identity verification is perfect, to me it seems a lot more like that it’s really me logging in if I had to use my facial features or fingerprint as an entry point. After all, virtually any ID/PW pair chosen by a user can be guessed or hacked, but if you authenticate to my face/fingerprint and a registered device, the odds are high that you’re getting me.

So now it’s your turn, readers. What flaws do you see in this approach? Have you run into other apps that might serve this purpose better than True Key? Should HIT vendors create these apps? Have at it.

Are You Ready for Stage 2 HIPAA Audits?

Posted on June 27, 2016 I Written By

John Lynn is the Founder of the HealthcareScene.com blog network which currently consists of 10 blogs containing over 8000 articles with John having written over 4000 of the articles himself. These EMR and Healthcare IT related articles have been viewed over 16 million times. John also manages Healthcare IT Central and Healthcare IT Today, the leading career Health IT job board and blog. John is co-founder of InfluentialNetworks.com and Physia.com. John is highly involved in social media, and in addition to his blogs can also be found on Twitter: @techguy and @ehrandhit and LinkedIn.

Many organizations probably didn’t even realize that OCR (HHS’ department in charge of HIPAA) had put in place HIPAA audits since the pilot program only audited 115 covered entities. That’s likely to change for a lot more healthcare organizations (including business associates) as Stage 2 HIPAA Audits are rolled out. Is your organization ready for a HIPAA Audit?

After spending about 2 months scouring the Stage 2 HIPAA Audit prototol, HIPAA One put together a great comparison of the simplicity of stage 1 HIPAA audits versus stage 2 HIPAA audits:

What it was – Phase 1 of the OCR’s Privacy, Security and Breach Notification Audit Program:
  1. HITECH added Breach Notification to HIPAA and endorsed the OCR‘s Audit Program.
  2. Contained 169 total protocols.
  3. Pilot program included 115 covered entities.
What it is now – the HIPAA Audit Program-Phase 2:
  1. OCR is implementing Phase 2 to include both CEs and business associates (every covered entity and business associate is eligible for an audit)
  2. Provides an opportunity for the OCR to identify best practices, risks and issues before they result in bigger problems (e.g. resulting in a breach) through the expanded random audit program.
  3. 180 Enhanced protocols (groups of instructions) which contain the following updates:
    1. Privacy – 708 updates (individual lines of instructions)
      1. Most notable changes are more policies and procedures surrounding the HIPAA Privacy Officer as well as some changes for Health Plans and Business Associates.
    2. Security – 880 updates (individual lines of instructions)
      1. Most notable changes are that Health Plans must have assurances from their plan sponsors and all companies now have to get proof of HIPAA compliance from their business associates, vendors and subcontractors.

That’s a lot of changes that are going to impact a lot of organizations. How many organizations have spent the time seeing which of these changes are going to impact their organization? I’m sure the answer to that is not many since “ignorance is bliss” is the mantra of many healthcare organizations when it comes to HIPAA compliance.

Particularly interesting is that HIPAA One points out that many of the checklists, books, commercial compliance software, and even ONC’s own SRA tool are likely outdated for these new changes to the HIPAA audit protocol. They’re probably right, so make sure whatever tool you’re using to do a HIPAA SRA takes into account the new HIPAA audit protocol.

Just so we’re clear, there actually hasn’t been a change to the HIPAA Omnibus update in 2013. However, the HIPAA audit protocol clarifies how the HIPAA law will be interpreted during an audit. That means that many of the gray areas in the law have been clarified through the audit protocol.

In HIPAA One’s blog post, they outline some important next steps for healthcare organizations. I won’t replicate it here, but go and check it out if you’re a HIPAA compliance officer for your organization or forward it to your HIPAA compliance officer if you’re not. The first suggestion is a really key one since you want to make sure you’re getting your HIPAA audit emails from OCR.

It’s taken HHS and OCR a while to roll out the full HIPAA audit program. However, it’s fully functioning now and I expect 2016 will be a real wake-up call for many organizations that aren’t prepared for a HIPAA audit. Plus, many others will be woken up when their friends fail their HIPAA audit.

Is your organization ready for a HIPAA audit?

Full Disclosure: HIPAA One is an advertiser on Healthcare Scene.

NFL Players’ Medical Records Stolen

Posted on June 21, 2016 I Written By

John Lynn is the Founder of the HealthcareScene.com blog network which currently consists of 10 blogs containing over 8000 articles with John having written over 4000 of the articles himself. These EMR and Healthcare IT related articles have been viewed over 16 million times. John also manages Healthcare IT Central and Healthcare IT Today, the leading career Health IT job board and blog. John is co-founder of InfluentialNetworks.com and Physia.com. John is highly involved in social media, and in addition to his blogs can also be found on Twitter: @techguy and @ehrandhit and LinkedIn.

I’d been meaning to write about this story for a while now, but finally got around to it. In case you missed it, Thousands of NFL players’ medical records were stolen. Here’s a piece of the DeadSpin summary of the incident:

In late April, the NFL recently informed its players, a Skins athletic trainer’s car was broken into. The thief took a backpack, and inside that backpack was a cache of electronic and paper medical records for thousands of players, including NFL Combine attendees from the last 13 years. That would encompass the vast majority of NFL players

The Redskins later issues this statement:

The Washington Redskins can confirm that a theft occurred mid-morning on April 15 in downtown Indianapolis, where a thief broke through the window of an athletic trainer’s locked car. No social security numbers, Protected Health Information (PHI) under HIPAA, or financial information were stolen or are at risk of exposure.

The laptop was password-protected but unencrypted, but we have no reason to believe the laptop password was compromised. The NFL’s electronic medical records system was not impacted.

It’s interesting that the Redskins said that it didn’t include any PHI that would be covered by HIPAA rules and regulations. I was interested in how HIPAA would apply to an NFL team, so I reached out to David Harlow for the answer. David Harlow, Health Blawg writer, offered these insights into whether NFL records are required to comply with HIPAA or not:

These records fall in a gray zone between employment records and health records. Clearly the NFL understands what’s at stake if, as reported, they’ve proactively reached out to the HIPAA police. At least one federal court is on record in a similar case saying, essentially, C’mon, you know you’re a covered entity; get with the program.

Michael Magrath, current Chairman, HIMSS Identity Management Task Force, and Director of Healthcare Business, VASCO Data Security offered this insight into the breach:

This is a clear example that healthcare breaches are not isolated to healthcare organizations. They apply to employers, including the National Football League. Teams secure and protect their playbooks and need to apply that philosophy to securing their players’ medical information.

Laptop thefts are common place and one of the most common entries (310 incidents) on the HHS’ Office of Civil Rights portal listing Breaches Affecting 500 or More Individuals. Encryption is one of the basic requirements to secure a laptop, yet organizations continue to gamble without it and innocent victims can face a lifetime of identity theft and medical identity theft.

Assuming the laptop was Windows based, security can be enhanced by replacing the static Windows password with two-factor authentication in the form of a one-time password. Without the authenticator to generate the one-time password, gaining entry to the laptop will be extremely difficult. By combining encryption and strong authentication to gain entry into the laptop the players and prospects protected health information would not be at risk, all because organizations and members wish to avoid few moments of inconvenience.

This story brings up some important points. First, healthcare is far from the only industry that has issues with breaches and things like stolen or lost laptops. Second, healthcare isn’t the only one that sees the importance of encrypting mobile devices. However, despite the importance, many organizations still aren’t doing so. Third, HIPAA is an interesting law since it only covers PHI and covered entities. HIPAA omnibus expanded that to business associates. However, there are still a bunch of grey areas that aren’t sure if HIPAA applies. Plus, there are a lot of white areas where your health information is stored and HIPAA doesn’t apply.

Long story short, be smart and encrypt your health data no matter where it’s stored. Be careful where you share your health data. Anyone could be breached and HIPAA will only protect you so much (covered entity or not).

Don’t Blame HIPAA: It Didn’t Require Orlando Regional Medical Center To Call the President

Posted on June 13, 2016 I Written By

The following is a guest blog post by Mike Semel, President of Semel Consulting. As a Healthcare Scene community, our hearts go out to all the victims of this tragedy.

Orlando Mayor Buddy Dyer said the influx of patients to the hospitals created problems due to confidentiality regulations, which he worked to have waived for victims’ families.

“The CEO of the hospital came to me and said they had an issue related to the families who came to the emergency room. Because of HIPAA regulations, they could not give them any information,” Dyer said. “So I reached out to the White House to see if we could get the HIPAA regulations waived. The White House went through the appropriate channels to waive those so the hospital could communicate with the families who were there.”    Source: WBTV.com

I applaud the Orlando Regional Medical Center for its efforts to help the shooting victims. As the region’s trauma center, I think it could have done a lot better by not letting HIPAA get in the way of communicating with the patients’ families and friends.

In the wake of the horrific nightclub shooting, the hospital made things worse for the victim’s families and friends. And it wasn’t necessary, because built into HIPAA is a hospital’s ability to share information without calling the President of the United States. There are other exemptions for communicating with law enforcement.

The Orlando hospital made this situation worse for the families when its Mass Casualty Incident (MCI) plan should have anticipated the situation. A trauma center should have been better prepared than to ask the mayor for help.

As usual, HIPAA got the blame for someone’s lack of understanding about HIPAA. Based on my experience, many executives think they are too busy, or think themselves too important, to learn about HIPAA’s fundamental civil rights for patients. Civil Rights? HIPAA is enforced by the US Department of Health & Human Services’ Office for Civil Rights.

HIPAA compliance and data security are both executive level responsibilities, although many executives think it is something that should get tasked out to a subordinate. Having to call the White House because the hospital didn’t understand that HIPAA already gave it the right to talk to the families is shameful. It added unnecessary delays and more stress to the distraught families.

Doctors are often just as guilty as hospital executives of not taking HIPAA training and then giving HIPAA a bad rap. (I can imagine the medical practice managers and compliance officers silently nodding their heads.)

“HIPAA interferes with patient care” is something I hear often from doctors. When I ask how, I am told by the doctors that they can’t communicate with specialists, call for a consult, or talk to their patients’ families. These are ALL WRONG.

I ask those doctors two questions that are usually met with a silent stare:

  1. When was the last time you received HIPAA training?
  2. If you did get trained, did it take more than 5 minutes or was it just to get the requirement out of the way?

HIPAA allows doctors to share patient information with other doctors, hospitals, pharmacies, and Business Associates as long as it is for a patient’s Treatment, Payment, and for healthcare Operations (TPO.) This is communicated to patients through a Notice of Privacy Practices.

HIPAA allows doctors to use their judgment to determine what to say to friends and families of patients who are incapacitated or incompetent. The Orlando hospital could have communicated with family members and friends.

From Frequently Asked Questions at the HHS website:

Does the HIPAA Privacy Rule permit a hospital to inform callers or visitors of a patient’s location and general condition in the emergency room, even if the patient’s information would not normally be included in the main hospital directory of admitted patients?

Answer: Yes.

If a patient’s family member, friend, or other person involved in the patient’s care or payment for care calls a health care provider to ask about the patient’s condition, does HIPAA require the health care provider to obtain proof of who the person is before speaking with them?

Answer: No.  If the caller states that he or she is a family member or friend of the patient, or is involved in the patient’s care or payment for care, then HIPAA doesn’t require proof of identity in this case.  However, a health care provider may establish his or her own rules for verifying who is on the phone.  In addition, when someone other than a friend or family member is involved, the health care provider must be reasonably sure that the patient asked the person to be involved in his or her care or payment for care.

Can the fact that a patient has been “treated and released,” or that a patient has died, be released as part of the facility directory?

Answer: Yes.

Does the HIPAA Privacy Rule permit a doctor to discuss a patient’s health status, treatment, or payment arrangements with the patient’s family and friends?

Answer: Yes. The HIPAA Privacy Rule at 45 CFR 164.510(b) specifically permits covered entities to share information that is directly relevant to the involvement of a spouse, family members, friends, or other persons identified by a patient, in the patient’s care or payment for health care. If the patient is present, or is otherwise available prior to the disclosure, and has the capacity to make health care decisions, the covered entity may discuss this information with the family and these other persons if the patient agrees or, when given the opportunity, does not object. The covered entity may also share relevant information with the family and these other persons if it can reasonably infer, based on professional judgment, that the patient does not object. Under these circumstances, for example:

  • A doctor may give information about a patient’s mobility limitations to a friend driving the patient home from the hospital.
  • A hospital may discuss a patient’s payment options with her adult daughter.
  • A doctor may instruct a patient’s roommate about proper medicine dosage when she comes to pick up her friend from the hospital.
  • A physician may discuss a patient’s treatment with the patient in the presence of a friend when the patient brings the friend to a medical appointment and asks if the friend can come into the treatment room.

Even when the patient is not present or it is impracticable because of emergency circumstances or the patient’s incapacity for the covered entity to ask the patient about discussing her care or payment with a family member or other person, a covered entity may share this information with the person when, in exercising professional judgment, it determines that doing so would be in the best interest of the patient. See 45 CFR 164.510(b).

Thus, for example:

  • A surgeon may, if consistent with such professional judgment, inform a patient’s spouse, who accompanied her husband to the emergency room, that the patient has suffered a heart attack and provide periodic updates on the patient’s progress and prognosis.
  • A doctor may, if consistent with such professional judgment, discuss an incapacitated patient’s condition with a family member over the phone.
  • In addition, the Privacy Rule expressly permits a covered entity to use professional judgment and experience with common practice to make reasonable inferences about the patient’s best interests in allowing another person to act on behalf of the patient to pick up a filled prescription, medical supplies, X-rays, or other similar forms of protected health information. For example, when a person comes to a pharmacy requesting to pick up a prescription on behalf of an individual he identifies by name, a pharmacist, based on professional judgment and experience with common practice, may allow the person to do so.

Other examples of hospital executives’ lack of HIPAA knowledge include:

  • Shasta Regional Medical Center, where the CEO and Chief Medical Officer took a patient’s chart to the local newspaper and shared details of her treatment without her permission.
  • NY Presbyterian Hospital, which allowed the film crew from ABC’s ‘NY Med’ TV show to film dying and incapacitated patients.

To healthcare executives and doctors, many of your imagined challenges caused by HIPAA can be eliminated by learning more about the rules. You need to be prepared for the 3 a.m. phone call. And you don’t have to call the White House for help.

About Mike Semel
Mike Semel, President of Semel Consulting,  is a certified HIPAA expert with over 12 years’ HIPAA experience and 30 years in IT. He has been the CIO for a hospital and a K-12 school district; owned and managed IT companies; ran operations at an online backup provider; and is a recognized HIPAA expert and speaker. He can be reached at mike@semelconsulting.com or 888-997-3635 x 101.

Securing IoT Devices Calls For New Ways Of Doing Business

Posted on June 8, 2016 I Written By

Anne Zieger is a healthcare journalist who has written about the industry for 30 years. Her work has appeared in all of the leading healthcare industry publications, and she's served as editor in chief of several healthcare B2B sites.

While new Internet-connected devices can expose healthcare organizations to security threats in much the same way as a desktop PC or laptop, they aren’t always procured, monitored or maintained the same way. This can lead to potentially major ePHI breaches, as one renowned health system recently found out.

According a piece in SearchHealtlhIT, executives at Intermountain Healthcare recently went through something of a panic when connected audiology device went missing. According to Intermountain CISO Karl West, the device had come into the hospital via a different channel than most of the system’s other devices. For that reason, West told the site, his team couldn’t verify what operating system the audiology device had, how it had come into the hospital and what its lifecycle management status was.

Not only did Intermountain lack some key configuration and operating system data on the device, they didn’t know how to prevent the exposure of stored patient information the device had on board. And because the data was persistent over time, the audiology device had information on multiple patients — in fact, every patient that had used the device. When the device was eventually located, was discovered that it held two-and-a-half years worth of stored patient data.

After this incident, West realized that Intermountain needed to improve on how it managed Internet of Things devices. Specifically, the team decided that simply taking inventory of all devices and applications was far from sufficient to protect the security of IoT medical devices.

To prevent such problems from occurring again, West and his team created a data dictionary, designed to let them know where data originates, how it moves and where it resides. The group is also documenting what each IoT device’s transmission capabilities are, West told SearchHealthIT.

A huge vulnerability

Unfortunately, Intermountain isn’t the first and won’t be the last health system to face problems in managing IoT device security. Such devices can be a huge vulnerability, as they are seldom documented and maintained in the same way that traditional network devices are. In fact, this lack of oversight is almost a given when you consider where they come from.

Sure, some connected devices arrive via traditional medical device channels — such as, for example, connected infusion pumps — but a growing number of network-connected devices are coming through consumer channels. For example, though the problem is well understood these days, healthcare organizations continue to grapple with security issues created by staff-owned smart phones and tablets.

The next wave of smart, connected devices may pose even bigger problems. While operating systems running mobile devices are well understood, and can be maintained and secured using enterprise-level processes,  new connected devices are throwing the entire healthcare industry a curveball.  After all, the smart watch a patient brings into your facility doesn’t turn up on your procurement schedule, may use nonstandard software and its operating system and applications may not be patched. And that’s just one example.

Redesigning processes

While there’s no single solution to this rapidly-growing problem, one thing seems to be clear. As the Intermountain example demonstrates, healthcare organizations must redefine their processes for tracking and securing devices in the face of the IoT security threat.

First and foremost, medical device teams and the IT department must come together to create a comprehensive connected device strategy. Both teams need to know what devices are using the network, how and why. And whatever policy is set for managing IoT devices has to embrace everyone. This is no time for a turf war — it’s time to hunker down and manage this serious threat.

Efforts like Intermountain’s may not work for every organization, but the key is to take a step forward. As the number of IoT network nodes grow to a nearly infinite level, healthcare organizations will have to re-think their entire philosophy on how and why networked devices should interact. Otherwise, a catastrophic breach is nearly guaranteed.

Can Healthcare Ransomware Be Stopped? Yes, It Can!

Posted on May 25, 2016 I Written By

The following is a guest blog post by Steven Marco, CISA, ITIL, HP SA and President of HIPAA One®.
Steven Marco - HIPAA expert
As an Auditor at HIPAA One®, my goal is to dot every “i” and cross every “t” to ensure a comprehensive HIPAA Security Risk Analysis.  The HIPAA One® Security Risk analysis is a tool to guarantee compliance, automate risk calculations and identify high-risk technical, administrative, physical and organizational vulnerabilities.

Recently, I was on-site for a client named “Care Health” (name changed to protect their identity). Care Health had invested in the highest level of our SRA (Security Risk Analysis) to cover all aspects of security and protection from Ransomware, malware, and the proverbial “sophisticated malware.”

The HIPAA One® HIPAA Security Risk Analysis and Compliance Interview process guided Care Health through a series of HIPAA citation-based questions and required users to upload documents to demonstrate compliance.  These questions directly addressed the organization’s security controls in place to protect against ransomware and cyber-threats.  You can see a sample of the citation-driven controls HIPAA One required for malware and malicious software below:

Technical Audit Controls 164.312(b)
HIPAA One® Requirement:  Upload screenshots of the systems configuration page(s) detecting malware network communications or ePHI/PII going out/in.
Client Controls:  End-user education on malware and phishing. Cisco IPS/IPS module active to block critical threats and WebSense Filter for deep-packet web-traffic inspection.

Administrative Protection from Malicious Software 164308(a)(5)(ii)(B)
HIPAA One® Requirement:  Provide a document showing a list of all servers, workstations and other devices with updated AV Software versions.
Client Controls: BitDefender Enterprise deployed on all workstations and laptops.

Administrative Procedures to guard against malicious software 164.308(a)(5)(ii)(B)
HIPAA One® Requirement:  Please upload a list of each server and sample of PC devices containing server name, O/S version, Service pack and the most recent security updates as available by the software vendor.  Verify critical security patches are current.
Client Controls:  Microsoft Security Operations Center combined with an exhausting change-management process to test new patches prior to release.

HIPAA Citation:  Administrative Training program for workers and managers 164.308(a)(5)(i) for the HR Director role.
HIPAA One® Requirement: Please upload a screen capture of the HIPAA training system’s grades for individual employees and detail the training/grading system in notes section.  Go through training and verify it efficiently addresses organization’s Policies and Procedures with real-world threats.
Client Controls:  Training that is due and required before bonuses, pay-raises or schedule to work are awarded.  Workforce and IT Helpdesk are trained to forward any calls regarding suspicious activities to the HIPAA Security Officer (HSO).

HIPAA Security Risk Analysis Tool

Back to the Ransomware attack…One day during the project, two staff members’ in the Billing department were going about their daily tasks, which involved working with shared files in a network-mapped drive (e.g. N: drive).  One of them noticed new files were being spontaneously created and the file icons in the network folder were changing. Being attentive, she noticed one was named ransom.txt.

Acting quickly, she contacted the IT Helpdesk who were trained to triage all security-related service-desk requests immediately to the HIPAA Security Officer(HSO).   The HSO logged-into the N: shared drive and found Care Health files were slowly being encrypted!

How do you stop a Ransomware attack?
The Security officer ran Bitdefender full-scans on the Billing department computers and found nothing.  He then installed and ran Windows Defender, which has the most current malicious software removal utilities on Server 2012 and found Tescrypt.  Installing Windows Defender on the two desktops not only detected this, but also removed it.

This Ransomware variant had somehow infected the system and was encrypting these files.  The quick-acting team at Care Health recognized the attack and stopped the Tescrypt variant before patient data were compromised.  Backups were used to restore the few-dozen encrypted files on the network-drive. It was a close call, but Care Health was ready and the Crisis Averted.

Upon a configuration review of all of Care Health’s security appliances, WebSense had been configured to allow “zero-reputation” websites through.  Zero-reputation websites are new sites without a known reputation and are commonly used by hackers to send these types of attacks. At Care Health, the Ransomware apparently came from a valid website with an infected banner ad from a zero-reputation source. The banner ad was configured to trigger a client-browser download prior to the user being allowed to see the valid web page.  This forced visitors to this website to download the executable virus from the banner-ad and unknowingly installing the Ransomware on their local computer.  When downloaded, the Ransomware would start encrypting files in high-lettered network-drives first.

Lesson Learned
Ransomware is here to stay and attacks are rising.  Healthcare organizations need to have policies and procedures in place to prevent these attacks and a comprehensive user training and awareness program.  The HIPAA One® software is one of the most secure ways to implement a HIPAA Security Compliance Program.  But a risk analysis is only one step… Ultimately, organizations must build top line end-user awareness and training programs. So like at Care Health, the employees know to quickly report suspicious activities to the designated security officer to defend against Ransomware, Phishing and “sophisticated malware attacks”.

To learn more about stopping Malware and using HIPAA One® as your HIPAA Security Risk Analysis accelerator, click to learn more, or call us a 801-770-1199.

HIPAA One® is a proud sponsor of EMR and HIPAA.

Joint Commission Now Allows Texting Of Orders

Posted on May 17, 2016 I Written By

Anne Zieger is a healthcare journalist who has written about the industry for 30 years. Her work has appeared in all of the leading healthcare industry publications, and she's served as editor in chief of several healthcare B2B sites.

For a long time, it was common for clinicians to share private patient information with each other via standard text messages, despite the fact that the information was in the clear, and could theoretically be intercepted and read (which this along with other factors makes SMS texts a HIPAA violation in most cases). To my knowledge, there have been no major cases based on theft of clinically-oriented texts, but it certainly could’ve happened.

Over the past few years, however, a number of vendors have sprung up to provide HIPAA-compliant text messaging.  And apparently, these vendors have evolved approaches which satisfy the stringent demands of The Joint Commission. The hospital accreditation group had previously prohibited hospitals from sanctioning the texting of orders for patient care, treatment or services, but has now given it the go-ahead under certain circumstances.

This represents an about-face from 2011, when the group had deemed the texting of orders “not acceptable.” At the time, the Joint Commission said, technology available didn’t provide the safety and security necessary to adequately support the use of texted orders. But now that several HIPAA-compliant text-messaging apps are available, the game has changed, according to the accrediting body.

Prescribers may now text such orders to hospitals and other healthcare settings if they meet the Commissioin’s Medication Management Standard MM.04.01.01. In addition, the app prescribers use to text the orders must provide for a secure sign-on process, encrypted messaging, delivery and read receipts, date and time stamp, customized message retention time frames and a specified contact list for individuals authorized to receive and record orders.

I see this is a welcome development. After all, it’s better to guide and control key aspects of a process rather than letting it continue on underneath the surface. Also, the reality is that healthcare entities need to keep adapting to and building upon the way providers actually communicate. Failing to do so can only add layers to a system already fraught with inefficiencies.

That being said, treating provider-to-provider texts as official communications generates some technical issues that haven’t been addressed yet so far as I know.

Most particularly, if clinicians are going to be texting orders — as well as sharing PHI via text — with the full knowledge and consent of hospitals and other healthcare organizations — it’s time to look at what it takes manage that information more efficiently. When used this way, texts go from informal communication to extensions of the medical record, and organizations should address that reality.

At the very least, healthcare players need to develop policies for saving and managing texts, and more importantly, for mining the data found within these texts. And that brings up many questions. For example, should texts be stored as a searchable file? Should they be appended to the medical records of the patients referenced, and if so, how should that be accomplished technically? How should texted information be integrated into a healthcare organization’s data mining efforts?

I don’t have the answers to all of these questions, but I’d argue that if texts are now vehicles for day-to-day clinical communication, we need to establish some best practices for text management. It just makes sense.

The Downside of Interoperability

Posted on May 2, 2016 I Written By

Anne Zieger is a healthcare journalist who has written about the industry for 30 years. Her work has appeared in all of the leading healthcare industry publications, and she's served as editor in chief of several healthcare B2B sites.

It’s hard to argue that achieving health data interoperability is not important — but it comes with risks. And I’ve seen little discussion of the fact that interoperability may actually increase the chance that a major attack could hit a wide swath of healthcare providers. It might be extreme to suggest that we put off such efforts until we step up the industry’s security status, but the problem shouldn’t be ignored either.

Sure, data interoperability is a critical goal for healthcare providers of all stripes. While there’s room to argue about how it should be accomplished, particularly over whether providers or patients should drive health data management, there’s no question it needs to get done. There’s little doubt that most efforts to coordinate care will fall flat if providers are operating with incomplete information.

And what’s more, with the demand for interoperability baked into MACRA, we pretty much have no choice but to make it happen anyway. To my knowledge, HHS has proposed neither carrot nor stick to convince providers to come on board – nor has it defined “widespread” interoperability to my knowledge — but the agency has to achieve something by 2018, and that means change will come.

That being said, I’m struck by how little industry concern there seems to be about the extent to which interoperability can multiply the possibility of a breach occurring. Unfortunately, security is only as good is the weakest link in the chain, and data sharing increases the length of the chain exponentially. Of course, the risk varies a great deal depending on who or what the data-sharing intermediary is, but the fact remains that a connected network is a connected network.

The problem only gets worse if interoperability is achieved by integrating applications. I’m no software engineer, but I’m pretty sure that the more integrated providers’ infrastructure is, the more vulnerabilities they share. To be fair, hospitals theoretically vet their partners, but that defeats the purpose of universal data sharing, doesn’t it?

And even if every provider in the universal data sharing network practices good security hygiene, they can still get attacked. So it’s not a matter of requiring participants to comply with some network security standard, or meet some certification criteria. Given the massive incentives these have to steal health data (and lock it up with ransomware), nobody can hold out forever.

The bottom line is that I believe we should discuss the matter of security in a fully-connected health data sharing network more often.

Yes, we almost certainly need to press ahead and simply find a way to contain the risks. We simply can’t afford our fragmented healthcare system, and data interoperability offers perhaps the best possible chance of pulling it back together.

But before we plunge into the fray, it only makes sense to stop and consider all of the risks involved and how they should be addressed. After all, universal interconnection exposes a virtually infinite number of potential points of failure to cybercrooks. Let’s put some solutions on the table before it’s too late.

Medical Device Security At A Crossroads

Posted on April 28, 2016 I Written By

Anne Zieger is a healthcare journalist who has written about the industry for 30 years. Her work has appeared in all of the leading healthcare industry publications, and she's served as editor in chief of several healthcare B2B sites.

As anyone reading this knows, connected medical devices are vulnerable to attacks from outside malware. Security researchers have been warning healthcare IT leaders for years that network-connected medical devices had poor security in place, ranging from image repository backups with no passwords to CT scanners with easily-changed configuration files, but far too many problems haven’t been addressed.

So why haven’t providers addressed the security problems? It may be because neither medical device manufacturers nor hospitals are set up to address these issues. “The reality is both sides — providers and manufacturers — do not understand how much the other side does not know,” said John Gomez, CEO of cybersecurity firm Sensato. “When I talk with manufacturers, they understand the need to do something, but they have never had to deal with cyber security before. It’s not a part of their DNA. And on the hospital side, they’re realizing that they’ve never had to lock these things down. In fact, medical devices have not even been part of the IT group and hospitals.

Gomez, who spoke with Healthcare IT News, runs one of two companies backing a new initiative dedicated to securing medical devices and health organizations. (The other coordinating company is healthcare security firm Divurgent.)

Together, the two have launched the Medical Device Cybersecurity Task Force, which brings together a grab bag of industry players including hospitals, hospital technologists, medical device manufacturers, cyber security researchers and IT leaders. “We continually get asked by clients with the best practices for securing medical devices,” Gomez told Healthcare IT News. “There is little guidance and a lot of misinformation.“

The task force includes 15 health systems and hospitals, including Children’s Hospital of Atlanta, Lehigh Valley Health Network, Beebe Healthcare and Intermountain, along with tech vendors Renovo Solutions, VMware Inc. and AirWatch.

I mention this initiative not because I think it’s huge news, but rather, as a reminder that the time to act on medical device vulnerabilities is more than nigh. There’s a reason why the Federal Trade Commission, and the HHS Office of Inspector General, along with the IEEE, have launched their own initiatives to help medical device manufacturers boost cybersecurity. I believe we’re at a crossroads; on one side lies renewed faith in medical devices, and on the other nothing less than patient privacy violations, harm and even death.

It’s good to hear that the Task Force plans to create a set of best practices for both healthcare providers and medical device makers which will help get their cybersecurity practices up to snuff. Another interesting effort they have underway in the creation of an app which will help healthcare providers evaluate medical devices, while feeding a database that members can access to studying the market.

But reading about their efforts also hammered home to me how much ground we have to cover in securing medical devices. Well-intentioned, even relatively effective, grassroots efforts are good, but they’re only a drop in the bucket. What we need is nothing less than a continuous knowledge feed between medical device makers, hospitals, clinics and clinicians.

And why not start by taking the obvious step of integrating the medical device and IT departments to some degree? That seems like a no-brainer. But unfortunately, the rest of the work to be done will take a lot of thought.