Medical Devices for Today’s Health Care: Report from Boston Summit

MRI machines taking commands from Russian botnets…developers withholding device data from researchers within their own company…those are just a couple spectacular symptoms of what ails medical devices, stories aired on April 23 at Boston’s Medical Device & IoT Summit. As I listened to the devices’ risks and challenges, I wondered if the industry could rise to the demands of today’s networked, data-driven environments.

My challenge might seem odd given the ubiquity and importance of medical devices. Spending on them was 172 billion dollars in 2013 in just the US (see page 5 of the PDF) and perhaps 390 billion dollars worldwide in 2016. A single manufacturer in Boston earned 2.56 billion dollars in 2018, an increase of 17 percent, and the industry globally continues to grow, albeit spottily.

But let me pull myself away from my search engine to explain what keeps medical devices from cohering into a robust industry. I had the opportunity to sit in on several talks at this new summit, joining 65 attendees and half a dozen vendors hawking WiFi modules and security solutions. The team that built this conference, led by consultant Tim Gee, based their work on earlier conferences of a similar nature, which I have also reported on.

If this article comes across as negative, it is simply reflecting the impressions left by the speakers at the summit, who were overwhelmingly alarmed by the failure of medical devices to live up to their potential. That doesn’t mean that they’re bad or that development is not worth the cost. Devices are getting better all the time, and saving lives–but they are not participating fully enough in health care systems in ways that can generate useful data, do more for patients, relieve burdens on caregivers, and save money, all while ensuring privacy and security.

These are what I think manufacturers and users need to do:

  • Collaborate intensively with users over their activities, workflows, and environments so that products meet real needs.

  • Promote interoperability and other robust practices through industry associations. These associations need especially to evaluate standards (of which many exist) to determine which will enable data sharing and interoperability. They also need to develop and enforce new standards, as industry associations do in other domains, to prevent the proliferation of incompatible readings and increase robustness.

  • Apply practices from the ISO 9001 series of standards routinely used by manufacturers in other industries.

  • Apply known security practices from the computer and networking fields. If devices cannot support the software that most computers run for security purposes, or encrypt data to protect it when communicating with other systems, they must be connected to hubs that use these security practices to protect them.

  • Test security fixes and other software updates thoroughly, relieving the clients at hospitals and clinics of the risks of updates.

Underlying all these goals, perhaps, is a more agile and open concept of medical devices. I will return to that concept at the end of the article.

Context matters more than ever

What stood out at this year’s conference as new, for me, was the addition of “IoT” to the summit’s title. This addition struck me as simply a way to catch up with the reality of how devices have operated in health care settings for many years.

Speaker Stephen L. Grimes summarized the reasons devices are turning up more and more problems with complexity and security. They are depending more and more on functions performed by software, joining networks (and therefore subjecting themselves to unanticipated forms of attack), and processing more data.

The industry is caught in a dilemma: despite their incompatibilities, the devices are based on a plethora of commodity software ranging from operating systems (usually old versions of Windows) to wireless connectivity through Bluetooth and WiFi.

On the one hand, it makes perfect sense to build on common software. They’re commoditized, making them cheap and well-tested. Developer and user expertise is easy to find. One really wouldn’t want devices to eschew common software components. But using them also opens the devices to common attacks, whether the botnets running MRI machines or a casual visitor with a laptop breaking into devices over a clinic’s WiFi network.

Some vulnerabilities can be ameliorated by network architecture, according to developer Seth Jeacopello. He pointed out that network segments (sets of nodes that trust each other) are often defined on organizational boundaries, such as a ward or clinic. Thus, patient records may be on the same network segment as insecure devices, and an intruder getting into one can easily get into the other. Jeacopello suggested defining segments on the basis of the types of devices or software systems they connect.

The computer industry also has means to secure devices that cannot host security software (“agents”), either because their computing capabilities are too small or they were designed some time ago without adequate consideration for security. At the summit, Misha Seltzer described the monitoring solution provided by his company, Armis. They are agentless, running on hubs outside the devices. They not only check for suspicious traffic, but discover and classify devices by the type of traffic they operate on or generate. This helps IT staff track the many devices–sometimes thousands in a single hospital–that otherwise could be open to many security risks.

Although security turned up repeatedly at this summit, along with patient privacy, there are many other aspects to context. Despite years of haranguing from user advocates and product designers (including entire conferences on user experience and collaborative design), most devices are still created without a firm understanding of user needs and workflows. As a simple example, a device might record a pulse but cannot record whether the person was sitting, standing, running, etc. More significantly, the devices may require staff to step outside of their familiar workflows, leading to inefficiency and risk of errors.

Robert Havasy warned the audience about devices that fail to meet real needs and urged us to think about the environment in which they are expected to run. A device that warns a user she’s in danger of a fall, if there’s nothing she can do to prevent it, is like a genetic test that tells you of a risk for an incurable disease. In both cases, we can spend our money better. Another recent example of out-of-step technology comes from a company that developed a way for pills to send messages to the health care institution when ingested, and that wants to prescribe those pills to paranoid schizophrenics to make sure they take their medicine.

Throwing away data

Hardly any reference to analytics came up during the sessions I attended. Apparently, the field is rarely exploiting the tremendous potential for data analysis that so many other industries are reaping. This is a shame, because devices are generating unprecedented amounts of raw data, as pointed out in an interview I held with device developer Shahid Shah many years ago. Of course, all data must be cleaned and vetted, but there are established practices in data science to do this. So why are we throwing the data away?

First, device manufacturers make it hard to share data. This came through strong and clear in Gee’s opening remarks, where he lamented the refusal of the manufacturers to work together (much less work with users) to adopt existing standards. They can’t even agree what to call the vital signs and metrics they collect. The situation is so bad in terminology that someone has cobbled together a taxonomy called the Rosetta Terminology Mapping.

Second, the potential industry for handling data is fragmented, with devices in one set of companies and electronic health records in another set. A perennial complaint in health IT is that EHRs are organized around billing instead of treatment. Consultant Bridget A. Moorman pointed out that even more than billing, EHRs exist for the purposes of legal protection. And in this context, as suggested by speaker Pedro Arboleda, storing a lot of data is dangerous. If a clinician doesn’t have the analytical tools to process the data, she may miss something that can be used later in a lawsuit against her. We face a chicken-and-egg problem: without collecting and sharing data, we can’t demonstrate the value of analytical tools, but without analytical tools no one wants to collect and share data.

Moorman made another point: the default assumption that all data be stored in the EHR is arbitrary. This assumption is widespread among U.S. health researchers (although I know several data-driven analytics firms bucking the trend) and is less common in Europe. Relying on the current crop of EHRs as a single source of truth is crippling, because they are ill-designed for the kinds of advanced analytics we need, and we are held hostage to their legacy weaknesses.

I saw this achievement gap during a recent check-up. The technician used an impressive little machine that takes three vital signs, such as blood pressure and pulse, simultaneously. But then the technician wrote the results on a slip of paper, walked over to a computer, and typed in the data. Not only does this waste time, but it creates two additional chances of error and a paper trail that could undermine privacy.

Finally, we have to deal with the tired old problems of data hoarding and fears of violating HIPAA. A few years ago, HHS and others raised the specter of “information blocking,” and although one could find plenty of reasons to trace blocking as the unfortunate side effect of bureaucratic industry practices, there is also evidence that sometimes blocking is deliberate.

Regulatory reform

We have seen what can happen when regulation of mission-critical systems is lax–most recently through airplane crashes. Medical devices need regulation like any other system on which life and health depend. Most devices fall under Class II under FDA regulation, and therefore require a rigorous certification process. The vendors are unable to square the certification requirements with a robust process for installing updates–even a patch for a security bug in the operating system. The fears behind this restriction are borne out by experience: Grimes reported that systems could be brought down by a bug fix that wasn’t tested for the environment in which the devices ran.

The FDA is now softening its certification requirements in specific areas where it feels there is justification for doing so, as well as–this is critical–alternative ways to demonstrate quality. One such innovation is for breakthrough devices, which can use an alternative path to certification because of their value to treatment. Even more important, the FDA is starting to accept the exploding importance of software in the medical industry through its definition of Software as a Medical Device (SaMD). Although the definition applies only to software running on general-purpose devices (such as cell phone apps), I expect the FDA to take insights from this experimental program into the general device market.

Better silos or flatter companies?

Listening to the lapses of device and EHR vendors, I could see why Apple, Google, and other big-muscled players in the computer field are jumping into health care. They have used standards and data so productively in other areas–surely they can shatter some of the barriers in our field.

Yet I hope for a better solution than bigger silos. I think that both EHRs and medical devices could be broken into layers and commoditized–particularly with the help of free and open source software, whose value I have championed before. If software is the direction that the world is traveling in, let medical devices and EHRs be more like software: open, cheap, modular, commoditized, containerized, extendible. Standardized data streams would be a key part of the environment.

How could this come about? Each device must be sufficiently well-defined and limited in function to be verified as safe and effective. But in a networked health care system, we have to let go of the idea of a self-contained, stand-alone item. Perhaps we can find a way to treat safety and effectiveness more holistically.

About the author

Andy Oram

Andy Oram

Andy Oram writes and edits documents about many aspects of computing, ranging in size from blog postings to full-length books. Topics cover a wide range of computer technologies: data science and machine learning, programming languages, Web performance, Internet of Things, databases, free and open source software, and more. My editorial output at O'Reilly Media included the first books ever published commercially in the United States on Linux, the 2001 title Peer-to-Peer (frequently cited in connection with those technologies), and the 2007 title Beautiful Code. He is a regular correspondent on health IT and health policy for He also contributes to other publications about policy issues related to the Internet and about trends affecting technical innovation and its effects on society. Print publications where his work has appeared include The Economist, Communications of the ACM, Copyright World, the Journal of Information Technology & Politics, Vanguardia Dossier, and Internet Law and Business.