For Medical Device Design on the IoT, Get a Solid Head Start

Their value for patient care and the efficiency they create for medical personnel has medical devices proliferating rapidly on the Internet. This brings along heavy responsibilities for accuracy, reliability, and meeting certification standards. Due to the wide range of specific needs among patients and the devices used to care for them, medical device developers should start with a powerful and rich set of tools based on a platform that offers the team a solid starting point to implement the power-saving, processing, and security features.

The development of intelligent medical devices has always been a challenge. Adding to the familiar pressures of cost, time to market, size, weight and power (SWaP) optimization, safety, security and providing the proper feature mix, there is also the challenge of certification by agencies of multiple countries. These certifications also involve different levels of stringency depending on their possible risk. Still, hospitals and medical facilities have long relied on medical electronics in the clinic and operating room and a great deal of experience has been gained in their development.

Medical, industrial, and consumer devices all increasingly connect via the Internet, making them part of a world that can seem like the Wild West. Medical devices which are part of the IoT can shorten hospital stays and enable elderly patients to live at home longer, thus driving down the costs of medical care. For more active patients the IoT’s medical “things” can also be a huge advantage with their ability to directly sense and interpret vital bodily functions and signal alerts when needed as well as connect via the cloud to physicians and specialists for more regular monitoring and emergency attention. In athletics, they can help prevent serious injury by sensing possible concussions along with other signs that could indicate a player should receive immediate attention (Figure 2).

Figure 1:  Medical IoT devices must communicate securely over one of a variety of wireless network protocols, eventually connecting to the Internet using an IP stack and ultimately to a cloud service—in this case, Microsoft Azure. And they must maintain security along the whole path. Source: Microsoft, Inc.

Among the additional challenges for wearable medical devices are even more demanding size and low-power requirements, implementing the appropriate wireless communication technology and perhaps most important—security. The latter is needed both to comply with existing regulations such as HIPPA as well as to protect the devices against hacking. Hackers could exploit access to devices to find their way into larger systems to steal and exploit data. And as gruesome as it may sound, there is also good reason to protect devices such as pacemakers from attack. The advantage to having a pacemaker connected wirelessly is to be able to make adjustments and software upgrades without surgery. But that also exposes it to possible malicious attack.

Start with a Solid Platform
Fortunately, developers do not have to start from scratch, and wearable medical devices, while addressing very specialized needs and functions, do have many things in common. If developers are able to start from a point from which they can directly address their shared challenges, they can add innovation—and value. Early in the process they can quickly get started meeting those often intricate specific needs for a successful medical device project. That boils down to the concept of a “platform”—a combination of basic software and hardware that lets developers get right to adding their specific value and innovation. Of course, such a platform must offer hardware and software components, which, while shared among medical projects, still focus on the common needs of medical devices. Its aim is to provide selected components that can offer a broad set of features for medical devices without making developers search through a complex set of unnecessary components. They should be able to quickly find and evaluate those most suited to their development goals.

Among the options in such a platform should be a choice of wireless connectivity. If a device is to be worn by a patient in a hospital setting, the link should be to the hospital’s network, possibly via Wi-Fi. If the device is to be worn by a patient during normal daily activities, then a Bluetooth link to the patient’s smartphone might be more appropriate. For sporting events, such as a marathon that covers extended areas, a wider-ranging choice might be LoRa. While devices can connect directly to the Internet, the more usual approach is to connect to a gateway device using one of the wireless protocols. The gateway then sends the data over the Internet to cloud services using Internet protocols such as Transport Layer Security (TLS), which also offers methods of securing communications beyond the gateway.

The gateway or edge device can be a specialized design or a PC in the home running the needed applications and connected to the Internet. One important design consideration is how and where to make decisions that are necessary to the patient’s well-being. For example, a fall or a blow to the body should invoke an instant response alerting the proper remote service professionals to deal with it. In other cases, the gateway can simply forward data to a cloud application where it is analyzed. Anomalous or out-of-range results can then alert a physician who can determine what steps to take. Yet again, code on the device could provide the ability to recognize the need to dispense medication, possibly via a module worn on the body. Decisions such as these will influence the allocation of resources including memory, power consumption, and processing capability and where in the device/gateway/cloud chain they are implemented. So, in addition to a rich selection of specialized peripherals and their support, the developer must select a processor, an operating system, power management functions, location and motion sensing, body sensors, security support, and a choice of wireless communication hardware and protocols.


Figure 2: For a device like a concussion monitor, sensors, drivers, and a certain amount of processing, security and communication capability must be built in to concentrate on a very specific set of issues both to detect the concussion and to relay information as to its possible effects.

The issue of the human interface is also one that must be thoughtfully developed. There is little room for a rich human machine interface (HMI) on the device itself but important functions can be placed on a small display on a smart watch, for example. When—and only when—practical, a richer set can also often be implemented on a smartphone. The gateway device is often the major host for the HMI because it can be quickly accessed by the patient or remotely by the physician either directly over the Internet or from applications in the cloud. Of course, other control and analysis applications running in the cloud can utilize the device HMI as well as other application-based user interfaces.

and Security is a Must
As mentioned above, devices must be able to negotiate secure connections that not only protect data, but also guard against hacking and malicious access. One should quite naturally expect security support in the form of security-critical software components such as secure mail or secure SMTP along with secure web pages or HTTPS for implementing layered security strategies plus TLLS as noted earlier. Secure management—SNMP v3—can be used to secure both authentication and transmission of data between the management station and the SNMP agent along with an encrypted file system.

Given the different protocols used in connecting medical IoT devices from the patient over a wireless network to edge/gateway device and then via the Internet up to the cloud services, it is vital that security be assured end-to-end over the whole route. This must ensure that data and control codes can be authenticated as passing between a sender and receiver that have both verified their identities. It means that the messages must be undistorted and uncorrupted either by communication glitches or by malicious intent. And communications must remain secure and private, which also involves encryption and decryption.

Encrypted messages passing through the gateway from wireless protocol to the Internet will utilize a standard Internet protocol like TLS, which uses a securely stored private key with a public key to generate a unique encryption key for a given session. For both message integrity and privacy, it is important that the content as well as the private key remain secure. TLS forms the basis for HTTPS for implementing layered security strategies. Secure management—SNMP v3—can be used to secure both authentication and transmission of data between the management station and the SNMP agent along with an encrypted file system. Additional protocols for graphics functionality along with camera and video support set the developer up with a rich selection of options for the entire range of possible medical applications.

Another thing that is often missed is the memory model used by the underlying operating system. Today, many RTOSs are modeled on Linux, which supports dynamic loading where the code can be loaded into RAM and then run under control and protection of the operating system. However, that protection can sometimes be breached, and so a dynamic loading memory model involves definite dangers when used in critical embedded systems like medical devices.

Another model executes code from Flash memory. In order for code to be loaded in so that it can execute, it must be placed in Flash. Loading malicious code is much more difficult than just putting it into RAM. Flash-based code is a single linked image so that when it executes, it just executes from that image. There is no swapping of code in and out from RAM. RAM is of course used for temporary storage of variables and stacks such as used for context switching, but all instructions execute from Flash.

Even if an attacker could breach the security used for program updates, they could not load a program into device memory to be executed even under control of the OS because the code must be executed from Flash. The only way to modify that Flash image is to upload an entirely new image, presumably one that includes the malware along with the regular application code. That means a hacker would need a copy of the entire Flash-based application in order to modify and upload it. Such a scenario is extremely unlikely.

Figure 3: Rowebots, Ltd. supplies a selection of prototyping platforms consisting of RTOS, communications components, and supported peripheral (including sensor) drivers. There is also a selection of processor boards such as the STM32F4 (l) and STM32F7 (r) boards from STMicroelectronics.

These days, idea of a “development platform” is widespread and well accepted. Nobody wants to start from scratch nor do they need to. Developers may already have a fairly clear idea of the class of processor and mix of peripherals they will need for a given project and will look for a stable and versatile platform consisting of a choice of supported MCUs and hardware devices along with an RTOS environment tailored for very small systems along with a host of supported drivers, software modules and protocols. Finding a platform that has a range of features and supported elements that is close to a project’s goals can go a long way toward shortening time to market and verifying the proof-of-concept before making that potentially expensive commitment to a specific design. The key is to have those goals firmly in mind and then look for the platform that best meets them. Fortunately, today, many semiconductor manufacturers as well as RTOS vendors are collaborating to offer such platforms, some of which are targeted to specific markets and application areas (Figure 3).

On the other end, it is also wise to tailor the project for cloud connectivity out of the box. Among the available services are Microsoft Azure IoT Hub, AWS IoT, and IBM Watson IoT. Such services let developers build, deploy, and manage applications and services through a global network of Microsoft-managed data centers. Microsoft Azure, for example, provides a ready-made cloud environment and connectivity for IoT devices to communicate their data, be monitored, and receive commands from authorized personnel.

Kim Rowe has started several embedded systems and Internet companies including RoweBots Limited. He has over 30 years’ experience in embedded systems development and management. With an MBA and MEng, Rowe has published and presented more than 50 papers and articles on both technical and management aspects of embedded and connected systems.

Share and Enjoy:
  • Digg
  • Sphinn
  • Facebook
  • Mixx
  • Google


Extension Media websites place cookies on your device to give you the best user experience. By using our websites, you agree to placement of these cookies and to our Privacy Policy. Please click here to accept.