Features

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.

« Start Prev 1 2 Next End»