Photo courtesy of Carestream Health.
Recently, the biomedical equipment technology (BET) department at Texas State Technical College (TSTC), Waco, Tex, solved an internal reloading problem. The nature of this problem relates to the medical field, specifically in environments similar to our lab. We have eight computers that require an erase and reload between semesters. All use Windows 7 and the entire Microsoft Office suite, as well as a common set of software used in the BET applications. The problem comes when we have to reload systems. We used to load the software individually, a process that took several days. This worked, but it took two people a couple of days to fix driver conflicts and complete all updates. A friend of mine assured me there was a better way. He suggested we use a FOG Project system—an open-source cloning/imaging solution/rescue suite—to manage the hard drive images. We tried this technique, and it cut the time and labor in half! Now I recommend it for anyone reimaging computer-based medical systems. Here is how the FOG Project works, with the risks and the benefits of using a network-deployed backup system in a hospital environment.
FOG is a small operating system that deploys within a network using a network boot setting found in the target system’s BIOS settings. To set up FOG, download and install the FOG server software on an Ubuntu UNIX server attached to the network. Configure the FOG server, via the Web interface, to work with the target machine using a media access control (MAC) address. When the target system boots, it enters a Preboot eXecution Environment (PXE or pixie boot). In this state, the FOG server will determine if the system has a scheduled reimaging task. If needed, the FOG server copies the hard drive to the server as an image or deploys the image back to the target computer. An image is a file, or rather a snapshot, of a hard drive partition. This image allows for copies of the operating system, including all installed software, to reload on a specific computer. FOG allows a technician to remotely copy or deploy an image over a network in a technique called cloning.
The medical uses of this software were instantly apparent. Several devices in medicine operate on Consumer-Off-the-Shelf (COTS) technology. For example, if a hospital has several EEG systems running on a Dell or HP computer, the medical device itself is actually a COTS system. This means it should be able to run on a PXE boot setting and the FOG technique will work. In the field, an operating system reload fixes several problems. With a network-deployed cloning system, such as FOG, a reload is simple. Just tell the server to redeploy to a specific computer. Afterward, simply reboot the target system and FOG will take care of the rest. This technology can provide a means to copy an image and restore a medical device to its original, functional state. Since it works on COTS designed systems, EEG systems, PACS workstations, telemetry systems, and even some patient monitoring environments can benefit from this technique.
Despite benefits, this approach is not without problems. Primarily, there is a problem with data integrity. It is not a concern for the security of the upload/download process. The server is secure and accessible only through MAC verification and a Web-based login. Rather, the vulnerability is the current patient data on the target system. If there is usable information present on the target system, a wipe and reload will erase all usable medical data. This is a big no-no. For this reason, anyone using a reimaging process has to use best practices when handling patient data.
I have two major pieces of advice when dealing with reimaging. First, try to recover the patient files from the system before any reload. This is a very important piece of advice for anyone approaching a problem with an operating system crash. True, HIPAA may not cover Windows 7. However, it does relate to a patient data file. Be sure to back up any data before performing a wipe and reinstall. Second, try to work with the manufacturer. It is possible that the people who designed the system do not mind reimaging, in theory. They are concerned with a piece of equipment bearing their name to work in the best possible manner. Therefore, always call and ask which data files to preserve before reimaging any system. As a general piece of advice, remember to work with the entire maintenance team during a reload process, both in-house and via OEM. This ensures the maximum chance of protecting patient data.
The second problem with a full reload deals with changes and settings. After an image deployment, redo any modifications or updates to the system. Nothing is worse than returning a system to a department only to get a call to help put back user preferences. It lowers the credibility of a maintenance department and is counterintuitive to the entire repair process. To help reduce this problem, upload a fresh image on a regular basis. This ensures the most up-to-date settings and configurations are preserved in the backup image.
At TSTC, we use a test system. Since all of the lab machines use the same hardware, we have a spare unit for the purposes of fielding changes. This may not always be practical for a hospital environment, but try a lower use device as a test for updates and settings. Make sure all users are comfortable with the environment before making any changes. Get their approval after modifications, and update the image using the test machine. Then verify all is well before leaving the department. This is the best way to maintain a current image for a COTS-based medical system.
Recording Product Keys
The last concern is for licensing of an operating system. This is a simple matter because most computers list the product key either on a sticker or in the documentation. A fresh deployment may require a product key. It is a part of good documentation to record this information when a system first enters a hospital. Make sure to record all product keys for all operating systems on all medical devices. It is impossible to know when this information will come in handy. It helps insure hospital property; after all, the facility bought the operating system rights when it bought the medical device. When deploying an image, use the same operating system and software for the device. This helps guarantee that the hospital is in licensing compliance. Always follow up on the licensing side after a system reload and update keys from logs as needed. In the end, this is a simple matter of proper documentation. Take the time to make sure the legalities are correct.
I hope this information is fruitful to any health care technology management professional dealing with reloads. To make matters better, I suggest the FOG software for maintaining hospital environments. If this technology existed 10 years ago, I would gladly have used the technique to maintain at least three departments. You can find more information on the FOG Project Web site: www.fogproject.org/. Oh, I forgot the best part about FOG … It’s free!!
Garrett Seeley, MS, A+, N+, BS-AST, is an instructor of biomedical equipment technology at Texas State Technical College, Waco, Tex. For more information, contact .