Collecting activity data using the Open mHealth platform An exploratory study on integrating objective data with sport monitoring systems Daniel Gynnild-Johnsen , Lars-Erik Holte Master’s Thesis Spring 2017 Collecting activity data using the Open mHealth platform Daniel Gynnild-Johnsen Lars-Erik Holte May 2, 2017 Abstract Football players works together as a unit to perform on an elite competi- tive level, and the most minor abnormalities can determine the outcome of a match. Success can often be the result of healthy, uninjured and rejuve- nated players working together as a collective. Even though it is impossible to control all outcomes and scenarios, the risk of failure might be mini- mized by monitoring players closely on an individual level. If we monitor players over a longer period of time we might discover patterns or abnor- malities in their training. This information can be used to avoid multiple scenarios related to fatigue, injuries and overtraining. In this thesis we present a proof of concept for expanding an existing self- reporting monitoring system called pmSys, and look at how football teams and players can utilize modern technology like phones and wearable de- vices to capture objective data. This system will collect and store the data, which can be processed into useful visualised feedback, and help a team to evaluate their players. This way the coaches can make mitigating mea- sures to improve certain aspect that might be lacking on a player or team level. By eliminating the use of pen and paper, pmSys introduces a simpler way of reporting the players’ health status. By expanding the system with objective data, the team performance can effortlessly be evaluated and ad- justments made if needed. Compared to the subjective data, which are a player’s assessment of themselves and their health, objective data is not as simple to tamper with and rarely lies, and can more accurately determine a player’s performance state. We believe this monitoring system can help giving a team the advantage to succeed. ii Contents 1 Introduction 1 1.1 Background . .1 1.2 Problem definition . .2 1.3 Limitations . .2 1.4 Research methods . .3 1.5 Main contributions . .3 1.6 Outline . .4 2 Related Work 6 2.1 GPS . .6 2.2 Wearables . .7 2.2.1 Accelerometer . .8 2.2.2 Gyroscope . .8 2.2.3 Altimeter . .8 2.3 Mobile health . .8 2.4 Ohmage . .9 2.5 Open mHealth . 10 2.6 Docker . 11 2.6.1 Composing a docker container . 12 2.7 MongoDB . 13 2.8 OAuth 2 . 14 2.9 Third-party data sources . 16 2.10 Athlete Monitoring . 18 2.11 Summary . 19 3 Shimmer 20 3.1 Shimmer components . 20 3.1.1 Shims . 21 3.1.2 Resource server . 21 3.1.3 Console . 21 3.2 Schema . 23 3.2.1 Design principles . 24 3.3 Grant Type: Authorization Code . 26 3.4 Installation . 28 3.5 GPS in Shimmer . 28 3.6 Summary . 30 iv 4 Runkeeper and Health Graph 32 4.1 Runkeeper . 32 4.1.1 Runkeeper application . 32 4.1.2 Wearable hardware . 33 4.1.3 GPS accuracy . 33 4.2 Health Graph . 34 4.2.1 API . 34 4.2.2 Health Graph console . 35 4.2.3 Limitations . 36 4.3 Summary . 36 5 PmSys 38 5.1 Current pmSys . 38 5.1.1 PmSys Mobile Application . 38 5.1.2 PmSys-trainer . 39 5.2 PmSys with objective data . 40 5.2.1 Motivation . 40 5.2.2 Injecting shimmer into the backend . 40 5.3 Summary . 41 6 Testing 42 6.1 Using Shimmer . 42 6.2 Using bash script . 43 6.3 Summary . 44 7 Proof of concept 46 7.1 System requirements . 46 7.1.1 Functional requirements . 46 7.1.2 User stories . 47 7.1.3 Non-functional requirements . 47 7.2 Working with Shimmer . 49 7.2.1 GPS schema . 49 7.2.2 GPS data point mapper . 52 7.3 Connect pmSys user to Runkeeper . 53 7.4 Fetch data from Runkeeper . 58 7.4.1 Scheduling requests . 64 7.5 Database storage . 66 7.5.1 Replication . 66 7.5.2 Concurrency in MongoDB . 68 7.5.3 Big data . 71 7.5.4 Database optimization . 74 7.6 Summary . 75 8 Conclusion 77 8.1 Summary . 77 8.2 Main Contributions . 77 8.3 Future work . 78 8.3.1 PmSys frontend . 79 v 8.3.2 PmSys backend . 79 8.3.3 Aggregation of data . 81 Appendix A Accessing the source code 85 vi List of Figures 2.1 Wearable forecast . .7 2.2 Ohmage system architecture . .9 2.3 Open mHealth architecture . 11 2.4 Difference between Docker and VM . 12 2.5 MongoDB data collection . 14 2.6 JSON team sample . 14 2.7 OAuth 2.0 Protocol flow . 15 2.8 Worldwide smartphone OS market share . 18 3.1 Shim workflow architecture . 20 3.2 Adding client id and secret in the console . 22 3.3 List of added APIs in the console . 23 3.4 JSON schema sample . 26 3.5 OAuth access token example . 27 3.6 Grant type: Authorization code flow . 28 3.7 JSON raw data . 29 3.8 JSON shimmed data . 30 4.1 Actions during activity recording . 33 4.2 JSON team sample . 35 4.3 Open Health developer console . 36 5.1 RPE scale . 38 5.2 PmSys-app flow . 39 5.3 PmSys backend . 39 5.4 Isolated pmSys backend with shimmer . 41 7.1 Calories burned sample data . 50 7.2 Shimmed GPS data from Runkeeper . 52 7.3 Application registration in Runkeeper . 54 7.4 Logical model of the authorization table . 54 7.5 Service data collection . 55 7.6 Service authorization data collection . 55 7.7 Sequence diagram: Connect to Runkeeper . 56 7.8 Connect mockup . 57 7.9 Logical model of the activity table . 58 7.10 Activity data collection . 59 7.11 Sequence diagram: Fetch daily data . 64 7.12 Modified JSON response . 67 viii 7.13 Database deadlock . 69 7.14 Concurrency flowchart . 70 7.15 Horizontal database sharding . 71 7.16 Big data . 72 7.17 Distributed database . 73 ix List of Tables 2.1 Currently supported shims and requestable measures . 16 2.2 Supported APIs and requirements . 17 3.1 Examples of Unified Code for Units of Measure . 25 6.1 Shimmer non-detailed test results . 43 6.2 Shimmer detailed test results . 43 6.3 Bash script non-detailed test results . 44 6.4 Bash script detailed test results . 44 7.1 User stories . 47 7.2 Crontab entry parameters . 65 7.3 Crontab keywords . ..