Operationalizing Medical Device Cybersecurity at a Tertiary Care Medical Center
Priyanka Upendra, Purna Prasad, Glenn Jones, and Harvey Fortune
This article describes a methodical process to ensure medical device cybersecurity at a 400-bed tertiary care medical center. The entire cycle of retrieving the network-connected medical equipment list, upgrading systems with security features, standardizing the incoming inspections and the procurement process, documenting manufacturer statements, and ensuring proper updates through continu-ous monitoring are covered. It took about seven-and-a-half months for the teams to complete the upgrades and installations. Installing security features such as antivirus software, operating system patch updates, full-disk encryption, and user access control on medical devices and their worksta-tions consumed five-and-a-half months. The teams involved in this effort were Clinical Technology & Biomedical Engineering (CTBE), Information Security (IS), desktop engineer-ing, product security, and development experts from medical device manufacturers.
Introduction to the FacilityStanford Children’s Health is a 400-bed tertiary care facility in Palo Alto, CA. Approximately 10,700 medical devices are actively used for patient care. Clinical Technology is a part of the Information
Technology (IT) and Information Security (IS) department. Clinical Technology main-tains and provides user support to the medical devices at the facility. The majority of the medical devices are standalone and are
not connected to the hospital network or to electronic medical records (EMR).1 The vulnerabili-ties and risks of a patient data leak increase when the medical devices are connected to the hospital network and integrated into electronic medical records.2 As more medical
devices are connected to the network, it becomes necessary to perform a risk assess-ment and security review.3
Identifying the Network-Connected Medical DevicesThe Clinical Technology computerized maintenance management system (CMMS)contains current data on the medical device inventory. Medical device serial numbers, model name, model number, manufacturer name, distributor name, purchase cost, purchase order, in-service date, and history log of repair work orders were stored in the database. Using the information stored in this database, the list of all the medical devices used in the facility was extracted to an Excel spreadsheet. Although this process
About the Authors
Priyanka Upendra, MS, BE, CCMS, SSLP, is a clinical technology analyst at Stanford Medicine in Stanford,
The vulnerabilities and risks of a patient data leak increase when the medical devices are connected to the hospital network and integrated to the electronic medical record.
was very tedious, it proved to be very effective since it allowed us to examine every piece of equipment. The status of the equipment was classified as active, retired, and out for service. The retired equipment list was checked to confirm that all items were removed from the facility and not used for patient care. Patient units and surrounding areas were rounded to check for equipment with return-to-vendor and vendor-service tags. Follow-ups with the vendor were conducted to confirm that the equipment was received by them. The out-for-service equip-ment list was extracted, and these items were confirmed with the manufacturers to be out of the facility for repair and service using the serial numbers. The active equipment list contained 23,756 devices. Table 1 lists some of the different types of equipment classified per ECRI standards:
Devices that do not store, transmit, cap-ture, or receive confidential patient data and are not connected to the hospital network and the EMR were excluded.4 Such equip-ment includes audiometers, aspirators, and
handheld ultrasonic blood flow detectors. Table 2 represents an approximation of the characteristics that defined the low-, medium-, and high-risk categories.
For each device, the model number and model name were verified with the mainte-nance management database and the manufacturer. The user manuals for these model numbers were collected along with the manufacturer statement. Rounding the hospital and performing an audit of the inventory confirmed the exact number of equipment units.
Identifying VulnerabilitiesThe Healthcare Information and Management Systems Society (HIMSS) recommends that medical device owners and users use the Manufacturer Disclosure Statement for Medical Device Security (MDS2) during the medical device purchas-ing and security review process.5 The MDS2 was originally developed by HIMSS and the American College of Clinical Engineering and standardized with joint efforts between
Airway Clearance Units Analyzers, Point-of-Care Analyzers, Physiologic Anesthesia Units
Angioplasty Systems Angioscopes Apheresis Units Aspirators
Audiometers Automation Systems Autotransfusion Units Electronic Balances
HIMSS and the National Electrical Manufacturers Association. The MDS2 provides information about the security features of a medical device. This informa-tion was beneficial to the healthcare technology management and information security teams during their medical device security review and mitigation of risks.
Once the comprehensive equipment list of 23,756 items was ready, the clinical technol-ogy analyst contacted the manufacturer customer and technical support for the MDS2. Very few companies responded initially, and even fewer understood the importance of the MDS2. Every call with customer service or technical support involved explaining what the MDS2 con-tained, the manufacturer personnel who would have to complete it, and the deadline by which they should submit so that a thorough review could be conducted by the IT and CTBE security teams. With each call, the master list of equipment was updated with the contact information of the manufac-turer personnel assisting with the cybersecurity needs and issues. The updated contacts proved to be a big help in addressing the issues we had during the course of the continuous monitoring project.
A lot of time was spent contacting manu-facturers who are based outside the United States. Some observations experienced when
attempting to contact technical managers, regulatory and quality specialists, and software development managers included the following: • Customer Service/Technical Support—
involved a wait time anywhere between two days to five weeks for a response to the MDS2 request.
• Calls and e-mails to the known field service engineers— involved a wait time of approxi-mately one day to two weeks.
• LinkedIn— this was employed as a last resort. The analyst brought the paid account, which allowed sending messages to any and all company representatives, listed on LinkedIn. Direct e-mails were sent to the manufacturer company president or vice-president or regional managers. This escalated the issues and a response was received within one business day.
Taking care of MDS2 forms delayed the entire project cycle by more than a month. A lot of e-mail conversations were involved when it came to who filled out the forms.
Criteria Low risk Medium risk High risk
Connects to a PC • •
Connects to the SCH network •
Access to web browsing • •
Windows operating system • •
Stores patient data in hard disk • •
Transfers patient data to removable media/ PC • • •
Captures patient data on volatile memory • • •
Supports SCH approved encryption techniques •
Supports SCH approved anti-virus software •
Supports OS patches •
Unique SCH approved user names and passwords • • •
Open USB and RJ45 ports • • •
Table 2. Examples of criteria used to group equipment according to cybersecurity risk levels
The MDS2 provides information about the security features of a medical device. This information is beneficial to the healthcare technology management and information security teams during their medical device security review and mitigation of risks.
Each device went through a detailed security process that consisted of the following: • A thorough review of the user manual,
operating manual, and service manual. • Verification of usage in patient areas. The
wireless capability and network connectiv-ity of the equipment was confirmed during this phase.
• Involvement of IT security and CTBE
teams to discuss hospital security stand-ards and ePHI policies. The security team assisted the CTBE team with questions about antivirus installations, updates, scanning exclusions, encryption possibili-ties, operating system patch updates, and security exceptions for noncompliant equipment units that have a strong busi-ness justification.
• Installation of the software by the manu-
facturer. A team member from IT security and/or CTBE would assist the manufac-turer representative and make note of the instructions for installation, exclusions during scans, policies on antivirus and encryption, and maintenance.
• Updates to service reports and mainte-nance manuals in the database. We started experiencing delays and issues when manufacturers’ responses to the MDS2 were not as expected. Some responded with a “Not Applicable” in every field, some with the same answer in every field, and some with inaccurate answers. The inaccuracy was verified when the analyst went to the clinical setting/patient unit where the equipment was used. For example, one manufacturer indicated on the MDS2 that the equipment was not connected to the network or did not support wireless connectivity, but it was verified as being connected to the hospital network wirelessly. An IP address and MAC address were seen on the equipment network information.
The analyst in the CTBE department first
Figure 1. Partial screenshot of equipment in the master list. A full list would show the manufacturer, model number, model name, count and description.
Taking care of the MDS2 forms delayed the entire project cycle by more than a month. A lot of e-mail conversations were involved when it came to who filled out the forms.
reviewed the MDS2 form. A second review was performed by the security lead in the IT department. This gave the team a better understanding of the risks presented to us.
All MDS2 forms were collected within three months.
Mitigating the Risks This phase involved field service engineers coming on-site to install antivirus software on vendor-provided workstations or equipment with Windows operating systems, full-disk encryption software that support AES 128 or 256, OS patches, and SCH-approved user name and passwords authentication. However, there were no instances where non–human-entered or hard-coded string were used. Some manufacturers who had remote access to the equipment chose to update the software remotely. Vendor remote access is monitored by our security team. Each time a vendor needed access to a medical device for support or updates, the help desk and server team were informed, who then granted temporary access to the vendor through a closely monitored generic account. The vendor was able to get remote access only after a two-step authentication to confirm that he/she was a representa-tive of the medical device manufacturer who is authorized to perform service via remote access.
When we encountered situations where these security installations could not be performed, some manufacturers were extremely helpful and had their develop-ment engineers and testing teams provide release updates that supported antivirus software, Bitlocker encryption (used in SCH because the IS team is more familiar with it), and patch updates. Every week, the analyst and an assistant director had conference calls with teams from the manufacturer during which they discussed options for antivirus, encryption, OS patches, securing patient data transfer through removable media, and so on. The IT security lead would be informed
of these updates, who would then ask the desktop engineering or field services team to help with installations. For equipment requiring security exceptions, a request form was created. This form included details such as medical equipment manufacturer name, model name, model number, importance and relevance for patient care, and business justification. These exception requests were reviewed by an outsourced company. A total of three security exceptions were issued for 77 devices out of the master list. Reasons for the security exceptions included: • The equipment was not connected to the
network, but it transferred patient vital signs to another network-connected equipment unit.
• The equipment would be disposed from patient use in the next few months and a refresh would be brought in for use.
• The equipment could not support full-disk encryption per hospital policies but was essential for patient care. In such cases, a request was submitted to the manufacturer to release an update within six to eight months that would support Bitlocker encryption. The security safeguards present in each
medical device were documented in the CMMS. The vulnerabili-ties were discussed with hospital IT, CTBE, and IS teams, as well as with purchasing, and mate-rial management, and the manufacturers. The hospital-approved configurations of antivirus and encryption software were tested and validated by the manufacturer.6 User-names and passwords
were enabled on the networked devices that store, transmit, receive, or capture patient data. Security patches were applied on medical devices that work on Windows-based operating systems. All the upgrades and installations were documented and recorded in the CMMS for future reference.
Every week, the analyst and an assistant director had conference calls with teams from the manufacturer during which they discussed options for antivirus, encryption, OS patches, securing patient data transfer through removable media, and so on.
Managing Upgrades And InstallationsOn-site manufacturer visits were scheduled after discussing the vulnerabilities and upgrade options with different teams. Over a span of two months, three to four upgrades were scheduled daily. Some upgrades and installations were scheduled for weekends to take advantage of equipment availability.
Performing upgrades was not easy. It involved the collaboration of cross-func-tional teams.
Per SCH policies, all changes related to upgrades, updates, system reboots, system reconfigurations had to be approved by a Change Advisory Board (CAB), comprised of technical experts from the leadership team.
Requests submitted to the CAB had to include details on the proposed change, how it would be implemented, a back-out plan in case the change failed, the timeframe, and resources that would be used. If the CAB
approved the change, an e-mail was sent to all end users who might be affected. Also, the biomed team then rounded the respec-tive units to confirm that the clinical staff was aware of what was coming.
Support staff was put in place to help end users. Although this was a long process, it was effective.
All usernames and passwords were set according to hospital policies. The encryption and antivirus software on the medical devices were analyzed and approved by the security team. Manufacturer policies on uploading antivirus and encryption software were received and documented accordingly. Medical devices that transmit or receive confidential patient data using Bluetooth were checked for Bluetooth security by the teams.7 The length of the Bluetooth password chosen during each device sync had to meet Stanford Children’s Health standards (i.e., at least eight characters, with at least one alpha, one numeric, one uppercase, and one lowercase character). The devices had to be discoverable and connectible only when necessary for patient care.
Instructions and policies about antivirus and security patches were made available to the IS and Clinical Technology teams for
maintenance and support. Some manufac-turers preferred performing periodic updates and upgrade, and some delegated the task to in-house IT and Clinical Technol-ogy personnel. The ability to set up user logins and passwords was made available only to the nurse managers, who were given specific instructions to keep them confiden-tial. All laptops and workstations that were connected to a medical device were regis-tered with the hospital IT, which was responsible for the updates.
Lessons Learned Some of the lessons learned during this process were: • Collaboration with different teams was
essential to perform a thorough security review of medical equipment. The differ-ent teams were information technology, information security, materials manage-ment, buyers, clinical technology and biomedical engineering, senior leader-ship, and manufacturers.
• Opening tickets with service management teams to monitor the process proved helpful. The IT department can track and follow up with tickets on a daily basis.
• There is value in strong coordination and communication with nurses and physi-cians to accommodate equipment downtimes and patient monitoring during upgrades and installations.
• It is good to double check the information presented in the MDS2 by reviewing the equipment performance, security needs, MDS2, and manufacturer-recommended installations during daily team meetings. This saves a lot of time and possible confusion with e-mail conversations.
• It’s valuable to have daily and weekly follow-up with the manufacturers sped up the security process.
The biggest challenge was to keep up with the upgrades and make sure each was performed when Windows updates are available. Manufacturer websites offer software updates and notices. The CTBE analyst was tasked with staying on top of the updates. When available, the clinical engi-neers and field service engineers were notified to upgrade the software remotely.
Performing the upgrades was not easy. It involved the collaboration of cross-functional teams.
Standardizing the Procurement ProcessIT, finance, legal, contracts administration, CTBE, and materials management teams met to review the process for approving medical device requisitions. The procure-ment process for capital and noncapital orders was analyzed. The review process of capital orders was well defined, and it covered security considerations for equip-ment that is capable of connecting to the hospital network. The clinical technology leadership was involved in the process. The process for noncapital medical device requisitions was flawed and needed stand-ardization. The new process included collecting the MDS2 in the purchasing packet or during the request-for-information phase of a purchase. Security features were reviewed and analyzed for maintenance and support before the purchase of any device. Currently, teams are working on modifying the supply chain management system to include uploading the MDS2 when a requisi-tion is placed in the online ordering system. MDS2 is mandatory for the issuance of all medical device purchase orders.
Standardizing the procurement process proved to be very tedious and confusing. The materials management and buyer teams needed training to sort through equipment that transmits, stores, and captures patient information and connects to the hospital network. The master list that contained network-connected equipment was used as a basic reference. A list of vendor companies with equipment capable of connecting to the network was provided to the procurement team. Any doubts during a requisition order would be addressed with the CTBE team before approval. The purchasing packet on the online supply chain management system now contains a disclaimer for all patient care computing equipment. The disclaimer includes requirements that these devices should meet, procedures to perform the security review and exceptions, and contact information.
At the time this article was submitted, it had been three months since the completion of the upgrades and installations. Thus far, we have not come across any cybersecurity issues. However, we had one issue, where
our teams missed the acquisition of new equipment that did not have antivirus software installed. Within a few hours of connecting to the network, the IT depart-ment tracked the device that was sending and receiving malicious e-mails. Our teams immediately white-listed the equipment and reimaged the entire workstation.
A Strategy to Maintain Cybersecurity of Medical DevicesStandardization of an online supply chain management system for cybersecurity was necessary. Medical device preventive mainte-nance should include cybersecurity upgrades. A staff member should be assigned to review security updates of high-priority devices on manufacturer websites and other resources. Clinical technology and information security should be updated on current literature and best practices to ensure cybersecurity of medical devices. A biomed should be assigned to perform daily checks on cybersecurity updates from the manufacturer, distributors, suppliers, and other resources. A periodic audit should be performed to assess the value of connecting medical devices to the hospital IT network.8
The clinicians who use USB flash drives to transfer data between different workstations or a workstation and a medical device were advised to use USB flash drives that are encrypted and supported by Stanford Chil-dren’s Health IS team. However, our teams were trying to change this workflow pattern to avoid using USB flash drives because we have seen viruses spread via USB drives. We were initiating stricter processes to install SCH-approved encryption in case of theft, and introducing antivirus and patching to prevent USB infection.
Another ideas was to avoid using USB drives completely and opt for file sharing via the network drive instead, which is closely
Standardizing the procurement process proved to be very tedious and confusing. The materials management and buyer teams needed training to sort through equipment that transmits, stores, and captures patient information and connects to the hospital network.
monitored by the organization’s security team. Another process in progress was the use of non–human-entered password keys. The clinical technology and IS team was working with the medical device manufactur-ers to include such features in high-risk medical devices.
Making information technology a part of the clinical technology cybersecurity program and holding both teams accountable for complet-ing the updates on medical devices is essential.9 Both teams should be aware of the risks and vulnerabilities associated with medical devices and ways to mitigate them. Cybersecurity is a part of an overall patient safety program.10 n
References1. ECRI Institute. Making Connections [guidance
article]. Health Devices. 2012;41(4):102–21.
2. Coronado AJ, Wong TL. Healthcare
Cybersecurity Risk Management: Keys to
an Effective Plan. Biomed Instrum Technol.
2014;Spring(suppl):26–30.
3. Deloitte Center for Health Solutions. Issue
Brief: Networked medical device cybersecurity
and patient safety: Perspectives of health care
information cybersecurity executives. Deloitte.
2013:1-16. Available at: www2.deloitte.com/
content/dam/Deloitte/us/Documents/risk/
us-risk-networked-medical-device-11102014.pdf.
Accessed July 1, 2015.
4. U.S Food and Drug Administration. Cybersecurity
for Medical Devices and Hospital Networks: FDA
Safety Communication. Available at: www.fda.
gov/MedicalDevices/Safety/AlertsandNotices/
ucm356423.htm. Accessed July 1, 2015.
5. Healthcare Information and Management
Systems Society. Manufacturer Disclosure
Statement for Medical Device Security (MDS2).
Available at: www.himss.org/resourcelibrary/
MDS2. Accessed July 1, 2015.
6. Brost D. Beware These Nine Medical Device
Vulnerabilities. Available at: www.24x7mag.
com/2014/08/beware-nine-medical-device-
vulnerabilities. Accessed July 1, 2015.
7. Kumar P, Lee HJ. Security Issues in Healthcare
Applications Using Wireless Medical Sensor
Networks: A Survey. Sensors (Basel). 2012;12(1):55–
91.
8. Hayhurst C. Healthcare Networking: A
Risky Business. Available at: www.24x7mag.
com/2014/09/healthcare-networking-risky-
business. Accessed July 1, 2015.
9. U.S Food and Drug Administration. Cybersecurity
for Networked Medical Devices is a Shared
Responsibility: FDA Safety Reminder. Available
at: www.fda.gov/MedicalDevices/Safety/
AlertsandNotices/ucm189111.htm. Accessed July
1, 2015.
10. U.S. Food and Drug Administration.
Cybersecurity. Available at: www.fda.gov/
MedicalDevices/ProductsandMedicalProcedures/
ConnectedHealth/ucm373213.htm. Accessed July
1, 2015.
Standardization of an online supply chain management system for cybersecurity is necessary. Medical device preventive maintenance should include cybersecurity upgrades.
WITHget more
“The articles arewritten specifically about
Biomedical challenges and successes.”
- Biomedical Engineer
Get a free issue of 24x7 Magazine!Go to 24x7mag.com/subscribe for more information.
ANSI/AAMI SW87:2012Application of quality management system concepts to medical device data systems
American National Standard
ANSI/AAMI/IEC TIR80001-2-1:2012
Technical Information Report
Application of risk management for IT-networks incorporating medical devices — Part 2-1: Step by step risk management of medical IT-networks; Practical applications and examples
ANSI/AAMI/IEC 80001-1: 2010Application of risk management for IT Networks incorporating medical devices—Part 1: Roles, responsibilities and activities
