Sam.cs.lth.se

Master's Thesis
Medical Accelerometor Smartphone
Application For PalCom Based Systems
Peter Abrahamsson
Department of Computer Science Faculty of Engineering LTH Lund University, 2013 ISSN 1650-2884 LU-CS-EX: 2013-02 Medical Accelerometor Smartphone Application For PalCom Based Systems Peter Abrahamsson Master's Thesis at the department of Computer Science Examiner: Boris Magnusson Lund, 2012, October 8 This project is about a medical accelerometer smartphone application (MASA) that was built to serve as a motor function analysis tool for patients diagnosed with Parkin- son's disease (PD). The application is capable of measur- ing rest tremor from a subject by analysing accelerometer values gathered by the smartphone. It does this by us- ing a custom method developed during this project, the mean RMS method. There is a lot of research in measur- ing different kinds of movements with accelerometers in the medical community. The research is currently limited due to the lack of large scale tools. The goal of the MASA application is to remove this limitation. This project has established the foundation of the solution to problems sur- rounding the development of such an application as well the basic application and its architecture.
I would like to thank all the participants of the research, which was conducted at Clinic of Neurology at Lund Uni- versity hospital. I would also like to thank Katarina A Johansson for helping me gather the accelerometer values from the patients motor function evaluations, my mentor Bjorn Johnsson for teaching me the basics of the Pal- Com framework, Boris Magnusson for granting me this project, Carmen Arevalo for giving me great feedback on the accelerometer data gathered and finally Johan Abra- hamsson and Vanja Maslo for editorial notes.
2.1.2 Current diagnostic methods . . . . . . . . . . . . 11 2.2.1 An accelerometer in a smartphone . . . . . . . . . . 12 3 Problem description and proposed solution 3.2.1 Large scale accelerometer data gathering . . . . . . . . 17 3.2.2 Interchangeable analyses methods . . . . . . . . . . 18 3.2.4 Interpretable presentation of data . . . . . . . . . . 18 3.3.1 The execution of the research . . . . . . . . . . . 19 4 The Medical accelerometer smartphone application system 4.2.2 The MASA system architecture . . . . . . . . . . . 22 5 The mean RMS method and research results 5.5 Evaluation of the mean-RMS method . . . . . . . . . . . 32 5.5.2 Related work and discussion . . . . . . . . . . . . 34 6 Summary and future work With Parkinson's disease (PD) the loss of motor function is an inevitable result of the disease and it is clinically apparent in the advanced stages of the disease[3,6]. Most clinical evaluations of motor function are the result of the subjective interpretation of a clinician and the detection of abnormalities is commonly based on assessments that are only useful for diagnostic purposes [1,4,7]. Subjective interpretations of symptoms are less useful as they vary between clinicians and perceived changes may occur even if the symptoms remain constant. Consequently, there is much to be gained from the development of clinical tools that can gather variables that objectively quantify and measure the occurrence of e.g. trembling. Methods such as camera-assisted motion analysis, electromyography for kinesiology studies, optoelectronic systems for kinematics and accelerometer data analysis are potential tools in this setting [4]. The accelerometer stands out as it is relatively cheap compared to the majority of the other previously mentioned instruments[2] and can be used outside a laboratory environment. There have been many failed attempts to use accelerometer data to measure movement because of unacceptable variability in the resulting data. However, in recent years, there have been many improvements to the accelerometer measurement technique such as use of threshold filters[1] and custom algorithms[5].
To my knowledge, there is currently no cheap, readily available tool that can be used in the clinical setting described above. I believe that the next natural step for the clinical research community for gait, PD and stroke is to make use of commercial smartphones.
Smartphones already have a triaxial accelerometer present in their internal hardware and the technology is mass produced, cheap and easy to use. Also, through application devel- opment the triaxial accelerometer is readily adaptable to suit specific needs and that is the subject of this project.
The purpose of this project is to establish the basic principles for collecting, measuring and analysing the data from a smartphone's accelerometer. The MASA system was built to satisfy this purpose. The MASA (Medical Accelerometer Smartphone Application) system consists of two parts: the analytical methods and the application system.
One analytical method is developed in this project and it serves primarily as a pillar for quantifying data for the evaluation of rest tremor. The analytical method is known as the mean RMS method. To achieve data quantification the analytical method uses different mean values of root mean squares to act as different standards of comparisons. Its goal CHAPTER 1. INTRODUCTION is to measure and then analyse the PD patient's rest tremble data collected with the accelerometer and break it down to into interpretable numerical components for analysis.
The analytical method is right now suited for PD patients but can be adapted for a variety of purposes. The application has been developed in such a way that the analytical method can be replaced or adjusted to suit other possible future settings.
A basic android application was first developed in order to conduct field research to assess application and analysis method requirements. During the field research tremble data was collected from 9 patients diagnosed with PD. The analysis of the data was done in Matlab.
The final application is able to measure and compare different kinds of rest trembles and sort out most of the noise data and spikes. The measurements can potentially be compared to any other previously gathered data with respect to age, natural trembles and other illnesses etc.
The final android application system is designed for the end-user, in this case the patient diagnosed with PD. With the help of the application a patient could potentially be able to relay tremble data to the hospital for analysis and receive feedback from a doctor.
The relaying of the data could be done at any location with cell-phone coverage. The data gathered could also be used for research purposes. The application was built on the Android platform using Java and the communication to the server from the application makes use of PalCom. The PalCom framework is a programming framework proposed to easily establish communication between different devices.
Chapter 2 provides necessary knowledge to grasp the problems and solutions in the rest of the report. It includes an overview of Parkinson's disease, the accelerometer and the Palcom framework.
Chapter 3 is a detailed description of the common problems faced by research communities that are looking to the accelerometer as a viable aid for quantifying data of motor function symptoms. It is then followed by a proposed application solution that could aid the research and treatment of Parkinson's disease and other disorders with decreased motor function symptoms.
Chapter 4 presents the internal architecture of the medical accelerometer smartphone application system and its neighboring components. The chapter also includes parts where the application could be expanded.
Chapter 5 concerns the mathematical analytical method (mean RMS method) created to break down the smartphone's accelerometer data into interpretable and comparable numerical components. The chapter also contains results from the research that was conducted during the project and a minor elevation of the mean RMS method.
Chapter 6 includes a summary of the android application and the mean RMS method.
It also includes a future work section that present areas where MASA application and analysis methods could be improved or developed.
This chapter provides key concepts in Parkinson's disease and basic knowledge pertaining to the accelerometer and the Palcom framework.
2.1 Parkinson's disese Parkinson's disease is a degenerative disorder of the central nervous system. It is the result of the loss of dopamine-generating cells in the substantia nigra, a region of the midbrain. The cause of cells death is currently unknown. Early symptoms of PD include shaking, rigidity, slowness of movement and difficulty with walking gait. Advanced stages of PD may include symptoms such as behavioural problems as well as cognitive decline and dementia.
Modern treatments make use of levodopa and dopamine agents to manage the early motor symptoms of the disease. As the disease progresses, these treatments will inevitably become ineffective and cause a complication called dyskinesia, which is marked by involuntary writhing movements. There are other available treatments for PD but they are beyond the scope of this essay.
2.1.1 Trembles of interest The symptoms that are of interest to this project are the movement related symptoms i.e.
shaking, rigidity, slowness of movement, difficulty with walking gait (pattern of movement) and dyskinesia. These symptoms have different visual presentations and the severity may differ between patients.
2.1.2 Current diagnostic methods Diagnosing PD is complex and involves many different diagnostic methods. The methods that are of interest for this project are the motor function evaluation methods. The evaluation is done by a specialised nurse or doctor observing the patient performing certain predetermined tasks such as standing and sitting down from a chair or sitting still and CHAPTER 2. BACKGROUND counting backwards from a hundred. The evaluation tasks are designed to provoke certain symptoms characteristic for PD. The assessment involves visually observing the patient and subjectively determining the severity of the different symptoms. I have included the motor function evaluation methods in the appendix section of the rapport.
2.2 Accelerometer The accelerometer is a device that measures proper acceleration. Proper acceleration is a change in velocity relative to free-fall (zero-gravity). It does not measure the change in acceleration but the force it is subjected to during the acceleration. This force is otherwise known as g-force (although its not actually a force). An accelerometer only measures one direction. If held vertically it will measure Earth's gravity.
Simply put, if the accelerometer is accelerating freely to the ground it will show zero.
This is because the frame of reference of the entire measuring system is subjected to same acceleration. However, if the measurement system would face a deceleration like hitting the ground, its internal frame of reference will still be subjected to Earth's gravitational pull.
There are a number of different ways to measure proper acceleration. A commonly used accelerometer is the capacitive accelerometer, which is used in most smartphones today.
A technical description of capacitive accelerometers is beyond the scope of this paper. For a detailed description of the technology of capacitive accelerometers, the reader is referred 2.2.1 An accelerometer in a smartphone The behaviour and reliability of an accelerometer varies depending on the model of the smartphone it is integrated in. The accelerometer readings can be influenced notably by the following reasons[9]: • Multitasking: Smartphone operating systems use multi-tasking systems, meaning that the processor switches between tasks depending on priority or timer. This might alter the performance of the accelerometer and consequently cause inconsistencies in • The hardware specifications (clock frequency, architecture etc.) of a smartphone model also affects the accelerometer even if the same accelerometer chip is used in • Threshold: Some operating systems use various thresholds to remove insignificant noise from the accelerometer. The threshold may vary depending on the type of operating system on the mobile device. This means that the operating system decides if the measurements have changed enough to notify the user.
• Access to the accelerometer sensor may very depending on the model and operating system. This is because the layers between the hardware and the application can vary in architecture and access. As an example, some smartphones close access to the accelerometer sensor when it's in hibernation while others do not.
2.3. THE PALCOM FRAMEWORK In short, different smartphones may have varying software and hardware configurations which is a potential source of measurement error and inconsistency if one is not aware.
2.3 The PalCom framework The PalCom framework is the result of a project lasting between 2004 and 2007. PalCom (Palpable Computing) is a framework aimed at easily establishing communication between digital devices. These devices can range from personal computers to ubiquitous devices.
Examples of such ubiquitous devices can be medical equipment, smartphones, digital cam- eras and GPS's. The primary gain of using this framework is that an application will gain the ability to easily share its functionality with other applications and thus expanding its 2.3.1 Architecture The implementation of the open framework is done in Java and consists of a set of commu- nication protocols and logical structures representing various parts of the communication system.
This paper only provides an overview of relevant concepts regarding the PalCom frame- work. For more information, the reader is referred to [8].
The underlying architecture of the PalCom framework is centered on three concepts, namely devices, services and assemblies. Interplay between these three concepts is achieved through discovery, connections and tunnels as stated below.
• Devices: A PalCom device can represent any kind of device. This device could be a digital camera, smartphone or software simulation. The purpose of the device is to host services and manage its identity in the PalCom environment. For instance hosting a smartphone as a PalCom device will result in the smartphone showing up in the PalCom environment.
• Services: A PalCom service is hosted on a PalCom device. It serves as the in- put/output terminal link to the physical world. It's where commands are defined and executed e.g updating an internal counter or displaying certain data on a screen.
A service is defined by a service description, which defines the interface which the system will operate. This description is where the developer specifies the commands the service will provide for the user.
• Assemblies handle the logic of interaction between services. Through configuration an Assemble can describe how and when a communication between services should happen, in other words event handling. But for this to be possible the Assem- bly needs to have references to the devices and their services participating in the communication event. The logic of the interaction between the services is handled through creation of scripts, in other words event scripts.
• Communication is a discovery protocol that makes the PalCom devices aware of each other. This is achieved through "heartbeats", which are periodically sent broadcasts messages that urge all devices to identify themselves as "alive". The discovery pro- tocol is limited to local area networks but with use of tunnels the network can be CHAPTER 2. BACKGROUND extended to include a remote network location. The tunnels are simple connections between two networks that forward PalCom traffic such as "heartbeats" from one location to another. This creates the appearance of two networks being one and the In order to use the PalCom framework on Android smartphones, a PalCom environment was an adaptation of "The Thing" for android. It's an application that enables the user to establish and manage communication between other PalCom applications or external devices while it can load services dynamically. It follows the same architecture as the PalCom framework.
Problem description and proposed This chapter is a detailed description of the common problems faced by research commu- nities that are looking to the accelerometer as a viable aid for quantifying data of motor function symptoms. It is then followed by a proposed application solution that could aid the research and treatment of Parkinson's disease and other disorders with decreased motor function symptoms.
3.1 Problem description Initially, the goal of this project was to build a smartphone application that could regulate a Parkinson patient's dosage of levodopa with the use of a smartphone's accelerometer. Also, project was to enable a patient to use the application at any location to send accelerometer data to a remote location. The purpose of this project was eventually adjusted due to (mainly medical) obstacles discovered during development that were not obvious the start.
The final application is therefore not designed to guide a patient's intake of levodopa.
Rather, the main purpose of this project is to provide an objective variable that can be used by a clinician in addition to other information in the assessment of symptoms in a patient with PD. On a wider note, this project seeks to shed light on the inherent potential of smartphones and their use in a medical setting. Significant technological developments in recent years have led to the wide distribution of advanced technology which is relatively cheap compared to specifically designed medical equipment. As demonstrated in this paper, this technology can be adjusted to potentially suit medical needs.
Given the performance characteristics of accelerometers available on smartphones and the nature of the Parkinson's disease, there lies a challenge in distinguishing random move- ments from tremor or motor function impairment [1]. Creating accelerometer-based sys- tems for determining the movement differences between healthy subjects and those with PD has been done before [2]. The results[5] of these systems can identify changes in move- ment characteristics associated with PD in domestic environments and are encouraging from a clinical viewpoint. The average triaxial accelerations obtained from selected seg- ments of PD patients are capable of providing comparable values to established methods CHAPTER 3. PROBLEM DESCRIPTION AND PROPOSED SOLUTION of diagnosing dyskinesia [6,7]. To the best of my knowledge these types of methods have not yet been tested with a smartphone device. The results of the previously mentioned studies need to be at least reproduced with a smartphone device in order for this to be a viable alternative. The challenges are several: 1. The methods used in aforementioned studies need to be adapted to suit accelerometer data from a smartphone.
2. The results of the data quantification need to be be presented in a manner such that they can be easily interpreted by a clinician.
3. The interface must be designed in such a way that a patient can use this application outside a hospital environment.
4. The application must be able to transmit the results to a hospital.
5. The application should support multiple accelerometer recording sessions i.e record accelerometer data with multiple smartphones at the same time. This being as mul- tiple accelerometers are required to record complex gait patterns and other move- So, four basic requirements can be deduced: 1. Large scale accelerometer data gathering.
2. Interchangeable analysis methods.
3. Intuitive interface.
4. Interpretable presentation of data.
The accelerometer in the smartphone measures proper acceleration. There are essentially two different ways of gathering data from a patient. One way is to gather accelerometer data over a long period of time while the patient is performing random tasks. Another way is to have patients perform standardised tasks, which makes it easier to distinguish abnormal involuntary movements and tremor characteristics in illnesses like PD. The ap- plication developed in this project is primarily designed for standardised movements that can be performed in or outside a clinical setting.
When attempting to develop software that is capable of gathering clinically useful data, some fundamental questions are raised concerning the recording of standardised move- ments: What constitutes clinically significant tremor during a predetermined, standardised task? What constitutes severe tremor as compared to modest tremor or even normal move- ment when comparing accelerometer data? Also, a standardised task can be performed in slightly different ways, which can cause abnormalities in the data.
The first thing to do is to sort the data into interpretable components that can be presented to the user. There are many ways to do this e.g. RMS values[4], threshold filters [1], custom algorithms[5], min and max values and harmonic movement analysis[2]. These methods have been used to extract certain aspects of data collected from standardised movements. For instance, harmonic movement analysis in the frequency domain would yield more useful information on walking patterns than RMS. This being as the RMS doesn't include information significant to evaluating walking patterns. To the point, when choosing a method to extract interpretable components from accelerometer data, one needs to consider what specific task is going to be performed.
3.2. THE PROPOSED SOLUTION 3.2 The proposed solution The solution is a system that meets the four basic requirements presented in the problem description. This solution is called MASA (Medical Accelerator Smartphone Application).
Before the development of the MASA system research was conducted in order to assess a more detailed requirement specification such as user interface, analysis methods and large data gathering. The execution of the research is presented in section 3.3.1 page 19. The proposed solution is partially shaped from the findings of this research. The research was performed before the final application was built. This is because the findings from the reseach would shape the final application.
The chosen smartphone platform is Android. The MASA system will use the PalCom framework to handle its communication logic. An Android application can use the Pal- Come framework with an additional application called The Thing. The Thing runs in the background of the android device and only needs to be setup once.
3.2.1 Large scale accelerometer data gathering The MASA system should be scalable enough to support a large population of users. It should be possible to increase the amount of users by installing the application on more A large population of user results in large quantities of data, so there need to be scalable data structure to support this. Therefore the storage of the recorded data and user in- formation needs to be in centralized server with a database. The server could be located either in a hospital or in a remote location. This solution would enable the MASA system to be scalable and easily managed by administrators of the system. A user of the applica- tion would gather the accelerometer data through recording sessions. The sessions would be associated to a user id and certain predetermined tasks that the user would perform. It will run a session for the preset amount of time that is needed to draw a conclusion from the recorded data. The user provides an user id so the recording sessions can be associated to a patient id in the hospital. The user id also enables the MASA system to avoid storing sensitive patient information. That information could remain in the hospital's internal databases. This is done by the hospital having the user id and the real patient informa- tion. The MASA system would have the user id and the accelerometer data. This way the MASA system avoids constraining privacy laws set on many hospitals today.
A low level communication protocol between the applications is not necessary to create.
The PalCom framework can manage the lower level communication logic while the devel- oper only needs to establishes the higher level commands, such as send and receive. Instead the developer focuses on creating PalCom services that interconnect via an assembly. The communication logic is to be done by establishing scripts in the assemble. The services are designated modules that have certain roles in the MASA system. These services will be discussed in more detail in chapter 4.
To make it a robust application it should be able to be used at any location with or without a cellular transmission signal. If it does not have a signal it will save the recorded data on in the memory of the smartphone and then transmit it when it gets a signal. Therefore the MASA system has an internal buffer service on the client side of the application.
CHAPTER 3. PROBLEM DESCRIPTION AND PROPOSED SOLUTION 3.2.2 Interchangeable analyses methods It should be possible to add additional analysis methods to the MASA system. To make it easier to get the application to use the new analysis methods it would be preferable to put them on the server side of the MASA system. This will enable a research team or responsible administrator to update a method without seeing to that all the users update their application on the client side of the system. The disadvantage of this solution is that the user needs to transmit the accelerometer data to the server to get the results.
The system architecture should feature future implementation of multiple accelerometer data gathering sessions. This means that the MASA architecture of the services in the client and server side have the ability to be configured so that it can support multiple accelerometer data gathering sessions.
3.2.3 Intuitive interface The application needs to have good user feedback of what's happening on the device, such as status of the accelerometer, connection to the database, session status etc. The interface needs to have restrictions such as locking input fields while in a session and non sensitive buttons to avoid mis clicks on buttons. These requirements are based on experiences that was gained from the research that was conducted during this project.
3.2.4 Interpretable presentation of data There are many methods for measuring and analysing motor and tremor related dys- functions characteristic to PD. Many of these methods would include variety of different techniques for gathering data with an accelerometer. Below I have reviewed some common requirements that are posed on accelerometer analysis methods outside of a lab environ- 1. Relative comparability: To move from arbitrary number or measurement to result that explains a result in terms of good and bad, is done by introducing an appropriate point of reference. An appropriate reference to a result can be done by comparing the subject to other healthy subjects with common non disorder related characteristics or subjects with similar disorder symptoms. For instance a result could be compared to patients within the same age group or disease development.
2. Time independent: The recording time of a session has varied lengths. This means that in order to have an adaptable analysis of the data it needs to be time inde- pendent. In other words longer recording sessions should amount a more precise 3. Spike insensitive: While in a recording session, a user could introduce a spike in the accelerometer data by accidentally bumping the smartphone into a object or shifting their weight in an unexpected way. These accidents could easily go unnoticed and effect a result of an session significantly if not handled properly. There is no way to completely exclude spikes without effecting the result. But there are methods of minimizing the effect of a data spike. But these methods are dependent on what measurement technique is used. Therefore the spike "filtering" should be dealt with with consideration to what measurement technique is used.
4. Noise filtering: In accelerometer measurements there is always the presence of noise fluctuations in the recorded data. It's important to consider the effects of the noise in the analysis method. Handling noise in the data can essentially be done in two different ways: include the noise-data in the recordings and reference material and introduce a certainty variable in the result, or filter out the noise-data when recording the data and compare it to filtered reference material. Choosing between these two methods of handling noise data is dependent on what measurement techniques are used. But either way, the choice of handling the noise problem should result in an interpretable variable with a certainty value of the analysis findings.
So in order to create an analysis method suited for an smartphone accelerometer like the MASA system, these requirements need to be met. Additionally the results of these methods need to be interpretable by a user.
The goals of this research was to gather accelerometer data with a smartphone on a variety of different clinical methods and compare the results of the clinical methods to the accelerometer data. The clinical methods are done by assessing an opinion of a PD patients motor functions. It was conducted with the help at the neurological clinic at Lund University hospital. The main goal of the comparison was to enable an evaluation of the smartphone as an accelerometer tool for diagnosing PD.
An additional goal was to gather knowledge of what requirements would be posed on the MASA system in terms of interface, analysis methods and large scale data gathering 3.3.1 The execution of the research Research included accelerometer recordings of 9 patients diagnosed with PD performing 5 different tasks. A basic accelerometer recording application was first built to provide a platform for assessing the requirements of the final MASA application. The Smartphone used to record the accelerometer data was a Sony ericsson Xperia X10. The smartphone was placed on a patient's right and left bicep in a sport band. It served as a recording tool to collect data from different diagnostic tasks. The tasks that were performed were 1-3, 5 and 7 in the motor function evaluation (Motorisk utvardering) sheet in the appendix.
Accelerometer data was gathered from both arms in tasks 1-3 and 7 while only the right arm was necessary on task 5. The task performance was graded by a specialized nurse or doctor on a scale of 0 to 3. The basic application was very simple. It worked by pressing a start button on the display which initiated the accelerometer recording process.
When the patient was done performing a task a stop button was pressed and the recorded accelerometer data was saved on a file in the smartphone. The file was then transferred via bluetooth over to a laptop.
After the accelerometer data was collected it was analysed through a variety of different numerical methods in MATLAB. The numerical analysis methods included fourier analysis and a RMS breakdown of the data. The results of some numerical methods were then compiled and compared to the findings of the clinical methods. Some of the findings will CHAPTER 3. PROBLEM DESCRIPTION AND PROPOSED SOLUTION be presented in Chapter 5. From the findings an analysis method was created suited for analysing task one (Resting tremor evaluation) in the motor function evaluation sheet.
This analysis method is based on using multiple RMS values to quantify the data into levels so the accelerometer values could be presented. The method will be referred to as the mean-RMS method and it will be described in more detail in Chapter 5.
3.3.2 Experiences gained During the execution of the research the basic application encountered numerous problems that would help determine some important requirements of the final MASA system. These are some problems that the basic application faced during the research.
To press start and stop when recording is problematic even when the patient is assisted with the task. The reason for this is that by just pressing the smartphone introduced errors in the recording because the smartphones hasn't really finished the recording when the button is being pressed. To further add to the previous problem the buttons of the interface also need to be insensitive to light touches. This is because the buttons could be inadvertently pressed when the smartphone is in a sport band. In order to avoid unintentional interaction with a recording session and have long press buttons the sessions needs to be automated. But to have automated recording sessions also implies that for each recording session it needs to have customized settings. The customized settings would include a script for how long the recording session should last and a countdown before the session starts. This solution would satisfy both problems in this section. In addition an automated recording session enables the possibility for using the application alone.
Early in the research it was realized that every recorded task needed to be analysed in an individual way. The reason for this is because the patterns that the tasks created in the accelerometer all have particular patterns that need to have customized analysis methods in order to generate useful data that could potentially be used as diagnostic aid.
During the recording sessions it was found that a lot of work went into documenting where the smartphone was placed and which task the session was associated to. From this it was found that the MASA application needed to have a section for input parameters, such as left or right arm, user id, task number etc.
The Medical accelerometer smartphone application system This chapter includes a description of the first version of the MASA (Medical accelerometer smartphone application) system. The initial goal of this project was to provide the user of MASA with five different accelerometer analysis methods for diagnosing Parkinson's disease. But the initial goal was set too high as creating five different analysis methods would be an overreach of what is possible for me to create in the set time frame to complete this project. The goal of the application was reset to one accelerometer analysis method.
This not a completed system, the unfinished implementation will be detailed in the Future Work section 6.1 page 35.
The clinical resting tremor evaluation is created to provoke symptoms of what is referred to as resting tremor. This is task one in the motor function evaluation sheet seen in the appendix of this report. The patient would be sitting down in a chair with the arms placed on their thighs. The patient is asked to close his or her eyes and count backwards from a 100. The evaluation is done by observing (if apparent) the amplitude of arm tremors under a period of 20 seconds. The amplitude is graded on a scale of 0 to 3, 0 being no visual signs and 3 being very high amplitude of tremor (4 cm tremors).
In its current state the MASA system features analysing accelerometer data from a rest tremor evaluation and displays the result from the analysis. The smartphone is placed on the patients bicep with the help of a sport band. It is during this evaluation the MASA application would be activated to record the patient's movements. All the input parameters of the application and recorded data are currently not saved anywhere but serves as an illustrative purpose for future development.
CHAPTER 4. THE MEDICAL ACCELEROMETER SMARTPHONE APPLICATION The design of the MASA system is Client Server based. The client part is located on the Android part of the system while the server is located outside of a hospital. The Android client is responsible for coordinating a recording session and sending the data to the server for analysis. The server saves and analyzes the recorded accelerometer data and sends it back to the client. The communication between the Server and the Client is established by the PalCom framework. To properly support the PalCom framework the overall architecture needs to satisfy its basic design principles: devices, services and assemblies. For the client to work with the PalCom framework the Android device needs to have The Thing installed. It will enable PalCom services and devices to show up in other PalCom networks, in this case the server side. This is done by setting up a tunnel in The Thing, it will forward all the communication to the other end of the tunnel thus enabling the Server to detect other Android devices and in turn running the MASA application.
The MASA system architecture focuses on the creation of sessions. A session is a collec- tion of data referring to a patient that performed an standardised task. For instance a completed session has collection of accelerometer data that refers to a standardised task.
A session also includes user id and other information relevant to the standardised task such as last time a medication was taken.
4.2.2 The MASA system architecture When Palcom is running on both the server and client side they are capable of commu- nicating with each other with their corresponding assemblies: the Client assembly and server assembly. The assemblies on both sides handles the communication logic with their services. Each service has individual responsibilities, such as providing storage or accelerometer services. Here is an overlay of the MASA system architecture.
Figure 4.1: An overview of the MASA system • GUI service: Creates events that tell the system when to start, stop, reset and save recording data. The GUI is created as an Android Activity, this means that the Service is not always available to the PalCom network. Therefore a PalCom device is needed. The device in turn is hooked up to an ordinary service. This enables the GUI activity to show up as a separate entity in the PalCom network when GUI is activated on the smartphone. The reason for this is that the GUI service is only available when the GUI is active in the android operating system.
• Accelerometer service: It works by a service registering itself as receiver, then the accelerometer will stream accelerometer data to whomever is registered. A receiving service can stop receiving data by unregistering itself from the accelerometer service.
• HD service: Is a buffering service created as a recording session storage point. When the session is started the accelerometer service will stream its data to the HD service.
When its done streaming, the HD service is told to save the data in a bundle and wait for further commands. The HD service is also meant to serve as an offline storage point when the smartphone does not have a connection to the server.
• Analysis service: This is the service that analyses a set of accelerometer data and returns the result to the service that sent the data. In the future it is meant to provide multiple analysis services. The Analysis service uses my custom analysis java classes (Analyzers). There is currently one analysis method, it serves to analyse accelerometer data from a rest tremor evaluation. MATLAB has good support for creating java classes from a matlab function. So it's recommended that the developer creates new analysis functions in MATLAB because it's possible to export them as java classes. Working with analysing methods is preferable to do in MATLAB because it has good support fore just that type of development, This being, creating CHAPTER 4. THE MEDICAL ACCELEROMETER SMARTPHONE APPLICATION mathematical functions that analyse data. Also note that to export java classes you would need a paid certain MATLAB API license.
• Database: This is the final storage location for the accelerometer and user data sessions. This database uses standard units and formats appropriated for research • Database Adapter: A Service that provides a translations of accelerometer and user data sessions to standard units and formats that matches the database.
• Patient Database: The patient database is to be located in a hospital. This is where all the sensitive patient information is stored such as patient identification etc.
4.2.3 Communication The communication logic is done by scripts in assemblies. Scripts are a chain of responses from events. The events are associated to service input and output commands that trigger the events. The client and server assembles communicate with each other by forwarding these commands between each other. Below is a sequence diagram of a typical commu- nication between the services when the MASA system records an event. In this case a resting tremble evaluation session.
Figure 4.2: This is an sequence diagram of the services in the MASA system in a normal recording session case. The red diamonds are user interface interaction or updates (de- pending on arrow direction). The red circles correspondence to the interface states seen in figure 4.3 on page 25 4.3. THE USER INTERFACE Figure 4.3: This is a step by step display of the different states of the MASA user interface.
4.3 The user interface The basic design principles of the application limits the user from unnecessary inactive functions. Such as not displaying a cancel button when there is nothing to cancel. Due to the simple nature of a recording session it is usually not necessary to display more than one button at a time in a recording session. All the buttons in the application feature a long touch click handling. The interface also feature input lock for when the application is in a recording session. The lock is necessary to avoid the input parameters to be accidentally changed during a session.
The red numbers in figure 4.2 on page 24 corresponds to the red numbers seen in figure 4.3.
State 2 in figure 4.3 shows the countdown process before the client initiates the recording process. State 3 is the recording session. State 4 is when the user is presented with a CHAPTER 4. THE MEDICAL ACCELEROMETER SMARTPHONE APPLICATION choice of whether to discard the previous recording or to send it for analysis. State 5 is the analysis result of the recording session, a more detailed description will be featured in 4.4 Requirement comparison In section 3.2.1 it is stated that the application needs to satisfy four basic requirements in order to be able to satisfy the problems that are discussed in section 3.1. There is architectural support for all of the requirements that are discussed but there are features yet to be implemented, such as interchangeable analysis methods, multiple smartphone sessions and offline buffering. These desired implementations are described in more detail in section 6.1.
The system should support a large number of active applications, but it has not been tested yet. The concept of recording sessions is integrated in the architecture although modification is needed for when the MASA application should support multiple analysis methods. Furthermore customized settings is a prerequisite for this to work. By the application having customized settings for every analysis method would enable the client to receive specification of how to adjust its interface accordingly.
The mean RMS method and This chapter is about the rest tremor analysis method that was created during the re- search of this project: The method is referred to as the mean-RMS method and it focuses on quantifying and presenting the data into interpretable components. The goal of this chapter is not to prove that the developed method works but to propose an analysis model for future development. The data that was gathered from the resting tremor evaluation was used to create this method. Data from the resting tremor evaluation of the patients is presented here although not the rest of the evaluations. In the end of this chapter is an evaluation of the mean RMS method. Note that the accelerometer data could be de- pendent on what type of accelerometer and smartphone is used. The Smartphone used to record the accelerometer data was a Sony ericsson Xperia X10.
5.1 The accelerometer data The accelerometer data that was collected has the following parameters: • x, y, z: A vector that describes the physical movement of an accelerometer. To get a grasp of the proportions of the values, the sum of a x,y,z-element with the smartphone laying completely still would approximately add up to 9.8m/s2 (SI units) which is very close to 9.81m/s2(earth's gravational pull).
• t: The timestamp paired with the vector x,y,z.
The x,y,z vector is merged as euclidean distance1 to enable simple analysis of the vector.
The euclidean distance is referred to as k.
1Otherwise known as L2-norm, it's calculated by k = x2 + y2 + z2 where k is the L2-norm CHAPTER 5. THE MEAN RMS METHOD AND RESEARCH RESULTS 5.2 Research results The results from the research include a rating from the specialized nurse who performed the evaluation on 9 patients who participated in the research. The patients task performance was rated on a scale from 0 to 3, 0 being no visual signs of tremor and 3 being very clear signs with arm tremor amplitude up to 4 cm. The right and left arm are evaluated individually. The developed analysis method is created in Matlab but was later translated into java.
There is a lot of additional information connected to the evaluation results: Such as time since last received medication, hand injuries, first apparent symptoms ect.
Patient number 1 2 3 Table 5.1: The left and right arm rows are the result of the clinical rest tremor evaluation.
Patient nbr refers to the different patients that participated in the research. Patient 1 and 2 is not used in this research because the accelerometer data was not gathered from the left arm at that point of the research.
5.2. RESEARCH RESULTS Figure 5.1: The x-axis is time in milliseconds and the y-axis is the euclidean distance of x,y,z, can be seen as m/s2. This data is from the patients left arm.
Some of the data from table 5.1 is plotted in figure 5.1. The gathered data has been divided into 3 groups. Patient 5 and 9 have significant differences result and evaluation, and were thus not included in group 2.
• Group 1: Control group of two healthy males ages 26, 32. The plot in group 1 is a typical representation of that group.
• Group 2: A typical plot of a PD patient (Patient 7) with an evaluated rating of 1. Group 2 includes patients 3-4 and 6-8 and have ratings between mostly 0 and 1.
Their medication was taken on average 2 hours before the accelerometer recording.
• Patient 5: PD Patient with very apparent dyskinesia, rated 1. medication taken right before the recording.
• Patient 9: PD Patient without medication, rated 2.
• Group 3: This group is created to later be used in the mean-RMS section. It includes Patient 5 and 9.
CHAPTER 5. THE MEAN RMS METHOD AND RESEARCH RESULTS 5.3 The mean RMS method This is a custom method meant for analysing accelerometer data from a resting tremor evaluation. Quantifying the accelerometer data and creating interpretable components of it could be done by creating group reference points. The mean-RMS method uses this technique. By selecting different groups of data, lets say group 1 in the previous section, we could create a quantifying area from this control group. This could be done by taking the mean RMS2 value of that group. An RMS value could here be seen as the effective value of an mechanical motion, in this case proper acceleration.
In expression 5.1 ki is accelerometer data set from a group of patients. n is the amount of sets in the group. ↵mean is the mean-RMS line.
Next step is creating mean-RMS values from equation 5.1 on different groups of patients.
In figure 5 we have selected group 1 and group 3 as two different reference points. ↵group1 and ↵group3 includes both left and right arm values. The lines are placed around the mean value of the sample to create quantifying areas. The group 1 line can be seen in figure 6 as a green line and group 3 as a red line.
Figure 5.2: A description of the different areas created by ↵area1 and ↵area3 created by the different ↵mean There are three different areas that ↵area1 and ↵area3 creates in figure 5.2: In (within the green line), Inbetween (outside of green but in red) and Out (outside red). The proportions of the data in three different areas are then calculated. In other words the number of data points in the three different areas divided by the total number of data points in the sample.
area3 ki ↵area1 Expression 5.2 is a set theory annotation of the different proportions.
This results in the proportions in, inbetween and out that can be expressed as percentages.
To make the percentages more interpretable they are expressed here in pie chart form.
2The RMS (root mean square) is calculated rms = mean(x2) where x is a set of data points.
5.4. REQUIREMENT COMPARISON Figure 5.3: This is a pie chart representation of the proportions of data placements within the different areas of the mean-RMS lines created.
When interpreting the pie charts it is important to consider what groups have been used to create the reference lines, or baselines. This is important because the baselines create answers that are relative to which group they are compared to. In this case the baselines are, group 1 and 3. Group 1 creates a standard for what is considered "normal" while the group 3 baseline (consisting of two severe cases) sets the bar for what is considered abnormal tremor.
It is possible to create a point system from the proportions the RMS-method creates. Such as applying weight points to the different proportions. For example: in + intbetween ⇤ 3 + out ⇤ 6 = s This s creates an arbitrary scale that can be compared to findings of clinical evaluation methods. With more statistical data expression 5.1 could be adjusted to create a more accurate categorical scale by using appropriated weights and mean lines for quantification.
5.4 Requirement comparison In section 3.2.4 page 18 it is stated that to have interpretable data, an analysis method of this sort needs to the best of its ability have relative comparability, time independency, spike insensitivity and noise filtering.
The mean-RMS method addresses relative comparability by using different baselines for comparison of the analysis data. These baselines could be selected from a pool of previous patients that can act as good comparison points with parameters such as age group, symptoms, injuries etc. Time independence is achieved through the use of calculating the proportions of the data distribution. This allows the possibility of longer data gathering sessions which would yield a more precise proportion result. In other words the proportion result would converge towards a solution over time. The RMS-method is not completely insensitive to spikes but is not affected by the amplitude of them either, other than that it might be counted as an out element.
CHAPTER 5. THE MEAN RMS METHOD AND RESEARCH RESULTS Figure 5.4: This is a chart of a spike in the data that went unnoticed in the clinical evaluation. The data is from patient 4 left hand.
As seen on figure 5.4 the data spike effects the result but could be negated by an appropriate round off. The RMS-method handles NOISE data not through filtering but by including noise in the creation of the baselines and including the error in the result. Although the noise data is present there is no real error magnification in these calculations. The noise on the accelerometer is about four decimal places.
5.5 Evaluation of the mean-RMS method With expression 5.3 page 31 it is possible to create values that can be compared to an arbitrary scale. By adjusting the weights of function (2) to it is possible to calculate the correlation coefficient between the mean-RMS method results and the clinical evaluation (scaled from 0 to 3). It is important to consider that the result of this evaluation is not fully reliable. The reason for this is that there is a very small amount of clinical evalua- tion results and accelerometer data (that can contain recording method errors) to create intervals for categorization (statistical insignificance). Furthermore the clinical evaluation was conducted by one (experienced) evaluator and thus a slight element of human error present. Therefore this evaluation should only be considered a model for future evaluations and not a precise result.
5.5. EVALUATION OF THE MEAN-RMS METHOD Weight formula 5.4 is applied on the mean-RMS method result gathered from patient 3-9.
intbetween ⇤ 3 + out ⇤ 4 = s The result of the weight formula is seen together with the clinical rest tremor evaluation in this plot.
Figure 5.5: This plot is weight formula 5.4 versus the evaluated value of the patients. The red circles represent the patients left arm while the blue is there right. The numbers on the circles corresponde to patients numbers in table 5.1 on page 28.
The calculated correlation coefficient3 between the clinical evaluation and the mean-RMS weight column is approximately r = 0.63 which is moderate result. Another way to calculate the correlation is by using Spearman's rank4 that yields r = 0.72 and p < 0.01.
The correlation coefficients varied depending on what weight function was used, so the correlation could be higher if a better weight function is found. A better correlation could also be achieved by using different baselines depending on what patient that is being 3The Pearson product-moment correlation coefficient. for more information se http://en.wikipedia.
4It is like Pearson product-moment correlation but instead uses a "grade correlation", for more infor- CHAPTER 5. THE MEAN RMS METHOD AND RESEARCH RESULTS 5.5.2 Related work and discussion There have been several proposed accelerometer-based systems that identify changes in movement charecteristics assosicated with PD in domestic enviroments. The method used in "An ambulatory dyskinesia monitor"[7] included using a triaxial accelerometer worn on the shoulder that recorded levodopa-induced dyskinesia. The recorded data was compared to mean clinical accelerometer scores5 and yielded an r = 0.972 with and p < 0.001 (Spear- man's rank). The ambulatory dyskinesia monitor study has used a different approach for calculating mean acceleration of the data compared to the mean-RMS method. Here the translation of the accelerometer data was done by using a finite fourier transformer with preset time intervals to create mean acceleration amplitude blocks that could be compared to manually created arbitrary scores.
In "Ambulatory Motor Assessment in Parkinson's disease"[5] a more comprehensive tech- nique was employed through the gathering of triaxial accelerometer data from six different parts of the subject. The work included developing an algorithm that could distinguish between the on and off states6 during a PD patients daily life activities. Among the results it was concluded that gathering data from the trunk area of the body yielded a sensivity of 0.97.7 and 0.96 in specificity by analysing the peak frequencies of the subjects tremor.
Taking into account the data from related works, the results from using the mean-RMS method (spearman rank of 0.72) are encouraging especially considering that the method is in earlier stages of development. There is also the option of implementing and further evaluating the methods applied in related works in the MASA system as they do not require any other hardware than the triaxial accelerometer provided by a smartphone.
5The score was based on the AIMS and the Goetz score, much like the motor function evaluation score performed in this project 6This is one way of describing levodopa induced dyskinesias (LID) 7A statistical measument of performance of a binary classification test. http://en.wikipedia.org/ Summary and future work This chapter includes a summary of the android application and the mean RMS method.
It also includes a section on future work, which focuses on areas where MASA application and analysis methods could be improved or developed.
Much of the future work is drawn from the purposes solution section 3.2.1 to 3.2.4 page 17 to 18 the four base requirements 6.1.1 Development work Databases. The Database, Database Adapter and Patient Database needs to be set up so the MASA system can store the result from data gathering sessions. This is also a useful feature during future analysis method development.
Offline support. The android device should be able to store accelerometer data in its memory when there is no connection to the server. The stored data should be sent to server once the application establishes a connection.
Multiple analysis methods. There is need for the application to feature more analysis methods that can potentially serve as clinical motor function evaluations. The application should have interface support for choosing which type of evaluation that should be per- formed. This results in changes of how a session is created, in other words a session needs to feature what type of tasks that are being performed and possibly what analysis method that should be used.
Multiple accelerometer recording session support. There are two reasons for the implementation of Multiple accelerometer recording session support. The first reason is that there are many research projects that use multiple accelerometers in an attempt to gain insight into complex motor functions. The second reason is that it could accelerate recording sessions of patients significantly. Many evaluations require gathering accelerom- eter data from many locations of the patient's body, such as left and right arm. Two CHAPTER 6. SUMMARY AND FUTURE WORK smartphones can gather data simultaneously which would decrease recording session time 6.1.2 Mean RMS method work For the MASA system to feature more analysis methods, more insight into accelerometry and how clinical studies are designed would be required.
• The mean-RMS method has not been clinically proven yet is a viable method to be included in a clinical research. Such studies can be designed to gather data from different patient categories and establish better baselines for e.g. specific age-intervals or stages or presentations of PD.
• Function 5.3 page 31 can be used to create an arbitrary scale to correlate the mean- RMS methods result with clinical motor function evaluation method used in patients today. Improvements to this function could be done by adjusting the weights (the multipliers) so it results in a higher correlation rate.
There have been plenty of studies in the gait, stroke and PD research community that focus on advancing methods for motor function evaluations with use of an accelerometer.
Many of these studies have been inhibited by the cost of instruments that are required in this kind of research. This project has attempted to show that a smartphone with a built in accelerometer has the potential to serve as a cheap and viable tool in large clinical studies. Initial research led to the establishment of four basic requirements that needed to be met in order to satisfy the needs of users, these being multiple analysis method support, large scale data gathering capabilities, intuitive interface and interpretable presentation of the data. An additional goal was to test the application by gathering accelerometer data from patients diagnosed with PD. Accelerometer data was gathered from 9 patients with PD performing 5 differents tasks from a motor function evaluation sheet. The gathered accelerometer data helped create the mean-RMS method, which is customised to analyse data for rest tremor evaluation.
After the four requirements were formulated, the MASA system was developed. It features an android application built as a client that connects to a central server. The purpose of the server is to analyse and store results from a recording session done by the android client application. A session is a collection of accelerometer data recorded from a patient that has performed a standardised task. The MASA system makes use of the PalCom framework to achieve a scalable and flexible internal communication architecture. The MASA system is modeled after the PalCom designing principles: assembles, services and devices. For the application to be used it makes use of PalCom on the android platform "The Thing" installed on the device. This enables an android application to make use of the PalCom framework.
The MASA system in its current state is capable of performing a rest tremor accelerom- eter data analysis for research and demonstration purposes. The application features an interpretable presentation of the result in the form of a pie chart. The MASA system could potentially make use of existing methods [1-7] to help further development in featuring more analysis methods from the clinical evaluation methods sheet. If the application is to be used by patients on a large scale, additional analysis methods need to meet four basic requirements i.e. relative comparability, time independence, spike insensitivity and noise filtering. The mean-RMS method satisfies these requirements to a large degree. The mean-RMS method result is relative to what subject group it is compared to (relative comparability). The result approximates over time due to calculating data placement pro- portions around established baselines (time independent). The method is not completely insensitive to spikes but is not affected significantly by a few random ones. Noise data is included in the creation of the baselines and does affect the result significantly but there is need for it to be highlighted in the result. The performance of the mean-RMS method is currently rated to moderate with a Pearson product-moment correlation of 0.63 and a spearman rank of 0.72. It could be improved by using a better weight function and more accurate baselines.
[1] Gitendra Uswatte, Wolfgang H. R. Miltner, Benjamin Foo, Maneesh Varma, Scott Moran, and Edward Taub. Objective Measurement of Functional Upper-Extremity Move- ment Using Accelerometer Recordings Transformed With a Threshold Filter Stroke. 2000;31:662- 667, doi:10.1161/01.STR.31.3.662[2] Justin J. Kavanagh, Hylton B. Menz, Accelerometry: A technique for quantifying movement patterns during walking, Gait and amp; Posture, Volume 28, Issue 1, July 2008, Pages 1-15, ISSN 0966-6362, 10.1016 j.gaitpost.2007.10.010.
[3] Martina Mancini, Fay B. Horak, Cris Zampieri, Patricia Carlson-Kuhta, John G. Nutt, Lorenzo Chiari, Trunk accelerometry reveals postural instability in untreated Parkinson's disease, Parkinsonism and amp; Related Disorders, Volume 17, Issue 7[4] Fazio, Patrik, Granieri, Gino, Casetta, Ilaria, Cesnik, Edward, Mazzacane, Sante, Caliandro, Pietro, Pedrielli, Francesco, Granieri, Enrico. Gait measures with a triaxial ac- celerometer among patients with neurological impairment, Neurological Sciences, Springer Milan, (2012)[5] Keijsers, Noel L.W, Horstink, Martin W.I.M, Gielen, Stan C.A.M. Ambulatory motor assessment in Parkinson's disease. Wiley Subscription Services, Inc. A Wiley Company.
(2006)[6] Noel L.W Keijsers, Martin W.I.M Horstink, Stan C.A.M Gielen, Movement param- eters that distinguish between voluntary movements and levodopa-induced dyskinesia in Parkinson's disease, Human Movement Science, Volume 22, Issue 1, February 2003[7] Manson AJ, Brown P, O'Sullivan JD, Asselman P, Buckwell D, Lees AJ. An ambulatory dyskinesia monitor. J Neurol Neurosurg Psychiatry. 2000;68:196âĂŞ201. doi: 10.1136 jnnp.68.2.196.
[8] Svensson Fors, D., Magnusson, B., Gestegard Robertz, S., Hedin, G., Nilsson- Nyman, E.: Ad-hoc composition of pervasive services in the palcom architecture. In: Proceedings of the 2009 international conference on Pervasive services. ICPS '09, New York, NY, USA, ACM (2009) 8392[9] Sieling, J and Moon. JPerformance of Smartphone On-Board Accelerometers For Recording Activity, http://www.actipal.com/MEI-TOS2011-Onboard_Accelerometer.
pdf. Nature publishing group, New york (11/2011)

Source: http://sam.cs.lth.se/ExjobGetFile?id=501