Top Ten Recommendations for Implementing PACS Security

Twitter icon
Facebook icon
LinkedIn icon
e-mail icon
Google icon

The University of North Texas (UNT) recently performed a survey to assess PACS security architectures and usage in more than 40 institutions. The facilities ranged in size from 100- to 1,000-bed facilities, and represented anywhere from 50,000 to one million examinations per year.

The data in the UNT survey showed several potential vulnerabilities with respect to security provisions. Taken in light of the U.S. Federal HIPAA security regulation goes into effect April 20th, these issues are not only impacting the availability and integrity of Patient Health Information, but also could represent potential federal HIPAA violations.

Please note, these 10 recommendations should not be considered a comprehensive assessment of the HIPAA regulations and/or how they apply to PACS. (For such an assessment, see PACS Fundamentals, chapter 8, available from www.otechimg.com.) Rather, they focus on the most obvious threats and issues, and are based on the UNT survey and through personal observations we have made while visiting institutions and talking with PACS administrators.

1. Deploy external & internal firewalls

Almost every institution has an external firewall connecting the hospital core network to the edge network provided by an ISP and/or WAN communications service provider. However, most threats actually appear from the inside - usually because someone inserts a virus-infected floppy or CD, or connects his or her laptop to a device to be calibrated or serviced. Our survey showed that 90 percent of the institutions do not have the RIS and PACS separated by a firewall. That means that a compromising situation at either the PACS or the RIS can impact both systems. Even the HIS is not always consistently screened. Several security incidents and downtime situations could have been avoided and/or their scope limited if an institution would have had these deployed more widely.

2. Implement VLANS to limit access

When combined with a gateway, a VLAN is the perfect complement because it limits the access from the gateway to a well-defined subnet. For example, one could configure the VLAN to make sure the CT or MR service engineers access only the equipment they should have access to. The same applies for any other vendor. In addition, with proper internal configuration, one can restrict certain devices to only have access to sub-domains using VLAN technology. Most of our respondents confirmed they were using this technology; however, it is not universally implemented at each institution.

3. Make sure your virus scanner is installed and up to date

Virus protection is somewhat difficult because most commercial virus protections do not always do a good job with dedicated and specialized medical imaging equipment. From personal experience, my laptop slows considerably after I've installed a virus scanner for all in-coming and out-going files. Also, it does not make sense to scan every image that leaves or enters a medical device. There have been stories about images being quarantined because they fit certain patterns of a particular virus, and the performance loss for scanning these files is often unacceptable. Therefore, deploy virus scanners, but work closely with the vendor to make sure they are configured correctly and they have been validated by the vendor to not have any negative impact on the device.

4. Force a service provider to use your gateway

The National Electrical Manufacturers Association (NEMA), in cooperation with several other international standards organizations, generated a proposal1 which specifies using a single gateway for remote service access as an entry point for hospital networks.  Based on our survey, 70 percent of participants implement a gateway. However, it appears that they allow vendors to install their own gateways rather than controlling the access themselves: only 30 percent of vendors in the survey are able to integrate their gateway with the hospital's gateway. Many vendors have indicated that installing their own gateways is a matter of preference. Imagine having four different vendors in a department. The institution is responsible to check the audit trails on these devices, especially if images and/or other clinical data are accessed or retrieved. From both cost and management perspectives (somewhere the institution pays for these devices), a single device makes much more sense.

5. Use the proper VPN configuration

Our survey showed that every hospital supports VPN for remote access, although 20 percent of the participants reported that they also provide dial-up access. SSL is predominantly used for remote access for PACS, which works at the communication level. In other words, a secure connection is established on an as-needed basis and the information is encrypted so that it can be exchanged using public networks. In some cases, it might actually make sense to use IPsec technology and establish a secure "tunnel" at the applications level. The table below details the differences between IPSec and SSL, and to alleviate any confusion about when to use which technology.

6. Deployment of network monitoring tools

It is essential to monitor the incoming and outgoing traffic on a continuous basis. For example, it is required to initiate periodic auditing of open ports using NMAP and monitor all the changed files. There are several open source network security monitoring tools. Some examples of these tools are Tripwire, Superscan, Nessus, and Ethereal. In addition, there are also several commercial tools like Lanscope which can give a three-dimensional display of the network traffic. These displays distinguish between normal and abnormal traffic.

7. Keep your IDS technology up to date

An Intrusion Detection System (IDS) is predominantly used to find abnormal behavior or activity within the network. The analysis of the survey results indicates that most (70 percent) of the hospital networks have this mechanism in their network. However, most of the IDS devices are limited in functionality and are generally unaware of the specifics of the protocols used, such as DICOM, HL7 or other proprietary protocols. IDSs are a rapidly evolving area and it is critical to make sure that one constantly monitors the new technology and is always alert to any intrusions.

8. Implement your security patches

The same caution applies when updating your operating system to include new patches that close security holes. You should not implement these as they become available, but rather, work with the vendor and your IT department to assess the risk. This might have to be done daily after the patch becomes available, because hackers are known to close the gap between security holes and create a new virus or Trojan horse that utilizes the hole. The trade-off between whether or not to implement the patch and the risk of someone exploiting it is called patch management and can be formalized using your specific architecture and implementation.

9. Limit your exposure through the use of a test system

It is amazing how many institutions install new software releases, upgrades, patches, and additional applications without properly testing and validating them on a non-clinical test system. It is common practice in the IT world to run tests - there are actually even special identifiers in the HL7 protocol messages that indicate test messages, so an application knows not to update the patient database or perform a lab test (as might have been indicated in the patient admission or order message). However, most institutions do not budget for a separate PACS test system, which can be as simple as a small version of the archive and a few simulators for modalities and workstations. We contend that with the HIPAA regulation stressing the preservation of data integrity, one could almost be required to have such a system. In addition, one also could use the test system as a back-up, thereby also satisfying another of the other critical HIPAA security requirements. Based on feedback from those using such a test system, and hearing what issues and problems were identified - things that prevented potential major problems with the clinical system - it seems a no-brainer. We did not ask about the availability of a test system in our survey, but based on other feedback and observations, it appears that the majority of the current PACS users do not have such a system in place.

10. Perform a regular risk analysis

The risk analysis is, perhaps, the single most important item in the HIPAA regulations; in part because every institution is unique and presents its own set of challenges, resources and cost limitations. One of the key messages in the HIPAA set of regulations is that security implementation should be reasonable and consistent with resources of the institution. In other words, a doctor's office will have a different security implementation than a major hospital. However, in all cases, it is impossible to justify any specific implementation without first performing a well-documented risk analysis. We mention this because when we visit institutions, we continue to see potential problems such as workstations displaying patient information and/or images which can be seen and accessed by anyone walking by, or workstations left un-attended, inviting anyone to disabled the auto-log-off. We've seen service personnel accessing devices without being monitored (until it is too late), and remote access from people not logged in and/or not monitored. Regular walkthroughs and risk analyses should be made every few months, if not monthly.

April 21st is coming soon

In conclusion, are we ready for HIPAA? Based on our survey, and through individual observations, it appears as though there are still many improvements which should be made. It also seems there are ad-hoc changes and awareness, not to mention several vulnerabilities and threats which could impact the HIPAA compliance of an institution and its data integrity.

1www.nema.org/prod/med/security/

Ram Dantu is an assistant professor in the Computer Science department at the University of North Texas. Herman Oosterwijk is president of OTech Inc. and a member of the adjunct faculty of the University of North Texas.