e-Publications@Marquette
e-Publications@Marquette
Master's Theses (2009 -)
Dissertations, Theses, and Professional
Projects
Towards Developing A Mobile-Based Care for Children with ASD
Towards Developing A Mobile-Based Care for Children with ASD
using Remote Experience Sampling Method (mCARE)
using Remote Experience Sampling Method (mCARE)
Dipranjan Das
Marquette UniversityFollow this and additional works at: https://epublications.marquette.edu/theses_open
Part of the Computer Sciences Commons
Recommended Citation
Recommended Citation
Das, Dipranjan, "Towards Developing A Mobile-Based Care for Children with ASD using Remote Experience Sampling Method (mCARE)" (2020). Master's Theses (2009 -). 633.
by Dipranjan Das
A Thesis submitted to the Faculty of the Graduate School, Marquette University,
in Partial Fulfillment of the Requirements for the Degree of Master of Science
Milwaukee, Wisconsin December 2020
REMOTE EXPERIENCE SAMPLING METHOD (MCARE)
Dipranjan Das Marquette University, 2020
Autism Spectrum Disorder (ASD) is the most prevalent among all of the
neurodevelopmental disorders, which have increased 20-30 times in the last 50 years. A child with ASD requires regular monitoring, care, and support. But, the existing social-cultural-financial constraints and the scarcity of mental health care practitioners have deprived the families raising children with ASD in low-and middle-income countries (LMICs) like Bangladesh. However, the recent overwhelming adoption (∼80%) of mobile phones has created an opportunity to improve the existing practice of care using affordable mobile applications. mCARE, a mobile-based care system, has been developed to reduce the gap between families raising a child with ASD and psychologists with the help of the latest technology using a remote Experience Sampling Method (ESM). In the system, behavioral and developmental parameters of the patients are collected regularly. Three tools: mCARE-APP, mCARE-SMS, and mCARE-DMP, have been designed and implemented for the mCARE system. All of these allow caregivers to report routinely and systematically and thus build the personal records of behavioral progress for each child with ASD. Thus the system will definitely help psychiatrists and psychologists improve and expedite the decision-making process by viewing appropriate visualization tools along with different kinds of reporting to summarize this information.
ACKNOWLEDGMENTS
Dipranjan Das
Throughout this thesis I have received a great deal of support.
I would like to thank first my supervisor, Dr. Sheikh Iqbal Ahamed for his invaluable support throughout this research. I am also grateful to Dr. Munirul Haque for his guideline and suggestion for this project. My other committee members Dr. Abdur Sikder and Dr. Anik Iqbal also helped throughout this dissertation. I would like to thank the Graduate School and all of the Marquette University administration.
I would like to thank the Ubicomp Lab and the lab members for supporting and inspiring me to complete this long journey.
Finally, I would like to thank my beloved Parents and Parama Sridevi for keeping me inspired and supporting me in every step.
DEDICATION
This dissertation is dedicated to my parents, Mr. Haripada Das and Mrs. Dipali Rani Das, who relentlessly encouraged me to strive for success.
TABLE OF CONTENTS
ACKNOWLEDGMENTS . . . i
DEDICATION . . . ii
LIST OF FIGURES . . . vi
1 INTRODUCTION . . . 1
1.1 Autism Spectrum Disorder (ASD) . . . 1
1.2 ASD in Low and Middle-Income Countries (LMIC) . . . 1
1.3 Mobile Technology . . . 1
1.4 mHealth and ASD . . . 1
1.5 mCARE System . . . 2
2 BACKGROUND, MOTIVATION AND RELATED WORKS . . . 3
2.1 Prototyping . . . 3
2.2 User Interface Design . . . 3
2.3 Separating the Modules and Services . . . 4
2.4 Privacy and Security . . . 4
2.5 System Scalability . . . 4 2.6 Related Works . . . 5 3 REQUIREMENT ANALYSIS . . . 6 3.1 Specific Aims . . . 6 3.2 Workflow . . . 7 3.2.1 Parameters . . . 7 3.2.2 Patient Enrollment . . . 8 3.2.3 Intervention . . . 8 3.2.4 Triggers . . . 8 3.2.5 Data Analysis . . . 9
3.3 Security and Privacy . . . 9
4 SYSTEM DESIGN . . . 10
4.1 Principles . . . 10
4.2 Components and Services of mCARE . . . 11
4.3 Deployment . . . 12
5 FEATURES OF THE SYSTEM . . . 14
5.1 mCARE-DMP . . . 14
5.1.1 Access Roles . . . 14
5.1.2 Login and Password Change . . . 14
5.1.3 Enrollment . . . 14
5.1.4 View Patient . . . 18
5.1.5 Edit Contact Information . . . 18
5.1.6 Edit Parameters . . . 18
5.1.7 Longitudinal View . . . 19
5.1.8 Triggers . . . 21
5.1.9 End of Study . . . 23
5.1.10 Data Analysis . . . 23
5.1.11 Compare Multiple Children . . . 26
5.1.12 Portal for Caregiver . . . 27
5.1.13 Language Support . . . 28 5.2 mCARE-APP . . . 28 5.2.1 Login . . . 29 5.3 mCARE-SMS . . . 32 5.4 SMS Gateway . . . 33 5.5 API Service . . . 35 5.6 Email Module . . . 35
5.7 Cron Job . . . 35
6 IMPLEMENTATION DETAILS . . . 36
6.1 Platforms . . . 36
6.2 Architecture . . . 36
6.3 Design and Implementation . . . 36
6.3.1 Database Models . . . 36
6.3.2 Smartphone Applications . . . 40
6.4 Model View Controller (MVC) Pattern . . . 41
6.5 Deployment and Scalability . . . 41
7 ANALYSIS, LIMITATIONS, IMPACT AND FUTURE WORK . . . 42
7.1 Self Evaluation . . . 42 7.2 Extensibility . . . 42 7.3 Application . . . 42 7.4 Limitations . . . 42 7.5 Impacts . . . 43 7.6 Future Work . . . 43 BIBLIOGRAPHY . . . 44 A APPENDIX . . . 48
A.1 Tools and Technology . . . 48
A.2 Parameters . . . 48
A.2.1 Behavioral Parameters . . . 48
LIST OF FIGURES
5.1 Login screen . . . 15
5.2 Patient enrollment . . . 15
5.3 Behavioral Parameter Selection . . . 16
5.4 Enrollment validation . . . 17
5.5 List of patients . . . 18
5.6 Patient Profile . . . 19
5.7 Edit behavioral parameter . . . 20
5.8 Edit milestone parameters . . . 20
5.9 Longitudinal view select parameters . . . 21
5.10 Longitudinal report . . . 22
5.11 Longitudinal report run-time update . . . 22
5.12 Setting triggers . . . 23
5.13 Aggregated missing data . . . 24
5.14 Missing data calendar view . . . 25
5.15 ASD knowledge base of patients . . . 25
5.16 ASD knowledge base improvement . . . 25
5.17 SMS failure report. . . 26
5.18 Compare multiple patients . . . 27
5.19 Bi-Weekly report . . . 28
5.20 Previously generated Bi-Weekly reports . . . 28
5.21 App login . . . 29
5.22 Login with invalid credential . . . 29
5.23 App home after login . . . 30
5.25 Password change option . . . 31
5.26 Password change . . . 31
5.27 Set intensity scores . . . 32
5.28 Intensity score submission error . . . 32
5.29 Setting all the scores . . . 33
5.30 Home after submission . . . 33
5.31 Bi-Weekly reports . . . 34
5.32 Previous bi-weekly reports . . . 34
5.33 Caregivers received and replied scores via SMS . . . 34
6.1 Architecture diagram . . . 37
6.2 User model structure . . . 37
6.3 Behavioral models . . . 38
6.4 Milestone models . . . 38
6.5 Models for gateway . . . 39
LIST OF CODES
6.1 HTTPRequest . . . 40 6.2 HTTPRequestHandler . . . 40 6.3 Cron jobs . . . 41
CHAPTER 1
INTRODUCTION
1.1 Autism Spectrum Disorder (ASD)
Autism Spectrum Disorder (ASD) is the most common among all the
neurodevelopmental disorders. In the last 50 years, it has increased 20-30 times [52] and affects 1% of the population in the U.S. and abroad [7, 38], including Bangladesh [33, 40, 35]. Though it has an alarming impact, ASD is often underestimated, and many cases remain untreated because of a lack of awareness [29].
1.2 ASD in Low and Middle-Income Countries (LMIC)
In low- and middle-income countries (LMICs) like Bangladesh, families that have children with ASD often face a huge gap between the care needed for those children and the existing practitioner-family care mechanisms [54]. In these countries, social-cultural-financial constraints and a scarcity of mental health care practitioners have deprived families raising children with Autism Spectrum Disorder (ASD) of regular monitoring, care, and support. Despite making notable progress in ASD screening and raising awareness in recent years, the healthcare support system is limited for families raising children with ASD in these countries. The situation is even worse in rural areas, since most of the practitioners are located in urban cities. Families visit ASD practitioners infrequently, which forces the practitioners to make intervention decisions based on a few unreliable, recall-biased [44, 56, 57] data points. In addition, the practitioners hardly receive any feedback once the caregivers leave the clinic. In Bangladesh, at present, approximately 200 psychiatrists and 50 psychologists are serving up to 160 million people [53].
1.3 Mobile Technology
The overwhelming adoption (∼80%) of mobile phones in Bangladesh in recent years has created an opportunity to improve the existing practice of care using affordable mobile
applications. According to the Bangladesh Telecommunication Regulatory Commission (BTRC), for December 2019, there were 165.572 million mobile subscribers in Bangladesh [14].
1.4 mHealth and ASD
Most previous research on ASD has been limited to developed English-speaking or wealthy Asian countries [4, 46, 31, 32, 37]. Research in the domain of ASD in LMICs is mostly
done in the area of screening [26, 36, 22]. Although a few mHealth tools exist that, in a limited capacity, serve for monitoring mental health diseases in LMICs, [23, 21, 47] those cannot
accommodate the wide variety, individual nuances, and the uncertain patterns of ASD. Also, most mHealth applications for health data collection are built considering health data will be collected by physicians or health care workers [43, 24, 25, 39].
1.5 mCARE System
In this thesis, we describe the requirements, development, and deployment of an mHealth system called mCARE, targeted to LMICs to assist doctors and patients in identifying and
reporting ASD symptoms and behaviors, along with analysis and reporting for tracking
improvement. Three tools: mCARE-APP, mCARE-SMS, and mCARE-DMP, have been designed and implemented for the mCARE system. All of these allow caregivers to report routinely and systematically and thus build the personal records of behavioral progress for each child with ASD. Thus the system will definitely help psychiatrists and psychologists improve and expedite the decision-making process by viewing appropriate visualization tools along with different kinds of reporting to summarize this information.
CHAPTER 2
BACKGROUND, MOTIVATION AND RELATED WORKS
New technologies depending on smartphones are providing a promising connectivity paradigm. mHealth tools are using the advantage of this paradigm to reduce the distance between a patient and a doctor. To develop an mHealth system, some key issues should be considered, which are discussed in this chapter.
2.1 Prototyping
In the Software Development Life Cycle (SDLC) [15], prototyping is a very popular working model where a simple prototype is developed, which mostly contains user interfaces and requires little internal logic to work [16]. Prototyping does not contain the final logic; however, it is very important to finalize the features, workflow, and system architecture design. The
prototype of a system helps to get an overview of the system, and it provides a model to discuss with others to get insightful feedback.
2.2 User Interface Design
User interface design is one of the most important aspects of a user-friendly system. A smooth User Interface (UI) with proper User Experiences (UX) is required to make a system user-friendly. There are different considerations of the user interface for both web portals and smartphone applications. For example, a web portal should contain a proper navigation system with shortcuts and accessible links to frequently used features, while a smartphone application should consider proper sizing issues of the UI components, because it may run on devices of different sizes. There are Human-Computer Interaction (HCI) guidelines to design user interfaces for both smartphone and web systems [20].
The target end-users of the mCARE system are doctors and parents/caregivers of children with ASD. Most of the consumers of the system will not be proficient at using modern technologies. Some of the patients will not be comfortable even to use the SMS service of a phone. To make an mHealth system convenient, especially for the general population of an LMIC, the system must contain a proper user interface and user experience so that the consumers are comfortable using it, and can get a smooth user experience for the best outcome.
2.3 Separating the Modules and Services
A software system usually is a combination of various small modules and micro-services. Modules are programming level constructs that encapsulate a piece of simple task or logic for reusing by other parts. On the other hand, a micro-service is a loosely coupled, small, and independent deployable piece of software that aims to serve a very specific task that could be a part of a bigger system. It is important for a system to identify and separate different modules and required services, because a loosely coupled modular design makes a software strong to scale and evolve in the future. The modularity of a system also increases test-ability and stability because individual modules can be tested independently to ensure that nothing else is broken by changes to other parts of the system [55].
2.4 Privacy and Security
One delicate concern of any mHealth tool is the security of the system and privacy of the data, because mHealth tools generally deal with sensitive medical information of patients. These systems need to maintain specific Health Insurance Portability and Accountability Act (HIPAA) [12] controls, provided by the Centers for Disease Control and Prevention (CDC). There are specific guidelines about how to store data, how to keep the privacy of it, and how to secure a system that is deployed for research.
Alongside the increase in technological advancement, security threats are also increasing. HIPAA specifies security measures to be taken for any system that works with medical
information to prevent it from being breached. This includes communication security, data storage security, data backup security, and all other safety measures that are related to the deployment architecture of a system.
Moreover, HIPAA guidelines are also concerned about data privacy. For example, any personal information cannot be shared without the consent of a patient. The schema that contains medical information should be de-identifiable to the corresponding patient. These measures are important to consider before designing a system, because this will directly affect the backend model design of the system. Any mHealth tool needs to make sure it is following all these specifications correctly.
2.5 System Scalability
The scalability of a system is an attribute to increase its capacity and functionalities to comply with the increased demand for usage. Scalable systems can remain stable with an
increased amount of load, and they are adaptable to futures changes of features. In the USA, 81 percent of adults have a smartphone, and over 60 percent of them are using different kinds of mHealth tools. [1]. The usage of these apps is being increased gradually. Moreover, features provided in mHealth tools are also being increased with the use of the latest technological inventions. Therefore, mHealth tools should be scalable both in terms of workload and feature extendability.
2.6 Related Works
Children having ASD are found almost in every society and country. In order to address the widespread problem, many research works have been performed but most of them had small and limited objectives. Among those research works, some well recognized approaches have been described in this section.
In [28], the proposed approach was based on mobile phones in LMICs. This research targeted at finding the obstacles behind the proper treatment of ASD affected children. The authors found a set of technical, cultural, and social challenges associated with ASD and roposed some design implications to overcome those challenges.
In [49], the real-time data collection for ASD affected patients by using smart technology (such as: wearable and mobile devices) has been discussed. The approach was a review-based approach from 149 peer-reviewed articles that were related to the children with ASD. They found that technology should be used for real-time data collection, identification of points-of-interest and effective real-time adaptation of the user. Their findings also showed that this technology should strive to blend-in with an everyday object.
The development of the picture exchange communication (PECS) was a mobile-based research targeted at ASD children’s caregivers [50] . A practice session was performed of this PECS learning with the ASD affected children’s parent so that they could communicate with their children through this method. This approach was developed in five stages: a. analysis, b. design, c. development, d. implementation, and e. evaluation, in all as known as “ADDIE.”
CHAPTER 3
REQUIREMENT ANALYSIS
The development of the mCARE system [34] is a part of an NIH research grant entitled Mobile-Based Care for Children with Autism Spectrum Disorder Using Remote Experience Sampling Method (mCARE) [13]. From the grant, along with previous and ongoing research, we have identified the requirements and key concerns that should be contained in this system. This chapter explains the requirements that should be served by the system and modularisation of different services.
3.1 Specific Aims
As mentioned before, the number of the practitioners (psychiatrists or psychologists) compared to patient load is very low in LMICs. Most of these patients are not content with the use of the latest technologies. The mCARE system aims to serve families raising children with ASD by getting regular monitoring, care, and support from practitioners and reduce the gap between these families with practitioners by the usage of the latest technologies.
Practitioners are interested in monitoring some parameters of children with ASD, some of which include:
• Repetition of the same word • Use of meaningless words
• Points to at least 5 body parts when asked • Listens to a story for at least 15 minutes
The mCARE will contain these parameters, along with others, beforehand in the system. When enrolling a patient into the system, the practitioner will be able to select suitable parameters from the system for that patient. They will also be able to select the frequency of parameters
individually, which defines the intensity to monitor those parameters.
The caregiver (parent or any relative of the children with ASD) will be using a smartphone app or communicate with mCARE using the SMS service, depending on their socioeconomic condition and proficiency in using technology. mCARE will ask about the selected parameters through the smartphone app or SMS. Caregivers will reply using the app or only by an SMS reply, and mCARE will store the information.
Practitioners will be able to view the parameter data submitted by caregivers in different formats. The data analysis part of the system will guide practitioners to get the overall progress of the children with ASD by different types of reporting and graphs. The practitioners will also be able to set trigger values for any specific parameters for any patient. If the value of the parameter crosses the limit of the defined trigger value, mCARE will notify practitioners so that they can take any necessary actions.
Another requirement of the system is the language support. As the target patients could be from rural areas, some of them might not be well educated. To use this system in LMIC countries like Bangladesh, this system needs to support multiple languages for the parameters.
3.2 Workflow
The workflow of how a patient will be involved with this service and how the practitioners will use it is described in this section.
3.2.1 Parameters
The practitioners will be able to monitor some parameters of children with ASD regularly, as mentioned before. There are two kinds of parameters to monitor, and they can be distributed into categories.
• Behavioral Parameters • Milestone Parameters
– Communication
– Daily Living Skills
– Socialization
– Motor Skills
Moreover, there two distinct sets of milestone parameters for the age groups of children – those age 6 years old or younger, and those older than 6 years. The behavioral parameters can be monitored with different frequencies. The frequency to observe these parameters can be:
• Daily • Weekly • Bi-Weekly • Monthly
The milestone parameters can be monitored with an interval of two months. All these parameters will be built into mCARE after deployment and before practitioners and caregivers start using this system.
Caregivers will submit the score for each parameter to express severity. Behavioral parameters will be scored on a scale of 0-10, and milestone parameters will be scored on a scale of 0-2, depending on severity.
3.2.2 Patient Enrollment
The life-cycle of a patient in mCARE will start with the enrollment of a child with ASD along with the related information. The enrollment part can be categorized into four sections:
• Demographic Information: collect all demographic information related to patient
• Behavioral Parameters: select behavioral parameters to monitor along with the frequency • Milestone Parameters: show the correct set of milestone parameters depending on the age
of the patient and let the practitioner select from different categories
• Other Information: mCARE will collect some information about the status before using the service along with a knowledge base. mCARE will collect and use this information later to evaluate how patients are being benefited through use of the system
After enrolling a patient, a credential will be generated for the caregiver. Caregivers will require this credential to activate the smartphone app. They will also be able to login to the web portal (described below) of mCARE to view their information.
3.2.3 Intervention
mCARE will collect scores for each parameter regularly depending on the defined frequency. Caregivers will use a smartphone app or SMS service, depending on their choice and technical proficiency. The mCARE app will show a notification to submit scores, and caregivers will be able to submit using the app. Caregivers who are subscribed to the SMS service will receive an SMS containing parameters for that day and specific instructions on how to submit scores. They can reply to that SMS, and mCARE will store that data by parsing it.
3.2.4 Triggers
After enrolling a patient in the system, practitioners will be able to set triggers for any specific parameter for any specific patient. Triggers can be set with a limit value and criteria (greater or less). If the submitted score of that parameter crosses its limit, depending on the set
criteria, mCARE will generate a trigger and will notify the corresponding practitioner.
Practitioners will be able to change trigger limit value or activate or deactivate any trigger any time during the life-cycle of a patient in mCARE.
3.2.5 Data Analysis
mCARE will provide detailed reporting to the practitioners in different ways so that they can have an overview of a patient, see details of day to day progress, and even compare multiple patients. The system also needs to provide information about which patients are failing to submit data so that practitioners can follow up regarding their patient’s well-being.
3.3 Security and Privacy
The architecture design of mCARE is HIPAA compliant and considers all kinds of security and privacy measures. Access to the web portal is secure (HTTPS), and client-server communication is also secure.
The back-end model design will follow HIPAA guidelines so that tables containing medical information will not contain user information. The security threats e.g. SQL injection [19], Cross-Site Scripting (XSS) [6], Cross-Site Request Forgery (CSRF) [5] need to be addressed.
Data privacy is also considered. Practitioners of an organization can only view patient information for that organization only. Caregivers will also be able to view data only related to that patient. URL jumping [17] is also considered while implementing the system.
CHAPTER 4
SYSTEM DESIGN
A good design makes a system reusable, maintainable, and extensible. To design a system properly, some system design principles should be followed.
4.1 Principles
There are various standard principles to follow while designing a system. Some of the key principles are discussed in this section.
DRY (Don’t Repeat Yourself)
Every piece of logic in the code-base should be repeated. This principle is important to make a system simple, more testable, modular, and extensible.
KISS (Keep It Simple, Stupid!)
This principle suggests keeping each small piece of module simple, and we should avoid unnecessary complexity.
SOLID Principle
SOLID is a set of five important principles of object-oriented design mentioned by RC. Martin [51]. The principles are:
• Single Responsibility Principle (SRP)
The responsibility of a class or module should serve a single purpose. This helps to build a loosely coupled and maintainable system.
• Open/Closed Principle (OCP)
The software entities, e.g., classes, modules, or functions, should be open to extension but closed to modification [18]. Once a module or functionality has been
developed and tested, these parts should be changed for bug-fixing only. On the other hand, the existing code should be extensible in order to introduce new functionality.
• Liscov Substitution Principle (LSP)
This principle suggests class hierarchy should follow design by contract [8], which implies that functions that use references to base classes should also be able to use objects of derived classes without knowing it [9].
This principle suggests designing simple and small interfaces rather than generic ones. The designer should split very large interfaces into smaller and more specific ones so that consumers will have to know only the interfaces they are interested on.
• Dependency Inversion Principle (DIP)
This principle is a very important one that helps to design modules or classes with a simple dependency graph. It suggests that high-level modules should not depend upon low-level modules, and both of them should use an abstract layer.
Component Based Design
The primary objective of this principle is to ensure reusability and modularity. Moreover, each component can be individually tested, which also increases the stability of any system. The component-based design also helps to design independent and loosely coupled modules, which makes a system extensible.
4.2 Components and Services of mCARE
To serve to its full extent and to run the system in scale, we need to identify different components, modularize them, and separate the services. In terms of features, mCARE is divided into three major components:
• mCARE-DMP (Data Management Platform) • mCARE-APP (Smartphone app)
• mCARE-SMS (SMS service)
For SMS communication, some external service could be used. These services needs to support two-way communication to both send and receive messages. But in Bangladesh, there is no suitable SMS service available that supports two way messaging. All of the existing services are one way, mostly for advertising purposes.
To run all these features, mCARE can be distributed into the following major components. • Web Portal: This is the main portal to be mostly used by practitioners. From this portal,
practitioners will be able to enroll patients, set triggers, view the data analysis part, and all other required features. Caregivers will also be able to log in and view their information and bi-weekly reports using this portal.
• API Service: This is the service that provides different RESTful API for the smartphone app and SMS gateway app to communicate with the back-end. This service is a layer between the database and other user-end services like the app and SMS gateway.
• Smartphone App: This is an app that will be used by caregivers. The practitioner will share the credential generated after enrollment, which will be required to activate the app. Caregivers will receive a regular notification as a reminder to submit parameter scores through the app. They will be able to submit scores, and they will also be able to view the bi-weekly progress report using the app.
• SMS Gateway App: This is a gateway app that is a smartphone app that works as a gateway for the SMS service. This app will run as a service on an Android phone. The service will periodically pull the messages that need to be sent to patients who are
subscribed for the SMS service by communicating with mCARE API Service. The received SMSs sent by caregivers will be synched to mCARE back-end by the gateway app and mCARE API Service.
• Email Module: The triggers generated by mCARE will be sent via email. This module will be responsible for sending emails to practitioners.
• Mobile Notification Service: Notifications will be sent to the smartphone app being used by caregivers. The responsibility of this module is to manage to send this notification to the installed mCARE smartphone app.
• Cron Job Service: To send notification via notification module and to generate SMS, a Linux based cron job [41] will be required.
• SMS Gateway Check Service: As the gateway app will run on smartphones all the time as a background service, there is a possibility to minimize the schedule from the operating system for battery optimization. This service will run on the web and check the health gateway, as the gateway app should always communicate with the server. If this health check service detects that gateway apps are not responding properly, it will generate an email notification for the mCARE administrator.
• Database Back-end: To store the data, mCARE is required to have a database back-end, which will store all the information related to all services and will work as a bridge between them by keeping different states of the system.
4.3 Deployment
Deployment architecture is also important for a system because the reliability, availability, and stability of a system also depend on this architecture. Nowadays, Amazon Web Service (AWS) is the most popular and arguably most secure web service, which also provides additional service for load balancing, scalability, and security. AWS also provides HIPAA compliance
guidelines [48] for systems like mCARE, and Relational Database Service (RDS) for the back-end, which is also part of the HIPAA compliance guidelines.
CHAPTER 5
FEATURES OF THE SYSTEM
This chapter briefly describes the features supported by mCARE and workflows in detail.
5.1 mCARE-DMP
mCARE Data Management Portal (mCARE-DMP) is a web portal that contains most of the functionalities of the system. It is a bigger tool containing some smaller modules.
5.1.1 Access Roles
From the user point of view, mCARE-DMP can be divided into three categories. There are three roles for different types of consumers.
• Researcher: Researchers who are part of the mCARE research. Researchers will have all kinds of access to mCARE-DMP
• Practitioner: Practitioners are the psychiatrists and psychologists who will observe the children with ASD. Practitioners will be able to enroll new patients, edit their information, set the triggers, and view different types of reporting
• Caregiver: Caregiver will be able to view detailed information about the corresponding patient. They will also be able to view the bi-weekly progress reports.
The following sub-sections will describe all the supported features of mCARE-DMP.
5.1.2 Login and Password Change
To access any feature of the system, users need to log in with their valid credentials. Figure 5.1 shows that mCARE requires a username and password for login. Every user is assigned to a specific access role, as defined in 5.1.1. Users will be able to access different navigation links depending on their access roles. While logged in to the system, any user can change their password as well. To do that, they need to provide their existing password, and the new password. The new password needs to be provided twice for confirmation.
5.1.3 Enrollment
As mentioned in the requirement analysis [chapter 3], the enrollment part consists of four parts. The four categories are:
• Demographic Information: this part collects all demographic information including:
Figure 5.1: Login screen
Figure 5.2: Patient enrollment
– Birth date and name
– Parent’s information
– Education
– Family demography
– Birth complications and many more
Figure 5.2 shows a partial interface of demographic information collection of user enrollment.
• Behavioral Parameters: Caregivers can select a certain number of parameters. They will also need to set an initial score for that parameter. Figure 5.3 shows how practitioners will
Figure 5.3: Behavioral Parameter Selection
choose a parameter, along with its frequency and intensity score. The score is on a scale of 0 to 10 meaning: 0 - Not applicable 2 - Very mild 4 - Mild 6 - Moderate 8 - Severe 10 - Extremely severe and other values in between.
• Milestone Parameters: There are two sets of milestone parameters depending on the age of the child. One set is for children 0 to 6 years old, and another set is for children older than 6 years. mCARE will automatically select the correct set by calculating age from date of birth collected in the demographic step, and it will change in run-time if the date of birth is changed while enrolling a patient. Milestone parameters are distributed into four categories including:
– Communication
– Daily Living Skills
– Socialization
– Motor Skills
Milestone parameters have a default frequency of two months. Practitioners will not be required to select the frequency for milestone parameters but, the intensity score needs to be selected. The intensity score values are:
Figure 5.4: Enrollment validation
0 - means the patient doesn’t do it anytime 1 - means the does it sometimes
2 - means the always do it
• Other Information: In the Other Information category, some evaluative information will be collected. This information will be collected again (see 5.1.9) later to compare and evaluate the system. This part collects:
– Satisfaction information
– Cost of visit
– ASD basic knowledge which includes,
∗ Do you know what are the primary symptoms of ASD? ∗ Do you think ASD runs in the family?
∗ Do you think their condition can be improved with proper treatment? ∗ Do you think ASD is infectious?
∗ Do you think it is a result of parental problems?
Validation
mCARE has some validation in the front-end of this enrollment process. Some fields are required, for e.g., date of birth, name, parent’s information, without which mCARE will restrict users to go to the next part of demographic information collection. Moreover, practitioners should select at least two milestone parameters from each category. mCARE will validate whether this information is missing and will notify and restrict the enrollment. Figure 5.4 shows how mCARE reports validation for missing milestone parameters.
Note that each practitioner will belong to an organization, and while enrolling a patient, the organization will automatically be assigned from the practitioner.
Figure 5.5: List of patients
5.1.4 View Patient
Practitioners will be able to view the list of patients with the corresponding organization. And by selecting a patient, the details demographic information, behavioral and milestone parameters along with their frequency and the current intensity scores can be viewed. Practitioners will also find a link to edit any kind of demographic information or parameters. Figure 5.5 shows how the list of patients will be shown and 5.6 shows the patient profile. This patient information is viewable by caregivers only for their own patients.
5.1.5 Edit Contact Information
Practitioners will be able to edit some basic information of a patient, which includes contact information, address, data collection, and some others. Practitioners will also be able to overwrite password credentials for any patient of their organization.
5.1.6 Edit Parameters
Practitioners may need to add a new parameter to observe or may need to remove any existing parameters. They will be able to update observable parameters any time after enrollment. The intervention frequency can also be changed for behavioral parameters. Figure 5.7 shows how practitioners can make changes for behavioral parameters for a patient. From the list of Add New Behavioral Parameter, new behavioral parameters can be added. To remove a parameter, editor should use Enable/Disable checkbox from Current Behavioral Parameters list. This list also shows the current intensity score for existing parameters that will help the editor to decide.
The milestone parameters for each category can also be updated. It has the restriction to have at least two milestone parameters in each category. Figure 5.8 shows a view about updating
Figure 5.6: Patient Profile
the milestone parameters. Note that this list will show the milestone parameter set between 0-6 or older than 6, depending on the age of the patient during enrollment.
5.1.7 Longitudinal View
The longitudinal view is a graphical reporting representation of intensity scores for different kinds of parameters for any specific patient. This graph can be generated for both behavioral and milestone parameters within a timeline. After selecting a patient, practitioners will find a list of the active list of parameters upon choosing a behavioral or milestone parameter. They will be able to select any set of them. After setting a date range, mCARE will generate the graphical report of the intensity score of selected parameters within the range. Figure 5.9 shows how mCARE allows choosing between behavioral and milestone, selecting the parameters and date range. Note that there is a common check box to select or deselect all of them at the same time.
Figure 5.10 shows how mCARE generates the graphical report. Practitioners will be able to get a clear understanding of the progress of different parameters viewing this report. One important feature here is, the viewer will be able to select/deselect any set of parameters after the generation of the report, and mCARE will update the graph in run-time without reloading the
Figure 5.7: Edit behavioral parameter
Figure 5.9: Longitudinal view select parameters
page. This provides a great experience to compare parameters. Figure 5.11 shows how this works in mCARE.
5.1.8 Triggers
mCARE allows setting trigger limits for any parameter for any patient. While setting or updating triggers, the user will be able to view the latest intensity score as well, which will help to decide on subsequent monitoring practices. mCARE supports updating of the trigger limits or to activate or deactivate any of them anytime after enrollment, shown in Figure 5.12. Note that currently, the system supporting Greater as comparison criteria. If any submitted intensity score crosses the defined limit, mCARE will generate a trigger event for that patient and will notify the corresponding practitioner using the email module of mCARE.
The already generated triggers are also viewable from a navigation link. The viewer can select a patient and a date range. mCARE will show all the triggered events generated within that date range for that particular patient.
Figure 5.10: Longitudinal report
Figure 5.12: Setting triggers
5.1.9 End of Study
This feature will invoke termination of observation of any patient. When a practitioner or researcher decides about the completion of a patient being part of the system, they can complete studying a patient using this part of the feature. After completing this part, the corresponding patient will not receive any notification in the app or SMS for parameters. This section collects some information similar to Other Information part of 5.1.3.
5.1.10 Data Analysis
This portion of mCARE provides various kinds of reporting that are different from Longitudinal View (5.1.7). There are three sub-parts of this feature.
Aggregated Missing Data
It is expected that the caregivers in LMICs are neither very much efficient to use technology nor very much aware of ASD. Some of the families won’t be able to submit the intensity score for different parameters regularly. mCARE provides a provision to find out the patients who are failing to do so. To do that, mCARE takes the type of data collection (App, SMS, or both) and a date range as input.
After selecting the required filters, mCARE generates an aggregated view about data submission status. Figure 5.13 shows how mCARE provides this information to practitioners or researchers. There are three types of status, which includes:
Figure 5.13: Aggregated missing data
• Submitted properly (3) • Did not submit (7)
• Submitted via SMS but with wrong format (
4
!)Individual
Using this part of the feature, mCARE allows viewing some patient specific reporting. There are five analysis types to choose from. The reporting information is discussed below. Note that the viewer needs to select an analysis type and a date range to generate this report.
• Satisfaction: mCARE collects satisfaction information of caregivers during enrollment and during the end of the study. mCARE shows this satisfaction information and percentage change of caregiver’s satisfaction while using the services of mCARE.
• Missed Data: This report shows a calendar view to show the data submission report for the selected patient. The viewer will be able to navigate to the next or previous months easily. The view can be changed from monthly to weekly or daily. Figure 5.14 shows that this report visualizes three types of information:
– If caregivers missed submitting
– If caregivers submitted successfully
– If caregiver submitted via SMS but in the wrong format (this is applicable for SMS users only)
This reporting is significant because practitioners can easily navigate back and forth, and calendar view also helps to relate this information with days of the week.
• ASD: This reporting shows the knowledge base of caregivers. The ASD knowledge base is collected during the enrollment and during the end of study. mCARE shows the knowledge base information and the transition or improvement throughout the period. Figure 5.15 shows the actual knowledge base of caregivers while figure 5.16 shows the improvement of knowledge base over time.
Figure 5.14: Missing data calendar view
Figure 5.15: ASD knowledge base of patients
Figure 5.17: SMS failure report.
• Cost: mCARE collects visiting cost and average cost for caregivers before using the service and during using the service. This report shows the comparison of these cost analysis of caregivers.
• SMS: This report shows the total number of SMS sent or received by the SMS patients to the mCARE system.
SMS Failure
As mentioned before, the target families raising children with ASD are mostly deprived and not proficient in using technology. Some families are not even comfortable to send or read SMS. Sometimes, these caregivers (SMS-based caregivers) submit the intensity scores that are incomplete or in the wrong format. This feature of mCARE supports practitioners to view these messages along with the name, organization, and contact information so that practitioners can communicate with them and correct them if necessary.
Figure 5.17 shows an example of these scenarios and how mCARE provides them to practitioners. This reporting feature shows wrong messages of that day while it contains navigation to move to previous or next days as well.
5.1.11 Compare Multiple Children
Compare Multiple Children helps to compare common parameters of multiple patients. This feature allows practitioners to select at least two to multiple patients of the corresponding
Figure 5.18: Compare multiple patients
or Milestone. mCARE detects the common parameters from the selected patients, calculates average intensity score for all of them, and shows a graphical report with the calculated
information. Figure 5.18 is a sample view of how mCARE generates this report. This report helps to get a comparative idea of the common parameters between them.
5.1.12 Portal for Caregiver
mCARE supports login into mCARE-DMP for caregivers as well. This is the same portal used by practitioners or researchers, but they will have access to different navigation within the system. Caregivers will be able to view:
• Graphical View: This is same as Longitudinal View (5.10). They need to select a set of parameters for behavioral or milestones. This report can be generated for any date range. • Registration Summary: Caregivers can view their collected information for mCARE along
with their behavioral and milestone parameters.
• Edit Information: They will find a link to edit their contact information, e.g., phone number, address, or name.
• Bi-Weekly report: The bi-weekly report is a progress report for the caregivers. After enrollment, a bi-weekly report will be generated every two weeks. This is similar to the
Figure 5.19: Bi-Weekly report
Figure 5.20: Previously generated Bi-Weekly re-ports
graphical view but will show only bi-weekly data. By default, mCARE will show the latest generated report. On a different tab, users can find the list of previously generated reports from which they will be able to view any older report. Figure 5.19 and 5.20 shows this feature of mCARE.
5.1.13 Language Support
The end-user or patients supported by mCARE could be from rural areas and economically deprived families. mCARE initially targets to deploy in Bangladesh. But, it is a generic system adjustable for any country. To achieve this goal, language support is a prime consideration for the system. Currently, mCARE support two languages:
• English • Bengali
Though the language is not changeable by practitioners, mCARE provides a provision to change language type configuration by the system administrator who deploys the system. mCARE currently contains bilingual information for behavioral parameters, milestone parameters, and for ASD knowledge base questions.
5.2 mCARE-APP
The mCARE-APP is the smartphone app to be used by the caregivers. Currently, the mCARE system only supports the Android version of the app. The Android app is available in Google Play. After installing the app, caregivers need to log in using the mCARE credential they receive from the practitioners. The basic feature of the app is discussed in this section.
Figure 5.21: App login Figure 5.22: Login with invalid credential
5.2.1 Login
Caregivers will receive login credentials after their enrollment. The credential includes a username and a password. To use the app, caregivers will be required to login first. Note that the app currently shows all kinds of information in Bengali. Figure 5.21 shows the login screen of the app. After providing the credential, the app communicates with the mCARE back-end using secure RESTful APIs of the system. If the user provides an invalid credential, the app informs that with a proper message (figure 5.22). If the credentials are correct, the login attempt will be
successful, and the app will move to the home screen.
Home
The home screen shows instructions about how the caregivers should decide the intensity score for different parameters. This screen will also show the parameters to be submitted for that
Figure 5.23: App home after login
Figure 5.24: Menu
day, if they have not been submitted already. The home screen also contains a menu for caregivers to navigate to the password change feature and buttons to submit scores along with a link to the bi-weekly report. Figure 5.23 shows a sample home screen of the mCARE-APP.
Password Change
The credential will be provided to the caregivers by the practitioners while enrolling the patient. It is recommended to change the initial password. Caregivers can find a menu (figure 5.24) that contains an option (figure 5.25) that links to the password change feature.
The password change screen requires caregivers to input the existing password, the new password, and confirmation of the new password. mCARE uses the API Service to update the password. After a successful operation, the app also updates the new password in its internal storage. The app shows a proper message if the current password is invalid, for example if the
Figure 5.25: Password change option
Figure 5.26: Password change
new password does not match or can’t update using the API Service.
Submit Score
The main purpose of this app and the whole system is to collect the intensity scores. Caregivers will be able to do that using this screen.
At the app home (figure 5.23), users can find the parameters to submit. Selecting on each parameter will lead to the score selection view (figure 5.27) where caregivers need to select an intensity score between 0-10 for the selected parameters. Caregivers need to select and score all the parameters of that day. Otherwise, mCARE will show a warning message and restrict the user from submitting. Figure 5.29 is the view of selecting all the scores correctly before submission. The app will send the scores calling the proper API, and mCARE will store them into the back-end.
mCARE allows caregivers to submit the scores only once a day. After the successful submission of scores, mCARE will not show the parameters on the home screen. Figure 5.30 shows how mCARE home changes after the submission. The app will enable the score submission again the following day.
Bi-Weekly Report
Caregivers will find the bi-weekly reports in the app as well. In the app, this report will list all the behavioral parameters. It will also show if the progress is increasing or decreasing by comparing with the previous report. Along with the progress information, this report will also show two ASD knowledge information randomly. The app will fetch the report and the ASD knowledge by calling the API of mCARE. Figure 5.31 is showing a sample generated bi-weekly
Figure 5.27: Set intensity scores Figure 5.28: Intensity score submission error
report, and figure 5.32 is showing the list of all generated bi-weekly reports for the corresponding caregiver.
5.3 mCARE-SMS
This is the service for caregivers who are not able to use the support of mCARE using a smartphone app. Users subscribed to the SMS service will receive the parameters that need to be monitored via SMS. The caregiver of the patient is required to reply to that SMS answering the intensity scores separated by separator like space, comma (”,”), dot (”.”), or semi-colon(”;”). The message will also contain specific instructions mentioning how to reply to the scores. Figure 5.33 shows the SMS communication feature.
The SMS service feature depends on an additional service, SMS Gateway (5.4). The message will be sent from the Android device that is running the gateway app. The messages containing intensity scores sent by the caregivers will be received by the gateway device, and the
Figure 5.29: Setting all the scores Figure 5.30: Home after submission
gateway app will sync this message calling different APIs of the API Service. The API Service will parse the message and store the scores in the correct format.
5.4 SMS Gateway
As discussed in section 4.2, the mCARE-SMS service requires both sending and receiving messages. Unfortunately, no suitable service was found that served the purpose of mCARE properly. There are some international services that support two-way messaging, but in this case, caregivers will need to reply to some international numbers, which is more costly for them.
Considering the situation, we built a gateway service that serves the purpose. The gateway service is an Android app that works as a background service in an Android device. The gateway app periodically fetches messages to send from the API Service and sends them using the Global System for Mobile Communications (GSM) service of that device. After receiving any messages, the gateway service syncs those with the API Service.
Figure 5.31: Bi-Weekly reports Figure 5.32: Previous bi-weekly reports
One drawback of this gateway app is, as the app always runs in the background and the device containing the app stays idle most of the time, the Android operating system sometimes stops the background service to optimize the battery. In the API Service, we have a system health reporting module that calculates the engagement of the gateway with the API Service and emails the system administrator if it detects any anomaly.
5.5 API Service
The API Service is a sub-module that runs along with the mCARE-DMP. The API Service provides some API for the mCARE-APP and the gateway app. This module is connected with the back-end database.
5.6 Email Module
The email module is responsible for sending emails. It uses an SMTP [42] back-end. The system administrator needs to provide an email SMTP server configuration for it during the deployment.
5.7 Cron Job
The cron job is a Linux based service that provides a job scheduling feature. mCARE requires configuration of a couple of cron jobs for different modules. Some of the cron jobs to configure includes:
• Send app notification (daily) • Generate SMS to send (daily) • Check gateway app health (hourly)
CHAPTER 6
IMPLEMENTATION DETAILS
This chapter discusses the implementation and design details of mCARE, which includes platforms, module architecture, database, design patterns, and other related implementation details.
6.1 Platforms
The server side of mCARE, which contains mCARE-DMP, API Service, and some other small modules, were developed using Python with the help of the Django framework. The back-end model is a relational database, and MySQL is used to store the data.
The smartphone app (mCARE-APP) was developed in Java with the help of the Android SDK. The gateway app was also built for the Android system, extended from an open-source project named EnvayaSMS [10].
6.2 Architecture
The MySQL database works as the back-end storage system, and there is no direct public access to it. Figure 6.1 shows the overall architecture, which connects different modules of mCARE. The web service is a combination of a couple of modules that stays in front of the database. mCARE-DMP is one part of the web service. For the communication of mobile
applications like mCARE-APP and SMS gateway, there is an API Service module. The API Service is not a physically different service, but a conceptual module that works along with mCARE-DMP.
6.3 Design and Implementation
As mCARE contains several modules with various purposes, the model and code design varies for different modules.
6.3.1 Database Models
This section describes the database models for different modules.
User Structure
Every user will belong to an organization. The organization is the root model mCARE. The Organization model will contain the information related to an Organization. The user will also contain some roles. The Role model will contain different roles for mCARE. The User model will
Figure 6.1: Architecture diagram
Figure 6.2: User model structure
also contain the username, full name, password, and other related information.
Behavioral Parameter Models
There are several models to store the behavioral parameters and to store scores submitted by patients. Figure 6.3 shows the model structure to store behavioral parameters in mCARE.
Figure 6.3: Behavioral models
Figure 6.4: Milestone models
Milestone Parameter Models
Figure 6.4 is the relationship between models to store milestone data. Other than behavioral parameters, milestone parameters are divided into categories. Moreover, there could be multiple distinct sets of parameters depending on the age of the patient.
Other Models
There are other dependent models to store different states of the system. For example, the SMS module requires a couple of models. The SendSMSQueue contains the messages that need to be sent by the gateway service. After a successful send, the message will move to the SentSMS. The received message by mCARE will be stored in the ReceivedSMS model. For the gateway health, mCARE requires to store some state and hourly hit-count invoked by the gateway app. Figure 6.5 shows the relationship between the gateway models. Apart from these, there are some other models to store demographic data of the patient, ASD knowledge questions, ASD
knowledge data collected from patients, satisfaction data of patients, etc.
Figure 6.6 shows the dependency graph between all the models. The model design is highly extensible. It is very easy to add new parameters to the system. Also, the addition of new language support or features is flexible.
Figure 6.5: Models for gateway
Figure 6.6: Dependency graph of all mdoels
Authentication
The password of users will be stored in password field of the User model. mCARE stores the password as SHA-1 hash [27] of the original password and never stores or logs the plain text password across the system.
APIs
The API Service provides couple of RESTFul [45] APIs for the apps to communicate with mCARE back-end. Each API communication requires to a contain a token for security purposes. Some of the API URLs are:
• verify/user verify credentials of a caregiver • survey/save store submitted scores
• token/upload upload push notification token • sms/gateway/receive sync received SMS • app/password/reset reset password from app
6.3.2 Smartphone Applications
The mCARE-APP built for the Android smartphone was coded in Java. The implementation of the app is designed into multiple classes and activities. Each task and responsibility are distributed into classes. For example, every view is divided into different activity views and classes. The task of calling and receiving HTTP requests is also implemented separately. There is a handler interface. The requester only needs to create an instance of class of HTTPRequest (code 6.1) and need to implement HTTPRequestHandler (code 6.2) and the
HTTPRequest will take care of everything. 1 enum RequestMethod {
2 GET , POST 3 }
4
5 p u b l i c c l a s s HTTPRequest implements Runnable {
6 p u b l i c HTTPRequest ( S t r i n g api , S t r i n g parameters , RequestMethod requestMethod , HTTPRequestHandler handler ) { . . . } 7 } Code 6.1: HTTPRequest 1 i n t e r f a c e HTTPRequestHandler { 2 enum ResponseType { 3 SUCCESS , ERROR 4 }
5 p u b l i c void onCompleted ( ResponseType responseType , S t r i n g r e s p o n s e S t r ) ;
6 }
Code 6.2: HTTPRequestHandler
The code also contains some model data-structure to store and communicate properly between different classes. The app requires to connect with the Firebase service [11] to receive the push notifications. After a successful login, the app registers with the Firebase service and gets a push notification token. To communicate with Firebase, the code needs to extend
FirebaseInstanceIdService and FirebaseMessagingService service. After receiving the token, the app uploads it to the mCARE API Service with the help of TokenUploader class. The gateway app is a modified version of the open-source module EnvayaSMS. We have customized it to work with our system.
6.4 Model View Controller (MVC) Pattern
MVC is the most popular pattern to segregate model, view, and controller logic. In the Django web service, there is a provision to use MVC very easily. First, we generated the model, which is the backbone of a system. We used the template engine of Django to generate different views. All the logics are separated into the controller part, which handles different requests by using different models and generating views.
MVC pattern is followed to design the smartphone app codes as well. The views are contained in different layout files; the logic contains in different controller classes for different activities. Some custom data-structures work as models for different classes.
6.5 Deployment and Scalability
The system design is scalable in terms of the new feature or increased user load. A version of mCARE has been deployed following the HIPAA guideline of AWS. The web service is deployed on an EC2 [2] and the database deployed on an RDS [3], which is available for multiple regions and backup enabled. The web service is running under a setup of Apache [30] server. SSL certificate has been configured to secure the communication. The cron jobs are also configured in the same Linux instance.
1 CRON TZ=Asia/Dhaka
2 0 6 ∗ ∗ ∗ c u r l −X GET ’ h t t p s :// mcare . h e a l t h /sms/survey/send ’ 2>&1 | /usr/bin/ l o g g e r −t mcare
3 0 ∗ ∗ ∗ ∗ c u r l −X GET ’ h t t p s :// mcare . h e a l t h /sms/gateway/ h e a l t h /check ’ 2>&1 | /usr/bin/ l o g g e r −t mcare
CHAPTER 7
ANALYSIS, LIMITATIONS, IMPACT AND FUTURE WORK
Though mCARE has a self-evaluation feature while serving caregivers and practitioners, we have evaluated it in terms of integration complexity, learning curve, and extensibility as well.
7.1 Self Evaluation
mCARE has provisions for evaluating itself by the caregivers. During the enrollment and end of the study, mCARE collects satisfaction, cost improvement, and knowledge base
improvement from caregivers. This feedback will help to evaluate the impact after deployment.
7.2 Extensibility
The design of mCARE is highly extensible. Adding a new parameter to the system will not require any development changes. Developing for a new smartphone platform will also be easy, because the APIs of mCARE are platform-independent. Minimal changes would be needed to deploy mCARE to a new country with a different language. Translation of a new language can be easily be added in the model layer, and only configuration change will be required to make mCARE usable for a different environment.
7.3 Application
As mentioned before (3), the development of mCARE is part of an NIH research grant; mCARE is currently deployed as part of that research. Caregivers and practitioners are already using the service of mCARE. Currently, practitioners of four organizations are using it. A total of 300 patients have already been enrolled and are using it properly, which also proves the
competency of the system.
7.4 Limitations
mCARE currently only supports only the Android app. If some caregiver uses the iOS operating system supported device, they need to use the SMS service for now. Using the app is more flexible than the SMS service. The gateway service has a limitation to send a single message in five minutes because the operator doesn’t support frequent message sending. For this throttle, mCARE requires multiple gateway devices.
We have shown that mCARE support features can reduce the gap between deprived families and practitioners to get treatment by enrolling children with ASD under the service. A lot
of patients who are unable to visit psychiatrists for distance, cost, and negligence can get proper treatment.
7.5 Impacts
Though the application is currently deployed in Bangladesh, it can be easily deployed in other countries. Apart from LMICs, developed countries like the US can also benefit from this system. Families living in rural areas will not be required to visit psychiatrists frequently, as they will be able to provide information remotely, get regular updates and can monitor their status.
7.6 Future Work
mCARE has room to improve. The most important issue is an application supporting iOS devices. In developed countries like the US, a large number of people use iOS devices. mCARE can also provide smartphone app support by developing an iOS supported version.
Secondly, mCARE supports only greater comparison criteria to generate triggers (5.1.8). There could be some parameter which might require less comparison criteria.
BIBLIOGRAPHY
[1] 11 surprising mobile health statistics.
https://www.mobius.md/blog/2019/03/11-mobile-health-statistics/. Accessed: 2020-10-21. [2] Amazon ec2, secure and resizable compute capacity to support virtually any workload.
https://aws.amazon.com/ec2/. Accessed: 2020-10-21.
[3] Amazon relational database service (rds), set up, operate, and scale a relational database in the cloud with just a few clicks. https://aws.amazon.com/rds/. Accessed: 2020-10-21. [4] Autism tracker pro.
https://apps.apple.com/us/app/autism-tracker-pro-track-and-analyze-asd/id478225574. Accessed: 2020-10-21.
[5] Cross site request forgery (csrf). https://owasp.org/www-community/attacks/csrf. Accessed: 2020-10-21.
[6] Cross site scripting (xss). https://owasp.org/www-community/attacks/xss/. Accessed: 2020-10-21.
[7] Data & statistics on autism spectrum disorder.
https://www.cdc.gov/ncbddd/autism/data.html. Accessed: 2020-10-21.
[8] Design by contract. https://en.wikipedia.org/wiki/Design_by_contract. Accessed: 2020-10-21.
[9] Different types of software design principles. https://www.dotnettricks.com/learn/ designpatterns/different-types-of-software-design-principles. Accessed: 2020-10-21. [10] Envayasms. https://github.com/youngj/EnvayaSMS. Accessed: 2020-10-21.
[11] Firebase.https://firebase.google.com/docs. Accessed: 2020-10-21. [12] Health insurance portability and accountability act of 1996 (hipaa).
https://www.cdc.gov/phlp/publications/topic/hipaa.html. Accessed: 2020-10-21. [13] Mobile-based care for children with autism spectrum disorder using remote experience
sampling method (mcare).
https://www.fic.nih.gov/Grants/Search/Pages/mhealth-r21mh116726.aspx. Accessed: 2020-10-21.
[14] Mobile phone subscribers in bangladesh december, 2019, btrc.
http://www.btrc.gov.bd/content/mobile-phone-subscribers-bangladesh-december-2019. Accessed: 2020-10-21.
[15] Sdlc - overview.https://www.tutorialspoint.com/sdlc/sdlc_overview.htm. Accessed: 2020-10-21.
[16] Sdlc - software prototype model.
https://www.tutorialspoint.com/sdlc/sdlc_software_prototyping.htm. Accessed: 2020-10-21.
[17] Semantic url attack.https://en.wikipedia.org/wiki/Semantic_URL_attack. Accessed: 2020-10-21.
[18] Solid.https://en.wikipedia.org/wiki/SOLID. Accessed: 2020-10-21.
[19] Sql injection.https://owasp.org/www-community/attacks/SQL_Injection. Accessed: 2020-10-21.
[20] User interface design guidelines: 10 rules of thumb.https://www.interaction-design.org/ literature/article/user-interface-design-guidelines-10-rules-of-thumb. Accessed: 2020-10-21.
[21] Vanshree Patil Balasinorwala, Nilesh B Shah, Soumya D Chatterjee, Vinayak P Kale, and Yusuf A Matcheswalla. Asynchronous telepsychiatry in maharashtra, india: study of feasibility and referral pattern. Indian journal of psychological medicine, 36(3):299, 2014. [22] Sharmistha Bardhan, GM Monjur Morshed Mridha, Eshtiak Ahmed, M Anwar Ullah, Helal Uddin Ahmed, Shaheen Akhter, Md Golam Rabbani, and Khondaker Abdullah Al Mamun. Autism barta—a smart device based automated autism screening tool for bangladesh. In 2016 5th International Conference on Informatics, Electronics and Vision (ICIEV), pages 602–607. IEEE, 2016.
[23] Jennifer Chipps, P Brysiewicz, and M Mars. Effectiveness and feasibility of telepsychiatry in resource constrained environments? a systematic review of the evidence. African Journal of Psychiatry, 15(4), 2012.
[24] Nicola Lee Dell, Sugandhan Venkatachalam, Dean Stevens, Paul Yager, and Gaetano Borriello. Towards a point-of-care diagnostic system: automated analysis of immunoassay test data on a cell phone. In Proceedings of the 5th ACM workshop on Networked systems for developing regions, pages 3–8, 2011.
[25] Brian DeRenzi, Nicola Dell, Jeremy Wacksman, Scott Lee, and Neal Lesh. Supporting community health workers in india through voice-and web-based feedback. In Proceedings of the 2017 CHI conference on human factors in computing systems, pages 2770–2781, 2017. [26] Thyde Dumont-Mathieu and Deborah Fein. Screening for autism in young children: The
modified checklist for autism in toddlers (m-chat) and other measures. Mental retardation and developmental disabilities research reviews, 11(3):253–262, 2005.
[27] Donald Eastlake and Paul Jones. Us secure hash algorithm 1 (sha1), 2001.
[28] Upol Ehsan, Nazmus Sakib, Md Munirul Haque, Tanjir Soron, Devansh Saxena, Sheikh Ahamed, Amy Schwichtenberg, Golam Rabbani, Shaheen Akter, Faruq Alam, et al. Confronting autism in urban bangladesh: unpacking infrastructural and cultural challenges. EAI Endorsed Transactions on Pervasive Health and Technology, 4(14), 2018. [29] Mayada Elsabbagh, Gauri Divan, Yun-Joo Koh, Young Shin Kim, Shuaib Kauchali, Carlos
