IT Policy: Don’t Be Surprised, Be Engaged!

Dennis Minsent, MSBE, CCE, CBET

Last month, we examined some of the differences between the biomed and information technology (IT) worlds. This month, we will look at some specific challenges regarding the interface of the IT and biomed departments.

As we previously discussed, for years we have been the masters of our own domains. Our networked clinical monitors and systems were controlled and managed by us (biomeds). We controlled what went on our network, and the protocols were typically proprietary.

As clinical technology advances, more and more devices are being released that can connect to a hospital’s wired or wireless 802.11 network. When this occurs, our devices are subject to the policies and protocols established by the IT department.

Get familiar with IT policy, and ask to be included as policies are developed and updated.

Here is a scenario that is not too uncommon. You receive an e-mail from IT indicating that the network will be down from midnight until 6 am for service and updates. While this is likely the best time to perform this service, this could have a major impact on the clinical departments involved if you have clinical devices on that network transmitting live clinical data. Imagine telling your intensive care unit (ICU) nurse manager that you are going to shut down the central monitoring station for 6 hours for service. I do not think that would be very well received!

Much like us, IT has been the master of its domain as well. It has established the policies and procedures that govern the IT network and environment. There was little need for IT to go outside of its department to seek input on its policies, because in health care, many users do not have the technical background to provide much meaningful input. It is like dealing with the electric company; it provides a critical service for you, but it will not likely ask you to provide input on its policies and procedures.

Biomeds must become familiar with and get engaged in collaborative and cooperative discussions with IT about policies. Security is a huge issue for networks, especially in health care. Three areas of security need to be considered:

• Access security: Ensure that only authorized personnel can access the system. This could include, for example, the use of strong passwords; magnetic cards; and retinal, fingerprint, or bar-code scanners. This would also include remote access from home and remote offices, or connecting to do remote diagnostics on clinical systems.

• Intrusion protection: Protect systems from malicious attacks using firewalls and proxy servers, and by allowing connections only to necessary systems. This would include ultrasound devices, EKG, or cardiology systems that connect to the hospital network to download studies stored on the system.

• Patient security: This would include policies relating to the Health Insurance Portability and Accountability Act of 1996 and the safeguarding of protected health information. It is becoming common to get data feeds to clinical systems like ICU and obstetrics monitoring, telemetry, and the nurse-call system from the admission, discharge, and transfer system to automatically load patient-identification information into the system.

There are other likely IT network spe-cifications and protocol policies that are absolutely appropriate for an IT system but may pose problems for clinical equipment and systems. The clinical systems are approved and regulated by the US Food and Drug Administration based on configuration and protocols submitted by the manufacturer. These configurations and protocols may be in direct conflict with your hospital’s IT policy. It is not a simple process to get the clinical-device manufacturer to change its protocol; in fact, it may be impossible.

Operating-system patches and security updates pose a particular challenge for clinical devices. For years, we asked the vendors to move away from proprietary software to make it simpler to interface devices with other systems. I guess the saying is true: “Be careful what you wish for, as it may come true!” When we made that wish, we didn’t have the problems with viruses and malware that plague the IT industry today. Below are some of the serious issues between IT and biomed we must ensure are worked out in advance.

• IT needs to update systems as soon as new patches are released to protect the hospital network. For clinical devices, these patches need to be tested by the clinical-device manufacturer before they can be released and applied. This does not occur at the same time that IT receives and releases its patches. In fact, it can take days and sometimes weeks before a patch is released. The clinical-device manufacturer must ensure that the patch does not interfere with the device’s operation. Patient diagnosis and treatment could be affected if the patch affects a critical element of the clinical-device operating system.

• IT has automated software that can push patches to computers on the network. Given the number of devices and the number of patches that are released, this is the most effective and efficient way to get systems updated. If your IT department uses this technique, you need to discuss how or if they have a way to filter it—that is, not push patches to clinical-equipment systems that may be on the network.

As you can see from these examples, as our clinical equipment is connected to the hospital network, we must be aware of IT department policies and procedures that may conflict with how we may have managed systems in the past. The key is communication and engagement with your IT group. Get familiar with IT policy, and ask to be included as policies are developed and updated. Having a good, collaborative relationship with the IT department is vital in the environment of today and the future.

Next month, we will explore the expanding number of devices that are or can be placed on, or be connected to, the hospital network. 24x7

Dennis Minsent, MSBE, CCE, CBET, is the director of clinical technology services at Oregon Health & Science University, Portland.