AAMI: In defense of the in-house wireless test lab for devices
 |
“As you reach a threshold of bringing more and more devices into an IT network in a hospital, it becomes more and more problematic because of the increased potential for risk,” said Phil Raymond, chief wireless architect at Philips Healthcare in North Andover, Mass.
Before beginning the process of establishing a lab for testing new wireless devices to enter the IT network, Raymond recommended that the facility document its goals, such as the desire to safely share the network or to improve efficiency or to reduce costs—or all three. For the device inventory, facilities should include network and clinical requirements. They also recommended the use of risk-based lifecycle solutions: IEC 80001-1:2010, IEC80001-2-1 or IEC80001-2-3.
All members of the panel stressed the importance an extensive testing phase.
During the evaluation phase, Raymond said, “If you test one network, you’ve tested one network,” including the adage that the “tried and true is often better than new.” Thus, providers should test multiple, more mature networks.
The panel also encouraged communication between departments, specifically between the biomedical or clinical engineering (CE) department and the IT department. As part of this convergence process, CE needs to learn IT terminology, such as CCNA and CWNA, while IT needs to better understand the workflow of CE. “Build a relationship with IT, work together to develop a safe and effective Medical-IT network,” Raymond told the audience of mainly CEs.
“In addition to having strong lines of communication between CE and IT, said Shawn M. Jackson, principal manager at Kaiser Permanente, based in Oakland, Calif., “you need to take that same level of communication external of the organization—to the vendor who is responsible for customizing your network.”
Each hospital has “unique needs and requirements, and therefore, no two hospitals assess risks in the same way,” said Rickey L. Hampton, wireless manager at Partners HealthCare, based in Boston. “At Partners, we tend to be quite paranoid about risk, and are proud of it, but other facilities may have a lower risk tolerance.”
Those engaged in evaluation phase of the process need to understand vendor specific features because every WLAN vendor builds proprietary extensions on IEEE 802.11 specifications, and Raymond added that they should stay on general software-level releases.
The panelists agreed that the very “first step” in establishing a wireless/medical device IT environment is the convergence of the IT and CE departments. IT worries about data security, network availability and application management, while the CE worries about patient safety, clinical effectiveness, medical device availability and medical device interoperability. Therefore, their concerns complement each other.
Why is it important to test devices that may go onto the wireless network? First, it poses a risk to patient safety, clinical effectiveness and electronic protected health information, and because it is a significant investment for hospital networks, “let’s use it wisely,” Raymond said.
When is it important to test devices that may go onto the wireless network? The panel recommended to consider testing for “any” change, including WLAN configuration, new device introduction(s), WLAN physical layout and new construction (radiofrequency [RF] impact changes). “If the risk level is high and testing decreases the probability or severity of unintended consequences, then test” said Raymond, adding that the departments should compare the difficulty in testing vs. the difficulty in recovering from network failure.
Which devices should you test? Depends on what has changed, so Raymond recommended that the facility undergo a risk review that includes regression testing. Hampton added that greater communication is needed even during software upgrade roll-outs, and suggested requesting a “bug report” from the vendor about what the upgrade intends to improve.
When should you test? If you use a small clinic or IT network in a non-patient area of the hospital, there are pros and cons. The pros are it is isolated physically and logically from the larger network, which eliminates direct risk of connected patients; it uses IT network configurations; and it includes both medical and non-medical traffic. The cons include that it requires changes (adds, modifications) to IT network configuration, which could be mitigated through a permanent test subnet/VLAN; it may require coordinated scheduling with IT and hospital administration; and it requires definition to test traffic pathways require definition.
A stand-alone lab has similar pros (test when needed with full control over network configurations and higher costs due to dedicated network) and cons (smaller network footprint which has less network devices and is less complex; and device numbers not representative of IT network loading).
Thus, the panel recommended a phase approach because it allows for isolated IT network testing with high-confidence testing. The testing should not occur on patients, and most devices have demo models to prevent for that.
In fact, the “perfect and unrealistic test bed,” says Raymond, is an actual network or an exact replica on a network scale, which would use smaller version mimicking IT network topology (e.g. L3 routing). The panel also recommended using risk analysis in developing test capabilities, which ensures that mitigations are verified with testing and mirror WLAN and device configurations between the test bed and IT network.
The final step in building a test lab includes risk analysis, which determines required testing, closely emulate production network (PHY+L2/L3 boundaries); use network loading tools; actual medical and non-medical devices; client-to-server connections; production network and device configurations; and implement and understand performance monitoring tools.
Despite all the technical requirements, the panel concluded that organization and collaboration between the CE/biomed department and IT, as well as improved communication with industry are truly integral. Also, throughout the process, those involved need to “document everything” with consistent test plans and reports.