Skip to main content
NIHPA Author Manuscripts logoLink to NIHPA Author Manuscripts
. Author manuscript; available in PMC: 2019 Nov 18.
Published in final edited form as: Proc SPIE Int Soc Opt Eng. 2013 Mar 7;8667:86670V. doi: 10.1117/12.2007530

MessageSpace: a Messaging System for Health Research

Rodrigo D Escobar a, David Akopian a, Deborah Parra-Medina b, Laura Esparza b
PMCID: PMC6859841  NIHMSID: NIHMS1052031  PMID: 31741551

Abstract

Mobile Health (mHealth) has emerged as a promising direction for delivery of healthcare services via mobile communication devices such as cell phones. Examples include texting-based interventions for chronic disease monitoring, diabetes management, control of hypertension, smoking cessation, monitoring medication adherence, appointment keeping and medical test result delivery; as well as improving patient-provider communication, health information communication, data collection and access to health records. While existing messaging systems very well support bulk messaging and some polling applications, they are not designed for data collection and processing of health research oriented studies. For that reason known studies based on text-messaging campaigns have been constrained in participant numbers. In order to empower healthcare promotion and education research, this paper presents a system dedicated for healthcare research. It is designed for convenient communication with various study groups, feedback collection and automated processing.

Keywords: Health promotion, Short messaging, SMS, Mobile applications, Health care systems

1. INTRODUCTION

Healthy People1 defines health communication as “the research-based crafting and delivery of messages and strategies to promote the health of individuals and communities.” As one of the enablers of health promotion2,3, health communication, when effectively used, can inform, educate, motivate, and empower individuals, communities, and nations.

The ubiquitous cell phone has revolutionized the way people communicate. There have been many reports on using mobile technology for health, and the area is already uniquely identified as mobile health (mHealth)4,5. Across social and economic strata, the texting or Short Messaging Service (SMS) is one of main communication services used in mHealth. According to Forrester research6 text messaging users in US send or receive an average of 35 messages per day which is equivalent to 6 billion SMS messages total sent per day, and there was a 14% increase in the number of SMS messages from 2010 to 2011. Considering about 105% mobile penetration in US and 86% worldwide in 20127 SMS will still serve as a powerful communication technology for health professionals.

mHealth has been successfully applied for health promotion810. Examples are behavior change11, sexual health1213, physical activity14 and weight control1510. The authors recently overviewed representative messaging systems16 that support known health promotion efforts such as RapidSMS17, FrontlineSMS18, MobileResearcher19 and EpiSurveyor20. A typical architecture of these systems is shown in Figure 1. While serving as advanced systems for data collection, these systems are not tailored for research tasks and typical studies are constrained in the number of participants. As indicated in16 the following desirable research-oriented features are needed for successful research efforts: (1) client accounts and access/records management; (2) capability to create and remove new research “attributes” as necessitated by the studies over the time; (3) a “grouping” logic to define various cohorts, groups, teams for comparative analysis of interventions and other studies; (4) “polling” capability to collect responses from the clients; (5) group-specific broadcast messaging for awareness; (6) advanced message history tracking for individual clients; (7) scheduling of message communication for automatic message management; (8) data analytics for fast assessments and (9) report logs.

Figure 1.

Figure 1.

General messaging system architecture16

This paper describes a MessageSpace system which implements all these features and is currently applied in health promotion studies. The rest of this paper is organized as follows: Section II presents an overview of the features of the system, section III describes the architecture designed and deployed to support the system’s features including the frontend and back-end components, Section IV presents privacy enforcement considerations and finally, conclusions are provided in Section V.

2. SYSTEM OVERVIEW

The MessageSpace login page is shown in Figure 2, which also provides the list of functionalities that have been developed for the system. This includes registration of research participants, study attribute management, grouping of participants for various study tracks, poll and message management, messages scheduling, etc. The system has access control based on specific user roles as described next.

Figure 2.

Figure 2.

MessageSpace login page

2.1. Users

Three main types of users are the following:

  • System’s administrators: They are technical support personnel that create projects and associate the first user-manager (i.e. a project manager) to each one of them. Once a project has been created and an initial user has been associated to it, that initial user, usually a user of type project manager is in charge of creating any other system’s users needed for that particular project.

  • System’s users: System’s users can be project managers or project administrators. They are healthcare researchers. As shown in Figure 3, they can potentially use any of the features of the system, except creating projects, which is a task restricted to system’s administrators. Within a project, different permissions can be independently set for project managers or project administrators in order to allow them access different features of the system. The permission to set permissions itself can be modified for project managers or project administrators. System’s users log in to the system by making use of a web browser, and username and password credentials.

  • Project’s participants: Project’s participants are people being part of the study being carried out. These are the users that will receive SMS messages from or send SMS messages to the system according to what researchers have previously set up.

Figure 3.

Figure 3.

System’s features available to healthcare researchers

2.2. Participants’ registration

Study participants can be registered in one or several different projects. Registration can be performed by researchers using the system’s user interface or by participants themselves through an additional application provided to serve that purpose. Researchers can perform a bulk registration of many participants by uploading a comma separated values file (csv) or an MS Excel file containing all the participants’ attributes previously defined by that particular project’s researchers. Examples of participants’ attributes include first name, last name, age, ethnicity, or any other information about participants that researchers may find of interest for their projects. Participants are also provided with an option opt-out from projects by sending an SMS message containing a predefined word

2.3. Attributes management

A versatile attribute management component is developed which allows attributes to be created depending upon a project’s specific needs. Attributes are variables that characterize participants in one or another way. Researchers use the system’s user interface to create any attribute or participants’ characteristic that they consider relevant for their particular projects. Attributes can be dynamically created or deleted by project’s managers or administrators, should they have the permissions to do it. A type of data is required to be assigned to each attribute. Each attribute can be a date, a string, a number or a boolean value. Attribute values distinguish participants from each other and are used for creating groups of participants for programming group-specific study conditions.

2.4. Grouping

A grouping component is developed in order to group participants either manually or based on previously created attributes. Several filters, along with a recursive filtering option, are provided for researchers to create groups of particular interest. Groups can be edited at any time. SMS broadcast messages and polls can be sent to groups or to individual participants, and statistics about groups or participants can also be generated in real time.

2.5. Messages creation and scheduling

Two types of SMS messages can be created and sent to participants from MessageSpace: Broadcast messages and poll messages. Participants respond to polls by sending an SMS message with their answer to the system or by selecting an answer in their android client application. Up to nine options can be configured as possible answers to be selected by participants as shown in Figure 4. Polls introduce scenarios in which participants’ responses may lose the unique identifier of the poll they refer to. Therefore, in MessageSpace each broadcast or poll message receives an automatically generated numeric identifier from which one or more digits are used to associate received poll responses with the appropriate poll. This configuration makes concurrent polls possible, so researchers may have several open status polls. The number of digits that can be used to associate a poll response with its associated poll can be modified depending on different factors such as expected amount of simultaneous active projects, or the number of communication channels, SIM cards or modems. By using those identifiers, data received from participants are automatically handled by the system without the need for researchers or system administrators’ intervention. These data are stored in a database allowing researchers to create reports that include the most recently received responses from participants. Messages can be sent to either individual participants or to a previously created group. Figure 5 shows the procedure that researchers follow in order to create groups and messages and send them tailored SMS messages.

Figure 4.

Figure 4.

Poll message configuration

Figure 5:

Figure 5:

Messages sending procedure

It has been noticed that annual event dates and particular days of the week may be more effective than others in the sense of responsiveness to messages12. Similarly researchers may want to select specific time of the day for optinal communication. Therefore, in MessageSpace, researchers can choose between sending messages immediately or by scheduling them by selecting more appropriate dates and times.

Researchers, independently of their roles, interact with the system through a web browser. On the other hand, participants mainly interact with the MessageSpace by sending and receiving SMS messages. Participant feedback is obtained through polling system by sending them multiple choice questionnaires and collecting and processing their responses. Broadcast messages in general should not result in participants’ responses. Figure 6 illustrates the system interactions with researchers and participants.

Figure 6.

Figure 6.

Dataflow of the the system

2.6. Reporting and analytics

Reports and statistics assessments are very useful for the project monitoring. For example, researchers can retrieve dates and times messages have been sent to or received from participants, how many messages were sent in particular period of time, and how many correct responses were received for a particular poll, among others. Statistics about messages sent and received are also available and are presented in real time generated charts showing for instance how many responses were received for a particular poll and how many correct or incorrect answers were received. This up-to-date illustrative information simplifies monitoring. Figure 7 presents the procedure that users must follow in order to access the analytics section and generate project statistics. And Figure 8 shows an example of chart corresponding to the number of participants of a project who responded to a poll named reg_poll compared to the number of participants who did not respond to the same poll.

Figure 7:

Figure 7:

Statistics generation procedure

Figure 8:

Figure 8:

Analytics section example

3. SYSTEM DESIGN

The system architecture follows a Model-View-Controller (MVC) configuration based on Java 2 Enterprise Edition (J2EE) platform. The MVC design pattern isolates business logic from user interfaces and helps to provide different frontends (i.e. user interfaces) while using the same backend components21. Additionally, we added the following two tiers to the solution:

  • A relational database to provide efficient and reliable persistence to data

  • An SMS messaging service to appropriately handle incoming and outgoing SMS messages

This isolation between software components reduces the complexity of the system, thus improving the flexibility and maintainability of the system. Figure 9 shows the architecture of the system and the MVC interactions are shown in Figure 10. The following implementation considerations are taken into account to develop the software components of the system:

Figure 9.

Figure 9.

Architecture of the system

Figure 10.

Figure 10.

Model-View-Controller interactions

3.1. Model

The model represents data and rules that govern access to this data. Models often serve as a software approximation of a real-world process22. Java beans were created to represent the data on which operations are performed. System’s entities such as messages, users, groups, permissions, etc. are represented by Java beans. These Java beans also contain the necessary code to communicate with the persistence layer (i.e. the relational database).

3.2. View

View components present information to the user and interact with him. If the model data changes, the “view” must update its presentation as needed22. A set of Java Server Pages (JSP) were developed in order to take data from the model and appropriately display it to users. To provide a more interactive and better experience for users than the one obtained when using regular web request-response operations, we make use of Asynchronous Javascript and XML (AJAX) techniques to asynchronously request data from or send data to the server. Table 1 presents a list of the sections and functionalities of the system, and the type of communication used.

Table 1.

Type of communication used per functionality

Section Process Type
Create user Load users’ list Synchronous web request
Remove user AJAX
Participants Load participants’ list Synchronous web request
Load participant details AJAX
Generate participants’ list in XLS file AJAX
Attributes Load attributes’ list Synchronous web request
Remove attribute AJAX
Create attribute AJAX
Polling and broadcasting New broadcast/poll ID Synchronous web request
Poll answers codes Synchronous web request
Create or update broadcast/poll AJAX
Load existing broadcasts/polls list Synchronous web request
Get broadcast/poll details AJAX
Grouping Delete group AJAX
Load list of existing groups Synchronous web request
Filter participants Synchronous web request
Save/update group AJAX
View group details AJAX
Polling and Broadcasting Load list of existing broadcasts/polls Synchronous web request
Get message details AJAX
Load list of destination group/participants AJAX
Send/schedule SMS AJAX
Permissions Update list of permissions AJAX
Analytics and reports Load data/draw chart AJAX
Generate XLS reports AJAX
Messages by status Synchronous web request
Received messages report AJAX
List of sent messages AJAX

3.3. Controller

Controllers are responsible for passing information between “model” and “view” components. Controllers’ tasks may also include selecting the appropriate view to present model data22. We use servlets to manage the data flow from the view component to the model component and the other way around. It also selects the corresponding view according to the requests received from users.

3.4. Sender process

This component was developed to further isolate the main system – which contains the business logic needed for healthcare researchers to perform their tasks in the system, from the SMS service. This isolation makes easier to perform maintenance tasks and also helps to improve the privacy of participants’ phone numbers because, once a message has been sent, that record can be removed from the messages table. When sending an SMS message to a participant, his phone number is required to be inserted in the messages table until the message has been sent.

Once a message is sent or scheduled to be sent, it is stored in a preliminary table containing basic data, such as a destination identifier, a type of destination (which can be a group or a participant), and date and time when the message has to be sent. The sender process checks this preliminary table periodically and recognizes messages to be sent at that time, and then it queries the phone numbers to which the message has to be sent and inserts them in the messages table. The SMS service will get the messages from the messages table and send them through the GSM modem. SMS messages that have been sent through the GSM modem to their destinations can be removed from the messages table.

3.5. Persistence

A relational database is used to store information corresponding to participants, groups, broadcast messages, poll messages, poll responses, permissions, etc. in a structured and efficient way. Data integrity is also enforced by restricting modifications to the database that violate dependency relationships as explained below. A relational database is described by its tables and the dependencies between those tables. A diagram with the entities and relationships existing in the database is shown in Figure 10. In the diagram, each box represents a table, whereas connectors between tables represent dependency relationships. A table may contain many rows or records and each record is composed of one or more fields or columns. Columns give the structure of a table. In the diagram, column names are shown inside each box representing a table. For simplicity, only those fields that have dependencies with other tables are shown in the diagram since any other field would not affect the structure of the database. For instance, the connector existing between the tables projects and systemsusers in this case reveals that every record in the table systemsusers has to have a reference to a record in the table projects. The way the system is implemented, translates that requirement into the fact that every user of the system has to be associated to an existing project. Thus, for example deletion of a particular project record requires it not to be referenced by any record existing in the table systemsusers.

The messages table in the database is used to communicate the core system with the SMS server. A set of triggers are associated to the messages table in order to notify the SMS service that there are pending messages to be sent. The messages table stores details like messages, direction, status, type and format of the messages that have to be sent or that have been received.

3.6. SMS service

The SMS communication with the GSM modem is carried out by the ActiveXperts messaging service that runs as a service on Windows operating systems. In our solution it was deployed to work as the middleware between MessageSpace and the mobile network. As described above, a set of triggers associated to the messages table of the database notify the SMS service when there are messages pending to be sent. After that, the SMS service will take those messages and send them through the GSM modem to the participants. This process is shown is Figure 12.

Figure 12.

Figure 12.

SMS messages dataflow from database to mobile network

3.7. Participants’ interaction

Research participants receive broadcast and poll messages in their cellphones and they can reply accordingly to the polls either by manually sending a message with their answer or by making use of an android application that provides a friendlier interface. Android smartphones account for more than 44% of the total smartphones market23. By providing a friendlier interface, it is expected that the number of poll responses received by projects will be increased. In this case participants only have to choose an option and click send as shown in Figure 13. Nevertheless, communication still occurs by means of SMS messages.

Figure 13.

Figure 13.

Poll response interface. (a) regular SMS messaging (b) android client application

4. PRIVACY AND SECURITY

Privacy and security are important issues to be addressed when developing and deploying healthcare related computer systems. Privacy and security measures in MessageSpace have been implemented using two approaches: Access control lists (ACL), and communication links encryption.

By using ACLs, we guarantee that only authorized people can gain access to certain sections of a project in MessageSpace. ACLs associate types of users with sections of the system that can be accessed. Three types of users exist to which different types of access can be granted: managers, administrators and participants. By default, managers have access to all sections of the system. Managers can allow or deny access of other types of users to each section of MessageSpace or give them grant permissions as well. Thus, for instance managers’ permissions can allow them to access all the features of the system, while restricting project administrators to access only a few sections of the system.

Besides, connections from the web application to the database and from web clients to the web application make use of Secure Socket Layer (SSL) encryption. Thus, a secure communication channel is established that prevent the interception of information. Up to this point, certificates have been self-signed. However, migrating to a scheme where certificates are signed by a well-known certification authority (CA) requires few modifications. Figure 14 shows the parts in which SSL communication occurs.

Figure 14.

Figure 14.

Secure links communication in MessageSpace

5. CONCLUSIONS

The paper describes a texting system MessageSpace for health promotion researchers. It provides one of the architectures that can be used to assist in programming research scenarios. The system addresses most of the requirements needed to perform healthcare promotion studies including participants’ registration, grouping, reports generation and messages creation and scheduling, among others. Access lists and encryption of communication channels are used to add security and privacy capabilities to the system. The system is successfully implemented and is actively used for health promotion.

Figure 11.

Figure 11.

DB entities and relationships diagram

REFERENCES

  • [1].Healthy People. Health Communication and Health Information Technology. http://www.healthypeople.gov/2020/topicsobjectives2020/overview.aspx?topicid=18 (Accessed Jan 20, 2013).
  • [2].Glanz K., Rimer BK, and Lewis FM, M. F Editors. Health behavior and health education: Theory, research, and practice (3rd ed.). San Francisco, CA: Jossey-Bass; 2007 [Google Scholar]
  • [3].McKenzie JF, Neiger BL, and Thackeray R.. Planning, implementing, and evaluating health promotion programs: A primer (5th ed.). San Francisco, CA: Pearson Education, Inc; 2009 [Google Scholar]
  • [4].Generations and their gudgets. Pew Research Center. Feb 3, 2011. http://pewinternet.org/Reports/2011/Generations-and-gadgets (Accessed Jan 20, 2013).
  • [5].Istepanian RS, Laxminarayn S., Pattichis CS. M-Health: Emerging Mobile Health Systems Topics in Biomedical Engineering. International Book Series; London, UK: Springer-Verlag; 2010 [Google Scholar]
  • [6].Forrester Research. Mobile media application spending forecast 2012 to 2017 (US). www.forrester.com (Accessed Jan 20, 2013)
  • [7].Portio Research. Mobile Factbook 2012. http://www.portioresearch.com/en/free-mobile-factbook.aspx (Accessed Jan 20, 2013).
  • [8].World Health Organization. mHealth, new horizons for health through mobile technologies: second global survey on eHealth, Vol.3, 2011. http://www.who.int/goe/publications/goe_mhealth_web.pdf (Accessed Jan 20, 2013). [Google Scholar]
  • [9].Déglise C., Suggs LS, Odermatt P., “Short Message Service (SMS) Applications for Disease Prevention in Developing Countries,” Journal of Medical Internet Research (JMIR), Vol 14(1):e3, 2012, doi: 10.2196/jmir.1823. [DOI] [PMC free article] [PubMed] [Google Scholar]
  • [10].Nyberg T., Xiong G., and Luostarinen J., “Short messages in health promotion: Widespread and cost effective two-way communication channel for health,” Proc. of IEEE Int. Conf. on Service Operations, Logistics, and Informatics (SOLI), Beijing, China, July 10–12, 2011, pp. 274–277 [Google Scholar]
  • [11].Cole-Lewis H., Kershaw T., “Text Messaging as a Tool for Behavior Change in Disease Prevention and Management,” Epidemiologic reviews, Vol. 32(1), 2010, pp. 56–69. [DOI] [PMC free article] [PubMed] [Google Scholar]
  • [12].Gold J., Lim M., Hellard M., Hocking J., Keogh L., “What’s in a message? Delivering sexual health promotion to young people in Australia via text messaging,” BMC Public Health Journal, Vol. 10:792, 2010, doi: 10.1186/1471-2458-10-792. [DOI] [PMC free article] [PubMed] [Google Scholar]
  • [13].Lim M., Hocking J., Hellard M., Aitken CK, “SMS STI: a review of the uses of mobile phone text messaging in sexual health,” Int. Journal on STD and AIDS, Vol. 19, pp. 287–290. [DOI] [PubMed] [Google Scholar]
  • [14].Newton KH, Wiltshire EJ, Elley CR, “Pedometers and text messaging to increase physical activity: randomized controlled trial of adolescents with type 1 diabetes,” Diabetes Care Journal, Vol.32, pp. 813–815, 2009 [DOI] [PMC free article] [PubMed] [Google Scholar]
  • [15].Haapala I I., Barengo NC, Biggs S., Surakka L., Manninen P., “Weight loss by mobile phone: a 1-year effectiveness study,” Public Health Nutr. Journal, Vol.12, pp. 2382–2391, 2009. [DOI] [PubMed] [Google Scholar]
  • [16].Akopian D., Jayaram V., Aaleswara L., Esfahanian M., Mojica C., Parra-Medina D., S. S. Kaghyan, “Mobile Text Messaging Solutions for Obesity Prevention,” Proc. of SPIE Multimedia on Mobile Devices Conference, Electronic Imaging, Vol. 7881, 2011, pp. 788101–1-788104–15 [Google Scholar]
  • [17].RapidSMS. Software and documentation. www.rapidsms.org (Access: Jan 20, 2013)
  • [18].FrontlineSMS. Software and documentation. www.frontlinesms.org (Access: Jan 20, 2013)
  • [19].MobileResearcher. Software and documentation. www.mobileresearcher.com (Access: Jan 20, 2013)
  • [20].EpiSurveyor. Software and documentation. www.datadyne.org/episurveyor (Access: Jan 20, 2013)
  • [21].Tao Y., “Component- vs. application-level MVC architecture,” IEEE 32nd Annual Frontiers in Education (FIE) Conference, Vol. 1, pp. T2G-7 - T2G-101, 2002. [Google Scholar]
  • [22].Wang Y., Guo C., Song L., “Architecture of E-Commerce Systems Based on J2EE and MVC Pattern,” Proc. of Int. Conference on Management of e-Commerce and e-Government (ICMECG), pp. 284–287, 2009. [Google Scholar]
  • [23].Applico. Q1 State of Mobile Market Report. July 2012. www.applicoinc.com/q1-state-of-mobile-market-report/

RESOURCES