... support and understanding I would also like to thank Dr Yen Shih Cheng and A/Prof Gerald Koh for their patient explanation of concepts and timely pointers I am grateful to Ms Karen Koh and Angela... has also been a pleasure to work with Mr Benjamin Hon and Mr Phan Shi Wen who developed and maintained the iOS patient application, sensor nodes and o↵ered help and company to the author throughout... exercises and the amount of resistance with the the exercises and meant to be performed, along with traditional tele-rehabilltation capabilities of video calling between the patient and his/her
Tele-rehabilitation System for Elderly Yogaprakash Kumar A0039716Y B.Eng.(Hons.), NUS Friday 18th July, 2014 A THESIS SUBMITTED FOR THE DEGREE OF MASTER OF ENGINEERING DEPARTMENT OF ELECTRICAL AND COMPUTER ENGINEERING NATIONAL UNIVERSITY OF SINGAPORE 2014 DECLARATION I hereby declare that the thesis is my original work and it has been written by me in its entirety. I have duly acknowledged all the sources of information which have been used in the thesis. This thesis has also not been submitted for any degree in any university previously. Yogaprakash Kumar Friday 18th July, 2014 2 Abstract Post-stroke patients tend to have low participation rate in their supervised therapy schedule. This is due to factors such as high cost of therapy, complexity of exercises and difficulties involved in travelling to a rehabilitation centre. Therefore, a mobile tele-rehabilitation system that uses low-cost components to guide, monitor the patients exercises and provide timely feedback is proposed. This system also facilitates tele-communication with a tele-therapist who prescribes exercises for the patient and supervises his/her progress. The e↵ectiveness of this system is being tested using a Randomized Controlled Trial (RCT) consisting of patients from Ang Mo Kio Thye Hua Kwan Hospital (AMK-THKH) and Singapore General Hospital (SGH). This thesis presents in detail the hardware and software components of the mobile tele-rehabilitation system and concludes with preliminary results from the RCT. The focus of the thesis will be on the author’s main contribution to the project. This includes the sensor validation, iOS application developed for the therapist as well as server-side database design and scripts. The iOS application developed for the patient and the hardware devices will also be discussed for the sake of completeness. 1 Acknowledgements I would like to thank my supervisor, A/Prof Arthur Tay for providing continuous guidance, support and understanding. I would also like to thank Dr Yen Shih Cheng and A/Prof Gerald Koh for their patient explanation of concepts and timely pointers. I am grateful to Ms Karen Koh and Angela Cheong from the Saw Swee Hock School of Public Health for contributing knowledge from decades of experience in physiotherapy and working with patients. They have also been instrumental in both the product development and the testing of the prototypes on normal subjects and patients. It has also been a pleasure to work with Mr. Benjamin Hon and Mr. Phan Shi Wen who developed and maintained the iOS patient application, sensor nodes and o↵ered help and company to the author throughout the project. It has been enriching to help out several batches of FYP students on related project as these helped me to gain confidence in solving problems. I would also like to acknowledge Ms S. Mainavathi, the laboratory technician who made many of the administrative tasks proceed smoothly. I would also like to thank all my friends and everyone else who provided support or expressed curiosity or interest in this project. Last but certainly not the least, I would like to thank Singapore Millennium Foundation, National University Health System and National University of Singapore for their generous funding for the project. This project would not have been possible without their support. 2 Contents 1 Introduction 11 1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 1.2 Contribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 1.3 Organisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 2 Literature Review 16 3 22 The Tele-Rehabilitation System 3.1 Overview of proposed solution . . . . . . . . . . . . . . . . . . . . . 22 3.2 System Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . 23 3.3 The patient Application and Sensors . . . . . . . . . . . . . . . . . 25 3.4 The Therapist Application . . . . . . . . . . . . . . . . . . . . . . . 25 3.4.1 Login . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 3.4.2 Patient Selection . . . . . . . . . . . . . . . . . . . . . . . . 33 3.4.3 Activity Selection . . . . . . . . . . . . . . . . . . . . . . . . 36 3.4.4 Five-frame Scroller . . . . . . . . . . . . . . . . . . . . . . . 41 3.4.5 Videos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 3.4.6 Forms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 3.5 Database Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 3.6 Server scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 4 System Testing 62 3 4.1 Calibration of static accelerometer . . . . . . . . . . . . . . . . . . . 62 4.2 Goniometer-Sensor comparison for angular measurements . . . . . . 62 4.3 Preliminary Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 4.4 Randomized controlled trial . . . . . . . . . . . . . . . . . . . . . . 79 5 Conclusion 82 5.1 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 5.2 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 Appendices 86 Appendix A Database Tables 86 Appendix B Exercises for testing of sensor accuracy 94 4 List of Figures 2.1 Photo of the NESS system is use, taken from a brochure . . . . . . 2.2 System architecture of Gertner Tele-Motion-Rehab system, taken from [11] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3 17 19 Screenshot of the one of the games o↵ered by the Gertner system, taken from [11]. The screenshot shows the customer ordering item 2 from the menu shown in the right. . . . . . . . . . . . . . . . . . . . 20 2.4 Photo of the Armeo spring system, taken from [15]. . . . . . . . . . 21 3.1 Overall System Architecture . . . . . . . . . . . . . . . . . . . . . . 27 3.2 Storyboard of Therapist Application . . . . . . . . . . . . . . . . . 28 3.3 Screenshot of Login screen . . . . . . . . . . . . . . . . . . . . . . . 32 3.4 Screenshot of Patient Selection screen . . . . . . . . . . . . . . . . . 33 3.5 Screenshot of Patient Selection screen with call notes and forms . . 34 3.6 Screenshot of Activity Selection Screen . . . . . . . . . . . . . . . . 36 3.7 Arrangement of the screens on a UIScrollView . . . . . . . . . . . . 42 3.8 The change in the arrangement of the screens on a UIScrollView, just after a user scrolls to the screen that is to the right hand side. The screens with ‘X’ are to be discarded while the dotted screens are to be generated. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.9 42 Screenshot of the video screen showing a user performing shoulder flexion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 3.10 Screenshot of the navigation tables at the video screen. . . . . . . . 46 5 3.11 A screenshot of the heart rate - blood pressure (HR-BP) form, alerting the user that the systolic blood pressure is too low and that the diastolic blood pressure is too high. . . . . . . . . . . . . . . . . . . 47 3.12 E-mail sent to the administrator to inform that an abnormal HR-BP entry has been added for a patient. . . . . . . . . . . . . . . . . . . 49 3.13 A screenshot of the main page of the compliance form . . . . . . . . 50 3.14 A screenshot of the one of the week-pages of the compliance form . 51 3.15 A screenshot of the patient search screen, with call notes opened . . 53 3.16 A screenshot of the first part of the adverse events form . . . . . . . 55 3.17 A screenshot of the second part of the adverse events form . . . . . 56 3.18 Enhanced-Entity-Relationship (EER) diagram of the tables in database 59 3.19 Flowchart of verification of a request on the server . . . . . . . . . . 4.1 61 Goniometer vs Static Accelerometer plot. The error bars for most of the points are too small to be seen. . . . . . . . . . . . . . . . . . . 63 4.2 Positions of sensors on the upper and lower extremities . . . . . . . 68 4.3 Scatter Plots of Angles Using Goniometer vs Sensor of Major Joints (a) UE and (b) LE in normal subjects 4.4 . . . . . . . . . . . . . . . . Scatter plots of angles measured using goniometer vs sensor of major joints (a) UE and (b) LE in patients . . . . . . . . . . . . . . . . . 4.5 71 Scatter plot of angles measured using goniometer vs sensor for specific joints in both sides of UE in patients . . . . . . . . . . . . . . . . . 4.8 71 Scatter plot of angles measured using goniometer vs sensor for specific joints in both sides of LE in normal subjects . . . . . . . . . . . . . 4.7 70 Scatter plot of angles measured using goniometer vs sensor for specific joints in both sides of UE in normal subjects . . . . . . . . . . . . . 4.6 69 72 Scatter plot of angles measured using goniometer vs sensor for specific joints in both sides of LE in patients . . . . . . . . . . . . . . . . . 6 72 4.9 Scatter plot of angles measured using goniometer vs sensor for specific joints in both sides of UE in normal subjects . . . . . . . . . . . . . 73 4.10 Scatter plot of angles measured using goniometer vs sensor for specific joints in both sides of LE in normal subjects . . . . . . . . . . . . . 74 4.11 Scatter plot of angles measured using goniometer vs sensor for specific joints in both sides of UE in patients . . . . . . . . . . . . . . . . . 75 4.12 Scatter plot of angles measured using goniometer vs sensor for specific joints in both sides of LE in patients . . . . . . . . . . . . . . . . . 76 4.13 Upper extremity inter-therapist and inter-sensor Plots of specific exercises from 19 normal subjects . . . . . . . . . . . . . . . . . . . . 76 4.14 Lower extremity inter-therapist and inter-sensor Plots of specific exercises from 19 normal subjects . . . . . . . . . . . . . . . . . . . . 77 4.15 Upper extremity inter-therapist and inter-sensor Plots of specific exercises from 19 newly disabled patients . . . . . . . . . . . . . . . . 77 4.16 Lower extremity inter-therapist and inter-sensor Plots of specific exercises from 20 newly disabled patients . . . . . . . . . . . . . . . . 7 78 List of Tables 3.1 List of screens with the name of the ViewController object managing the screen and description . . . . . . . . . . . . . . . . . . . . . . . 4.1 29 This table provides an overview of days of activity within the first 3 weeks of intervention. Days that are in bold are those days during which the first 4 patients performed exercises. . . . . . . . . . . . . 80 A.1 Therapist information table (therapist info) to store data identifying the therapists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 A.2 Patient information table (patient info) to store data identifying the patients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 A.3 Strengthening Activity Lists table to store information about all strengthening activity . . . . . . . . . . . . . . . . . . . . . . . . . . 91 A.4 Strengthening Progression levels table to store information about the progression levels of strengthening exercises . . . . . . . . . . . . . 91 A.5 Strengthening activity selection table to store the therapists’ strengthening activity prescriptions for the patients. . . . . . . . . . . . . . 91 A.6 Strengthening activity record table to store the patients’ strengthening activity repetitions. . . . . . . . . . . . . . . . . . . . . . . . . . 92 A.7 Compliance form data table to store the number of minutes of exercise per day for every patient . . . . . . . . . . . . . . . . . . . . . 8 92 A.8 HR-BP record table to store the heart-rate and blood pressure values of patients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 A.9 FaceTime calls record table to record the date and time of calls made by the therapist, and call notes . . . . . . . . . . . . . . . . . . . . 93 A.10 iPad record table to keep track of the various iPads that are under use. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 A.11 Seen graphs record table to keep track of the graph-pages that have been seen by each therapist . . . . . . . . . . . . . . . . . . . . . . 93 B.1 Outline of Range-of-Motion (ROM) assessment exercises . . . . . . 94 9 List of Abbreviations AMK-THKH Ang Mo Kio Thye Hua Kwan Hospital. 1, 83 B-A Bland-Altman. 69 BVH Bright Vision Hospital. 83 ECE Electrical and Computer Engineering. 83 EER Enhanced-Entity-Relationship. 6, 62 HR-BP heart rate - blood pressure. 5, 6, 10, 48–51, 104 NMES Neuromuscular Electrical Stimulation. 14 NUS National University of Singapore. 66, 83 RCT Randomized Controlled Trial. 1, 63, 64, 83, 94 ROM Range-of-Motion. 10, 14–16, 18, 20, 33, 60, 66–68, 105 SGH Singapore General Hospital. 1, 83 SSH Saw Swee Hock School of Public Health. 83, 84 STARS Singapore tele-technology aided rehabilitation in stroke. 61 VR Virtual Reality. 15 10 Chapter 1 Introduction 1.1 Motivation The medical condition of stroke occurs when a blockage of a major artery in the brain results in the death of cells within the a↵ected tissue(s)[1]. This a↵ects the bodily function that corresponds to the a↵ected tissue and can result in disabilities or even death. The World Health Organisation has identified stroke to be the second leading cause of death worldwide, accounting for 11.9% of deaths in the year 2011[2] (leading cause is ischaemic heart disease and 3rd leading cause if chronic obstructive pulmonary disease). The common disabilities include inability to move one or more limbs on one side of the body or an inability to understand or formulate speech. Patients admitted into hospitals due to stroke are usually discharged after a few weeks of initial treatment, which may involve a surgery. After the initial treatment, stroke rehabilitation is usually encouraged in an attempt to recover the lost functions. The goal of rehabilitation is to enable the patients to reduce their dependency on others when performing routine tasks and increase the chances of their long-term survival. For cases of physical disabilities, the patients are usually taught individually customised therapy exercises to perform before their initial discharge from the 11 hospitals. They are often encouraged to continue performing these exercises on a daily basis, after the initial discharge. In Singapore, they are also encouraged to return to a hospital or a rehabilitation centre in their neighbourhood, to perform the rehabilitation exercises under the supervision of a therapist. In the case of Singapore, these centres are located all over the relatively small land area of the country, making it accessible for most residences. The supervision enables the therapist to check if the exercises are being done properly, monitor patients’ progress, change the prescribed exercises if needed and o↵er feedback and encouragement. The alternative to the patient travelling down to the rehabilitation centres is home therapy, where a therapist travels to patient’s home for a supervised home-based rehabilitation session. This is uncommon in Singapore as it is expensive (about 200 SGD per session for home-based rehabilitation versus approximate value of 60 SGD per session for rehabilitation at rehabilitation centres) and not widely available. A local research on 215 stroke patients from 2 hospitals in Singapore found that sustained participation in supervised therapy provides faster and greater functional recovery when compared with performance of unsupervised therapy at home as prescribed prior to discharge[4]. This trend of greater functional recovery was evident through objective functional measurements at five time-points from the time of admission into hospitals till 1 year after the initial discharge from hospitals. To add to the significance of supervised therapy, 66.9% of the patients performing unsupervised rehabilitation at home performed therapy more than 75% of the recommended time while only 33.3% of the patients performing supervised rehabilitation at centres performed therapy more than 25% of the recommended time. This also means that only 33.3% of the patients in the supervised therapy group actually commuted to hospitals or rehabilitation centres frequently enough to participate in supervised therapy more than 25% of the recommended time. Therefore, although supervised therapy gives better functional outcomes such as improvement in performing activities of daily living, there is a low utilisation rate of rehabilitation services by 12 stroke patients. This could be due to the cost of therapy sessions and/or social and physical difficulties involved in travelling to a rehabilitation centre. It will therefore be of benefit to the patients if supervised therapy can be performed at the comfort of the patients’ homes without the high cost involved in therapists visiting homes. This can potentially reduce crowd at outpatient rehabilitation wards. A RCT on telerehabilitation performed in America found that it can significantly improve physical function, with improvements lasting up to 3 months after completing a 5-week long intervention [5]. The telerehabilitation intervention used in this study includes an in-home messaging device that would ask the patient questions regarding common post stroke complications on depression, self-care/mobility and falls. Therefore, the aids provided to the patient could not monitor and guide the patient in performing the prescribed exercises. There are several tele-rehabilitation hardware/software based systems available in the market that attempt to help, guide and monitor the patient to perform their prescribed exercises at home [7][10][15]. However, these systems lack the ability to focus on both the upper and lower limb related exercises and assessments. This capability is required to attend to the variety of stroke patients who require improvement in active ROM of upper and/or lower limb(s) in order to eventually be able to perform functional tasks. These systems are often bulky and expensive, relative to the cost of home therapy. There are also an unmet need of enabling the therapist to remotely prescribe relevant upper and lower limb exercises and adjust the difficulty levels of these exercises according to the patient’s progress. 1.2 Contribution The proposed tele-rehabilitation system consists of 3 software sub-systems that work together with a pair of sensor nodes. These include the patient application, therapist application and a server. 13 The therapist application allows the therapist to modify the exercise prescriptions for any of the assigned patients and to look at summary graphs of the exercises performed by the patient. Exceptional cases spotted in the graphs can be further investigated by viewing a video of the patient performing the exercise. There are also administrative forms for the therapist to take down clinical notes, as they would usually do. The server contains a database to store information about the patients, teletherapists, independent assessors assessing the patients, activity prescriptions for the patient by the tele-therapist, activities performed by the patients. The author has designed mySQL tables in the database in order to reduce redundancies in the data being stored. The server also contains PHP scripts coded by the author, rendered by an Apache server. The server scripts securely connect to the database to query and retrieve data required by the iOS applications. Communication between the PHP scripts and the applications is encrypted by a session keys as part of the HTTPS protocol. The author also helped in the collection of data from patients in AMK-THKH in order to establish the reliability of sensor measurements relative to goniometry. The author is currently assisting in the technology side of the RCT in order to test if the tele-rehabilitation system increases the compliance of post-discharge stroke patients to their prescribed exercises. 1.3 Organisation Chapter 1 contains the motivation for developing the tele-rehabilitation system, as well as an outline of the parts of the system which the author has worked on. Chapter 2 presents a literature review of related products to observe their strengths and weaknesses. Chapter 3 focusses on subsystems that make up the tele-rehabilitation system. These include the patient application, sensors, therapist 14 application, mySQL database and the server scripts. The results and discussion of the tests performed on the sensors are presented in Chapter 4, together with preliminary results and analysis of the data from the first few patients of the ongoing RCT. The thesis is then concluded in Chapter 5, with pointers for future research. Appendix A lists the columns that are used in the various database tables, together with the type of variables stored in these columns. Appendix B lists the exercises that are used in establishing the reliability of the sensors, with respect to the goniometer. 15 Chapter 2 Literature Review There have been several tele-rehabilitation systems developed in an attempt to transcend some of the barriers that patients face in attaining supervised therapy. However, the systems developed often lack in providing the ability to monitor the ROM of various joints in both the upper and lower limbs while remaining portable. ROM is one of the fundamental evaluation procedures used by both occupational and physiotherapists to assess patients undergoing rehabilitation. For example, the systems covered by [7] and [13] focus on rehabilitating and monitoring ROM of hand-joints. Article [7] discusses the details and examines the efficacy of a remote arm rehabilitation system. There are several components to this intervention regimen. First is the Ness H200 Hand Rehabilitation System, which is a Neuromuscular Electrical Stimulation (NMES) system consisting of a moulded forearm brace with an array of electrodes. Priced at US$6200 per unit [8], the electrodes deliver alternating current waves to stimulate the contraction of digit flexors or extensors of the forearm. A photo of the system in use is shown in Figure 2.1. In addition to this, Logitech Buddy Cams were used with Skype telecommunication software to allow a tele-therapist to conduct 30 minutes of individualised therapy sessions, two times per week at scheduled times. Computer to computer video communication through Skype is free of charge. The study points out that 16 Figure 2.1: Photo of the NESS system is use, taken from a brochure lack of computer competency and lack of comfort with technology is a threat to the generalised use of this regimen. This would also be true in the context of Singapore where a significant proportion of the stroke patients are elderly and are not likely to be able to operate relatively complex computer software independently. Another learning point from this study is that regular face-to-face communication between the therapist and the patient would be necessary during tele-rehabilitation, for the therapist to fully assess and advise the patient. Hence, the hardware and software interfaces to be used in tele-rehabilitation has to be user-friendly and should only require minimal manual input from the user. Some of the stroke patients in Singapore are looked after by a caregiver 17 who remains with them for most of the day. This maybe a domestic helper, the patient’s children or other relatives. While it may not be justifiable to expect the caregiver to be more comfortable or competent with technology than the patient, they can be trained to operate simple, straightforward and robust hardware and/or software-based tele-rehabilitation systems for the patient. Another relevant example is the Gertner Tele-Motion-Rehab presented in [10] and evaluated in [11]. The system uses the Microsoft Kinect camera (priced at US$99.99 [9]) interfaced with a customised software package to engage a patient in Virtual Reality (VR) games while it captures the various ranges of motion and compensations of the upper extremity joints. The system’s angular measurements have been validated with the Vicon optokinetic system. The system as a whole can be used in 3 configurations: One therapist to one patient, one therapist to many patient and patient self-support. The games provide control over the level of difficulty, configurable live feedback and storage of results for later retrieval. In addition to the results of the games, evaluative data such as the ROM angles of shoulder (flexion and abduction) and elbow (flexion) and the maximum compensation angles that occur while making these movements. The trunk lateral and anterior-posterior motions are captured as compensatory angles. The difficulty of the games can be decided by the software based on the stored evaluative data. These decisions can also be manually adjusted onsite or remotely. The advantage of this system is that the patient does not need to wear sensors of controllers for the Kinect system to pick up movements and evaluative angles. The downside of this feature is that if a patient is accompanied by a care-taker, the caretaker cannot block the line-of-sight between the patient and the Kinect camera(s). This may happen in cases where passive ROM is being measured, with the caretaker assisting the patient to perform required movements. Furthermore, the caretaker’s should be able to provide assistance to the patient however required, without being concerned about the Kinect camera. 18 Figure 2.2: System architecture of Gertner Tele-Motion-Rehab system, taken from [11] Another relevant example is the well-established Armeo line of products that are capable of monitoring and controlling the upper limb’s ROM[15].This system uses a gravity-supporting exoskeleton apparatus with a pressure sensitive handgrip and has been proven to enable patients to increase their active ROM more than what is possible without support[12]. The system, through virtual reality, can simulate and help the patient accomplish functional daily living movements such as table wiping. It also provides auditory and visual performance feedback during and after practice. The virtual reality is shown on a 24-inch flat screen monitor with speakers. The advantage of this system is the partially active ROM that is o↵ers, as well as immediate feedback through virtual reality and also feedback that is capable of pointing out sublet improvements in patients’ functionality. This is significant since it may be a challenge to stroke patients to lift the weight of their own arm, in which case, getting them to perform arm movements without support might prove to be too difficult for them. The difficulty level of the activities can also be customised to the patient’s ability. On the other hand, the Armeo system is bulky (weighs upto 82 Kg) and restricted to the upper limb. 19 Figure 2.3: Screenshot of the one of the games o↵ered by the Gertner system, taken from [11]. The screenshot shows the customer ordering item 2 from the menu shown in the right. Therefore, the shortcomings of current options include high cost, lack of portability and the lack of flexibility to monitor multiple joints of both upper and lower limb. Hence, to date, there is no single system that can monitor the ROM of both upper and lower limb joints, provide exercises for these joints, allow the therapists to remotely prescribe the relevant exercises and the amount of resistance with the the exercises and meant to be performed, along with traditional tele-rehabilltation capabilities of video calling between the patient and his/her tele-therapist. 20 Figure 2.4: Photo of the Armeo spring system, taken from [15]. 21 Chapter 3 The Tele-Rehabilitation System 3.1 Overview of proposed solution The proposed tele-rehabilitation system consists of 3 software sub-systems that work together with a pair of sensor nodes. These include the patient application, therapist application and a server. The patient and therapist applications are developed on the iOS platform. The sensor nodes communicate with the patient application via bluetooth and both the applications communicate with the server through internet. In addition to this, the patient might also require a stand to hold the iPad, a heart rate and blood pressure monitoring set and traditional rehabilitation aids such as theraband/theratubes. The theraband/theratubes are used to o↵er di↵erent colour-coded levels of resistance, while the iPad stand helps to hold the iPad in a position from which its camera can capture the patient performing the exercise. The iOS platform was chosen for its well-known and robust video communication solution, FaceTime. It also allows a relatively fast development of the therapist and patient applications due to its intuitive development environment. Low-level technologies like Grand Central Dispatch make it easier to perform multi-threading across multiple processor cores. Automatic Reference Counting avoids the perfor- 22 mance lag that garbage collection mechanism in Java can cause. The iPad was chosen due to its user-friendly and intuitive user interface. The iPad has proven reliability as it is being used in life-critical applications such as aircraft and medicine. The therapist application allows the therapist to modify the exercise prescriptions for any of the assigned patients and to look at summary graphs of the exercises performed by the patient. Exceptional cases observed from the graphs can be further investigated by viewing a video of the patient performing the exercise. The patient application presents a simple and minimal user interface to allow the patient to perform the assigned exercises at the settings prescribed by a therapist. The prescriptions and data for identification of the patient are retrieved from the database, after an iPad is allocated to a particular patient. The data collected from the exercises are uploaded to the server, together with the videos of the patient performing the exercises. There are 2 sensor nodes that are used in this system. The number of sensor nodes for monitoring ROM have been minimised through various trials with hospital inpatients. The sensors used in this system have been validated in earlier work, with traditional tools used in rehabilitation. Validation of the sensors with goniometry has been established in [17] and [18]. Validation of the sensors with the Kinesia system [19] has been reported in [20]. The Kinesia system has already been validated in [21]. Therefore, the ROM measurements performed by these sensors are sufficiently reliable for this application. 3.2 System Architecture Figure 3.1 shows the system architecture of the entire tele-rehabilitation system. The 3 software sub-systems are namely the therapist application, patient set and the server. The therapist application has a server communication module that is 23 used by other components that need to send and/or receive data from the server. These include retrieval of data from the database through HTTP POST requests and retrieval of video files for streaming. The server is addressed using a domain name that is mapped to a public static IP address. The patient application has a similar server communication module that enables it to communicate with the PHP scripts on the server through HTTP POST requests. The patient application also has a bluetooth communication module to enable it to send command and receive data from the nodes. The server used in this system runs a non-server version of Mac OS X operating system that comes with an Apache web server installed. This web server is then configured to receive and direct HTTP POST requests to a set of PHP scripts. These scripts then connect with the mySQL database if needed, to send mySQL queries and receive the resulting data which are then used to reply the HTTP POST requests. These requests can be sent by the patient or the therapist application. Uploading of videos by the patient application also uses a PHP script while retrieval of videos by the therapist application is through a password-protected web address. The database that the PHP module communicates with is a mySQL database running on the same machine. This database is used to store discrete data such as the patient and therapist details, exercise prescriptions, ROM for the repetitions performed by the patient and so on. This is in addition to the file-system which stores the videos and raw sensor data in xml files, for each of the exercise sessions. The neck and limb sensor nodes have the same hardware components and run similar programs. Their only di↵erence is in the identity numbers that are hardcoded into them. Each of the sensors have a ATMEGA328 processor that polls the gyroscope, accelerometer and magnetometer chips via I2 C protocol to retrieve inertial data. These numbers are processed, packaged by the ATMEGA328 processor onboard the sensor node and then sent to the patient application via low-energy bluetooth module. 24 3.3 The patient Application and Sensors Each sensor node consists of a ATMEGA328 microprocessor embedded on a Printed Circuit Board (PCB) with 3 motion sensors and a bluetooth module for wireless communication with the iPad. The motion sensors include a BMA180 accelerometer, ITG3200 gyroscope and a HMC5883L magnetometer. The bluetooth module used is the BLE112-E low energy single mode module by Bluegiga Technologies. The data from the various sensors are polled into the ATMEGA328 processor over a daisy-chained I2 C connection. This data is then fused into a 4-dimensional quaternion orientation vector using the algorithm suggested by [16]. This vector denotes the orientation of the sensor node with respect to the direction of gravity vector. This sensor fusion is performed by the ATMEGA328 processor. The timestamped orientation data is then communicated to the iPad over a bluetooth 4.0 connection. The patient application analyses this data to determine the orientation of the 2 sensor nodes. These orientation data is used to calculate the various angles that are needed for evaluation of each repetition or exercise performed by the patient. The cost price to buy the parts and manufacture one sensor node is about 50 SGD for bulk orders. The minimum cost of an iPad that supports low-energy bluetooth is 528 SGD, as of April 2014. 3.4 The Therapist Application This chapter goes though the typical as well as the exceptional workflows that can occur in every screen of the therapist application, followed by a technical description of each of the workflows. This method of discussion is selected due to its closeness to the organisation of code. The view objects in each of the screens are managed by a particular view controller object, as shown in Table 3.1. This table also has a description of each of the screen for easier identification. The therapist application was developed with regular input from an experienced physiotherapist 25 and a doctor. The storyboard feature added from XCode version 4 allows a graphical display of all of the screens with their content and the connections representing the transitions between those screens. Each screen represents a view controller. Each view controller manages a single hierarchy of view objects. Therefore, all of the view objects within a particular screen are subviews of a single background view that is managed by the corresponding view controller. There are also container view controllers that manage other view controllers instead of managing views. The 2 navigation view controllers and the split view controller at the start of the storyboard’s flow are examples of container view controllers. A mock-up of the story board is provided in Figure 3.19. The actual storyboard is not shown since the words and subviews are too small for the various view controllers or the screens to be identified. 26 Therapist sub-system Patient Sub-system Therapist Application Patient Application Server Communication Module Server Communication Module Bluetooth Communication Module HTTP POST requests Port 80 Via internet Node 1 Server Apache Web Server mySQL Database PHP Module File system Sensor Node Patient Application Interface Patient Application Server Communication Module Bluetooth Communication Module Sensor Node Bluetooth Low-energy Module Gyroscope ITG3200 Accelerometer & Magnetometer LSM303DLH Serial Port I²C ATMEGA328 I²C Figure 3.1: Overall System Architecture 27 Node 2 Split View Controller Navigation Controller Compliance Form Master TVC Bar Graph VC used by Custom Navigation Controller Adverse Events Web VC Patient Search TVC Login VC 28 Activities Selection TVC Compliance Form Detail Main VC Exercises Weeks Years Graph Navigator VC Integrated Video VC Exercises Years Weeks Days Video Navigator VC Compliance Form Detail Weeks VC Call Notes History TVC Heart Rate Blood Pressure TVC used by Call Note Editor VC Form Options VC used by Integrated Graph VC used by used by Scatter Plot VC Activity Remarks Editor VC Figure 3.2: Storyboard of Therapist Application Friendly name Login screen Name of View Controller LoginViewController Patient selection screen PatientSearchTableView Controller Activities Selection Screen ActivitiesTableView Controller Scroll Infrastructure Graphs for IntegratedGraphView Controller Scroll Infrastructure Videos for IntegratedVideoView Controller 29 Pop-up screen to navigate ExercisesWeeksYearsGraph between graphs NavigatorViewController Pop-up screen to navigate ExercisesYearsWeeksDaysVideo between videos NavigatorViewController Description The initial screen that allows the therapist to log into the system. This screen contains a list of patients assigned to a therapist. Contains links to the forms and allows FaceTime calls to patients. This screen allows assignment of exercises to a selected patient and adjustment of exercise parameters. This screen allows scrolling across graphs to navigate to subsequent exercises or weeks. Left/right scroll for next/previous exercise and top/bottom scroll for previous/next week of activity. This screen shows a video of the patient performing an assigned exercise and allows scrolling to navigate to the videos of subsequent exercises or weeks. Left/right scroll for next/previous exercise and top/bottom scroll for previous/next week of activity. This pop-up screen contains 2 lists: A list of exercises and a list of weeks organised by year numbers. The user first selects the exercise to navigate to and then selects the week to navigate to within that exercise. This pop-up screen contains 3 lists: A list of exercises, a list of weeks organised by year numbers, and a list of days and video times, organised by days within a selected week. This screen allows the user to navigate to another video by selecting an exercise, week and then the time of the exercise session to watch. Table 3.1: List of screens with the name of the ViewController object managing the screen and description Friendly name Name of View Controller Pop-up remarks editor for ActivityRemarksEditorVC an activity’s prescription Form selection screen FormOptionsViewController Heart rate/Blood Pressure HR˙BPTableViewController form screen 30 Compliance Form Navigator table ComplianceFormMasterTable ViewController Compliance Page Form Main ComplianceFormDetailMain ViewController Compliance Page Form Week ComplianceFormDetailWeeks ViewController Call Notes List Screen CallNotesHistoryTableViewController Description This pop-up screen is used within the activities selection screen to allow therapists to enter remarks linked to particular exercise prescriptions. This pop-up screen is used within the patient selection screen to allow therapists to select a form to fill-up. The options are HR/BP form, compliance form, call notes and adverse events form. This screen is used to fill the systolic, diastolic blood pressure of the patient, together with the hear rate. It also shows the history of HR/BP records for the patient. This screen is the one on the left side of the compliance form screen. It allows the user to navigate between the main page and the various weeks of compliance forms. This screen is the one on the right side of the compliance form screen, when the form is first opened. It states the details of the selected patient, such as the trial number, initials, start date and date of 3rd month assessment. This screen is the one on the right side of the compliance form screen when a particular week number is chosen from the left navigation pane. It allows the therapist to fill in the number of minutes spent in therapy with a therapist and the number of minutes spent doing any prescribed rehabilitation exercises for everyday of the chosen week within the 13-week period of the study. This pop-up screen is shown when ‘Call Notes’ is selected from the form options screen. It presents a list of all the call notes for a particular patient (regardless of which therapists entered it), with the timing and snippets of the notes. Friendly name Call Note Editor Screen Name of View Controller CallNoteEditorViewController Adverse Events Form Screen Custom Navigation Controller AdverseEventsWebViewController Custom Split View Controller splitViewController CustomUINavigationController ViewController 31 Description This pop-up screen is shown in patients selection screen when the user needs to add or edit a particular note. It contains a text field for editing the call note. This screen loads and shows a web-based form that is to be filled up in case of an adverse event. This is an inheritance of a standard UINavigationController. The customisation is to catch and handle the event of the user pressing the back button to go back to a previous screen. A common use is to check if the user has saved the changes made in screens such as the activity selection screen, before navigating back to a previous page. This is an inheritance of a standard UISplitViewController. This serves as the root view controller of the entire application, for the purpose of using it for the compliance form. The master side of this split view controller is hidden for the rest of the screens. This customisation is to store a reference of this root view controller at the appDelegate class for accessing it later on, at runtime. Figure 3.3: Screenshot of Login screen 3.4.1 Login The login screen as shown in Figure 3.3 asks for the username and password of the therapist in order to login into the application. It is managed by the LoginViewController class.This is the first screen that is presented upon launching the therapist application. A typical workflow would involve the therapist using the 2 text fields to enter the username and password before pressing the ‘Log In’ button. When the user is in the username field, the ‘Return’ key on the keyboard has been configured to show ‘Next’ to go on to the password field. When the user is in the password field, the ‘Return’ key has been configured to show ‘Go’ and has the same e↵ect as the ‘Log In’ button. The button, textfields and the application icon have been positioned on the screen such that they are not hidden when the keyboard is activated. The keyboard is automatically activated when the screen is initially shown, for the user’s convenience. Additionally, this screen also shows error messages for reachability and login 32 Figure 3.4: Screenshot of Patient Selection screen issues. If the invalid credentials are used to log-into the application, the user is notified of this through the message ‘Therapist name and/or Password invalid. Please try again’. The transition to the patient selection screen occurs if the credentials are verified to be valid. There are also some additional but hidden features on this screen, for developers. Single one-finger tap on the application icon displays the version number of the application and indicates if it is a developer or production version. Single twofinger tap on the application icon displays the device and the advertiser identifiers. A subsequent single one-finger or two-finger tap on the application icon hides the text label that the corresponding initial tap brought up. 3.4.2 Patient Selection The patient selection screen, as shown in Figure 3.4 shows a list of patients under the therapist who has logged into the application. It is managed by the 33 Figure 3.5: Screenshot of Patient Selection screen with call notes and forms PatientSearchTableViewController class. This is the first screen that is presented upon logging into the therapist application. For each patient, the table shows the paralysed side, how many weeks ago the latest activity was performed and the current week number of the patient in the study. This is also the screen where the therapist can access the various forms (HR/BP Form, Compliance Form, Call Notes and Adverse Events Form) for each patient. The therapist can place a FaceTime call to a patient by tapping the FaceTime icon on this screen. A example workflow at this screen would involve the therapist inspecting when the latest activity was performed by patients and then tapping on a patient’s row to go on to the activities selection screen and check if there are any new graphs to look at. A search feature is available in case of a long patient list. This search updates the list at every addition or deletion of character from the search text field. The study protocol requires the tele-therapists to set an appointment for FaceTime call with the patient in advance. Tapping on the FaceTime icon for a patient 34 pushes the therapist application to the background while FaceTime Application is fired up. A call is then automatically made to the patient. If the initial call is unsuccessful, the therapist can either come back to the Therapist Application to place another call or stay within the FaceTime application and using the patient’s contact from the address book view on the right. Every time the therapist returns to the app after having pressed the FaceTime icon, an alert pops up to ask if the call was successful. The alert is dismissed in cases of unsuccessful calls. If the therapist replies that the call is in progress, the alert is dismissed to show a list of forms (Form Selection Screen) that the therapist may want to fill up during the call. If the therapist indicates that the FaceTime call is over, a new note editor window pops up to allow the therapist to fill up notes from her recent call. From a developer’s perspective, an example workflow would start with the appearance of a progress indicator to indicate the progress of loading the basic patient information from the server. This is followed by the sending of a request to the server to get the basic patient information. When the server’s reply has been received, the table is reloaded with the new data. Every time the text within the search bar’s text field is changed, a new request is sent to the server to obtain an updated reply to refresh the table with. When the FaceTime icon is tapped, a record is made in an sqlite database within the application to indicate the time of button press, together with the ID of the therapist who pressed it and patient that the call was intended for. A request is then made to the server to get the patient’s FaceTime address. The FaceTime call is placed once a valid reply is received from the server. When returning to the application, the internal sqlite database is checked for any unfinished FaceTime calls. For each of these unfinished calls, an alert is shown to check the status of the call with the therapist. The reply of the therapist is processed as described above. The call is marked as settled if the therapist informs that the call was unsuccessful. If the call was successful, the therapist is prompted 35 Figure 3.6: Screenshot of Activity Selection Screen to fill up the call notes. Saving the note marks the FaceTime call into the database, along with the related note. 3.4.3 Activity Selection The activity selection screen, as shown in Figure 3.6 shows a list of exercise prescriptions for strengthening and balance exercises. These prescriptions are for the patient who was selected in the earlier patient selection screen. This activity selection screen is managed by ActivityTableViewController and is specific to one patient, whose name is indicated at the centre of the navigation bar on top of the screen. For each exercise, the table shows graph and video links to view graphs and videos associated with that exercise, alongside a switch to select or deselect that exercise and options to customise each exercise. A badge at the top right hand corner of the graph icons indicate the number of weeks that contain new or updated graphs that have not been seen by the therapist who has logged in. 36 After enabling the required strengthening exercises for a patient, the therapist can further customise the difficulty of each of those exercises by selecting the progress level and setting a target angle to achieve. Optionally, the therapist can also note down remarks associated with each of the exercise prescriptions by tapping on the ‘Remarks’ button. These customisations of difficulty level and target angle are performed by sliding knob on a slider. All of the strengthening exercises can be performed at any of the 7 difficulty levels. The slider for the target angle increases or decreases the angle in steps of 5o , within the ROM of the limb associated with the exercise. For example, the ROM associated with shoulder flexion is from 0o to 180o while the ROM associated with shoulder extension is only from 0o to 60o . As for the balance exercises, the difficulty levels range from level 1 to level 6. Additionally, the duration per repetition of balance exercise can be adjusted for all levels of standing balance and the first 2 levels of seated balance. Seated balance activity done at level 3 and above involve repetitive diagonal movements at a pace that the patient is comfortable with. Thus, duration is irrelevant for these higher levels of seated balance. Remarks can also be added to the seated balance exercise prescriptions. In the case where a therapist changes options for a particular activity without changing the remarks for that activity, the text entered as remarks would remain unchanged. At the end of making changes, the therapist would need to press the ‘Save All Changes’ to send the changes to the server. The application would remind the therapist if he/she attempts to navigate to another page without saving any changes made to the prescriptions. Tapping on the graph icon brings the therapist to the latest week that the patient has performed an activity at, for that particular exercise. Note that in cases where the therapist has seen the graph-page for the latest week, but has not seen the graph page(s) for preceding week(s), the number of unseen graph-pages, as indicated on the graph icon’s badge will not change until the therapist scrolls down to see the graph-pages of the previous unseen weeks. Similarly, tapping of 37 the video icon brings the therapist to the latest video of the most recent time that the patient has performed the chosen activity. If the patient has not performed any activity for the exercise that corresponds to the selected graph or video icon, this will be indicated via an alert window. In these cases, the application will not bring up the graph or video screen. A therapist entering this screen can have 2 possible goals: To check on the activities of a patient, or to adjust the exercise prescriptions for a patient. The patient concerned would have been selected before this screen appears. The workflow of checking on the activities of a patient begins with looking through the badges on the top right hand corner of the graph icons to check if there are unseen graph-pages. If there are no badges on any one of the graph icons, this indicates that the patient has not performed any exercises since the therapist last reviewed the graphs. If there are badges, the therapist can then tap on the graph icon below the badge to proceed to the latest graph-page for that exercise. Alternatively, the therapist can also tap on one of the video icons to look at the video of the latest time period at which the patient performed that exercise. A therapist may also enter the activity selection screen to alter the exercise prescriptions for a patient. In this case, the therapist may begin with adjusting the target angles and/or progress levels of the already selected exercises. In cases where the patient need not perform a particular activity, this activity would be disabled using the ‘Enable’ switch. If the therapist wants to prescribe an activity that has not been selected yet, he/she can ‘Enable’ the activity and customise the progress level and other options to the patient’s ability. From a technical perspective, the activity selection screen appears with a progress indicator indicating the progress of the loading of data from the server. This is followed by 3 requests to the server: The first and foremost request is to get the activity prescription data to display on the screen. The second request is to get a list of graphs that the therapist has seen. The third request is to get information 38 of the graphs that can be generated for the selected patient. The server replies from the second and third requests are compared to calculate the number of unseen graph-pages by the therapist for each of the activities. The screen elements are first created after the first reply is processed. The second and third replies are then processed to add on the badges to the already created table cells. This is the reason why the other contents of this screen appear before the badges indicating the number of unseen graph-pages appear. The activity prescriptions received from the server as a reply to the first request are stored in instances of the TelerehabActivitySelection class. This class manages the prescription details of a particular activity for a particular patient. These instances are used to keep track of changes that the therapist makes on the activity selection screen and to save these changes in the server when required. The properties such as activity name, related joint, minimum and maximum possible angles are not amendable by the therapist. These details are stored in an array of instances of the TelerehabActivity class. On the other hand, details such as whether an activity is enabled or not, the difficulty level prescribed for a patient, together with the target angle or duration prescribed are prescriptions that are amendable by the therapist. These are stored in each instance TelerehabActivitySelection class, together with the TelerehabActivity class for the corresponding activity. This organisation of data makes the code more organised and understandable. Passing the activity prescription data around several screens also becomes easier. There are 3 ways of leaving this screen: By going back to the patient selection screen or to proceed to the graph or video screens by tapping on the corresponding icons. In the case where the patient has not performed any activity, an UIAlertView would appear to notify the therapist of this issue. For the case where the patient does have activities performed, the graph and video icon taps are handled in a relatively straightforward manner. An NSInvocation to perform the exit operation is prepared before performing a check to see if the therapist has any unsaved 39 changes. If so, an UIAlertView appears to query the therapist if he/she wishes to save the changes made before leaving the page, with options of ‘Yes’ and ‘No’. Tapping on ‘Yes’ would get all of the TelerehabActivitySelection instances to send the changes made, if any, to the server. This is followed by performing the NSInvocation that was prepared before the check. Tapping on ‘No’ would perform the NSInvocation, without saving the changes to the server. This also reverts all of the unsaved changes made to the exercise prescriptions. In case of going back to the patient selection screen this action is caused by the patient pressing the back button on the upper left hand corner of the screen labeled ‘My Patients’. This button at the navigation bar does not and cannot be set to invoke a method within the UIViewController managing the activity selection screen. As a result, this action is caught in the UINavigationController which manages the main navigation stack of the application. This is the main reason for subclassing of the UINavigationController managing the detail side of the subclassed UISplitViewController at the root of the application’s storyboard. The back button invokes the navigationBar:shouldPopItem: method that is overwritten in the UINavigationConroller’s subclass. The preparation of the NSInvocation is performed here, before getting the UIViewController managing the activities selection screen to get the instances of TelerehabActivitySelection to check for any unsaved changes. A normal ‘pop’ workflow would occur if there are no unsaved changes. If there are unsaved changes, the usual ‘pop’ workflow is cancelled and the prepared invocation would be activated after processing the therapist’s input at the UIAlertView. The invocation in this case calls the popViewControllerAnimated: method in the subclassed UINavigationController, which then calls the navigationBar:shouldPopItem method. This time, there would be no unsaved changes and a regular ‘pop’ occurs, allowing the patient selection screen to appear. 40 3.4.4 Five-frame Scroller The five-frame scroller is the backbone of the screens showing graphs and videos. Both of these screens allow the user to scroll left or right to navigate to the previous or next exercise and to scroll up or down to navigate to the previous or next available week of activity respectively. This subsection discusses the logic behind its implementation. For this scrolling to be supported, the 4 screens adjacent to the screen on display need to be created and stored in the memory. This is to enable the screens to be displayed when the user scrolls in any of the four possible directions (up, down, left, right). With the inclusion of the screen that is on display, this makes five screens that are to be generated and stored in the memory at any one time. There are some exceptions to this case, where the scroll position is at one or more of the following positions: last week of activity, first week of activity, last exercise, first exercise. These exceptional cases will involve the visible screen having less than 4 adjacent screens. So, with every scroll action, the size and shape of the overall page containing the five screens has a possibility of being di↵erent from what it was before the scroll occurred. As a result, the position of the screen that is visible, relative to the five-frame scroll page that it is embedded in, has a possibility of being di↵erent from what it was before the scroll occurred, with every scroll action. When the user scrolls to a new page in a particular direction, with the exception of the screen that was scrolled away from, none of the previously adjacent screens would fall within the four frames that are adjacent to the screen that the user has scrolled to. As a result, these irrelevant screens would be released from memory to make space for storing the screens that are adjacent to the new screen that the user has scrolled to. A typical workflow of using the five-frame scroller would involve the user performing basic scrolling in one of the four possible directions to navigate to the adjacent exercise or week of activity. The user can also jump to a non-adjacent exercise or activity by using the ‘Other weeks & exercises’ button and the ‘Other 41 h 2h 3h 1 w 5 4 2 2w 3 UIScrollView 3w Figure 3.7: Arrangement of the screens on a UIScrollView 4 ⇥ 1 ⇥ 1' 5 2 3 ⇥ 3' 2' Figure 3.8: The change in the arrangement of the screens on a UIScrollView, just after a user scrolls to the screen that is to the right hand side. The screens with ‘X’ are to be discarded while the dotted screens are to be generated. Days & Times’ button on the graph and video pages respectively. From a technical perspective, just after being loaded into memory, the five-frame scroller gets information of the week and year numbers during which the patient has done the respective exercises. For the sake of convenience, declare this set of information to be data set A. This information is passed onto the five-frame scroller from the ActivitiesTableViewController. This helps the five-frame scroller to decide the size and shape of the UIScrollView and the origin of the view containing the visible graph or the video within the UIScrollView. The five-frame scroller also receives details of the activity that the therapist selected in the previous screen. This helps the five-frame scroller to decide which activity to load the graphs or 42 videos for. In the case where the user tapped on a particular part of a graph to look at its corresponding video, the five-frame scroller is also informed of the week number and the year number to load the video for, in addition to the activity. In the case where the week and year numbers are not specified, the five-frame scroller module uses the data set A to load the graph or video for the latest week of the selected activity. In the case of loading video, the video for the latest activity session within the latest week would be loaded if a particular session is not selected to be loaded. After following the above logic, the five-frame scroller would know the activity and the week number of the visible screen’s content. Following this stage, data set A is used to decide on whether there should be any screen content in each of the four possible scroll directions. This information is then used to set the size of the rectangular UIScrollView and the location of the visible screen that is to be mounted on the UIScrollView. After scrolling the UIScrollView to the location of the visible screen, the various screens adjacent to the visible screen, are created and added to the UIScrollView. If the five-frame scroller is used to show graphs, a request is sent to the server to note that is has been seen by a therapist when the graph in the visible part of the UIScrollView has finished loading, . When a screen contains all 4 adjacent screens, the screens are laid out on the UIScrollView as shown in Figure 3.7. Every scroll to an adjacent screen may require an adjustment of the size of the UIScrollView and location of the visible screen relative to the UIScrollView. This process begins with getting a list of screen locations there were, adjacent to the screen that was visible before scrolling. The screen that has become visible after the scroll action is then removed from this list and the remaining UIViewControllers in the list are deleted and removed from the UIScrollView. After these steps, data set A is used to decide on whether there should be any screen content in each of the remaining three possible scroll directions. This information is then used to dynamically resize the scrollview and change the position on the visible UIViewController 43 relative the resized UIScrollView. The last step is to create content for the screens that are now adjacent to the visible screen, with the exception of the screen that was visible before scroll. A progress indicator is used to freeze the screen to perform the dynamic resizing of UIScrollView, repositioning of the main view and the generation of new screen content without the user interrupting this process. Scroll actions within the five-frame scroller are restricted to the four standard directions. An attempt to drag the screen diagonally will result in either a horizontal or vertical scroll, depending on which component the diagonal is closer to. The end position of each scroll action is restricted to the bounds of the screen content that takes up a major part of the screen at the moment the drag action is stopped. When the screen ends its deceleration for a particular scroll, the new location is calculated and the process of adjusting the size of the UIScrollView and the location of the visible screen begins. When a new activity and week are selected using the ‘Other weeks & exercises’ button or the ‘Other Days & Times’ button, if the selected screen is not the same as the currently visible screen, all of the screens in memory are dropped and regenerated for the updated location after updating the title of the top navigation bar. 3.4.5 Videos The videos of the patient performing the exercises can be viewed either from the activity selection screen or the graph screen, as shown in Figure 3.9. From the activity selection screen, the therapist can tap the video icon at the same row as the selected exercise in order to get to the latest video available for that activity. From the graph screen, the therapist can double tap on a particular day’s plot area to view the video of the patient’s exercise session that resulted in that particular day of the plot. The video will automatically start playing once it is loaded. The therapist is then able to pan forward and backward on the video to focus on certain durations 44 Figure 3.9: Screenshot of the video screen showing a user performing shoulder flexion. of the session. If the patient has done more than one session for an activity on a single day, these other sessions’ videos can be viewed by clicking on ‘Other Days & Times’ and choosing another time within the same day, for the same exercise. An example of this is shown on Figure 3.10. Scrolling left or right allows the user to navigate to the video for previous or next activity within that week. The video loaded will be the latest video on that week, for that exercise, by default. Scrolling up and down allows the user to navigate to the video for previous or next week within an activity. Pressing the back button on the top left brings the user back to either the graphs or the activity selection screen, depending on where the user was before entering the video screen. From a technical perspective, the video is loaded within the five-frame scroller managing the scrollview for the video screen. Each of the videos is shown using a 45 Figure 3.10: Screenshot of the navigation tables at the video screen. UIWebView that is configured and added to the UIScrollView. When the screen is loaded, the UIWebViews are initiated with a blank page. A request is sent to the server to get a list of days and times of when the patient performed the selected activity within the selected week. When the reply is received, the url corresponding to the latest session within the selected day number will be created. This url is the used to load the video in the UIWebView at the specified location within the UIScrollView. When a new video is selected after using the ‘Other days & Times’ button, the selected option is checked to see if it requires scrolling to a new location. Scrolling would be required if either the activity or the week number or both was/were changed. The selected video, together with the videos at the neighbouring views on the UIScrollView, is then loaded. 46 Figure 3.11: A screenshot of the HR-BP form, alerting the user that the systolic blood pressure is too low and that the diastolic blood pressure is too high. 3.4.6 Forms This section discusses the various forms that are accessible from the patient search screen of the therapist application. These include the HR-BP form, compliance form, call notes and adverse events form. Heart Rate-Blood Pressure Form The HR-BP form, shown in Figure 3.11 is used by the therapists to record the heart rate of the patient, together with the systolic and diastolic blood pressures. A timestamp indicating the time when the ‘Submit’ button was pressed, is automatically recorded for each record. The screen of the HR-BP form shows a list of rows split into two sections. The top section has one row that is used for adding a new set of HR-BP values. The following section shows a list of previously entered 47 HR-BP values for that patient. A usual workflow involves the therapist getting the HR-BP values during a FaceTime call with the patient. These values are initially written down on paper. When the therapist returns to the patient search screen after the FaceTime call, an alert shows, asking the therapist if the call was successful, not successful or if the call is still in progress. If the therapist declares that the call is in progress, a list of forms, including the HR-BP form pops up. After the therapist fills up the HR-BP values into the form, he/she presses the ‘Submit’ button to save the values at the server. Before being sent to the server, the 3 values are checked if they fall within the pre specified ranges determined by a doctor. If they are within the prespecified ranges, these values are stored in the server, together with the identity of the therapist who entered them. The pre-specified range for systolic blood pressure is from 90 mmHg to 140mmHg. The pre-specified range for diastolic blood pressure is from 60 mmHg to 90 mmHg. The pre-specified range for heart rate is from 60 beats per minute to 100 beats per minute. As the units for these quantities are universal and commonly understood by therapists, they are not included in the form. If at least one of the entered values does not fall within the range, an alert is shown to let the therapist confirm the values that he/she has entered. This alert, as seen in 3.11, shows the entered values and highlights those that are out of the range. If the therapist chooses to confirm these out-of-range values, the values are saved into the server, along with the therapist’s identity. At the same time, an e-mail is also sent out to the administrator to keep him/her informed of the abnormal entry. An example of this mail is shown in Figure 3.12. From a technical perspective, when the therapist enters the HR-BP screen, a request is sent to the server to fetch a list of historical records for a patient. The UITable that the HR BPTableViewController manages reloads its data once the reply from the server is received. The table is configured to have 2 sections, with their own headers. The first section contains textfields for the entry of the HR-BP 48 Figure 3.12: E-mail sent to the administrator to inform that an abnormal HR-BP entry has been added for a patient. values and the ‘Submit’ button. The second section displays the list of HR-BP entries loaded from the server. The entered values are checked once the therapist presses the ‘Submit’ button. If the values are within the pre specified ranges, a request is sent to the server to insert the three values, together with the therapist and patient ID, after dismissing the keyboard. The timestamp is added by the database. If any of the three values fall out of range, an UIAlertView appears to ask the therapist to confirm the values. If confirmed, the therapist app sends 2 requests to the server. The first request is to insert the values into the database. The second request is to another script that then sends an e-mail to the administrator with the values included. Compliance Form The compliance form is used by the tele-therapists participating in the STARS to record the number of minutes that the patient does exercises using the system and the number of minutes for which the patient performed any of the exercises himself. The form can be accessed from the patient search screen by tapping on the ‘Forms’ button corresponding to the patient to fill the form for. The therapist then needs to tap on ‘Compliance Form’ button to access the compliance form. The screen displaying the form is split into two by a vertical divider. The left hand part of the screen is used for navigation and the right hand part of the screen is used for the form content. The navigator lets the therapist select the part of compliance form to access. The chosen part of the form, which can be the main page or one 49 Figure 3.13: A screenshot of the main page of the compliance form of the 13 weeks, is shown on the right hand side of the screen. The main page, as shown in Figure 3.13, is just for information and does not contain any fields that the therapist needs to fill up. If a start date is set for the patient, the fields in the other screens will be activated. The start date indicates the date at which the patient starts the tele-rehabilitation study. The Week 1 page shows the week that contains the start date, as shown in Figure 3.14. A typical workflow would involve the therapist navigating to the previous week of the study and filling up the numbers of minutes that the patient has spent in therapy with a therapist and the number of minutes that patient has spent doing any of the prescribed rehabilitation exercises for everyday of that week. The therapist would have recorded these numbers from a FaceTime call with the patient. After filling up the form, the therapist would tap on one of the ‘SAVE all changes’ buttons that are on every page, to push the changes to the server. 50 Figure 3.14: A screenshot of the one of the week-pages of the compliance form From a technical perspective, the compliance form is brought about and managed by several objects and view controllers. The compliance form is the only screen in the therapist application, that reveals the master side of the split view controller. This is used as the navigation pane to navigate to various parts of the form. The screen elements of this navigation pane is managed by ComplianceFormMasterTableViewController. The screen elements on the main page of the form is managed by ComplianceFormDetailMainViewController while the screen elements on the weeks pages of the form are managed by instances of the ComplianceFormDetailWeeksViewController. The data within the form is managed by an instance of the complianceForm class, which has 13 instances of the complianceFormWeek class. Each of the instances of complianceFormWeek class has 7 instances of complianceFormDay class. These three classes also communicae with the server to retrieve saved form data and to save any changes made to the form. These three classes and 51 the 2 view controllers managing the screen elements of the form are all managed by the ComplianceFormDetailViewControllersManager. This manager manages actions that require more than one of the weeks of the form. This includes the initial loading of form content from the server to the screen and the saving of changes to the server. A typical program flow of entering the form would start with setting of the compliance form screen. The PatientSearchTableViewController passes on its patient data to the next view controller-the ComplianceFormDetailMainViewController. It then passes on the job of being a delegate of the UISplitViewController to the ComplianceFormDetailViewManager and assigns the ComplianceFormDetailMainViewController to be managed by ComplianceFormDetailViewManager. A global instance of the ComplianceFormDetailViewManager is kept at the TelerehabApp2Delegate. The ComplianceFormDetailViewManager then creates the ComplianceForm object and asks it to fetch the data for the selected patient from the server. The manager then initiates the ComplianceFormDetailWeeksViewController objects. When the data is fetched from the server, the manager reloads the content of the various form pages. This is the end of the initial setup of the form and the therapist can now navigate around and fill up parts of the form before saving the changes, if any. When the ‘SAVE all changes’ button is pressed after making change(s) to the form, the ComplianceFormDetailViewManager passes the data on the screen to the ComplianceForm object. This object then synchronises the changes made in the form to the server. The therapist is updated of the progress of the synchronisation by an SVProgressHUD Heads Up Display. Call Notes The call notes feature is analogous to the clinical case notes that the therapists usually write in order to document the details of their interventions, results and 52 Figure 3.15: A screenshot of the patient search screen, with call notes opened other notes that are specific to the patient. The call notes feature also acts as a way to communicate the progress and the current state of the patient to another therapist in case the current therapist passes the patient over to another therapist. The call notes in the therapist application are linked to successful FaceTime calls. When a therapist returns to the patient search screen after a successful FaceTime call, a notes editor pops up for the therapist to type in the case notes based on the call. These notes are stored in the server and can be accessed from the patient search screen by tapping on the ’Forms’ button corresponding to a patient and then tapping ‘Call Notes’. This brings up a list of all the notes for that patient, arranged in a chronological order, with the latest one on top, as shown in Figure 3.15. Tapping on any of these historical notes opens the selected note in an editor which allows changes to be made to the note. The changes can be saved by saved by tapping the ‘Save and close’ button. 53 From a technical perspective, there are two pop-over windows associated with the call notes feature. The first window showing a list of notes for a selection patient, is managed by CallNotesHistoryTableViewController. The other window that lets the therapist edit a particular call note is managed by CallNoteEditorViewController. The list of notes can only be accessed by tapping the ‘Call Notes’ button after tapping the list of forms. The notes editor can be accessed either by tapping on one of the notes in the screen managed by CallNotesHistoryTableViewController or by coming back to the patient screen after having pressed the FaceTime button to call a patient. CallNotesHistoryTableViewController starts by requesting the server for a list of call notes for the selected patient. The table is then reloaded to show the titles and excerpts of the notes. When a note is selected, a push segue is performed to transfer to the CallNoteEditorViewController, with the selected note. In the case of a successful FaceTime call, the call note editor screen is presented by automating the push segue. When a note is requested to be saved after changes, the CallNoteEditorViewController sends a request to the server with the modified note. The server then replies to confirm if the save has been successful or not. The editor window will only close after the saving has been successful. Adverse Events Form The adverse events form is used to record adverse events that occur to patients during the course of study. This is a web-based PHP form that can be accessed from the patient search screen, by tapping on the ‘Forms’ button corresponding to a patient and then tapping on ‘Adverse Events Form’. The administrator will be informed through e-mail after the form is submitted. The fields that are to be filled up are shown in Figures 3.16 and 3.17. From a technical perspective, the adverse events form is managed by the AdverseEventsWebViewController. This uses a UIWebView to load the form from a given url before performing an automatic 54 Figure 3.16: A screenshot of the first part of the adverse events form log-in for the therapist. 3.5 Database Design MySQL relational database management system was selected for use in this system due to its reliability, scalability and low-cost. Using a database speeds up organised retrieval of information on demand while securely containing the data within. The database is used to contain data regarding the patients, therapists, exercises selected by the therapist, the activities performed by the patients. The tables in this database were designed to minimise redundancies in the data being stored in them and multiple record changes per access. This is done by splitting the data into multiple related tables. The relationship between these tables is shown in the EER Diagram in 3.18. This chapter briefly describes the various tables and 55 Figure 3.17: A screenshot of the second part of the adverse events form the usage of the data that they contain. The list of tables’ contents is presented in Appendix. The patient info table contains a list of information regarding each of the patients using the system. Each patient is assigned a unique number, which is used to refer to the patient in the other tables that store patient related data. The information contained within patient info is entered through the web application. The trial number is a string of text that is assigned to each patient by medical sta↵ in order to uniquely identify each patient. The trial number is not used as a primary identifier of the patient to reduce space used in tables which refer to patients and to reduce computing time in finding patients in the database. This is because, a string compare operation takes a much longer time than numeric comparison. This table also contains the number of the iPad that the patient is assigned to. This iPad number is a foreign key that references the iPad record table, which contains 56 a list of iPads and their identity information. This relation is used to perform an automatic login of a patient into the iOS patient application. The therapist info and the admin info tables contain information that is used to login a tele-therapist into the iOS therapist application and to login an administrator into the administrator zone of the web application respectively. iPads are not assigned to individual therapists as several therapists within a hospital might be time-sharing an iPad. Therapists can be added by using the web application, but administrators will have to be added manually through direct access to the database. There are four tables that contain data related to strengthening activities and three tables that contain data related to balance activities. The strengthening activity list contains the details that are specific to each of the strengthening activities, such as the joint that the activity is linked to and the ROM for that joint activity. The strengthening progression level table lists the various progression levels for each of the strengthening activities, as well as the colour of the theraband used at each level. Similarly, the balance level list contains a list of progression levels related to the balance activities, together with whether they involve the paralytic or nonparalytic side of the body. These tables contain information that only concern the activities themselves and thus are not referenced to patients. As these information is fixed, they can only be manually changed through direct access to the database. The strengthening activity selection and the balance level selection contain the prescription details of a strengthening or balance activities for the patients. These prescription parameters can be changed using the iOS therapist application. The strengthening activity record and the balance activity record contain details on the individual repetitions or exercises sessions performed by the patients. These entries are made from the iOS patient application as the patients performs the prescribed exercises. The selection and record tables are both linked to the patient table as each of the rows they contain is linked to a particular patient. 57 The compliance form data table contains data from the compliance form in the iOS therapist application. Each row represents compliance data of a patient, for one day of the study. The hr bp record table contains the heart-rate and blood pressure records of the patient that have been entered by the therapists using the iOS therapist application. The facetime calls record contains the details of the FaceTime calls made by the therapist, as well as call notes made by the therapist. These are entered though the iOS therapist application. The seen graphs table helps to keep track of the patient graphs that are seen by each of the therapists. During the Singapore tele-technology aided rehabilitation in stroke (STARS) study, each patient undergoes a series of assessments to measure his/her progress. These assessments are carried out at three time-points: before the tele-rehabilitation intervention, after 3 months of tele-rehabilitation intervention and 3 months after the tele-rehabilitation system is removed from their homes. Each patient will have the tele-rehabilitation system in their homes for a three month period. The data from the fields in the forms used in these assessments are recorded in initial log, third month log and sixth month log tables respectively. 58 59 Figure 3.18: EER diagram of the tables in database 3.6 Server scripts The Apache web server is chosen for use in this project due to its low cost, portability across operating systems and high reliability. The Apache web server receives and responds to HTTP requests from the mobile applications through PHP scripts. The web application is rendered by the server using PHP scripts. The data flow between client and server is encrypted by a short term session key as part of the HTTPS communications protocol. The server scripts securely connect to the database when required, to retrieve information needed to reply the requests. There is a need for organisation of the PHP scripts due to a large number of possible requests and the various tables involved. As development of the system will continue during the RCT, there is also a need for keeping a separate development environment in addition to the test environment. To this end, the PHP scripts were programmed using an object oriented approach. There is class that manages the overall running of workflows and one class per mySQL table accessed. Each of the requests is assigned a unique operation code, depending on the database table that it concerns. An operation code related to the table that is accessed the most is assigned when a request involves multiple tables. This results in one PHP file for every table in the database and thus shorter and more organised codes and PHP files. The PHP files for the web applications are organised such that there is one file for each form that is rendered. The PHP codes use the widely used PHPMailer library to send e-mails where required. There are two versions of codes on the server: one under a production environment for use in the RCT and another under a development version to fix issues and improve the system as the RCT goes on. The two versions are on two di↵erent locations on the filesystem of the server. The production version is stored at the root document of the apache server and the development version is not. The apache server is configured with an alias directive to allow access to this non-root location 60 Exit. Verification Fail. Others app_name Th Ap erap plic ist atio n nt tie tion a P lica p Ap Exit. Skip Verification. Yes Verify Username, password Is op_Code 1403? No Correct Verify Advertiser ID Correct Exit. Verification Pass. Exit. Verification Pass. Wrong Exit. Verification Fail. Wrong Exit. Verification Fail. Figure 3.19: Flowchart of verification of a request on the server through an url. 61 Chapter 4 System Testing 4.1 Calibration of static accelerometer The accelerometer is used to measure the angle of a static part of the body (that the sensor is attached to) with respect to the direction of gravity. The graph in Figure 4.1 shows that there is a high correlation between the measurements of this sensor and the measurements of a goniometer. For this test, the goniometer and the sensor were made to measure the same elevation angle by mounting the sensor on the goniometer. This can be translated into medical scenario where the sensor is mounted on a part of the body parallel to a particular bone, in order to measure the elevation of that bone relative to the direction of gravity. 4.2 Goniometer-Sensor comparison for angular measurements The accuracy of the sensors relative to the goniometer was tested on a group of newly disabled patients at the Ang Mo Kio Thye Hwa Kuan Hospital in Singapore and also on group of healthy subjects from the National University of Singapore. All of these participants consented to the test after being informed of the test by 62 Figure 4.1: Goniometer vs Static Accelerometer plot. The error bars for most of the points are too small to be seen. a therapist and the patients’ participation was voluntary. A therapist assessed the ability of each patient to ensure that he/she is able to perform at least some of the movements safely. The participants were also exempted from some of the activities if they wished to be exempted or if they were not able to perform the required movement(s). The participants were allowed to discontinue their participation in the study at any point of the data collection. The active ROM assessments were guided by occupational therapists who also measured the relevant angles using a goniometer. Approval for this research was obtained from the National University of Singapore (NUS) Institutional Review Board (Reference code 11-013 and approval number NUS-1270). A testing session for a patient begins with the participants wearing the required sensors. This is followed by the therapist helping the participants to passively 63 perform the movement, with the aim of familiarising the participants with the requirement movement. The participants then performed the movement actively till the maximal excursion is achieved. An angular measurement of the associated ROM is then performed by the sensors and the therapist. The measurements made by the sensor and the therapist were independent of each other. This process is repeated for all of the movements that the participant is to perform. After performing the first set of movements, another therapist takes over to repeat the set of movements. This results in a second set of angular measurements by the therapist and the sensors. For upper extremity, the exercises selected are flexion, extension and abduction of the shoulder, internal and external rotation of the arm, elbow flexion and radial and ulnar deviation of the wrist. This is in addition to pronation, supination, flexion and extension of the wrist. The lower extremity exercises are the flexion and extension, abduction and adduction of the hip, flexion and extension of the ankle, knee flexion and internal and external rotation of the hip. A total of 7 sensors were mounted on the upper extremity of the body to measure the ROM for the exercises. The placement of these sensors as shown in Figure 4.2, is as follows: • On top of the wrist perpendicular to the mid-carpal joint in neutral position of each arm • Parallel to the radius/ulna bone of each lower arm • Parallel to the humerus bone of each arm • At the back of the neck The lower extremity assessments are done one side at a time. A total of 3 sensors are needed for each side. The placement of these sensors as shown in Figure 4.2, is as follows: 64 • On the anterior side of the thigh, parallel to the distal femur • On the lateral side of the calf, parallel to the fibula • On the sole of the heel The 2 sets of exercises were performed with the help of 2 di↵erent therapists within 30 minutes of interval between each other. As the ROM can be expected to be fairly constant through such a short period of time, this data can be used to compare the reliability of the measurements. These angles are then compared with the sensor readings obtained from the respective sensors at the time of the goniometer measurement. The graphs in Figure 4.3 show the correlation between the sensor and goniometer measurements for all of the lower and upper extremity assessments in healthy subjects. The Pearson’s correlation coefficients, rp2 , between the sensor and goniometer measurements for upper and lower extremity movements are 0.97 and 0.99 respectively, as shown in Figure 4.3. This shows high correlation between the 2 methods when ROM measurements are made on healthy subjects. The rp2 for the measurements performed on patients are slightly lower, at 0.97 and 0.96 for upper and lower extremity movements respectively, as shown in Figure 4.4. These also indicate a very high correlation. Correlation was also evaluated for individual exercises. For measurements of upper extremity movements performed by normal subjects, the rp2 values range from 0.62 to 0.89, signifying a high correlation, as shown in Figure 4.5. The measurements of lower extremity movements performed by normal subjects result in rp2 values falling in a broader range, from 0.69 to 0.93, signifying strong correlation between the sensor and goniometer measurements, as shown in Figure 4.6. For measurements of upper extremity movements performed by newly disabled patients, the rp2 values range from 0.42 to 0.97, signifying a moderate to a very high correlation, as shown in Figure 4.7. The measurements of lower extremity move65 ments performed by patients result in rp2 values range from 0.73 to 0.98, signifying strong correlation between the sensor and goniometer measurements, as shown in Figure 4.8. Bland-Altman plots were also created to analyse the agreement between the therapists’ goniometer measurements and the sensor system’s measurements. These are plots of the di↵erences between the sensors’ measurements and the therapists’ measurements for various exercises, against the average of the sensors’ and therapists’ measurements. The mean of the two methods is used as the reference as neither of the methods are gold standard for angular measurements. The green and blue lines on the Bland-Altman plots indicate the 95% upper and lower bounds of the confidence interval of the mean di↵erences. This analysis is performed on the both upper and lower extremity movement measurements from both newly disabled patients and healthy subjects. The Bland-Altman (B-A) plots for healthy subjects show that 95% of the di↵erences between the two methods of measurements made for the various upper extremity movements fall in a range of ±11 to ±30 , with the greatest disagreements being from wrist extension and ulnar deviation. This plot is shown in Figure 4.9. The B-A plots for lower extremity movement measurements result in di↵erences falling in the range of ±9 to ±12 . This plot is shown in Figure 4.10. The B-A plots for patients show that 95% of the di↵erences between the two methods of measurements made for the various upper extremity movements fall in a range of ±11 to ±30 too, with the greatest disagreements being from wrist flexion and extension . This plot is shown in Figure 4.11. The B-A plots for lower extremity movement measurements result in di↵erences falling in the range of ±11 to ±30 , except for hip flexion where the confidence interval limit extends to 38 . This plot is shown in Figure 4.12. The inter-therapist inter-sensor scatter plots are used to show the repeatability of the ROM measurements made by 2 methods. Within each of the subplots, the blue line represents a plot of the set of measurements by the first therapist against the set of measurements by the second therapist, for all of 66 the participants, for a specific exercise. The red line represents a plot of the set of sensor measurements taken alongside the first therapist’s measurements against the set of sensor measurements taken alongside the second therapist’s measurements, for all participants for a specific exercise. The sensor system has some advantages over goniometry. As can be observed from the graphs, the system brings an increase in the repeatability of measurements. In addition to this, the therapists no longer have to focus on the positioning of the goniometer and the reading of angles. The sensor nodes, after being positioned at the start, can output angular measurement for the various exercises. The system is also capable of measuring the transient maximum angle, which cannot be measured by goniometry. In addition to this, the sensors are also capable of calculating other metrics such as angular velocity. However, in this test, the sensor system is being compared with goniometer, which is known to have its own sources of error. These sources of error as discussed in [22] include the variance contributed by the patient, diagnostic category, therapeutic approach and goniometric technique. However, this study shows that the 2 methods fairly agree with each other. Hence, while this may not satisfy the need for accuracy of measurements, it is sufficient to substantiate the replacement of the goniometry for the above mentioned exercises with the sensor system. A more detailed study can be done to investigate the factors that a↵ect the repeatability of the results of the sensor system. 67 Figure 4.2: Positions of sensors on the upper and lower extremities 68 Figure 4.3: Scatter Plots of Angles Using Goniometer vs Sensor of Major Joints (a) UE and (b) LE in normal subjects 69 Figure 4.4: Scatter plots of angles measured using goniometer vs sensor of major joints (a) UE and (b) LE in patients 70 Figure 4.5: Scatter plot of angles measured using goniometer vs sensor for specific joints in both sides of UE in normal subjects Figure 4.6: Scatter plot of angles measured using goniometer vs sensor for specific joints in both sides of LE in normal subjects 71 Figure 4.7: Scatter plot of angles measured using goniometer vs sensor for specific joints in both sides of UE in patients Figure 4.8: Scatter plot of angles measured using goniometer vs sensor for specific joints in both sides of LE in patients 72 Figure 4.9: Scatter plot of angles measured using goniometer vs sensor for specific joints in both sides of UE in normal subjects 73 [...]... upper and lower limb Hence, to date, there is no single system that can monitor the ROM of both upper and lower limb joints, provide exercises for these joints, allow the therapists to remotely prescribe the relevant exercises and the amount of resistance with the the exercises and meant to be performed, along with traditional tele-rehabilltation capabilities of video calling between the patient and. .. work together with a pair of sensor nodes These include the patient application, therapist application and a server The patient and therapist applications are developed on the iOS platform The sensor nodes communicate with the patient application via bluetooth and both the applications communicate with the server through internet In addition to this, the patient might also require a stand to hold the... ROM of various joints in both the upper and lower limbs while remaining portable ROM is one of the fundamental evaluation procedures used by both occupational and physiotherapists to assess patients undergoing rehabilitation For example, the systems covered by [7] and [13] focus on rehabilitating and monitoring ROM of hand-joints Article [7] discusses the details and examines the efficacy of a remote... the iPad, a heart rate and blood pressure monitoring set and traditional rehabilitation aids such as theraband/theratubes The theraband/theratubes are used to o↵er di↵erent colour-coded levels of resistance, while the iPad stand helps to hold the iPad in a position from which its camera can capture the patient performing the exercise The iOS platform was chosen for its well-known and robust video communication... exercises, a list of weeks organised by year numbers, and a list of days and video times, organised by days within a selected week This screen allows the user to navigate to another video by selecting an exercise, week and then the time of the exercise session to watch Table 3.1: List of screens with the name of the ViewController object managing the screen and description Friendly name Name of View Controller... products to observe their strengths and weaknesses Chapter 3 focusses on subsystems that make up the tele-rehabilitation system These include the patient application, sensors, therapist 14 application, mySQL database and the server scripts The results and discussion of the tests performed on the sensors are presented in Chapter 4, together with preliminary results and analysis of the data from the first... straightforward and robust hardware and/ or software-based tele-rehabilitation systems for the patient Another relevant example is the Gertner Tele-Motion-Rehab presented in [10] and evaluated in [11] The system uses the Microsoft Kinect camera (priced at US$99.99 [9]) interfaced with a customised software package to engage a patient in Virtual Reality (VR) games while it captures the various ranges of motion and. .. however required, without being concerned about the Kinect camera 18 Figure 2.2: System architecture of Gertner Tele-Motion-Rehab system, taken from [11] Another relevant example is the well-established Armeo line of products that are capable of monitoring and controlling the upper limb’s ROM[15].This system uses a gravity-supporting exoskeleton apparatus with a pressure sensitive handgrip and has been... of sensor nodes for monitoring ROM have been minimised through various trials with hospital inpatients The sensors used in this system have been validated in earlier work, with traditional tools used in rehabilitation Validation of the sensors with goniometry has been established in [17] and [18] Validation of the sensors with the Kinesia system [19] has been reported in [20] The Kinesia system has... it to communicate with the PHP scripts on the server through HTTP POST requests The patient application also has a bluetooth communication module to enable it to send command and receive data from the nodes The server used in this system runs a non-server version of Mac OS X operating system that comes with an Apache web server installed This web server is then configured to receive and direct HTTP POST