Last month’s IT Update (TechNation magazine) addressed how a few key network infrastructure systems facilitate data communication between devices. Building on that, it’s good to be aware of what is being transmitted to and from medical equipment and how that may affect operations and/or patient care. I believe two key starting points on this topic are Internet access and remote access.

Thinking through the inventory of network connected medical devices you manage, how many have direct Internet access? Of these, how many require Internet access for the proper operation or support of that device? If there is a big difference in your answer between those two questions, then the device owners have a big risk that should be addressed. Too many times I’ve seen devices with Internet access when it wasn’t necessary, and too many times I’ve seen those devices get infected with spyware, adware, Trojans, bots, worms, etc.

I’ve also seen devices that are not infected, but run slow or inconsistently because the device operators have installed all sorts of other software found online for entertainment during downtime. Even though there may be pushback for convenience, there are typically limited occurrences of patient treatment reasoning for why a system needs to be able to access the Internet. The typical consequence of putting the device at high risk for infection, data breach or just operational slowdown only typically serves to cause problems for CE, the device owner, IT, risk management, legal counsel and the patients.

So, if it is obvious a system does not require direct Internet access, what can be done and how does one implement a change on a system that currently has access? Before tackling the technical aspects, it’s important that the administrative ones are cleared first.

Anticipating clinician pushback on this change, some of the same stakeholders mentioned above should be involved along with quality, safety and management leadership. This allows for clinician convenience to be put in better perspective along with clinical care risks. The communication and documentation of such risks can be facilitated clearly to all parties by having a risk assessment performed and allowing for each group to review and comment on the results. Engaging this group also allows for any new policies, procedures and in-service training to be developed and addressed organizationally from the top down instead of laterally from another department like CE or IT.

Before addressing the technical methods, it’s important to distinguish between direct access and indirect access, especially for purposes of remote support. There can be clear financial and convenience advantages to allowing remote support access to medical devices over an Internet connection. What may take hours on the phone with technical support while in front of a device may only take five minutes for a specialist to troubleshoot remotely; in this case there is clear need for remote support access over the Internet. However, this doesn’t necessarily mean the device requires direct access to the Internet (or for legacy devices, a dial-in modem). A little planning and engineering for one or two preferable indirect remote access implementations can remediate many (but not all) of the risks.

Removing Internet access on a technical front can be addressed in many ways that vary in effectiveness, involvement and flexibility. For flexibility, as above, if indirect remote access is required use solutions which either redirect access through a controlled Virtual Private Network (VPN) system or easily permit one to “flip the switch” to allow temporary Internet access only when explicitly necessary. A VPN solution will typically involve using a VPN concentrator device owned and operated by IT; this may take a little more up-front planning, but has the advantage of keeping IT informed about the actions of remote support and allowing IT to manage accounts, passwords and troubleshoot access. A “flip the switch” solution is designed to prevent the device from outbound and inbound Internet traffic until the need arises.

Where possible, it’s preferable to open connectivity outbound first, such as using a WebEx session link for remote support, and only allow inbound connectivity, such as remote desktop sessions, as a last resort. Similar to the VPN solution, the “switch” solution may require IT assistance if using network controls such as a firewall, but if the device already has connectivity then the “switch” can be something less complex implemented on the device such as limiting DNS (Domain Name System) calls, gateway routing, VLANs (virtual LANs) and more. The idea here is that when direct Internet access is not needed, the “switch” is off, such as a blank DNS server entry or blank default gateway, but the local configuration “switch” is thrown by completing those configurations. It’s not foolproof and wherever possible a VPN or advanced firewall solution is preferable, but it is a minimally invasive and relatively flexible solution.

If a clinician has an opportunity to open a browser and surf Facebook, CNN or check their Gmail, the risk to that system has gone way up. Even a system which can access the Internet outbound only, once infected, can be accessed inbound even if the (unsophisticated) firewall attempts to prevent it. You would be amazed at the incredibly complex Trojans and bots I have witnessed which have been written specifically for this purpose.

Lastly, even if clinician Internet access is under control, a third party remote support company with access credentials which they can use 24/7 has the real potential to make their risks become your risks. No matter which solutions you choose, be aware that for devices with patient data there are a number of organizational HIPAA security and privacy requirements for technical and administrative controls. Overall, remove Internet access where possible, limit remote access and help ensure the organization has risk assessments for network medical devices with patient data.

(This article by Derek Brost, eProtex Chief Security Officer, was originally featured in TechNation.)

As a risk management professional, you carry an increasing load on your shoulders, considering the sharp rise in HIPAA enforcement, patient data breaches, and even new personal liabilities stemming from these issues. Meanwhile, independent audits reveal most of your peers miss one pressing threat to patient safety, data security and HIPAA compliance.

Look around: Scads of medical devices that store and feed patient data into your IT network — from pulse oximeters, CT scanners and even smart beds — typically do not receive the same level of protection as traditional IT equipment. Why is that? Simply put, you can’t treat FDA-regulated, medical devices like a computer, which leaves them especially vulnerable to data leaks and misfires.

Worse yet, misguided attempts to update or protect medical devices can alter their output, changing patient data or even how the device operates. It’s one thing for a CT scanner to be down; it’s another if that CT scanner has been impacted in a way that delivers an abnormally high dose of radiation, as one hospital experienced.

You can guard your organization against these risks by starting with the first thing HIPAA auditors would ask you (which also fulfills a HIPAA Security Rule requirement): a comprehensive risk assessment.

We invite you to take advantage of a complimentary security audit performed by a cross-functional team of IT, clinical engineering and HIPAA experts, and learn no-cost steps you can take toward greater safety and compliance.

Not sure this is right for you? Schedule a 20-minute introductory session over the phone and we’ll send you a $20 Amazon gift card for your time. To get started, email us at andrea.emerson@eprotex.com.

As the new year unfolds, we find scads of 2012 health IT predictions scattered throughout the blogosphere and industry media. Not surprisingly, most of it underscores what we’ve observed for months in terms of patient data security and HIPAA compliance.

As a recap, last year we saw considerable growth in a number of critical factors related to ePHI security:

• 32% rise in frequency of data breaches
• 10% increase in breach-related costs (averaging $2.2 million per breach)
• Ramped-up HIPAA audit program
• Increased use of ePHI-capturing/transmitting medical devices floating around healthcare facilities
• Greater push for electronic and “cloud” data management

Put it all together and it’s safe to predict that the Office of Civil Rights has every intention to recoup the $9 million it invested in a new audit program by year end. How? Via fines,  of course, which will in turn fund further enforcement. And so goes the HIPAA snowball, which we can count on spreading deeper and wider as it gains momentum.

How can you audit-proof your organization? We’ve talked at length about starting with a risk assessment before, so this time we’ll borrow a quote from the American Medical Association:

“Under the HIPAA Security Rules, organizations must complete a risk analysis and have policies in place detailing their approach to patient privacy and security and sanctions for those who do not comply” (“Health organizations not prepared for HIPAA audits,” Dec. 2011).

Aside from the much-publicized 150 audits coming this year, the AMA also notes that the OCR retains the authority to conduct additional audits based on complaints by patients who feel their privacy was violated.

What about all of those connected medical devices we mentioned earlier, much of which falls outside of IT’s traditional realm of expertise or even awareness?

Topping the list in its latest report, “Top 10 C-Suite Watch List: Hospital Technology Issues for 2012,” the ECRI Institute echoes our advocacy for clinical engineering and IT integration:

“Hospitals must develop a medical device integration plan, which will require clinical engineering (CE) and IT staff to work closely together to coordinate a plan… A strategic approach with the right medical device integration connections will get your hospital moving along the optimal path.”

In short, make sure your basics are covered by having a comprehensive risk assessment conducted by a team that’s well versed in how your medical devices, IT network, ePHI and HIPAA all impact one another.

This year, we’re honored to lend two featured speakers to the HIMSS12 Annual Conference and Exhibition (Feb 20-24 in Vegas). Whether you’ll be attending or following industry developments from afar, we invite you to join us in exploring hidden risks (and common blind spots) threatening patient data security at most hospitals.

Here’s the scoop:

As providers scramble to meet new mandates, independent audits reveal a collective electronic protected health information (ePHI) security failure stemming from medical devices. From data breaches to misdiagnoses, hefty penalties and more, we invite you to join us as we:

• Recognize hidden ePHI risks unique to network medical devices.
• Identify their business and clinical repercussions.
• Identify action steps to minimize or reverse risks, including some you can implement immediately, at no cost.

“Uncovering Hidden Data Security Risks of Connected Medical Devices”
(Lecture 158)

HIMSS12 Annual Conference and Exhibition
Thursday, February 23, 2012, 1-2 p.m.
Venetian Sands Expo Center, Las Vegas
Room: Marco Polo 705

Featured Speakers:

Earl Reber, Esq., Executive Director, eProtex

Derek Brost, CISSP, Chief Security Officer, eProtex

Meet us also at:

“Meet the Experts” Session
Thursday, February 23, 2012, 3:30-4 p.m.
Medical Devices Knowledge Center

eProtex Booth #13134
Lower Level, Hall G

(Can’t come? Email andrea.emerson@eprotex.com for presentation notes and resources.)

The Electronic Frontier Foundation (EFF) has a great New Year’s Resolution especially for all those attempting to meet HIPAA safeguards and lessen the impact from the highest cause of breaches!

As we hear about the nearly $5 billion in damages sought against Sutter Health for its recent patient data breach, out comes a study that confirms what we’ve known all along: Patient data breaches have increased 32 percent in the past year — and so have the financial risks to healthcare providers.

As the HHS Office for Civil Rights kicks off its ramped-up HIPAA audits this month, it’s worth reviewing some of the outcomes reported by the Ponemon Institute’s Privacy and Data Security Benchmark Study:

• 32% – Rise in health data breaches over the past year.
• 96% – Surveyed providers that reported at least one data breach in the last 24 months.
• $2.2 million – Average economic impact of a data breach over the past two years.
• $113,400 – Average lifetime value of one lost patient (customer).
• 2,575 – Average number of compromised records per breach.
• 81% – Surveyed providers who believe their organization suffered time and productivity loss due to a breach.
• 78% – Surveyed providers who believe their organization suffered brand or reputation loss due to a breach.
  (You can read the full report here.)

As you work to minimize or reverse the potential financial hit stemming from data security risks at your facility, we recommend you consider the first question HIPAA auditors would ask you: Have you completed a risk assessment?

Yes, we do sound a bit like a broken record on this point, but, truly, it’s the first step to compliance and a HIPAA Security Rule requirement.

As expressed in a recent training video by the Office of Inspector General, “[audits] are the heart of any effective compliance program. A good compliance program will identify problems from time to time. If it doesn’t, that’s a sign that what you’re doing is not working.”

It has been recently reported that the FBI and DHS are investigating a cyberattack against an Illinois water utility. An employee noticed the SCADA systems was power cycling which caused the burnout of a water pump. A review of the logs revealed the system had been remotely hacked (possibly for months) from an IP address in Russia. The system was remotely accessible via the Internet and, reportedly, a 3rd party had been granted credentialed access.

In many ways the risks and insecurity of SCADA systems and network connected medical devices are equal. There are a number of lessons to be learned from these recent activities and prudent risk remediations need to be made by medical device owners. A lot of these recommendations I’ve covered before, but for the sake of patient safety I’ll keep repeating them until the risks are remediated (which may be a LONG time.)

First, it’s almost never reasonable to connect a high-value, high-risk device directly to the Internet. Really. At eProtex we’ve seen this over and over. There are so few business reasons (and patient care reasons) for a medical device to be Internet routable… especially for devices which run Windows! Device operators may be tempted to surf the Internet from the device and the high-use websites such as Facebook, webmail, etc. all present numerous security threats to FDA regulated medical devices rife with vulnerabilities. A system which can access the Internet outbound, once infected, can be accessed inbound even if the (unsophisticated) firewall attempts to prevent it… incredibly complex trojans and bots have been written specifically for this purpose.

Second, do not permit a 3rd party vendor direct remote access to a medical device unless there is sufficient reason. If the vendor has a valid reason for remote access then you must conduct a thorough risk assessment and ensure appropriate administrative and technical safeguards are in place BEFORE the activity is permitted. Start with the administrative controls: ensure a change request and/or work order is in place and reviewed before remote access can be established, ensure the vendor does not store the password in plaintext in a support database, ensure proper liability clauses are contractually included, etc. Continue next with the technical controls: ensure the account isn’t always active, regularly review the logs for access originating from inappropriate locations (i.e. Asia or eastern Europe), add additional network protection systems such as IDS/IPS, etc. Remember, security is a chain of trust and when you introduce a 3rd party your weakest link becomes their weakest link.

I could go on and on and so will these stories. Unfortunately, like many things in security risk management, individuals don’t typically take action and plan response until AFTER problems occur. How many more SCADA systems will it take before owners and operators perform their due dilligence and take the minimum reasonable safeguards? Just don’t let it happen to you and please ask for help if you need it.

After much anticipation, new government-mandated HIPAA audits begin this month, as part of an increased enforcement program by the U.S. Department of Health and Human Services (HHS). The first 20 of a planned 150 audit subjects will soon be notified by KPMG, the contractor charged with managing the audit process.

In interviews with various media outlets, Leon Rodriguez, director of the HHS Office of Civil Rights, tells us one reason for the increased enforcement is because past efforts to educate and “shame” healthcare providers into compliance (mainly by exposing  breaches on the HHS website — a.k.a. “Wall of Shame”) haven’t been enough to motivate behavior change. “As I’ve learned as a prosecutor and then as a defense lawyer,” he shares, “enforcement promotes compliance.”

Program highlights:

• The first round of 20 audits is expected to take approximately five months. In all, up to 150 audits are targeted for completion by December 2012.
• KPMG, the contractor coordinating the audits, will notify audit subjects 30-90 days in advance. (First set of notices are going out now.)
• Each audit should take about 30 business days. Privacy and security documentation requests are due in 10 days.
• Every audit will involve an on-site visit, which will take three to 10 business days.
• While the primary focus will be on educating and helping audited organizations improve (while fine-tuning the audit process), “significant corrective action” may be taken if and when “significant vulnerabilities and weaknesses” are found, per Rodriguez’ interview here.

Related resources:

• Audit program overview and frequently asked questions.
• First step to audit-proofing your organization.
• Complimentary Security Audit or HIPAA Security Policy Review (no cost or commitment required): Email andrea.emerson@eprotex.com.

(This article, written by our very own Derek Brost, first appeared in TechNation magazine.)

In reviewing the U.S. Dept. of Health and Human Services’ website — home of the infamous “Wall of Shame” (public log of patient data breaches) — we came across a handy-dandy list of “Frequently Asked Questions” regarding HIPAA mandates and compliance.

In this post, we’ll focus on the following FAQ: “How will we know if our organization is compliant with the HIPAA Security Rule?”

Reminding us that the goal of the Security Rule is to “protect the confidentiality, integrity and availability of electronic protected health information (ePHI),” the government tells us that compliance is different for every organization: “No single strategy will serve all covered entities.”

“Covered entities should look at § 164.306 of the Security Rule for guidance to support decisions on how to comply with the standards and implementation specifications contained in §§ 164.308, 164.310, 164.312, 164.314 and 164.316. In general, this includes performing a risk analysis (…)”

Sound familiar? At the risk of sounding like a broken record, starting with a risk analysis not only fulfills a legal obligation, but it’s good business sense: You need to know where you (and your security gaps) are before you can make smart decisions about what needs to happen next.

“Compliance is not a one-time goal,” the HHS advice concludes. “Meeting the requirements set out in the evaluation standard at § 164.308(a)(8) will assist covered entities in maintaining substantial compliance.”