Research on Medical
Device Interoperability,
Audit, and Control
CLARA CURRIER
Introduction
Medical devices used around the world suffer from a host of security, data reliability, audit,
interoperability, and usability issues.
Some of these issues are a matter of convenience and efficiency
Some are related to administration and compliance
However, with ransomware and falsifiable data in the picture, vulnerabilities can become a
matter of life and death
Is there a way to add additional security and audit controls to
medical devices through a third-party device or accessory?
The Trial of Two British Nurses
In 2013, over 50 nurses at the Mid Staffordshire NHS Foundation hospital were investigated for
fabricating blood glucose data. At least three pled guilty but two went to trial.
The hospital used small digital glucometers that could be docked to a station to have test data
uploaded. The basis for trial was the large number of tests that were written on paper records
that had no corresponding data entry.
These glucometers had a number of problems:
◦ They required patient ID as an input, but if the ID did not take, nurses could bypass this by scanning
their own ID twice, known as “double-tapping”
◦ The system would reject this data behind the scenes, requiring manual input that almost never happens
◦ The docking procedure took up too much time and was done inconsistently. No glucometers were
tracked and there was one instance of a four-year gap between test and upload
◦ The database was poorly managed and easy to modify, with no audit trail
◦ Glucometers could overwrite past data if not docked in awhile
Inherently Insecure Design
The two nurses were acquitted… but eventually lost their jobs in a civil suit. The NHS hospital
still believed they were non-compliant.
Like many standard IoT devices, medical devices are very good at their “core” function but their
manufacturers do not know how to make a program secure. Manufacturers have been adding
computer functionality to devices for a long time with security as an afterthought.
Other Notable Events
Ransomware is another concern for data integrity: Hollywood Presbyterian Medical Center paid
$17,000 in Bitcoin.
Implantable medical devices are out of scope of this project, but face similar challenges: British
and Belgian researchers found vulnerabilities in the wireless communication protocols for 10
implantable cardiac defibrillators.
Patients are capable of hacking their own devices: One American patient found a password for
his infusion pump and gave himself larger morphine doses.
What Can Be Done?
With respect to most devices, very little
◦ FDA has only recently been considering cyber security requirements. There are new protocols that try to
encourage better practice but it takes time for regulation to proliferate
◦ Devices are profitable enough for manufacturers to prioritize release instead of security
◦ Many manufacturers are not “security companies” and focus instead on core functionality
◦ A large number of devices are legacy and are no longer supported but still used
◦ Doctors and nurses don’t always know what to do or understand security implications
◦ Manufacturers have financial reason to make their devices “not play nice” with devices made by
competitors
However, there have been some attempts to standardize device interoperability, such as
MDPlug-and-Play.
What Can Be Done?
With respect to the nurse audit dilemma, there is a possibility to implement third-party features
that provide security through vigilance
◦ If the devices themselves are insecure, then one solution is to constantly monitor the device for unusual
events or inputs
◦ Many devices, even legacy ones, have at least one form of input port. This could be an avenue for a
potential “universal” auditing device
◦ The reason for the nurses’ bad practices was bad product design
What if all medical device data was audited for validity on the spot
by an external monitoring device, adding security and usability
where there was previously none?
Potential Solution: an
Arduino-based
Monitoring Accessory
A Proof-of-Concept Auditing System
The focus of this research project is to craft a proof-of-concept accessory using readily available
accessories such as the Arduino.
The issue with the glucometers was that invalid data was not being detected and rejected on the
spot. However, we do not want to make nurses’ lives too difficult. Removing the docking station
from the picture and adding our own secure mechanism for downloading data can solve issues
with the docking station as well.
The potential solution includes not only a device, but a cloud-like server also designed with
security in mind. The goal is to ultimately connect to an app on a phone.
Basic device made with breakout boards and pinout
Communication diagram of hypothetical solution
Technical Specification
The core accessory is made of an ESP8266-12E wireless board. A DB-9 serial adapter is
connected to it. The microcontroller accepts programs made in the Arduino language.
◦ Uses the wifi protocol to connect to my laptop
◦ Only needs 3-5V power supply
Server was a simple python program on my laptop to substitute for a cloud-like solution.
◦ For proof-of-concept it only needed to establish a connection with the ESP board and receive some
form of data
◦ Potential upgrades may include a full database or an Apache server connection
Data is to ultimately upload to my phone
◦ An Android app is supposed to query my python server for any updates from the medical device
Experimental Design
1.
Obtain a functional medical device that has some form of serial output. GMU’s School of
Nursing has expressed interest in this project.
2.
Collect a working data dump. Before the device is fabricated, the target device will be
directly connected to my laptop. The device may simply deliver plaintext time-series data but
it will need to be converted into a machine-readable format.
3.
Build the accessory prototype. The matching serial connector will be affixed and the
necessary software and firmware will be created and installed.
4.
Using the sanitized data, construct a database and server that will then listen for future
updates from the accessory.
5.
Build an Android application that will receive updates from the server and output a status
report.
Target Device
Three devices were inspected for this project. A Quintet AC hand-held glucometer, a Mindray
PM-50 hand-held pulse-oximeter, and a Baxter Colleague C1 Fluid Monitor.
The IV pump has a single DB9 “COM” port and an interactive display with some elementary
programmable entries.
These devices were last produced in 2005, and a recall was issued from 2006-2011, but they are
still used in hospitals around the nation.
The device was the most complex piece of equipment in the nursing lab.
Baxter Colleague IV pump and the prototype
Results
Very Little
Unfortunately the project became stuck on step 2: Collect a working data dump.
Fabricating the device was fairly easy. However, I did not complete any further steps until I could
establish some form of output from the target medical device.
Using a direct DB9 serial-to-usb connection, I tried various ways to connect to the device.
◦ Discovered baud, parity, stop, and handshake through stty and used PuTTY on linux to attempt
connection
◦ Also tried screen, moserial, and a few other configurations
◦ Tried various configurations and modes on the Colleague, including “download data” mode
Connection attempts failed for all three of inspected devices.
Legacy Devices Don’t Talk
The Colleague’s manual states that there is a computer monitoring mode and a nurse call
accessory, with clear references to downloading data and connecting to other devices. The
Colleague is capable of transferring configurations to other Colleague devices over serial.
The glucometer and pulse-ox also had indicators that it could connect to a computer, with the
glucometer even having a “PC” port that uses micro-USB. This port is never mentioned in its
accompanying manual. The pulse-ox was stated to use proprietary software to download its
data. The serial port on that device was non-standard.
Interesting Finds
There were other discoveries made over the course of this project.
Most notably, the Colleague has a hard-coded password vulnerability and there are suspicious
websites that target the Colleague specifically. A search on duckduckgo for “baxter colleague
service manual” reveals generated urls leading to pdfs with links in them.
A forensics environment is being prepared to investigate the links. One probed link led to a
website that firefox blocked due to being “known to distribute malware”.
This is especially concerning given how old the device is, its continued use, and the fact that its
nurse call accessory allows some form of wireless access. (The accessory was not available in the
nurse lab)
Hardcoded passwords and suspicious links
Further Work
There is unfortunately little that can be done without taking apart the equipment itself. Many
forms of hardware hacking involve desoldering or specialized observation equipment. One
critical goal of the project was to avoid potentially breaking warranties or running afoul of FDA
regulations.
This project will also need more time to do forensics on the suspicious links and the
communication port.
Communication with Baxter itself were conducted but customer service could not provide much
help since the product was discontinued over a decade ago. They may still be able to provide
older copies of manuals that are not in the nursing lab, such as the “computer monitor” guide
and the nurse call accessory.
Conclusions
Providing security through a third party device is more difficult than it appears. Breaking into
devices and damaging them is much easier than constructively adding security. This was
unexpected because hacking devices still requires communicating with them.
There was also an unexpected hiccup in programming the ESP: the microcontroller does not
have existing libraries for some forms of wifi connections (WPA2-Enterprise was difficult to work
around). While this was not the terminating issue, this would have been the next issue to face if
the accessory could communicate with the Colleague.
This project underscores the need for security to be at the forefront of regulation and concerns
for consumers and doctors. If it is too difficult to establish a “band-aid” for security, then it is
critical that manufacturers are forced to prioritize security for all devices.
Bibliography
Arney, D., Fischmeister, S., Goldman, J. M., Lee, I., & Trausmuth, R. (2009). Plug-and-play for medical devices:
experiences from a case study. Biomedical Instrumentation & Technology, 43(4), 313–317.
https://doi.org/10.2345/0899-8205-43.4.313
Grissinger, M. (2009). A Patient’s Wandering Eye and the Internet Can Lead to Pump Tampering. Pharmacy and
Therapeutics, 34(6), 283–328.
Kramer, D. B., Ransford, B., Molina-Markham, A., Stewart, Q., Fu, K., Baker, M. C., & Reynolds, M. R. (2012).
Security and Privacy Qualities of Medical Devices: An Analysis of FDA Postmarket Surveillance. Retrieved from
https://dash.harvard.edu/handle/1/10445585
Newman, L. H. (2017, March 2). Medical Devices Are the Next Security Nightmare. Retrieved March 10, 2017,
from https://www.wired.com/2017/03/medical-devices-next-security-nightmare/
Thimbleby, H. (2017). Cybersecurity Problems in a Typical Hospital (and Probably in All of Them). In Safety-critical
Systems Symposium. Bristol, UK: Safety-critical Systems Club. Retrieved from
http://harold.thimbleby.net/cv/files/SSS17%20cybersecurity.pdf
Zetter, K. (2016, March 30). Why Hospitals Are the Perfect Targets for Ransomware. Retrieved March 10, 2017,
from https://www.wired.com/2016/03/ransomware-why-hospitals-are-the-perfect-targets/