We designed and prototyped an infusion pump for subcutaneous administration of immunoglobulin (IgG), an immunodeficiency treatment.  The device is an improvement on the technology which is currently available.  The prototype was fully functioning and was capable of administering customized medical therapy.  This project was completed as the final project submission in University of Pennsylvania's Medical Devices (BE 470) course.

Video #1 - Preparing Immunotherapy Infusion Demo

Video #2 - Executing Immunotherapy Infusion Demo

Video #3 - Concluding Immunotherapy Infusion Demo

Video #4 - Syringe Purge Demo

Problem Statement

Patients with compromised immune systems have what is called a primary immunodeficiency disorder (PID), where part of the immune system such as the immunoglobulin (Ig), or antibody population is missing or performing incorrectly. This makes them more susceptible to severe and recurrent infections because their body defense mechanism, the immune system, lacks a vital component (Bonagura). As of 2007, approximately “1 in 1,200 persons” is affected by PID in the United States (Boyle and Buckley). Patients who are unable to produce a sufficient amount of Ig require a treatment known as immunoglobulin replacement therapy. By taking into account the advantages and disadvantages of current treatments for PID, we propose a medical device that performs as an antibody pump and can provide more constant delivery of antibodies.

The current standard of care offers monthly injections, via IV infusions, or weekly subcutaneously-administered injections (Bonagura). The IV infusion is known as intravenous immunoglobulin (IVIG) therapy—it is administered approximately every 28 days and is “effective in preventing serious bacterial infections and improving the quality of life for treated patients” (Kobrynski). The other method is subcutaneous (SCIG) treatment, which is different because it is not administered through the vein and into the bloodstream, but rather under the skin in fatty tissue of the thighs, upper arm, or abdomen. Other differences include regularity of treatment reception, as SCIG must be delivered weekly. We will focus only on IVIG.

Patients with the immunodeficiency disorder are unable to produce the appropriate number of antibodies that a healthy individual has and so this treatment seeks to provide an external supply of antibodies on a regular basis. “Since [IgG] only replaces the missing end product but does not correct the patient’s defect in antibody production, [IgG] replacement is usually necessary for the patient’s lifetime” (Immunoglobulin Therapy & Other Medical Therapies for Antibody Deficiencies). This also creates a peak and trough pattern for antibody levels (a graphic representation is attached in the Figure 1). The peaks arise when treatment is given at the beginning of the 28-cycle and there is a trough in antibody levels towards the end of the cycle. Essentially, to prevent a patient from having a below-normal level of antibodies, doctors prescribe a large enough dose so that by the end of the month, patients will still have an antibody count that is greater than or equal to approximately 800 mg/dL, the healthy level for an adult (Immunoglobulins (IgG, IgA, and IgM), Serum).

Figure 1 - Increasing regularity of treatment decreases total amount of medication needed to maintain minimum, healthy antibody levels for patients with Primary Immunodeficiency Disorder. The areas under the curves decrease with greater regularity, which means less medication required, and therefore lower costs. 

This treatment has been the standard of care because patients are able to go about their daily normal lives, so long as they regularly receive infusion. However, the treatment also has several disadvantages. IVIG therapy is extremely wasteful. Patients must receive enough treatment such that the level of antibodies is sufficient until each treatment This treatment must also continue for an indefinite amount of time because it is not a curative process. The combination of these two issues make costs extremely high for patients; the cost ranges from “$164 to $314” (Immune Globulin Subcutaneous (Human), 20% Liquid). Moreover, not only are patients susceptible to lethargy when Ig levels are low but adverse effects of IgG infusions also include “headache, myalgia, fever, chills, low back pain, nausea and/or vomiting” (Duhem, Dicato and Ries). As a result, patients require separate medications, both before and after infusions to manage these side effects. The particular disadvantage we will focus on is reducing costs for patients by increasing regularity of treatment with the creation of a user-friendly infusion device.

The code for my project is attached here.

Device Specifications

This device is essentially an infusion pump for immunodeficiency therapies. Patients will receive medication through the pump. Patients typically know how much medication they should receive from a doctor’s prescription, so they can simply program that number through the keypad. This function will cause the motor to move the carriage a certain distance back from its “home base” position. During this time, the yellow LED will turn on to inform the patient that this function is running. Then the patient will load the 60 mL syringe which will contain the medication fluid. Once the patient initiates the infusion process and the motor begins pushing the syringe forward, he/she can perform various functions for important functions and information. For example, patients can navigate the keypad to determine how much more time is remaining in the infusion, or they can pause/cancel the infusion. When the infusion ends, the red LED turns on so that the user can be aware that the overall procedure has ended.

Specification Table

Specification	Value, Value Range, or Quality of Specification	Additional Comments (if needed)
Battery Life of motor	Indefinite	Powered through outlet
Battery Life of LCD, LEDs, Arduino	Indefinite	Powered through computer
Syringe Life	Replace after each infusion
Tubing Life	Replace after each infusion
Needle Life	Replace after each infusion
Age requirements	Safe/intended for all ages	Doctor prescription required, but operation should not be for children under
FDA Classification	Class II	Some harm to the user may occur because of motor, tubing, and needle; mandatory performance standards required so that users know that the medication works appropriately; other pumps are given Class II regulatory controls
Sterility	Syringe, tubing, needle must be sterile materials

Block Diagram

CAD Modeling

Feature and Benefit Table

Feature	Benefit
Red LED	Patient knows when infusion has completed
Yellow LED	Patient knows when carriage is moving to its appropriate place along rail
Green	Patient knows when…
LCD display	Informs patient about various features, such as how much medication to deliver, how much time is left over in the infusion, and allows patient to pause/cancel infusion
Servo Motor	This motor allows for constant delivery of medication because it can move a specified distance at a regular rate
Tubing	Wiring allows for simple transportation of medication from the syringe to the patient
Needle	Transportation from the syringe to the patient, as well
Arduino	Overall functionality and output device controls

Prototype Description

The device we have built is a user-friendly and easy to use apparatus at home. This allows for increased regularity of treatment so that patients incur lower costs for Primary Immunodeficiency Disorder therapies, which include antibody infusions. However, our device has much room for improvement. To begin with, we would want our device to mimic an insulin pump’s feature of checking blood insulin levels and provide dosages appropriately; if our device could record patient antibody levels, patients would receive more appropriate treatment, thereby further decreasing costs and keeping patients healthier. For example, immune systems may have to combat infections more actively during the winters when infections are more prevalent. As a result, the daily dosage can be higher if a patient needs it to be and lower when not necessary.

Other improvements include changing the power system so that wiring is not necessary. A battery-powered device would be more portable for the patient and allow for less restricted movement. Additionally, our pump has an open design as of now, but with more time, we would have placed it in a box so that the only parts of the apparatus visible would be the LCD display and the rail for syringe placement. Finally, we would improve the LCD functionality to include more information such as the antibody level, calendar for treatments, and pre-set settings for speeding up the infusion process and improving effectiveness of the device.



PREVIOUS TECHNOLOGIES

CONCERNS
There are a wide range of treatment doses.  

• how to accomodate all sizes
• http://emedicine.medscape.com/article/2157901-overview

Doctors may be comfortable with wastefulness

• Bloodwork does not directly identify the appropriate prescription level.  It is hard to tell what is abnormal performance and what is low levels of antibodies.

Lab 5: IR Lab

In this portion of the lab, we will be looking at control versus communication (communication is what we worked with in the prior lab). The difference between the two is that with control, there is less information sent to devices, with each bit of information carrying a particular function. With communication, there is a stronger focus on sending the information from one device to another.

We will be dealing with two different communication/interpretation processes. During the first process, the raw digital signal is reformatted so that the receiving device will understand it. Other formatting is also done so that the receiving device will be the only one understanding it (a TV will be controlled by only a TV remote). The second process is known as modulation, where the signal is able to put the signal into a specific frequency band. This will prevent signals from interfering (which could cause constructive or destructive interference) and will also filter out background noise.

We first set up the Arduino IR Remote Library and created two circuits: a receiver circuit and a transmit circuit.

The receiver circuit is shown below:


The transmit circuit is shown below:



Our video shows the overall performance of this setup. The code is attached here.

Next, we sent the same IR code to trigger an action in the previous step. Since we are working with Sony codes, we'll use Sony-specific protocol. We set up both the receiver and transmit circuits so that the first Arduino can translate the IR signal into a command, and turn the LED on and off each second.

Here is the video.

Receiver and transmitter code are both attached here.

Lab 5: Bluetooth Lab

Part 1

Many of us have utilized several bluetooth-enabled technologies, as the advantages of this wireless communication have caused it to become a widely used tool. Radio frequency (RF) communication operates at a frequency of 2.4 GHz and allows for data transmission through a "sending" and "listening" module. Bluetooth devices that are communicating are "paired" together so that only one particular listening module receives information from a specific sending module.

With regards to this class, we will receive two modules that are pre-programmed to communicate only with each other. Then we will connect the serial input and output of the Arduino to the serial input and output of the bluetooth module. We will use SofwareSerial to set up the software serial connection.

The purpose of this lab is to set up a bluetooth transmitter and receiver and create a wireless button to buzzer connection.

In the first portion, we set up the bluetooth transmitter so that the Serial Monitor would print "H" when the button is pressed and print "L" when the button is released. Rather than work with one Arduino, the signal will be wirelessly delivered. Since we didn't want the transmitter to be sending a continuous stream of letters, like what usually happens, we made use of an if statement so that the "H" or "L" would only be displayed once. Below is an image of our circuit.



For this part, our code is attached here.

Then we had to create a bluetooth receiver. After connecting the second bluetooth module to the other Arduino Board, setting up the LED, and writing a program for the LED to turn on if the Serial Monitor had an "H" (and off when "L"), we obtained our results. Below is an image of our circuit.



The code is attached here.

Finally, below is a video for this portion of the lab.

 Next, we wrote a program so that our transmitter could print different numbers to the serial port once every second. For example, the number would increment every second. Then, the integer value would be transmitted onto the LCD screen.

The code is attached here. Here is the video for this part of the lab.

Part 2

In this portion of the lab, we will acquire a continuously varying signal from a sensor and then send this signal wirelessly. We will use an inertial measurement unit (IMU) as our sensor, which can measure acceleration, rotation rate, and magnetic field all around three axes. It also has an on-board micro-controller that can perform calculations and provides data combining all of the detailed measurements.

We started off by installing two libraries developed by Adafruit, created the apparatus, and then used the program by Dr. Bogen. Then we wrote the program to monitor the IMU's orientation about a specific axis and map the orientation angle into a tune on an Arduino device that is located away from this apparatus.

Some issues we faced: the provided code gave instructions on calibrating the IMU but we were unable to find a rotation that calibrated the IMU. Soon enough, we figured out that if the IMU and the circuit board was rotated into different positions and then held there, it would eventually calibrate.

In order for the tune to play, we had to associate each orientation angle with a different frequency that would then result in a unique sound. First we converted the angle values into tone frequency values. Then we broadcasted these values using the bluetooth module (and this was through our transmitter-Arduino). Next, we had the second receiver-Arduino collect the data from the transmitter-Arduino. Then, the tones were played.

Our new circuit was a little different:




Our video is shown below.

Finally, the code is attached here.

Lab 4: Nonvolatile Storage

The purpose of this lab was to store data in nonvolatile storage, construct a data logger from nonvolatile data, and work with RC servos.

Essentially, memory on the Arduino is erased when the Arduino shuts off however, by storing the data into Electrically, Erasable, Programmable, Read-Only Memory (EEPROM), we can go around this to add greater utility to our Arduino. By using the Write() and Read() functions, we were able to write the data to the EEPROM and then read it after the Arduino shut down.

In our program, when we type a W into the Serial Monitor, the program began writing the data into the EEPROM and when we type a an R, we have the program read and display the data into the Serial Monitor. The code is attached here.

The following is what we obtained in our Serial Monitor. In the first line, the Serial Monitor displays "saving 0 at location 0." This means that the Serial Monitor read the value of 0 and wrote it onto the EEPROM.



Some issues we had in this portion of the lab: we accidentally created an infinite loop with i equal to 0 by typing "for(int i = 0; i < 6; i = i++)" but to fix this, we changed the loop to "for(int i = 0; i < 6; i = i+1)."
---

Part 2

In the second portion of this lab, we built a data logger for light intensity measurements by the Arduino. Our circuit resembled a variable resistance sensor with a photo-resistor, a voltage divider circuit, and the analogRead() function. This was similar to the work that we did in Lab 2. Once again, we used a 5.1 kOhm resistor because it was closest to the resistance of the photo-resistor provided.

Of course, we had to remember that not all pins work with the analog output and input, which was something we momentarily forgot. Luckily, we didn't take too much time to realize this was one of the issues we ran into.

Our circuit looked like this:



The code for the light sensor is found here.

---

Next, we had to write code so that the data logging device we make takes a measurement from the sensor at a regular rate (15 seconds for a duration of 3 minutes) and stores all of these data points into the EEPROM. The code for this portion is found here. (The code from the previous portion was slightly edited to achieve this.)

Next, we had to have this information displayed in the Serial Monitor. Here is the code. The image below shows the readings from the Serial Monitor. We can see that for 3 minutes, or 180 seconds, these readings were taken and recorded.



One of the issues we faced in this portion of the lab was receiving different outputs from EEPROM.read() versus analogRead(). We discovered that analogRead() pins produce an output between 0 and 1023, which is why they had to be scaled down when we were writing them through the EEPROM.write() function.

---

Then, we wrote a front end which would allow us to select if we wanted to start the data-logging process or whether we wanted to read the already-logged data. The serial input from the Serial Monitor was used to choose between data-logging and data-reading. The code is attached here.

The image below shows the Serial Monitor when w is pressed.



and




The image below shows the Serial Monitor display when r is pressed.



---

In the third portion of this lab, we built a rotational positioning device. Our circuit was to look like this:



The actual circuit looked like this:



Next, we started to control the servo position, or the rotation of the motor with the Arduino. We controlled the servo by sending pulses to the Arduino every 20 ms or so, with pulses that were approximately 1-2 ms in width. The code can be found here.

In the next portion, we had to write a program to have the motor move at a specified angular position, which was to be inputted into the Serial Monitor. We had a significant amount of trouble in this portion of the lab. One important component of this code was a while loop, through which we could enter integers into the Serial Monitor and the output would be the ASCII equivalent. The second component was when we had to close the if loop for serial.available(). Without these parts, entering inputs into the Serial Monitor would result in the motor taking a single-step towards the direction of the inputted location.

We have a video that displays what our code was before we corrected this mistakes:



And one after we corrected for this mistake:


We believed it would be worth while to really understand this mistake as our final project would require similar code. The code is attached here.

Next, we made the servo motor rotate back and forth between two different positions. The code is attached here and the video is below.



Next, we controlled for the servo speed for the back and forth motion of the prior task. The code is attached here and the video is below.



Then, we created a program that would allow us to set the servo speed from the Serial Monitor. The code is attached here and the video is below.



Finally, we had to build a rotational positioning device. Meaning, after mounting a cardboard disk on a servo motor, we want to make the hole positioned over the sensor on command. Essentially, the motor would take information based on the light in the area in order to figure out where the hole is and where to position the servo motor.

Our circuit looked like this:


Finally, our code is attached here and the video is attached below.