By Zhihao Jiang and Rahul Mangharam, University of Pennsylvania
From 1990 to 2000, manufacturers recalled more than 600,000 cardiac medical devices. About 200,000 of those recalls were due to software problems.
With a typical pacemaker containing 80,000 to 100,000 lines of code, it is difficult for manufacturers to identify software errors using current industry practices. These practices rely on open-loop testing in which testers feed prerecorded heart signals to the pacemaker and evaluate the corresponding output. Open-loop testing can reveal how the pacemaker responds to various heart conditions, but not how the heart responds to the pacemaker in a closed-loop system. This is especially important in conditions such as pacemaker-mediated tachycardia, where the pacemaker can drive the heart into unsafe states.
At the University of Pennsylvania's Department of Electrical and Systems Engineering, our team has developed a first-of-its-kind electrophysiological model of the heart that enables real-time closed-loop testing of pacemakers. Developed with MATLAB® and Simulink®, this heart-on-a-chip system can be configured to match a patient’s specific electrophysiological characteristics, and it can simulate a variety of heart conditions to enable early verification of pacemaker software.
From one engineering perspective, the heart is a mechanical pump that circulates blood throughout the body. From the perspective of a pacemaker, it is a real-time system requiring precise timing of electrical signals.
The cardiac conduction system is a network of nodes and pathways carrying electrical signals that cause the chambers in the heart to contract and relax (Figure 1). In a healthy heart, contractions happen in rhythm. Disruptions in the cardiac conduction system can cause fast heartbeats—including atrial flutter and fibrillation—as well as slow heartbeats, known as bradycardia.
Pacemakers are fitted with electrodes that sense the heart’s electrical activity. When the pacemaker software detects an abnormal heart rhythm, it sends precisely timed electrical pulses to one or more of the heart’s chambers. The heart and pacemaker form a closed-loop system in which changes in the heart’s behavior lead to changes in pacemaker activity, and vice versa.
To better understand how electrical signals work in the heart, we sat in on heart surgery operations at the Hospital of the University of Pennsylvania (Penn). During these operations, physicians in the electrophysiology department direct an electrical current into the heart via a catheter. They then monitor the electrical behavior of the heart and measure conductivity along pathways.
We created an initial electrophysiological model of the heart in MATLAB. We chose MATLAB for several reasons. First, we needed to conduct extensive design exploration in the early stages of development, and MATLAB is an excellent environment for trying out new ideas. Second, most of our graduate students are already experienced MATLAB users, so they can contribute to the project immediately, without having to learn new software. Third, MATLAB and Simulink support code generation for FPGAs and embedded systems, which we needed for real-time testing.
After simulating and refining the MATLAB heart model, we created a Simulink and Stateflow® version. This model gave us a visual representation of the nodes and pathways in the heart, and enabled much faster simulations than the MATLAB version. The Simulink and Stateflow model comprises approximately 30 nodes and 30 pathway submodels, which we developed as Stateflow charts. The node automaton submodel comprises three states corresponding to a rest state and two active states, the effective refractory period (ERP) and the relative refractory period (RRP) (Figure 2).
The path automaton is more complex, comprising five states that describe the conduction of the path: ante (forward conduction), idle (no conduction), retro (backward conduction), double (conduction in both directions), and conflict. Several arrhythmias in the heart model were validated by the Director of Cardiac Electro-Physiology at the Philadelphia VA hospital.
Before modeling the pacemaker in Simulink and Stateflow, we built a timed automata model specifically for formal verification using the UPPAAL modeling environment, which was developed jointly by Aalborg University in Denmark and Uppsala University in Sweden. Based on a specification provided by a pacemaker manufacturer, this model enabled us to explore the design space and prove that specific properties of the design met the requirements. A more conventional approach would have been to start with the Simulink and Stateflow model and then perform the formal verification using Simulink Design Verifier™. We plan to use Simulink Design Verifier for formal verification of the timing of events and for the run-time and safety properties of the design.
We used UPP2SF, a model translation tool developed at Penn, to automatically convert our timed-automata-based models in UPPAAL into a Simulink and Stateflow model for simulation and testing (Figure 3).
With Simulink and Stateflow versions of the heart model and pacemaker model completed, we conducted closed-loop simulations to verify pacemaker behavior. For example, we simulated several closed-loop scenarios, including pacemaker-mediated tachycardia and atrial flutter; scenarios that our formal verification analysis highlighted as potentially problematic; and failure conditions, such as a displaced pacemaker lead. We also used simulation to compare and evaluate different versions of the pacemaker algorithms.
Testing actual pacemakers—not just models—is one of our principal objectives. To achieve this goal, we needed to implement our heart model on real-time hardware. We used HDL Coder™ to generate VHDL® code from the Simulink and Stateflow model, enabling us to deploy the heart-on-a-chip on an Altera® FPGA (Figure 4). The generated code was so efficient that we were able to implement multiple versions of the heart model on a single low-end FPGA.
For our first real-time tests, we built a simplified pacemaker by generating C code from our Simulink and Stateflow pacemaker model with Embedded Coder® and deploying it to an Atmel® embedded microcontroller. Following the success of those tests, we conducted closed-loop tests using the FPGA heart-on-a-chip and production pacemakers.
The Heart-on-a-Chip platform won First Prize in the 2012 World Embedded Systems Competition (High-Tech Medical Service), in Seoul, Korea.
Our heart model is highly configurable, and can account for variations in electrophysiological conductivity across patients. At first, we made configuration changes directly in the Simulink model. To simplify this step for our team and other researchers, we developed the Penn Virtual Heart Model Simulator, an interface built with MATLAB that lets users specify a topology for a new heart model and then automatically configure the model based on the requested topology and configuration parameters (Figure 5).
Behind the scenes, the Penn Virtual Heart Model Simulator uses a MATLAB script to generate a Simulink and Stateflow model based on the requested topology and configuration parameters.
We are working with the U.S. Food and Drug Administration and pacemaker manufacturers to establish a framework and guidelines for using our heart model for early verification of pacemaker software. We plan to develop a system that automatically translates a patient’s electrophysiology test results into a customized model with parameters optimized for that patient’s heart.
Our work on the heart model complements a related project in which Penn researchers developed generic infusion pump models and reference specifications that are used to verify safety properties in medical infusion pumps. Both projects aim to provide realistic models of biological systems to enable improved testing of medical equipment. We plan to continue advances in this area by developing Simulink models of human systems that interact with a range of medical devices, including analgesic pumps and blood glucose and insulin monitoring systems. By enabling early verification of software as well as real-time, closed-loop testing, these models will make it easier for medical device manufacturers to improve the quality of their software and reduce the number of device recalls.
Published 2013 - 92119v00