Harnessing emergent opportunities and challenges for medical embedded applications

Article By : Colin Walls

Demand for medical care and, hence, for all the equipment that enables the care to be delivered, has been rising exponentially in recent years...

Demand for medical care and, hence, for all the equipment that enables the care to be delivered, has been rising exponentially in recent years. This is all great news for the shareholders of medical instrument manufacturers and the embedded system developers employed by those companies. It is the challenges and opportunities enjoyed by this latter group that is the topic of this article.

It is fair to say that, at this time, many of us have medical systems on our minds. I, in particular, had my awareness raised recently, when I went to my ophthalmologist. Most people have sight checks every two years, but, as my late father was Type 1 diabetic and suffered glaucoma many years ago, a more frequent check on my eyes seems prudent. This is why I got to experience all the medical electronics. I was given a thumbs up – nothing to worry about with my eyes – which is always a relief, but, as I said, it left me pondering all the technology that was brought to bear.

There are two, somewhat related reasons for the rise in demand for medical care. Firstly, there are an increasing number of conditions that can now be treated effectively. In the past, it was much more common to be told that you would just have to live with the illness and suffer or you might be told that you were going to die. Of course, all of this still happens, but it is much more likely that some treatment will be offered. The second factor is the mean age of the population in most western countries is rising – we are living longer – and medical treatment requirements tend to increase with age.

Historically, medical instruments were bulky, heavy machines to which the patient was transported when necessary. A few machines could be wheeled about within the hospital, as needed. Those were the only options. Nowadays, the big focus is on portable instrumentation. Obviously, there are still some big static machines – a hand-held MRI scanner is not likely to appear in the near future! Why this change? The obvious answer is because we can: Modern electronics makes portable equipment more feasible than ever before. But the move is also driven by the same factor that governs most parts of our lives: money.

The key driver of medical instrument design is the financial model of modern healthcare. To understand the nuances, the differentiation between the contexts in which healthcare is delivered needs to be appreciated:

1. Proactive health – Preventative measures, like exercise equipment (which is not generally considered to be associated with healthcare, but it is), and, increasingly, remote health monitoring.
2. Home care – An extension of (1), where various forms of intervention and drug delivery may be involved.
3. Residential care – A nursing home etc. A cheaper place to be than a hospital, with some medically skilled personnel.
4. Acute care – A hospital, where the full range of care may be possible. Historically this may have been the first place that a patient was sent, but increasingly hospitals are reserved for when the other options have been exhausted.

Broadly speaking, the cost of healthcare delivery in each of these contexts increases from (1) to (4). So, there is very strong demand for devices that facilitate (1) and (2) in particular to help keep costs down (but also increases in efficiency in (3) and (4) are obviously welcome). Portable devices are strongly favored wherever they are technically feasible. This necessitates battery operation and often wireless networking of some kind. Not only are portable, wireless devices very convenient, it has been shown that eliminating cables in hospitals helps with cleaning and infection control.

It is interesting to consider a “typical” medical instrument in order to focus on the software challenges. A possible example might be a portable device that is carried by a patient and monitors their vital signs. Periodically, it sends the vital data to their doctor. It sounds an alarm and automatically summons help if something is awry. The patient can view their own readings at any time. It is possible to envisage such a device being used in all four healthcare contexts, with slight variations in its capabilities.

The key priorities in the design would be portability and cost, along with functionality, of course. The challenges/requirements presented to the software developer with this device are very broad:

• Efficient tools. The generated code must be optimally small and fast, and the tools should enable development to proceed smoothly.
• Real time capability. It is quite likely that a device will need to have real-time functionality. A real-time operating system is likely to be useful and small code size is a priority.
• Wireless networking. A portable device that needs to upload information requires wireless networking in some form. In a hospital, a short-range technology, like Bluetooth, might fit the bill. Bluetooth’s Low Energy variant also helps to conserve battery life. In other contexts, Wi-Fi may be the best choice, even though this is more power hungry. It is possible that cellular – 4G or 5G – might be required for an instrument to be highly portable – for use by paramedics, for example.
• User interface. Most devices have a graphical user interface in some form. The design of the UI on a medical device is critical and significantly dependent on who uses it. A device that is used by the patient needs a UI that is fairly simple and straightforward, with careful provision for avoidance of errors. Also, the possibility of the user having impaired vision must be accommodated. A device that will be used by a healthcare professional may have a more complex UI, as it is most likely providing more detailed information. However, the possibility that the user may be stressed or over-tired must not be overlooked.
• Power management. Battery life is a big challenge with any portable device. How long a charge needs to last depends on the usage pattern of the device, but typically a full waking day is the goal (say, 18 hours). Although hardware design contributes to power management, it essentially defines the best power consumption; the rest is down to software. Designing software with power consumption in mind is a big subject, but the key factors are:
  • Consider power from the start of the design process; it should not be an afterthought.
  • Analyze the use cases of the device carefully. Small adjustments can make a big difference to energy usage.
  • Use an RTOS with a power management framework. The OS is best placed to implement power management, leaving application code developers to focus on their job.
• Certification. Most medical devices need certification from the FDA etc. This can be an expensive and time-consuming process. Some points to bear in mind:
  • Choose an RTOS with a track record of being used in certified medical applications.
  • As source code for the entire application, including the OS, is needed for certification, it is essential that the RTOS source code is available and of high quality.
  • The cost of certification is significantly affected by code size. A small RTOS with fine-grain scalability is obviously a benefit.
  • If the device is implemented using a multicore SoC, a mixed criticality design strategy may be beneficial, as this results in the need to certify only the safety-critical sub-system.

With healthcare being seen as in crisis all over the world, the embedded software developer has the opportunity to be the “hero” and really change lives.

Subscribe to Newsletter