A 2013 report from the American Health Association states that there are approximately 359,400 emergency medical services (EMS)-assessed cardiac arrests outside of a hospital setting each year. The same report confirms that “immediate cardiopulmonary resuscitation (CPR) and early defibrillation, with an automated external defibrillator (AED), can more than double a victim’s chance of survival.”¹ AEDs have become an invaluable medical device, and it’s their design that ensures they operate as reliably and safely as possible.

AEDs can be thought of as an electrocardiogram (ECG), or multi-parameter patient monitor, that also provides life-saving therapy. ECGs monitor heart signals via electrodes connected to specific locations on the human body. These signals, on the order of a few millivolts in amplitude, are difficult to discern against a noisy background, but are used to accurately determine a person’s QRS complex.

The QRS complex is what’s commonly used by healthcare providers to diagnose a wide range of heart conditions, such as arrhythmias or even atrial or ventricular fibrillation. The AED uses the same QRS complex to make the decision to provide therapy, or the shock to restart or resynchronize the heart. So there’s much more to the AED than meets the chest.

AED Architecture
Reliability, accuracy, extremely fast boot times, power management, and security are just some of the key considerations for AEDs. AEDs, which are used in situations to sustain life, are certainly considered safety critical. Systems such as these need a processing core (or cores) with an associated operating system (OS) that is powerful enough to acquire, process, and interpret several parameters at once, while also providing a friendly, straightforward, and safe human-to-machine interface (HMI).

Breaking down the overall architecture of typical clinical-grade AEDs, a simplified system block diagram generally looks something like the figure below.

Key considerations for the design are:

• Reliability & safety
• Accuracy
• Extremely fast boot times
• Outstanding power management
• Communication flexibility (wired and wireless)
• Security
• Rich and easy-to-use HMI

These design considerations drive the thought process for processor and software choices. With that in mind, the single most important objective is to seek out a supplier with a strong board-support package (BSP) and proper pedigree, such as IEC-62304, for the application.

In the recent past, medical device design engineers would usually decide on the target processor first, then build their hardware design around that. More recently however, many companies are collocating hardware and software designers, where as a team they consider a design platform composed of both the hardware and software. Today, savvy design organizations and leaders understand the critical relationship between the processor selected and the software that will be run on it, which is directly tied to the resources and energy required during the product development phase. This approach positively impacts the time-to-revenue for the medical device manufacturer. It is wise to start by selecting a hardware and software reference platform that comes complete with a board support package (BSP) inclusive of an application-appropriate operating system and the necessary drivers to complete the work. Beginning in this way, design organizations can focus their energy on their intellectual property (IP) – their application – rather than becoming an operating system or software company themselves.

The complete solution is also about the peripherals. Your need for connectivity just might affect your overall partner decision. Consider not only the hardware connectivity modules available, but the software plug-ins as well. How critical the decision depends on the medical device manufacturers’ tolerance for invention beyond their own value proposition, beyond developing their own IP. Look for a supplier that has Bluetooth stacks that are IEEE-11073 compliant, Wi-Fi software modules that are plug-and-play capable, and cellular expertise (if your application is ambulatory). The proper selection of BSP, with peripheral consideration, will positively impact the medical device manufacturer’s time-to-revenue and return on investment.

With all this connectivity, cybersecurity is paramount. If you’re considering selling into the U.S. government, such as the Department of Veterans Affairs (VA) hospital system, then FIPS 140-2 levels of security are required. On the consumer segment side of the market, there’s a far lower likelihood that lower-end equipment will house patient data. The need to lock down a consumer AED is primarily based on the need to prevent tampering with the software that delivers therapy. In either case, it’s wise to choose partners with a strong pedigree in security offerings.

In addition, seeking partners with a focus on security will provide you with a lower total cost of ownership and get you to market more quickly and with less risk.

References
¹https://www.heart.org/idc/groups/heart-public/@wcm/@adv/documents/downloadable/ucm_301646.pdf

Also read:

• The Fox and the Hedgehog – Patryk Fournier, Medical Marketing Communications Manager, QNX Software Systems
• Smart Devices Demand Smart Decisions – Steven Dean, Global Healthcare Segment Manager, QNX Software Systems
• When Smaller Is Better: Cybersecurity for Medical Devices – Steven Dean, Global Healthcare Segment Manager, QNX Software Systems
• The High Cost of Free Operating Systems – Steven Dean, Global Healthcare Segment Manager, QNX Software Systems
• How to Care for Medical Devices When They Have Left the Nest – Patryk Fournier, Medical Marketing Communications Manager, QNX Software Systems