Small, intelligent medical devices worn on the body and/or kept in the home — in addition to those used in hospital networks — are not just saving lives. They are shortening hospital stays and enabling elderly patients to live at home longer, thus driving down the costs of medical care. By directly sensing and interpreting vital bodily functions, these devices can signal alerts when needed as well as connect via the cloud to physicians and specialists for more regular monitoring and emergency attention.

Medical OEMs developing these devices face multiple challenges that include the familiar pressures of cost, time to market, size, weight and power (SWaP) optimization, safety, security, and providing the proper mix of features. They also must confront hurdles for certification, often by multiple countries and different levels of certification. While the specific functional requirements for medical OEM devices may vary widely, they also share some common characteristics.

Starting Point

Meeting the many specific demands and requirements can be greatly aided if developers are able to start at a point from which they can directly address their shared challenges. Such a point should also offer a way forward toward 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.

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. One of the major areas is home healthcare, which involves a device worn on the body that communicates with a smartphone carried by the patient and/or a PC-based or specialized gateway server in the home. This system is then connected to the Internet and ultimately to cloud services. However, developers may also encounter other scenarios such as a device worn outside the home with the wearer living a normal life, but which must monitor vital data and alert as needed. Devices used for different sporting events might have different communication needs depending on the given scenario (see Figure 1).

Fig. 1 - This concussion monitoring system developed by Rowebots has a specialized application that can still be used in very different situations. Here, the device used on a playing field will work very well with Bluetooth LE. In a different scenario, such as a marathon, a different wireless technology, such as LoRa, might be more effective.

The goal is to allow the patient maximum freedom while constantly attending to specific medical signs with the ability to alert at different levels, for example, when it is time to take a medication. At other levels, an alert would go to a medical professional site for routine monitoring or in some cases for more immediate action. This requires the ability to analyze and handle (store and/or transfer) data appropriately. In some cases, the analysis would result in an immediate alarm with an alert to the remote service. In others, it would simply involve storing data and transmitting it to other systems (gateway or cloud) as appropriate. One other option could provide the ability to store and dispense medications of various types.

Another aspect of home healthcare involves monitoring motion and location. For example, an accelerometer can signal if an elderly patient has taken a fall and either has or has not gotten up. If a patient gets up at night to use the bathroom, has he or she returned to bed? Has he or she eaten or taken medications? If an alert is sent, where is the patient's location to send help?

So, in addition to a rich selection of specialized peripherals and their support, the developer needs to 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 — a pretty tall order.

Support for Sensors and Peripherals

Given the size and power restrictions, a wearable medical device cannot be a multipurpose “utility knife” type system, but rather must focus on doing one or two things well and efficiently. However, that focused set of capabilities can vary widely and so it is important that a goodly selection of sensors be available to match the intended specific purpose of a device. Among the kinds of peripherals that should find support are temperature sensors and pressure sensors, gyroscopes and accelerometers for detecting motion such as falls, pulse oximeters, and light sensors.

Backing these up with source code drivers that can be compiled and quickly integrated into the real-time operating system (RTOS) for the selected processor can greatly speed development. A large number of such available peripherals and sensors use an I2C or SPI interface that fits with those supplied on a growing number of CPUs and MCUs for straightforward integration into a working system.

In addition to sensors, support is also essential for such peripherals as HMI interfaces, limited though these may be on the actual wearable device. Additional protocols for graphics along with camera and video set the developer up with a rich selection of options for the entire range of possible medical applications.

A selection of wireless communication options such as Bluetooth LE, 6LoWPAN, LoRa, and others is also needed. This should include support for a selection of appropriate hardware radio devices as well as the associated communication protocols. In addition, there should be support for the power management features built into the supported processors as well as for certain power-related peripherals such as battery chargers and/or fuel gauges.

Security Is a Must

Fig. 2 - Security must not only be built into the device, it must also be able to work with Internet security protocols to ensure security from sensor to cloud.

Perhaps one of the most demanding aspects of medical device design and one that requires detailed attention from developers is security. It is hard to sufficiently emphasize the importance of security in the medical device arena. There are, of course, federal regulations such as HIPAA that mandate patient privacy. In addition, these devices may end up being used in a variety of network environments from home-based Internet connections communicating with cloud servers and ultimately to doctors and specialists to connection inside various hospital wireless networks. Devices must be able to negotiate secure connections that not only protect data, but also guard against hacking and malicious access. As horrid as it may sound, there is even a definite need to protect pacemakers against hacking. And of course, security must be maintained across different communication levels from sensor to cloud (see Figure 2).

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. 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.

As important as such security support is, however, there is one crucial aspect that is often missed and that involves the actual internal design of an RTOS and the way it manages memory. A potential hazard for sensitive medical devices is connected to the fact that many RTOSs feature POSIX compatibility with Linux, especially in terms of their API. This, of course, has the advantage that many developers are familiar with it and a large amount of existing code, including open source, can be acquired and adapted for use in embedded applications.

The other thing that usually comes along with POSIX/Linux compatibility, however, is its memory management, which supports dynamic loading where the code can be loaded into RAM and then run under control of the operating system. Linux relies on protection of the OS to make sure that user programs cannot gain control of which programs are to be run. How-ever, that protection can sometimes be breached, and so dynamic loading involves definite dangers when used in critical embedded systems like medical devices.

Many RTOS implementations can also be breached because they are large and complex, and it only takes one small security hole to get privileged access or access to physical memory and bypass the entire security mechanism. Since the malware code must executed from the target device, it must therefore be loaded into that device's memory.

Using a different memory model can offer a much higher grade of security for embedded connected devices. In such a model, all code executes from Flash memory so in order for code to be loaded in so that it can execute, it must also be placed in Flash, which is much more difficult than 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 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.

Prototyping platforms consist of RTOS, communications components, and supported peripheral (including sensors) drivers. Also shown a selection of processor boards such as the STM32F4 (l) and STM32F7 (r) boards from STMicroelectronics.

This means that no external program can be loaded into device memory to be executed even under control of the OS because the code must be executed from Flash and 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. Getting ahold of a copy of the Flash-based application in order to modify and upload it is extremely difficult if not impossible.

And the remote field upgrade feature should also be a program on the device that uses encryption. If the image to be loaded is encrypted, it can only be decrypted if it is signed with the proper key, which is owned by the owner of the code and the device and kept separately from the device. In other words, you can't get the decryption key by hacking the device. Code that isn't properly signed is simply thrown away. The upshot is that even if a hacker could breach the password/user name barrier, he will not be able to modify the code in the device in any useful way.

Start with a Solid Platform

Developing systems of this variety and complexity from scratch would, of course, be a thankless task. Developers should seek 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 and with a host of supported drivers, software modules, and protocols. Many vendors now offer board-level prototyping development kits that allow developers to verify proof-of-concept before making a potentially expensive commitment to a specific solution.

Due to the wide variety of medical devices and their support systems such as in-home gateways, cloud connectivity, and more, wide support for different processors and their families is important to support later product enhancement and expansion. Support for a standard API like POSIX makes it easier to bring in new team members as well as open source code. And the ability to start adding value from day one will go a long way toward a successful project.

This article was written by Kim Rowe, CEO of Rowebots, Ltd. Waterloo, ON, Canada. For more information, Click Here .