mHealthSwarm: A Uniﬁed Platform for mHealth Applications

Ben Philip

1 a

, Yasmeen Alshehhi

1 b

, Mohamed Abdelrazek

1 c

, Scott Barnett

1 d

Alessio Bonti

1 e

and John Grundy

2 f

Deakin University, Burwood, VIC, Australia

Monash University, Clayton, VIC, Australia

Keywords:

mHealth Apps, mHealth Platform, micro-mHealth Apps.

Abstract:

Mobile health (mHealth) applications are ubiquitous and offer several beneﬁts such as easier access to one’s

health and wellness data through smartphones. However, their growth in popularity has also introduced several

challenges for both end-users and developers. Users face challenges around the poor user experience (UX)

introduced by the need to install several apps and limited customizability which is exacerbated by the limited

control over app functionality. While features common across different apps may not directly affect individual

developers, the fact that one app may provide a better implementation of features leads to wasted developer

effort. A single platform that can satisfy all user needs does not currently exist, and given the diversity of

the mHealth domain, a single app would be far too complex if it existed. In this paper, we present a new

approach and a platform for mHealth apps - micro-mHealth apps, and we discuss them as an alternative to the

current mHealth app development model, which we believe could improve the current state of mHealth app

development and adoption. We are currently evaluating our prototype with several micro-mHealth apps built

using common features in the mHealth apps available in commercial app stores.

1 INTRODUCTION

mHealth has been deﬁned as the “medical and public

health practice supported by mobile devices, such as

mobile phones, patient monitoring devices, personal

digital assistants (PDAs), and other wireless devices”

(WHO, 2011). Today, several health, ﬁtness and well-

ness applications for uses such as drug dosage and

medical reference (Ventola, 2014; Berauk et al., 2017;

Sezgin et al., 2017) and weight management (Hig-

gins, 2015) are popular among users as part of their

daily routines (Berauk et al., 2017; Higgins, 2015).

Despite the increase of mHealth apps and interest

in adopting them from a great many end users, there

are many limitations around existing mHealth app us-

ability, feature relevance, and data sharing. There are

an increasing number of users needing to install many

mHealth apps, a key challenge as there is no app that

delivers a complete set of features that a user might

need (Berauk et al., 2017). Users dislike downloading

multiple apps as they unnecessarily increase the num-

https://orcid.org/0000-0001-9438-4532

https://orcid.org/0000-0002-9432-9477

https://orcid.org/0000-0003-3812-9785

https://orcid.org/0000-0002-3187-4937

https://orcid.org/0000-0003-2240-0454

https://orcid.org/0000-0003-4928-7076

ber of applications on their smartphones (van Velsen

et al., 2013). Similarly, many users stop using health

apps due to the burden of repeated data entry, hidden

costs and confusion around several apps (Krebs and

Duncan, 2015; Wiechmann et al., 2016).

Data visualization is also a key component of

health tracking apps that helps users to track their

goals, habits, and achievements (Lee et al., 2020).

However, studies have shown diversity in data visu-

alization audiences (Jena et al., 2021), which in turn

introduce challenges related to the user experience

around mobile data visualization (Gu et al., 2018)

(Katz et al., 2017). For example, users generally de-

sire more control over charts to better monitor their

health progress and goals (Alshehhi et al., 2022a).

Further, another user survey around the strengths

and weaknesses of mHealth app visualizations high-

lighted the lack of interaction, such as zooming capa-

bilities, as a major limitation (Alshehhi et al., 2022b).

The ability to customize personal goals on charts was

also highlighted as one of the desired features. This,

in turn, indicates that the current data visualization

guidelines lack support for inclusive design, resulting

in a poorer experience.

From the engineering side, developing apps re-

quires writing large amounts of boilerplate code (Bar-

nett et al., 2015) and doing so for several different

Philip, B., Alshehhi, Y., Abdelrazek, M., Barnett, S., Bonti, A. and Grundy, J.

mHealthSwarm: A Uniﬁed Platform for mHealth Applications.

DOI: 10.5220/0011985600003464

In Proceedings of the 18th International Conference on Evaluation of Novel Approaches to Software Engineering (ENASE 2023), pages 605-612

ISBN: 978-989-758-647-7; ISSN: 2184-4895

 2023 by SCITEPRESS – Science and Technology Publications, Lda. Under CC license (CC BY-NC-ND 4.0)

605

platforms greatly increases cost and development ef-

fort (Pinto and Coutinho, 2018), which cross-platform

frameworks aim to simplify. Given the fragmentation

among the mHealth apps and current platforms, ef-

forts have been made to overcome these challenges.

This includes frameworks for cross-platform develop-

ment such as Ionic, Cordova and React Native. Al-

though these (limited) frameworks can be used for

developing mHealth apps (Banos et al., 2015), they

still do not solve the problem of data sharing between

apps, integration of wearables and peripherals, a uni-

form UX/UI and app features customization (Anas-

tasiadou et al., 2019). While recent works (Inupaku-

tika et al., 2020) have attempted to develop cross-

platform mHealth solutions that focus on simplify-

ing app development, they fall short on customizabil-

ity and integration with other services. The develop-

ment of a “super-app” that covers all major aspects of

health was previously suggested by Higgins as a so-

lution to such problems. However, this has its own

set of challenges, such as many unused features, di-

verse user needs and great maintenance issues (Hig-

gins, 2015).

There is thus a need for a new approach and plat-

form to accelerate and support building better collab-

orative mHealth apps with focused capabilities that

can be customized as needed. We propose an ap-

proach we term “micro-mHealth apps”, and we hy-

pothesize that they will offer a better experience for

both end users and mHealth app developers saving a

lot of effort, time and money. This paper discusses

our motivation and past work supporting this position,

a high-level solution architecture and platform de-

tails, and discusses the details of developing a micro-

mHealth app prototype.

2 MOTIVATION

2.1 Motivating Example

Consider a blood pressure management scenario.

Many blood pressure tracker apps are available in

commercial app stores. Unfortunately, users often

end up downloading different apps with several un-

used features, and feature overlaps between them

(Philip et al., 2022a; Alshehhi et al., 2022b). In the

case of data visualization, users can ﬁnd that their

apps present similar visualizations to track their blood

pressure (ﬁgure 1) – an example of redundant fea-

tures. In addition, related information such as weight

and glucose measurements are also often presented

separately. In such cases, this case, users may need

to switch between two or more apps to ﬁnd mean-

ingful insights derived from different metrics. A pre-

vious study highlighted these challenges when users

need to use more than one mHealth app, and user ex-

pectations, suggesting the need for feature customiza-

tion that would allow end users to tailor mHealth apps

to their needs (Philip et al., 2022a). Our solution to

this problem proposes combining several separate app

features – micro mHealth apps – into one, to provide

a highly customizable, uniﬁed mHealth platform for

end users.

Figure 1: App screenshot showing overlapping charts with

single unique feature.

2.2 User Challenges and Expectations

Alshehhi et al. conducted a review of user perspec-

tives around visualizations in mHealth apps that indi-

cated several difﬁculties in chart customizability, in-

teractivity and functionality (Alshehhi et al., 2022a).

A subsequent anonymous survey allowed them to

further investigate these issues, which indicated that

the needs of several users have to be considered to

improve the acceptance of mHealth data visualiza-

tions (Alshehhi et al., 2022b). Similarly, Philip et

al. (Philip et al., 2022a) conducted an online sur-

vey of people having experience with mHealth apps

to understand challenges when using several mHealth

apps and expectations from future apps. While poor

design was highlighted as one reason for poor app

adoption, the participants indicated several other chal-

lenges such as additional, unnecessary features, fea-

ture overlaps between different apps, and repeated

manual data entry that can inadvertently drive users

away The survey showed that users expect a lot more

from current apps and prefer a single platform that

allows feature customization to build an application

meeting all their needs without any additional bloat.

These studies motivated us to consider the develop-

ment of a uniﬁed mHealth platform to combine to-

gether micro mHealth app features, and we hypothe-

size that such platforms can solve both the developer

and end-user challenges.

ENASE 2023 - 18th International Conference on Evaluation of Novel Approaches to Software Engineering

606

2.3 Mini Apps

Mobile apps can be classiﬁed into three categories –

native apps, mobile web apps and hybrid apps (Inu-

pakutika et al., 2020) with their development largely

depending on their use. Web and hybrid apps are sug-

gested for better cross-platform compatibility, while

native or hybrid apps are suggested for better periph-

eral support (Serrano et al., 2013). mHealth apps can

be built using any approach and although the three

different formats of mobile apps offer some advan-

tage over each other, they are restricted to single apps

- i.e. each package or URL is a single application that

runs or renders on the user’s smartphone. Hybrid apps

offer the beneﬁt of using a web application wrapped

inside a native container, which is potentially more

beneﬁcial for developers as the web component can

be shared across platforms. However, end-users may

not see any difference or obtain any direct beneﬁts

through such designs.

The concept of “Mini-apps” was introduced in a

working draft white paper (W3C, 2019) submitted to

the W3C as a new format of mobile apps based on

web technologies that integrates with and behave like

native apps. Based on hybrid apps, they offer bene-

ﬁts such as being free from installation and storage

constraints with the ability to access platform capa-

bilities through native container apps. These apps can

be considered across two layers - (1) the Logic Layer

responsible for handling the business logic, internal

state and integration with system data and services;

and (2) the View Layer for rendering the user inter-

face (UI) and handling user interaction.

This structure can be compared to a traditional

web application, with the views constructed using

HTML and CSS, and the app logic handled using

JavaScript. UIs can be rendered using native compo-

nents such as WebViews which also act as an interface

between mini apps and the native container app. Ac-

cess to resources such as storage and hardware (cam-

era, GPS etc.) cannot be provided directly through

the web interface, but through custom APIs provided

by the container that allows controlled access to sys-

tem resources. By extending hybrid applications into

such containers, a whole ecosystem of mini apps can

be deployed in a way that facilitates data sharing be-

tween them and allows a user to create custom apps

with features tailored to their individual needs.

We build on top of this idea for health/ﬁtness/well-

ness apps by introducing a single, highly customiz-

able super-app and provide a much better health app

experience by avoiding the challenges of full apps

(Liu et al., 2019; Liu et al., 2020).

3 OUR PLATFORM

To address the requirements identiﬁed in the previ-

ous section, we have developed a novel mHealth-

Swarm uniﬁed mHealth platform. This provides a

framework for developing health and wellness ser-

vices and abstracts device features and low level oper-

ations into simple high level functionality, providing a

highly customizable environment that can be person-

alized by adding/removing single-function mHealth

services/apps.

Our mHealthSwarm platform uses a registration

mechanism that records app permissions when linked

to a user’s account. Each time a service app needs

user data or access to underlying device hardware, it

needs to make a request to the platform using exposed

APIs. These requests are then checked, and then the

appropriate resource is provided to the requesting ap-

plication. The following section presents a very high-

level overview of the main architectural components.

Our mHealthSwarm platform architecture is out-

lined in Figure 2. It is divided into four components,

which are brieﬂy described below.

Application Manager: The Application Manager

combines the view and logic layers and can be con-

sidered as a task manager that keeps track of active

micro-apps and provides an interface to the container

(i.e., our micro-mHealth app platform) APIs.

Data Manager: A gateway for all health data pro-

duced and consumed by hosted micro-apps, along

with raw data collected from health peripherals. Al-

though this component currently only supports local

data storage, future extensions are planned to support

remote storage and management.

Device Manager: The component is responsible for

handling sensors connected to the smartphone and

provides an interface for collecting raw data produced

by these sensors.

Conversation Manager: Although our platform could

reduce the need for several health apps, users may still

have to navigate through the micro-apps.

The ecosystem of conversational interfaces have

been expanding rapidly

and studies around their use

have also suggested their usefulness in performing

simple tasks such as scheduling appointments (Palan-

ica et al., 2019). Given the availability of numerous

health metrics on our platform, we believe it is a suit-

able environment for a chatbot to help users interact

with.

Our current prototype aims to provide end users

a better experience by providing complete customiz-

ability of functions through micro-health-apps. It is

https://www.businessinsider.com/chatbot-market-stats

-trends?r=AU\&IR=T

mHealthSwarm: A Uniﬁed Platform for mHealth Applications

607

Figure 2: Architecture overview of our platform.

implemented as an Android application, with the sup-

porting framework for micro-mHealth apps imple-

mented as a back end service using Node.js. The plat-

form is designed to facilitate access to device hard-

ware such as Bluetooth and GPS modules along with

other embedded sensors (IMUs, camera) through ab-

stract functions. However, given the very limited use

of external sensors by currently available apps (Philip

et al., 2022b), the current implementation has limited

support for peripheral devices, with plans for support-

ing more in the future. The micro-mHealth apps do

not have any control over the device hardware, but

are only passed the data from these sensors via the

platform.

Data storage currently uses the Room Persis-

tence Library for predeﬁned data types, with addi-

tional support for app-speciﬁc storage in separate

ﬁles. The platform interface allows all registered

micro-mHealth apps with the appropriate permissions

to fetch and store the required data. Data transfer

between the app and the remote service uses HTTP

methods with the data wrapped in JSON objects.

Our mHealthSwarm platform provides a set of

mini apps, which form the basis of our micro-mHealth

apps. These are structured like web applications,

which reduces the learning curve required for de-

veloping mHealth apps, while also making them

platform-independent. Interaction with the platform

is handled through exposed APIs called from the logic

layer, a brief example of which is presented in the next

section.

While native container apps for different mobile

operating systems will have to be developed, they of-

fer the beneﬁt of cross-platform support for the micro-

mHealth apps they host. To ‘install’ services, users

will just need to link those micro-mHealth apps avail-

able on the platform to their accounts, during which

permissions will be established. Launching a micro-

mHealth app will launch the feature droplet in the

container, which then handles app requests and pro-

vides data to the running micro-mHealth app after val-

idating permissions. The overall implemented ﬂow of

data and platform events are outlined in ﬁgure 3.

4 USAGE EXAMPLE

Consider an app such as MapMyWalk

with the core

feature of tracking walks. A micro-mHealth app can

be built with the same core feature, eliminating ad-

ditional, unnecessary functionality, allowing users to

choose the app functionality they need. To demon-

strate this, we developed a micro-mHealth app on our

platform

where the service keeps track of a user’s lo-

cation, step count and heart rate (if available) during

a workout session and allows them to review the data

later. The following code snippet from the JavaScript

logic layer outlines a very basic request for the user’s

location. It shows a call to the platform API for log-

ging the GPS coordinates in the database and setting

a callback reference to the function that handles the

location data. This data is then used by the micro-

https://play.google.com/store/apps/details?id=com.ma

pmywalk.android2

https://github.com/benphilip1991/del-container

ENASE 2023 - 18th International Conference on Evaluation of Novel Approaches to Software Engineering

608

Figure 3: An overview of our micro-application container data-ﬂow.

mHealth app to provide the walk tracking feature.

Figure 5 (right) shows the micro app implementing

this feature, and ﬁgure 4 shows the overall control

and data ﬂow for this app after it is launched. This

snippet also indicates how access to sensor data and

other resources can be greatly simpliﬁed through our

proposed approach.

1 function a pp In it () {

2 let a pp Re q ue st = {

3 // i nj ec te d on l au nc h

4 " ap pId " : this. appId ,

5 " r eq ue st s " : [{

6 " reso ur ce " : " lo ca ti on " ,

7 " call ba ck " : " pr oc es s Lo c " ,

8 " t og gl e " : true

9 }]

10 };

12 // Log da ta in the d at ab as e

13 D el Ut il s . se t Se n s or L og g er R equ e st (

14 JS ON . s tr ing if y ( a p pR eq ue s t ));

16 // R eg is te r c al lb a ck

17 D el Ut il s . se t Ca l lb a ck R eq u es t (

18 JS ON . s tr ing if y ( a p pR eq ue s t ));

19 }

21 // R eg is te r ed cal lb ac k for GPS da ta

22 function p ro c es sL oc ( dat aTy pe , l oc ) {

23 // p ro ce ss loc at io n da ta

24 }

Listing 1: App data request registration example.

Figure 4: Main interaction between the platform and a

micro-app after launch.

The sample application is built using JavaScript,

HTML and CSS with the OnsenUI framework

for

creating a native-like interface. Although the core

business logic for the micro-mHealth apps would re-

quire a similar effort as developing native code for

similar features, the beneﬁt of this approach is ap-

https://onsen.io

mHealthSwarm: A Uniﬁed Platform for mHealth Applications

609

Figure 5: Prototype with three “installed” micro-apps (left);

our micro-app implementation of a walk tracker (right).

parent when considering the single-function nature of

these app droplets and the overall simpliﬁcation of ac-

cess to device resources and shared user data.

The novelty of the platform for mHealth comes

from a highly customizable environment where each

micro-mHealth app provides a single function and can

be added/removed as required, enabling end users to

create personalized health apps. To evaluate our plat-

form and its feature customizability with end users,

we implemented core functions (i.e., workout track-

ing, meal tracking, and mood tracking) inspired from

3 popular apps. Our evaluations are still ongoing, and

preliminary results are discussed in the next section.

To further enhance the customizability, we also in-

troduced semi-customizable charts for different use-

cases such as tracking one’s meals (ﬁgure 5 right),

and while the current implementation is very lim-

ited, further extensions to visualization components

are planned to extend the range of personalization on

the platform.

This design is expected to remove unnecessary de-

velopment overheads from developers, who no longer

have to worry about low level details such as device

integration and data management. This may also open

up the domain to a wider developer community in ad-

dition to mobile app developers, allowing for more

innovation in the domain. The hybrid app design is

also expected to simplify updates as a veriﬁed service

update will be made available to all users on release

without the need for manual search and installation.

5 DISCUSSION

Although the Android and iOS operating systems of-

fer native support for health data aggregation with

frameworks such as Google Fit and Apple Health,

they still suffer from a common issue - the reliance

on more than one health app. However, given the

popularity of hybrid applications and wide commer-

cial success of mini-app frameworks for messaging

and eCommerce (e.g., WeChat

), they appear to be a

suitable alternative to native services. This approach

offers the beneﬁts of hybrid applications while pro-

moting an open, customizable platform of mHealth

services. Despite the advantages, this customizabil-

ity comes with some drawbacks, such as an added

overhead for learning the platform functionality and

slightly lower micro-app performance. However, we

believe that these are minor issues considering the

overall beneﬁts the platform offers.

In terms of functionality, our mHealthSwarm plat-

form is currently limited to an external heart rate mon-

itor, built-in sensors, GPS and camera. The platform

is also currently limited to Android, with a future ex-

pansion planned for supporting iOS. We are currently

also exploring ways to improve data visualization

in micro-mHealth apps by using platform-provided

components. This is expected to simplify the devel-

opment aspects and provide more ﬂexibility to end-

users. Similarly, given the highly speciﬁc and limited

nature of the platform and its capabilities, a domain-

speciﬁc language for developing micro-mHealth apps

is also being considered as a future extension to fur-

ther simplify app development by generating micro-

mHealth app components. However, despite the po-

tential advantages, the platform currently suffers from

limited support for existing apps and business models,

and requires further investigation.

Our mHealthSwarm platform is currently being

evaluated with end-users as well as mobile app de-

velopers to get their feedback. Preliminary user eval-

uations have indicated a preference for this approach,

with the participants stating they like the feature cus-

tomizability offered by the platform. This is high-

lighted by one participant’s comment - “What I def-

initely like about the platform is the customization -

that I can select the features that I use”. So far, almost

all users have indicated that the platform was easy to

learn, with emerging themes from participant inter-

views highlighting the ease of use, the beneﬁts of fea-

ture customization, and the ease of data management

on a single platform. Similarly, ongoing developer

evaluations have also seen mostly positive feedback,

with the main highlight being the reduced develop-

https://www.wechat.com/

ENASE 2023 - 18th International Conference on Evaluation of Novel Approaches to Software Engineering

610

ment effort. A developer’s comment - “...this seems

to be a bit more like web development, so yeah [it’s]

quite simple... with less boilerplate code, compared to

regular mobile apps” - highlights the potential ben-

eﬁts for app developers. However, major concerns

such as the limitations of the platform in its current

state (including limited support for testing and de-

bugging micro-mHealth apps, and limited documen-

tation) when compared to current mobile app devel-

opment frameworks were also highlighted.

Overall, our work in this domain focuses on pro-

viding a better framework and platform for micro-

mHealth apps as a means to achieve the following

goals: (1) To provide a consistent platform for bet-

ter collaboration and communication between the dif-

ferent apps; (2) To foster an ecosystem of micro-

mHealth apps built for speciﬁc functions, eliminat-

ing unnecessary components and bloat; (3) To reduce

the increasing device resource requirements and con-

tention of several large health apps on one device; and

(4) To provide a better user experience and increase

mHealth adoption.

6 SUMMARY

In this paper, we presented our mHeallthSwarm plat-

form of a micro-mHealth platform that addresses ma-

jor challenges with current mHealth apps such as the

need to install more than one app, unnecessary bloat

in the applications and challenges with data sharing

and management. We discuss implementation details

of our platform with a brief data ﬂow sequence dia-

gram showing a high-level ﬂow of app requests and

data. We then brieﬂy discuss a sample app and how

it can be developed using the platform APIs. Overall,

our approach for developing micro-mHealth apps will

guide the design and development of novel mHealth

apps and platforms, and in the future have a positive

impact on the adoption of mHealth services.

ACKNOWLEDGEMENTS

Philip is supported by Deakin University Schol-

arship and ARC Research Hub IH170100013.

Grundy is supported by ARC Laureate Fellowship

FL190100035.

REFERENCES

(2019). MiniApp Standardization White Paper, W3C First

Public Working Draft.

Alshehhi, Y., Abdelrazek, M., and Bonti, A. (2022a). Anal-

ysis of personal data visualisation reviews on mobile

health apps. In ACHI 2022, The Fifteenth Interna-

tional Conference on Advances in Computer-Human

Interactions, pages 111–118. IARIA.

Alshehhi, Y. A., Abdelrazek, M., and Bonti, A. (2022b).

Needs and Challenges of Personal Data Visualisations

in Mobile Health Apps: User Survey.

Anastasiadou, D., Folkvord, F., Serrano-Troncoso, E., and

Lupia

nez-Villanueva, F. (2019). Mobile Health Adop-

tion in Mental Health: User Experience of a Mo-

bile Health App for Patients With an Eating Disorder.

JMIR mHealth and uHealth, 7(6):e12920.

Banos, O., Villalonga, C., Garcia, R., Saez, A., Damas, M.,

Holgado-Terriza, J. A., Lee, S., Pomares, H., and Ro-

jas, I. (2015). Design, implementation and validation

of a novel open framework for agile development of

mobile health applications. BioMedical Engineering

OnLine, 14(2):S6.

Barnett, S., Vasa, R., and Grundy, J. (2015). Bootstrap-

ping mobile app development. In Elbaum, S. and Can-

fora, G., editors, Proceedings - 2015 IEEE/ACM 37th

IEEE International Conference on Software Engineer-

ing, ICSE 2015, volume 2, pages 657–660, United

States of America. IEEE, Institute of Electrical and

Electronics Engineers.

Berauk, V., Murugiah, M., Soh, Y., Sheng, Y., Wong, T.,

and Ming, L. C. (2017). Mobile Health Applications

for Caring of Older People: Review and Comparison.

Therapeutic Innovation & Regulatory Science, page

216847901772555.

Gu, J., Mackin, S., and Zheng, Y. (2018). Making sense:

an innovative data visualization application utilized

via mobile platform. In 2018 IEEE 20th Interna-

tional Conference on High Performance Computing

and Communications; IEEE 16th International Con-

ference on Smart City; IEEE 4th International Con-

ference on Data Science and Systems (HPCC/SmartC-

ity/DSS), pages 1105–1109. IEEE.

Higgins, J. (2015). Smartphone Applications for Patients’

Health & Fitness. The American journal of medicine.

Inupakutika, D., Kaghyan, S., Akopian, D., Chalela, P., and

Ramirez, A. G. (2020). Facilitating the development

of cross-platform mHealth applications for chronic

supportive care and a case study. Journal of Biomedi-

cal Informatics, 105:103420.

Jena, A., Butler, M., Dwyer, T., Ellis, K., Engelke, U.,

Kirkham, R., Marriott, K., Paris, C., and Rajaman-

ickam, V. (2021). The next billion users of visual-

ization. IEEE Computer Graphics and Applications,

41(2):8–16.

Katz, D., Dalton, N., Holland, S., O’kane, A., and Price,

B. A. (2017). Questioning the reﬂection paradigm for

diabetes mobile apps. In eHealth 360°, pages 315–

326. Springer.

Krebs, P. and Duncan, D. T. (2015). Health app use among

us mobile phone owners: A national survey. JMIR

mHealth uHealth, 3(4):e101.

Lee, B., Choe, E. K., Isenberg, P., Marriott, K., and Stasko,

J. (2020). Reaching broader audiences with data visu-

mHealthSwarm: A Uniﬁed Platform for mHealth Applications

611

alization. IEEE Computer Graphics and Applications,

40(2):82–90.

Liu, Y., Xu, E., Ma, Y., and Liu, X. (2019). A First Look

at Instant Service Consumption with Quick Apps on

Mobile Devices. In 2019 IEEE International Confer-

ence on Web Services (ICWS), pages 328–335. IEEE.

Liu, Z.-Y., Liao, K., and Wang, J.-L. (2020). Research on

the inﬂuence of we-chat applet on improving user ex-

perience. In Proceedings of the Korean Society of

Computer Information Conference, pages 613–615.

Korean Society of Computer Information.

Palanica, A., Flaschner, P., Thommandram, A., Li, M., and

Fossat, Y. (2019). Physicians’ Perceptions of Chatbots

in Health Care: Cross-Sectional Web-Based Survey. J

Med Internet Res, 21(4):e12887.

Philip, B., Abdelrazek, M., Barnett, S., Bonti, A., and

Grundy, J. (2022a). Towards Better mHealth Apps:

Understanding Current Challenges and User Expec-

tations. In 2022 IEEE/ACM 9th International Con-

ference on Mobile Software Engineering and Systems

(MobileSoft), pages 33–37.

Philip, B. J., Abdelrazek, M., Bonti, A., Barnett, S., and

Grundy, J. (2022b). Data Collection Mechanisms

in Health and Wellness Apps:Review and Analysis.

JMIR mHealth and uHealth, 10(3).

Pinto, C. M. and Coutinho, C. (2018). From Native to

Cross-platform Hybrid Development. In 2018 Inter-

national Conference on Intelligent Systems (IS), pages

669–676.

Serrano, N., Hernantes, J., and Gallardo, G. (2013). Mobile

web apps. IEEE Software, 30(5):22–27.

Sezgin, E.,

Ozkan-Yildirim, S., and Yildirim, S. (2017).

Investigation of physicians’ awareness and use of

mHealth apps: A mixed method study. Health Pol-

icy and Technology, (3):251–267.

van Velsen, L., Beaujean, D. J., and van Gemert-Pijnen,

J. E. (2013). Why mobile health app overload drives

us crazy, and how to restore the sanity. BMC Medical

Informatics and Decision Making, 13(1):23.

Ventola, C. L. (2014). Mobile devices and apps for health

care professionals: uses and beneﬁts. P & T : a peer-

reviewed journal for formulary management, (5):356–

364.

WHO (2011). mHealth: New horizons for health

through mobile technologies: second global survey on

eHealth, volume 3 of Global observatory for eHealth

Series, 3. World Health Organization.

Wiechmann, W., Kwan, D., Bokarius, A., and Toohey,

S. L. (2016). There’s an App for That? Highlighting

the Difﬁculty in Finding Clinically Relevant Smart-

phone Applications. The western journal of emer-

gency medicine, (2):191–194.

ENASE 2023 - 18th International Conference on Evaluation of Novel Approaches to Software Engineering

612