top of page

Increasing Seizure Medication Compliance in Ecuador

Who are we
How it works
Testimonials
Request demo

The project addresses the problem with seizure medicine compliance in rural Ecuador that our client Dr. Paciorkowski works with. We aim to create an application for the physician that would provide a customized reminder to the patient every day to make sure they are adhering to their seizure medication. The application would allow the doctor to alter the reminder sent to each patient, but would be an automated process that would not take away time from their normal day. Our goal is to have completed the app by early April to allow time for evaluation and validation of it. Because there would be no hardware cost, the only costs would be rights to the apps, and website URL rights. The end-goal would be to see our product implemented with the physicians in Ecuador with whom Dr. Paciorkowski works. Ultimately, we would hopefully see an increase in seizure medication adherence several months after the product has been implemented.

I'm a paragraph. Click here to add your own text and edit me. It's easy.

Project Scope

This week we worked on our preliminary report, for which we had to take several steps.  We first had to do background research into epilepsy and how it affect patients in the developing world, particularly rural Ecuador.  We also did a search for existing solutions, and found solutions implemented both in the US and rural Uganda that were very relevant.  Lastly, we looked into the steps for creating an app, as none of us are familiar with app development, in order to make our Gantt chart/schedule and divide up the team responsibilities.  Once we were done with the first draft of the report, we took it to the ECC for editting.

Weekly Report 10/14/16
Design Schedule

Early this week, prior to Amritha’s presentation on Monday, Mark and Ananya listened to her present and gave her feedback on how she could improve and if the slides needed any improvement. Additionally, we discussed moving forward on our webpage. We found an online website with templates that we could use for and chose to use Wixsite. We created our own email revolutionizehealthcare@gmail.com so that create a URL through Wixsite. We also published a website with a title page with the URL http://revolutionizehealt.wixsite.com/medicationcompliance. This coming week we plan to make it into a functioning site that we can use as our webpage throughout this semester.

The  Gantt chart below goes into the basic design schedule for the subsequent 8 months:

​

 

​

​

​

​

​

​

​

​

​

Design Requirements

Our design specifications were modified to address our revised project scope.  There are
seven main qualifications that the solution must fulfill. The product must be affordable, and cost
less than $3 per month.  Ease of use for the doctor must be high, with implementation of the
solution taking less than one hour upfront, and less than 2 minutes per day per patient.  Ease of
use also applies to the patient, who should spend no more than 5 minutes per day using the
device.  The product should be easily accessible and be available at a secondary care clinic at
most.  It should also be portable, weighing less than 3 pounds.  The solution should not require
extensive physician supervision, and take at most a physical checkup once a month.  Patient
convenience, defined as minimizing disruption to daily life, should ensure that no people around
the patient are bothered by the functions of the device.

Weekly Report 10/21

This week, our group worked on completing this website for our project using the website creator, Wix. Additionally, we have been having difficulties getting in touch with our client, but were finally able to do so this week and are setting up times to Skype with him and his physician team in the US and Ecuador. Lastly, we went over our weekly report from last week and met with Dr. Silva to get feedback on our mistakes. We learned from Dr. Silva that we need to expand on the design requirements for an app including specifying memory usage, operating system for which it will be used, method of creating app (he suggested the program Unity), and other such metrics. Also, we needed to detail the existing solutions further. These are now items our group is looking into to have everything we need moving forward. 

Weekly Report 10/28

This week we continued our literature search into existing solutions for the product. After realizing that our Project Proposal did not have enough, we decided to look more into the other solutions that there are and look at what they had patented. Additionally, we talked more with our client Dr. Paciorkowski in order to establish a meeting time. This is needed to decide what type of phone our application would be most suited for in Ecuador. Otherwise the product we are making would not reach as large of an audience. Moving forward, we want to learn and set up an interface on a platform compatible with IPhone or Android and plan our steps accordingly. Looking forward to this coming week, we are meeting to talk with our client and some physicians from Ecuador on what they think they would use the most. After that discussion, we will move forward with either learning more about Unity online or finding another platform to use.

This week we consulted with our client, Dr. Alex Paciorkowski, over email. Unfortunately we could not find a time where we could meet with him and Ecuador physicians. We will continue to figure out that time this following week. Over email, we decided that Android would be a smarter choice to choose for our application due to its higher prevalence in third world countries such as Ecuador. We found that the most common Android was Android 4.4 N7 and N10 which performed with performed with more precision than their predecessor, Android 4.3. This version of Android can run on a 512MB RAM or larger and most Android phones have around 2000MB RAM avoiding any issue with that. Further research will be done this following week if the platform developed for the app will have any differences between the versions of Android used, and if they do, which Android type we would use (most like Android 4.4 because it is the most common).

This week our group met to plan out our work for the next report and presentation. We spent time going over the possible solutions we had found, previously documented, and reached out to our client again to talk about what he thought would work. We are hoping to conference with him and the Ecuadorian doctors soon to gain a clearer picture of the needs. Additionally, we split up the work for the progress report and presentation, assigning Ananya to present, and days/times we would meet with Dr. Silva and the engineering communication center to go over our work. Our group plans to meet on Saturday to discuss the progress report more.

Weekly Report 11/04
Weekly Report 11/11

We updated our project scope to address epilepsy medication compliance.  In this way, we are not beginning with the solution of the SMS reminder system and working backwards, but actually addressing the problem from the beginning. This week, we met several times to work on the Pugh charts.  We first went through a Pugh chart on a macro level, addressing our general scope, and coming up with various solutions, including an alarmed pill bottle, an implant or patch that releases medicine whenever necessary, and the SMS reminder program.  We then addressed two Pugh charts more specific to the SMS system.  One will determine the method of implementation (a website, an app for a centralized tablet, a phone app, etc), and the other is more specific design considerations (SMS vs voice messages, whether or not the patient has to respond, etc).  We have not yet come to a conclusion on the two specific Pugh charts, and will be meeting this weekend or next week to do so.

Weekly Report 11/18
Weekly Report 12/02

This week was primarily focused on the progress report. On Wednesday we met with Dr. Silva to discuss where we were at and for recommendations with regard to our Pugh Chart analysis and to include software specifications in the overview of the chosen solution details. Moving forward, we assigned specific roles for the rest of the paper outside of the Pugh Charts. Ananya was assigned to do the design specifications and software modules for the overview of the chosen solution. Mark was assigned to do the conclusion, the user interface for the overview of the chosen solution, and budget. Amritha was assigned to do the introduction, formatting, and references. Our solution, via Pugh analysis, was revealed to be a software application on a Android tablet native application (decided earlier as well), which would not be interactive except for a patient kill switch if necessary.

Product Specifications

​The chosen solution will be software based using an Android tablet application as a
platform with text messages, an educational aspect, and some patient interactivity. The Android
tablet is the only hardware we will require with no additional hardware needed. A Galaxy Tab E
Lite tablet has a battery life of 6860 mAh which will last ten hours while using applications. The
tablet will be used during the day and charged at night. Additionally, it has a memory of 8 GB
(15). The application will be composed of a database back-end, and wireframe front-end with an
aesthetic user interface which will be created using an Integrated Development Environment
(IDE). The Android operating system primarily uses Android Studio as the IDE using Java.

This week our group reconnected after winter break to discuss what we will be doing going forward. Additionally, we skyped Dr. Paciorkowski about where the design is right now and how we plan on moving forward in the next couple of months. Dr. Paciorkowski was fine with using the Android Tablet and us creating an application to address medical compliance in Ecuador. Our group talked about our JAVA programming skills and how to move forward with the application. We set-up weekly meetings to occur on Monday mornings because we were all free then. Additionally, me and Amritha will continue to perfect our JAVA skills using CodeAcademy along with some CSE 131 modules we have. Ananya will refresh her memory with her 131 assignments. Moving forward, we hope to have our device functional by late March, early April.

Weekly Report 01/27/17
Weekly Report 02/03/17

​This week we discussed our plan going forward and tentatively decided on using Eclipse to do the coding (we will be using Java).  Eclipse was what was used in CSE 131 and seems the most conducive to our needs.  We will continue to do research, however, in which method is best.  Additionally, we have set up a meeting with Dr. Moran to discuss our budget, progress report, and next steps.  We are also reaching out to peers who are more familiar with app design for their input on which aspect of the app is the best place to begin coding, which we hope to do starting next week.

​This week we discussed our plan going forward and tentatively decided on using Eclipse to do the coding (we will be using Java).  Eclipse was what was used in CSE 131 and seems the most conducive to our needs.  We will continue to do research, however, in which method is best.  Additionally, we have set up a meeting with Dr. Moran to discuss our budget, progress report, and next steps.  We are also reaching out to peers who are more familiar with app design for their input on which aspect of the app is the best place to begin coding, which we hope to do starting next week.

This week we met with Professor Daniel Moran to discuss our Progress Report and had the weekly meeting with our group to look at the code we could use. We discussed the contents of our Progress Report as well as our next steps moving forward. Dr. Moran told us were that our budget was approved for a total of $157. Additionally, he told us if we needed any extra money, we would be able to have at least an extra $40 for unexpected purchases. Dr. Moran addressed our need for a database that will store the patients and their medication information and he offered several options that we could use for it. The Android application must use the database periodically to identify which patients will need a reminder and how frequently they will need it. We also added on the editing capability into our application basic module diagram which we had talked about in our Progress Report.

Weekly Report 02/10/17
Weekly Report 02/17/17
Weekly Report 02/24/17

This week we continued with designing the application needs, including the necessary database, user interface at each page (login through adding patients through editing), and sending out the text messages. We also began working on the Verfication and Validation report - we divided up the components between our group members and came up with a timeline to complete it. We also planned to meet this upcoming weekend to go over the report parts. Additionally, individually we are all working through Codeacademy for Java to better learn programming before launching into the main components of the app development. In addition to Java we are also working on learning a database language to program the database component of the app. Lastly, we are going through the Android app developer training modules online to learn how to design a app in that operating system.

​This week we began coding the app using Android Studio. We began with the basic function of being able to send an SMS message with user inputs for the phone number and message body. There have been some errors in the code, and some have been fixed we are still looking into the others. Our next step will be programming the part that sends the texts at the appropriate time.

Weekly Report 03/03/17

This week we continued to put together our Verification/Validation report, completing the VV plans that we drafted last week.  We also now have a preliminary proof of concept.  The current app displays an interface that allows the user to input one patient's name, phone number, and information, and uses this information to send a text message.  As of right now, the delivery of the message must still be done manually, so our next step is to program it to deliver automatically at the given times

Weekly Report 03/10/17

​This week, our group finalized the V&V presentation, which Mark practiced and presented. Additionally, we met to finalize all items we had to purchase and reimbursement forms to start working on our physical device. We worked through how to create an account to have a phone number on Android virtual studio, from which the text messages were sent. Mark and Amritha are working on getting the Android developer studio software working on their individual computers, and emailed EIT to hopefully get it on a Whitaker/Urbauer computer since for now the software has not been functioning as well on our personal computers. We also made a plan for the next steps to take over Spring Break.

Verification Plan

​This week, our group finalized the V&V presentation, which Mark practiced and presented. Additionally, we met to finalize all items we had to purchase and reimbursement forms to start working on our physical device. We worked through how to create an account to have a phone number on Android virtual studio, from which the text messages were sent. Mark and Amritha are working on getting the Android developer studio software working on their individual computers, and emailed EIT to hopefully get it on a Whitaker/Urbauer computer since for now the software has not been functioning as well on our personal computers. We also made a plan for the next steps to take over Spring Break.

We will ensure that the program performs all of the required functions by navigating through all of the possible scenarios that could occur. We will evaluate the following design specifications:

  •  Account creation:

    •  Each physician should be able to create an account that can store their patient list. The app should be able to store at least five accounts based on an estimate from our client.

  • Account login:

    • Each physician should be able to log in to their account and not have access to any other user’s account.

  • Add patient:

    • The physician should be able to add a patient to their respective patient lists. The app will then prompt the user for the patient’s name, phone number, medication type, medication dosage, and frequency of reminders desired.

  • Storage:

    • The application should store at least ten patient’s information.

  • Edit/delete patient:

    • The physician should be able to edit or delete any patient information.

  • Send SMS reminders:

    • The app should send SMS reminders to the phone numbers stored for each patient at a specific time for each patient. The message should be sent within five minutes of the time recorded in the patient information, and should occur automatically with no additional action required by the physician.

  • Opt-out:

    • At any time, the patients should be able to express that they no longer wish to receive messages so that they may be removed from the patient list.

The greatest risk is that our app will not send the SMS reminders, or will send them at the incorrect times to the patients. One method to monitor this risk is to create a notification whenever a reminder is delivered, and store these notifications in a log. However, this may not be necessary as our verification plan should be able to determine whether or not the reminders are being sent. The following are the steps of our verification plan:

1. Each team member (Amritha, Ananya, and Mark) will create an account for themselves as the “physicians”.

2. Each team member will ensure that they are able to log on and off of their respective account, and that no one else is able to log onto another’s account.

3. Each member will add three “patients” (peers who agree to let us use their phone numbers) to their lists, with arbitrary patient medication, dosage, and timing information.

4. Over 72 hours we will ensure that each of the nine “patients” consistently receives their reminders within five minutes of the appropriate time, with the correct medication information.

5. Each member will have one “patient” carry out the opt-out function to indicate to the “physician” that they wish to be removed. The member will subsequently delete that patient from the list. They will also edit one of their patient’s information to display different dosage information and send texts at different times. The final patient’s

information will be left unchanged.

6. The 72 hour survey will be repeated to ensure that all messages are sent correctly (or no longer sent) according to the updated patient information.

Each member will keep a written log of each patient, changes to patient information, and a confirmation from the patient at the time that each message was received. The log of message delivery time and content will be compared to the intended message information. We will strive for 100 percent of the messages to have the correct content and to be delivered within five minutes of the intended time.

The primary components of our app are the interactive ends with for the doctor and their patients. Our main goal is for the app to allow doctors to send text message reminders to patients and have patients receive them hence possibly increasing medicine compliance. The app should be easy to use for the doctor, allow patients to receive and stop text messages, and be understandable for the physician and patients. The steps below outline our plans to validate these components:

1. Ease of Use

   a. The app will be tested by outside people with no knowledge of the proposed app function to test if the user understands the app’s intended function.

   b. The app will be tested by people with varying skill sets/experience with tablet apps, to understand if the app is easy to navigate without prior experience to using similar programs.

2. Receipt and Stop of Text Messages

   a. The receiving end of the app, the test messages, would be tested by a user who would be directed to receive and stop the text messages to test the ease of use of the ‘stop’ function.

3. User Interface

   a. A Spanish-speaking test user will receive the text messages to test whether the language translation was effective and understandable.

   b. The app will then be tested by a healthcare professional to test if the program allows them to input all necessary information in a clear manner.

Overall, our validation plan ensures that all aspects of the product will be tested by a range of people to simulate the range of experiences the lay user may have. As this app is intended for use in rural Ecuador where the doctors and patients may have had less experience with similar technology, the varying test users will allow us to adequately prepare the app to be used by all our proposed clients.

Validation Plan
Weekly Report 03/24/17

​This week we worked on our code in Android Studio. Additionally, Mark worked on using a web emulator instead of a virtual device because his OS did not support the hardware accelerator. The Tablet we ordered came in, but it did not come with a charger so we had to return it and the new one is supposed to come within the week. Moving forward, we need to work on more of our code. We looked into using Node and Cordova and Apache which is open source for different components of the application. We plan on meeting several times in the coming week to work on the code including the JSON files and the basic interactivity of the UI.

​This week our group looked at the web emulator in Android Studio and how to run it. Additionally, we worked on a UI that included a log-in screen, a screen to add or remove patients, a screen to enter patient’s information, and a log-out screen. All of this UI was made using Adobe Illustrator. The web emulator created through Android Studio used the Node platform used an ionic framework in order to run online. In addition, by adding the Cordova plugin, the code could run faster based on the compiling properties of the plugin. Some initial code has been added to Android Studio using it and its open-source code available through Apache Software.

Weekly Report 03/24/17
Weekly Report 03/30/17
Weekly Report 04/07/17

This week our group focused on several things to complete individually. Mark worked on uploading .pngs or .jpgs to Android Studio and also on transitioning between screens for the UI and how each screen could be represented by an activity. Additionally, he updated the website with the verification and validation report and new weekly reports. The new updated website can be found here: http://revolutionizehealt.wixsite.com/medicationcompliance. Amritha started on the final report focusing on the design specification and “computer” requirements needed to run our application. Ananya focused on creating the text messaging system and making sure that it could deliver within a designated amount of time. Overall, as a group, we have organized around four to five times in the next three weeks to meet to really solidify the verification of our application. During this time, we will also work on validation by getting friends to agree to try out the application.

Weekly Report 04/14/17

​This week we worked on three main components - Ananya was working on the timing of the text messages (to send out daily), Amritha was working on using Google Accounts for the doctor sign-in, and Mark was working on using .json files to store patient data and the switching of the screens from one to the other. We met with Nate to figure out the timing of the text messages and found out this feature might just not work on the emulator and we would need to connect an actual phone to see this function. We have been meeting daily as a group to finish our respective components and write up the final report.

This week we finished up our project including the final report. The components included include sending timed SMS text messages once a day, storing up to ten patient’s information for one universal account, and creating a basic user interface on which to test it. Additionally, we created an “ideal” user interface which would be reflected in a future version of our application. However, due to time constraints, we were unable to employ this exact interface which I have attached here: https://invis.io/T4BB8X66S. Using Invision, we obtained all of the JSON code from an index.html file that the website uses. We were able to test our validation plan on individuals of varying technical skill levels from fellow students to parents and grandparents who had navigated smart devices much less Moving forward, we hope to fine-tune our app and add enough activities eventually so we could interlink with this user interface I created.

Weekly Report 04/21/17
Background

Medical compliance is a problem that is very prevalent throughout the modern world. There are many different solutions that people have tried including having other's remind them to take their medication to setting google calendar reminders or the like. Epileptic medication needs to be adhered to very closely for it to have its full affect and many individuals who do not adhere to this strict daily regiment will fall prey to frequent seizures. Our proposed solution looks to address this problem using text message reminders, and our thought process and procedure is explained in the subsequent website.

This project was used for Mark Orland's, Ananya Benegal's, and Amritha Gourisankar's Senior Design class for their Bachelors of Science degrees in Biomedical Engineering at Washington University in St. Louis.

Weekly Report 10/07/16
Weekly Report 9/30/16
Weekly Report 9/23/16

Rape Kit Client Meeting with Kim Webb

1. Research how long it takes to get DNA and to standardize the procedure of how long that it takes

2. Two different types of exams: safe and sane a. safe exams are not gathering evidence, but looking for

injuries

     b. sane exams are done by sexual assault nurse examiners and use forensics

3. Problems with procedure:

     a. Assumptions about identity, victimization, differences with the stereotypes

     b. Trauma history and what the purpose of each step is

     c. Clothing conside

ration that is not secure (hospital gown) with different clothing

     d. No private spaces for rape victims specifically

     e. No ability to stop the exam once it starts

     f. HIV prophylaxis required if rape was male to male, multiple assailants, unknown perpetrato

     g. One place in Missouri (SLU) that does forensic exams for dating or domestic violence i.e. sane

exam

 

Meeting with potential client: John Schmidt in the Bayly lab, MEMS

1. use Magnetic Resonance Elastography (MRE) to characterize brain tissue and brain tissue

     a. mimics to learn more about traumatic brain injury (TBI)

     b. need a device that will deform the samples during testing so far, the only characterization that has been done (even internationally) has been using small deformations want to do larger deformations to better simulate conditions of TBI want a device that can simultaneously do both small, linear deformations and larger, nonlinear

deformations at different frequencies both frequencies need to be adjustable independently, as well both magnitudes of displacement needs to be able to accommodate different sample materials

This week we chose our project to be Dr. Paciorkowski's centered on medicine compliance in Ecuador for epileptic patients. We emailed Dr. Parikh, and the other possible clients to let them know of our decision. We decided on this project because we figured it was something we were all passionate about and would have real world implication. Additionally, we found it very feasible compared to some of the other possible projects we were considering.

Presentation Information and Feedback

Amritha did the Preliminary Report, Ananya did the Progress Report, and Mark did the Verification and Validation Report presentations. The presentations were a reflection of the report using Powerpoint and hitting all the major points that were included in the rubrics for each of the reports. The main information from these presentations can be gleaned from the Project Scope, Design Specifications, Design Schedule, Validation and the Verification plan all listed above. Please contact us at the email below if there any more questions regarding the specific slides. The slides can be found below in the attachments where they are organized left to right: preliminary report, progress report, and verification and  validation report.

Design Safe

The following three images is the risk assessment excel sheet for our application. They are screenshots of what we found overall from a careful assessment of hazards that our product might bring. Overall, we found that were eight main hazards that our product could have with varying levels of risk:

  1. Mis-entered patient’s phone number (medium risk)
  2. Doctor who input patient’s information cannot find the patient to stop text messages (medium risk)
  3. Patient did not receive text messages (medium risk)
  4. Patient received text messages at wrong time of day (medium risk)
  5. Patient’s information is accessible to more than just the doctor inputting information (high risk)
  6. Patient receives texts at inopportune times (high risk)
  7. Doctor cannot delete a patient (medium risk)
  8. Doctor forgot account information (medium risk)

 

Subsequently, the comments address how these hazards can be addressed and how the risk level was minimized for each of them.

bottom of page