Heart on a Chip


Class EE Senior Design
Project Duration
8 months
Team Size 3 members

My Role
Electrophysiology Research
User Interviews
Circuit Prototyping
MATLAB UI Development
Presentation Design & Delivery

Awards
1st Place | $1000 Cash Prize
Senior Design Competition
University of Pennsylvania

1st Place | $1000 Cash Prize
World Embedded Software Contest
HighTech Medical Service Category
Seoul, Korea

Finalist - IEEE Presidents’ Change the World Competition

What is Heart on a Chip?

Heart on a Chip is an electrophysiological model of the human heart running on hardware as a testing platform for pacemakers. The goal is to reduce surgical recalls by allowing manufacturers and regulators to test the dynamic interactions between a pacemaker and an electronic heart before the pacemaker gets implanted to regulate a real heart.

Our team stands with the Dean of engineering as we win the $1000 first place cash prize in the University of Pennsylvania's interdepartmental Senior Design Competition. We went on to be finalists in the IEEE Change the World Competition, and won fir…

Our team stands with the Dean of engineering as we win the $1000 first place cash prize in the University of Pennsylvania's interdepartmental Senior Design Competition. We went on to be finalists in the IEEE Change the World Competition, and won first place in the HighTech Medical Service Category at the World Embedded Software contest in Seoul, Korea.


The Motivation

Patients have pacemakers surgically implanted when their hearts cannot maintain a normal heart rhythm. When working properly, pacemakers listen to the heart's signals and provide a jolt of electrical impulse to induce a beat when the heart does not keep a normal pace. Like any surgery, the implantation is lengthy, painful, risky. 

Between 1990 and 2000, over 200,000 pacemakers were recalled due to software errors.

The Problem: Testing is a One-Sided Conversation

Pacemakers are tested in an open-loop manner. This means that the pacemaker is given a signal and is expected to respond with an impulse. In reality, the heart and the pacemaker form a closed-loop system. This means that the heart's impulses, in turn, affect the pacemaker in a two-way conversation. This is where the problem arises.

Occasionally, the heart outputs a "premature ventricular contraction", which means that one beat occurs randomly out of sync with its normal rhythm. This is a safe occurrence. However, when the pacemaker detects this signal, it prematurely provides an impulse, which causes the heart to beat, and the pacemaker to again provide an impulse. As a result, the heart and pacemaker enter a closed-loop feedback cycle, causing an elevated and potentially fatal heart rate. This error is called pacemaker-induced endless loop tachycardia and has now been fixed in pacemakers. However, there may be other dormant errors that will likely surface.

 
 

The Solution: An Electronic Heart That Talks Back

The star of our testing platform is an electronic heart that models the electrophysiology of a real human heart. The electronic heart can mimic any number of heart arrhythmia via the manipulation of configurable conduction pathways and timing delays. We also developed a circuit such that the electronic heart and the pacemaker talk to each other in that same two-way conversation that happens after implantation. Finally, a top-layer UI displayed the ongoing conversation in a dashboard view, and conveyed an alarm state if an unsafe condition were occurring.


Our Target Users

Pacemaker manufacturers. Manufacturers suffer in both finances and reputation when a life-critical defect is found in their products. Introducing our product into their testing cycle can help find errors before a product reaches the public.

Regulators. There is currently no standardized way for third party entities such as the FDA to test the safety of pacemakers for public use due to the proprietary nature of the product.

Cardiologists. Imagine a cardiologist configuring our electronic heart to mimic the exact timing parameters of one of his/her patient's hearts. The doctor can ensure safe interactions between the pacemaker and the heart before any surgery is performed.


The Hardware

Our delightfully messy work-in-progress gives a glimpse of what went into the hardware portion of the project. The electronic heart was implemented on an FPGA board, shown in the bottom left corner. We also had to develop our own custom interfacing circuit (top left) that allowed the pacemaker and the electronic heart to understand each other.


The User Interface

I know, it needs a lot of love, but please do cut me some slack as I had zero exposure to UI design at the time :). Overall, the design takes on the form of a dashboard view of key information, with a control panel on the left. The key features are outlined below:

UI.JPG

 

Configurable arrhythmia

The user can select from a variety of preset arrhythmia, such as the Bradycardia option shown above. These presets come preprogrammed with common timing parameters that characterize the chosen arrhythmia. However, the user can instead choose to customize the timing delays to emulate a more specific type of arrhythmia.

 

Display of signals

The top row of the graph displays the heart signal, called an ECG signal. The bottom two signals emanate from the pacemaker. There are two signals because many pacemakers stimulate both the atrial and ventricular chambers of the heart. 

 

Display of heart rate

In the bottom right hand corner, the heart rate is displayed. This heart rate responds dynamically and realistically when modifying the timing parameters on the control panel, or when modifying the pacing settings on the actual pacemaker.

 

Alarm state

If the heart rate ever drops too low or raises too high, the blue border surrounding the UI will flash red instead, indicating that an error state has occurred. This gives instant feedback to the user who may be playing around with timing parameters.


Testing Software With Software

The models that mimic a human heart are complex, and can easily amount to thousands of lines of code. To avoid errors in our own software, we utilized a methodology called model-based development. This means that we do not write a single line of code ourselves, but rather automatically generate the code from diagrammatic models that are more conducive to human understanding and therefore less error-prone.