Rehabilitation Training System

From Mindworks
Jump to navigation Jump to search
      Kendall Gregory
      Chase Guyer
      Michael Mueller
      Katja Schumacher
      Joel Perry
      Bruce Bolden

Our team is building a software that helps occupational therapists with the rehabilitation process of a stroke patient. With the software the therapist can create game based routines that support and accelerate the patient’s recovery. Having game based routines makes the process more engaging and motivates the patient to practice more.

Problem Definition[edit]

The goal of this project is to make the rehabilitation process of stroke victims more automated and simpler for the occupational therapists, and at the same time be fun and engaging for the patients.

Project Requirements[edit]

  • Easy/quick to setup and use
  • Intuitive displays for configuration and visual feedback
  • Real-time feedback of performance indicators as well as aggregated performance metrics
  • Unilateral and bilateral mirrored movement and anti-phase movement capability
  • Corrective guidance when user lags or moves incorrectly
  • Data storage for off-line computation


In the stroke rehabilitation industry today, occupational therapists must sit with their patients and walk them through a set of movements that are designed to give them back their ability to control their muscles. There are many different ways in which this process can be improved.

Creating video games in which patients can mimic those motions not only makes the process more enjoyable but it can also motivate them to push themselves further. Including things like a rewards system and displaying graphs of their progress can be excellent motivation.

This is also a very time consuming process for the occupational therapists who are in charge of the patient's rehabilitation. They must sit with the patient and walk them through a specific set of motions designed to retrain their brain's muscle memory. Creating a system in which the therapist could create a regiment of games designed for a specific patient's needs and hand it off to them to run through on their own would make this whole process easier and more fun for the patient.

Detailed Specifications[edit]

Our group met with our client Doug Weeks who is the research director at St. Luke's Rehabilitation Institute and were able to discuss with him the kind of project that he wanted us to create. Below is a list of requirements that we collectively decided on after our interview with him:

  • Patient records must be private, in accordance with HIPAA.
  • The program needs to cover three areas of rehabilitation: cognitive, visual and upper mobility.
  • The games should be compatible with a variety of devices.
  • The graphics should be 2D.
  • The difficulty should be adjustable by the therapist.
  • Statistics regarding the performance of the patient should be recorded. These statistics should be as objective as possible.
  • Patients need to receive feedback telling them how they are improving.
  • The games should be relevant to older people, as this is the main audience.
  • Based off of Doug's suggestions and our own brainstorming, we came up with a few games we would like to start off with and time permitting we may add some more to make sure all aspects of a stroke victim's rehabilitation can be covered.

    • Maze Game:
      • A game where the patient needs to find their way through a maze; this would help with cognitive impairment and also exercise fine motor skills.
    • Card Game:
      • A matching game where the patient would be asked to remember a combination of cards. This helps with the patient’s memory.
    • Finder/“I-Spy”:
      • The patient would be tasked with finding a certain object within a bunch of colorful objects. This is intended for both cognitive and vision rehabilitation.

    Project Learning[edit]

    We have had many discussions on how we would like to implement out project and here are a few things we have made sure to cover to make sure the project will be put together as efficiently and skillfully as possible:

    • Roles
      • Quality Control
      • Project Manager
    • Code Specification
    • GitHub Etiquette
    • Taking age of users into account
    • Creating UI's in each game that are similar
    • Following HIPAA's patient confidentiality requirements

    Semester Progress as of 11/15/15[edit]

    This section will describe in detail the progress that has been made to the project over the course of the semester.

    Menu System[edit]

    The menu system itself consists of multiple different screens that the user can navigate through.

    The first screen is the therapist login. It prompts the user for a username and password. From this screen the therapist can either login or exit the application.

    The next screen is where the therapist will pick a patient of theirs or create a new one. After the patient is chosen, the application will lookup and load that specific patients file. This file will have their saved routines and information that the therapist has entered upon the patient's creation.

    The patient creation screen will have many different information fields and drop down menus that the therapist can use to report specific details about the patient and their history. There are some test that therapist run on their patients that have a certain score to report the patient's progress. The patient creation/edit screen will allow the therapist to log this information, and any other information they find relevant.

    Once the patient is logged in, there will be a number of patient-specific options that the therapist will have. They will be go to a "manage routines" screen (described below). There will also be a "manage patient option". The therapist will also be able to logout the patient here to be able to return to the patient login screen. Finally there will be the "load routine" and "new routine" options that will load or create the patient-specific routines that the therapist will be able to modify.

    The "manage routines" screen will give the therapist the option to edit the routines they have created. This may be changed so that the routine will be editable when loading, we will see how the menu looks and feels.

    The "manage patient" screen will be where the therapist can edit or delete the current patient. When the patient is deleted, all of their information will be wiped as to make sure their information is kept private. The options that are available to the therapist in the patient creation screen are the same options that will be available in the edit patient screen.

    "I-Spy" Game[edit]

    The "I-Spy" game will focus on testing the patient's ability to locate items on a screen. There are a number of customizable parameters that will make sure this game can be tailored to the patient's specific needs. "Easy" mode will consist of the patient locating colors. "Medium" difficulty will be where the patient is trying to find different shapes. "Hard" mode will be where the patient is trying to locate numbers and letters.

    The quadrant of the screen that these items show up in will also make the game easier or more difficult depending on where they are struggling. This will be up to the discretion of the therapist.

    Card Match Game[edit]

    The point of this game is for the patient to pair up a number of cards that are displayed face-down on screen. When they click on a card, it will flip over and they will be able to see what is on the card for a second or two(customizable). The card will then flip back over and they will have to find its pair. Much like with the "I-Spy" game, the difficulty will depend on what is on the card and what quadrant of the screen it is on.

    Maze Game[edit]

    The maze game is where the patient will need to navigate through a maze to get to the exit. They will have a top-down view of the maze and will be tasked with navigating out of it. Things like time limits and size of the maze will determine the difficulty of the game.

    Semester Progress as of 03/08/16[edit]

    Up until now we have made a number of changes to the Rehabilitation Training System. They are as follows:

    Menu System[edit]

    -Added Routes to -Create Therapist -Create Patient -Load Patient -Patient Information -Added a file I/O system in order to load and save patient/therapist information -Added a place for the therapist to enter in information about the tests the patients have taken

    I Spy Game[edit]

    -Made cards a rectangular shape -Added more diversity to the existing cards -Clarified instructions and score -Board shuffles after each click

    Memory Game[edit]

    -Cards shift to different parts of the screen upon completion of a round -Cards stay visible for 2 seconds after second has been clicked -Screen resolution size issue has been fixed

    Maze Game[edit]

    -Maze randomly generated with walls and floor tiles -Avatar to be moved around is in progress...

    Semester Progress as of 05/04/16[edit]

    We have concluded work on the Rehabilitation Training System. I will describe what progress has been made in the last 2 months of work since the last update. All of the client’s requests have been fulfilled with the games. The maze game has been finished and in addition, Kenny has created the path tracing game, where the player moves their cursor along a set of points connected by lines. This game will be described in further detail in its section. All of the games have metrics after each repetition which cue the player into how well they are doing.

    Menu System[edit]

    Since the latest client meeting, I have added a number of things to the menu system. For starters, I redesigned the patient information page. It used to be a lot more jumbled and confusing. I used Katja’s UI mockup as a guide and saw how in her example, all of the labels lined up in one column, and the text fields lined up in the second column. After implementing this, the page looks a lot nicer.

    I added sections for naming a routine, specifying the parameters, and loading the routine. At some point i figured out that I needed to have a page where the user exclusively names the routine so that I could create a filename with that name as a destination for the parameter information to go in. After naming th routine, the user is taken to a screen that has a button for each game. Clicking the games button will take you to its parameters page. When the user is done editing the parameter and press the done button, that information is sent off to a file in the corresponding routine folder. This is where the games will look to find the information they need at startup. Then there is a page similar to the name routine page where the user simply enters in the name of their routine and the routine is then executed.

    There was quite a bit to figure out in terms of all of the text files and where everything should belong. At some point I had to stop and figure out exactly what I wanted the tree of files and folders to look like. Basically there is a main folder that contains two folders: patients and therapists. The patients folder contains most of the information like patient names, routine, and their respective information. After that I had to figure out what exactly needs to be printed to those files and folders. Me and the other members of the team decided on what the input was going to be like and went from there. We decided that the routine information would just be in space separated files.

    The fun part was then linking all the games together in a routine. How it works is when a routine is created, a string is added to list that is basically just the games name. Then when I run the routine, I go through that list and in order of items, run the corresponding games. This was sort of tricky becuase I have no experience with libgdx’s screens and games. At one point the program was running every other game and I had no idea why. I quickly learned that setting the screen to an object will call that object’s show function, which is where I had my code that ran the games. I did not know that this function was called automatically, so I called it after setting the screen, hence skipping every other game.

    Of all my accomplishments with this project, I am proudest of figuring out that one should call setPasswordMode to true before trying to use setPasswordCharacter, and that using setPasswordMode by itself does not do anything useful if your font doesn’t include the dot character.

    I-Spy Game[edit]

    Micheal added a number of improvements to the I spy game. Most of these had to do with the clients requests. For starters, he maded it so that there is in intermediary screen that shows the card the player needs to find, and then shows all the cards, with no hint as to what the card was. There is also the option to choose which section of the screen the cards will be placed in, and an option to reshuffle the cards after every round.

    Memory Game[edit]

    Michael fixed a problem I was having with his game where the resolution would not play well with the placement of the cards. There are a number of ways to customize this game including number of pairs, displacement of cards on the screen, how the cards will be oriented, and how many seconds they will be revealed for.

    Maze Game[edit]

    Kenny finished off the maze game quite well. He used Kruskal’s algorithm in order to find a minimum spanning tree which basically ensured that each maze would be unique, and would have a solution. He then added a cursor that is yellow and will turn red if the player moves the cursor out of bounds. There are a couple different ways to customize this game, such as the user specifying the height and width of the maze.

    Path Trace Game[edit]

    The path trace is a new game that Kenny came up with and is a very good addition to what we’ve already got. Like the maze game, it focuses on keeping the player inside a certain area to regain some mobility back with their arms. Basically how to works is there is a set of nodes which are either set up in a circular path, or a random one(depending on the specification of the parameters). The player will start at one node and then when the reach that node, the next in the series will change color to indicate that one is next. The goal is to stay as close to the line connecting the two nodes as possible while the distance between them is crossed. The user has the option of choosing how many nodes there are in the path.

    The Future of RTS[edit]

    As we hand this project off to the next iteration of students that are going to come through and be added to this team, there are a number of things that we know need to be improved. For the most part, our goal we to set the base level of this project up so that it could be improved upon. Here are some things we noticed that could be better.

    My main complaint is how we store our data. A system of files and folders is just downright messy. We should have seen this coming from the start and implemented a database but that never happened. It is also tacky that when the user runs the program, that head folder that contains all of the data is placed outside of the executable, meaning all the passwords and patient information is up for grabs. Now the admin of the system can lock this file down, but that is still a vulnerability. All of this could be solved by using a database to store all of the information. I was unable to complete one of the client’s requests which was to have a system where they could add a date and a test score so they could see the patients progress over time. However, I could not do this because of the nightmare of files and folders that would have had to be created in order for this to work. Again, a database would solve this problem.

    The other problem is that in some areas, the games just look unfinished. We had to whip up a lot of the sprites and everything from scratch and they could definitely use improvement. It should be incredibly easy for the next set of students to make some better looking sprites and add them to the game because the code is alll there and done, they just need to change which png’s are being pointed to. The client also requested some different backgrounds be available for the therapists to choose from, but we never got around to this either. Basically there are just som asthetic changes that need to be made to make the game look more cohesive.

    Team Members[edit]

    Chase Guyer - I am a senior in Computer Science and will be graduating in the spring of 2016. I enjoy programming in any and all fields. I look forward to helping out in Team RTS however I can.

    Kendall Gregory - I'm a senior studying Computer Science. My interests include Evolutionary Computation, Machine Learning, and Software Engineering.

    Michael Mueller - Michael is a Computer Science major as well. He enjoys programming up his own video game projects in his spare time.

    Katja Schumacher - I am studying “Management & Engineering” at the Leuphana University in Germany. This fall semester I am an exchange student at the University of Idaho and I am happy to support the project and be part of Team RTS