Last month’s IT Update 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 including 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 from another state or country; 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 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.