Roadmap for mHealth Research

Joshua D. Cameron

, Arkalgud Ramaprasad

and Thant Syn

Miller School of Medicine, University of Miami, Coral Gables, FL, U.S.A.

Department of Information and Decision Sciences, University of Illinois at Chicago, Chicago, IL, U.S.A.

A. R. Sanchez, Jr. School of Business, Texas A&M International University, Laredo, TX, U.S.A.

Keywords: Mobile Health, Ontology.

Abstract: mHealth research has been growing exponentially in recent years. But, without a clear definition of the

mHealth domain, the research has been ad hoc and selective. A roadmap is necessary to guide the research

and harness mHealth’s full potential. We present an ontology of mHealth to define its domain. We map the

extent research on mHealth in 2014 onto the ontology and highlight the frequency of coverage of different

topics. We discuss how (a) a frequently researched topic may be important, but may also be simply easy,

convenient, and overemphasized; (b) an infrequently researched topic may be unimportant, but may also be

simply difficult, inconvenient, and underemphasized; (c) and an unresearched topic may have been

overlooked or simply infeasible. We then discuss how the emphases can be balanced in the roadmap for

mHealth. Using ontological mapping the roadmap can be updated periodically to assess and guide mHealth

research.

1 INTRODUCTION

The domain of mobile health, or mHealth as it is

commonly denoted, has garnered much attention in

recent years as its application has come to permeate

the healthcare industry. The concept of mobility has

evolved from the physical transportation of

healthcare staff and equipment to simply

transporting information using modern technologies

(Cameron et al., 2015); a novel paradigm that begins

in telemedicine and telehealth, giving rise to the

concept of eHealth with mHealth as its subset

(Nacinovich, 2011). The smartphones and associated

technologies represent the next stage of the

evolution in ‘transporting information to transform

healthcare’ (Ramaprasad et al., 2009).

There has been an explosion of research on

mHealth in the last few years. There are altogether

808 mHealth articles with abstracts indexed in

PubMed of which 364 (45%) are from 2014. The

numbers are likely to continue to grow.

Amidst this rapid explosion of interest in

mHealth there is absent a definition of its domain.

Researchers have focused selectively on different

parts of the whole, neglecting the “big picture” – a

theme analogous to the story of the five blind men

and the elephant (Ramaprasad and Papagari, 2009,

Börner et al., 2003). This selectivity results in

fragmentation of the research agenda; the sum of the

parts simply falls short of making the whole. There

is a need to articulate and make the combinatorial

complexity of mHealth visible to facilitate effective

research on mHealth systems (Ramaprasad and Syn,

2013). “The current confusion in the nomenclature

and classification hinder telemedicine research … it

frustrates our efforts to reach a reasonable

understanding of what we already know and what

we need to know. Equally important, it impedes

progress toward development and implementation of

a research agenda geared toward reaching answers to

questions regarding the true benefits and costs of

telemedicine.” (Bashshur et al., 2011, p. 492) With

these concerns in mind, we use an ontology to

represent the complexity of mHealth. The ontology

by itself can be used as a roadmap to guide research

in the domain. It can also be used to map and assess

the research in the domain. Such an assessment, the

topography of research in the domain, can be used to

develop a roadmap for future research. The ontology

and the mapping can be updated periodically to keep

the roadmap current.

Cameron, J., Ramaprasad, A. and Syn, T.

Roadmap for mHealth Research.

DOI: 10.5220/0005626800280038

In Proceedings of the 9th International Joint Conference on Biomedical Engineering Systems and Technologies (BIOSTEC 2016) - Volume 5: HEALTHINF, pages 28-38

ISBN: 978-989-758-170-0

2 AN ONTOLOGY OF mHEALTH

An ontology represents the conceptualization of a

domain (Gruber, 2008); it organizes the

terminologies and taxonomies of the domain. It is an

“explicit specification of a conceptualization,”

(Gruber, 1995, p. 908) and can be used to

systematize the description of a complex system

(Cimino, 2006). “Our acceptance of an ontology

is… similar in principle to our acceptance of a

scientific theory, say a system of physics; we adopt,

at least insofar as we are reasonable, the simplest

conceptual scheme into which the disordered

fragments of raw experience can be fitted and

arranged.” (Quine, 1961, p. 16) Using an ontology

we hope to make the metaphorical ‘elephant’ visible.

An ontology of mHealth is shown in Figure 3.

Four illustrative components of mHealth derived

from the ontology are listed below the ontology,

each with an example. A glossary of all the terms is

given in Appendix 1. We will discuss the

construction of the ontology, its dimensions,

taxonomies, elements, and the components

encapsulated within.

2.1 Construction of the Ontology

Our method of constructing an ontology is explained

by Ramaprasad and Syn (2013) and Ramaprasad and

Syn (2015). It was iterative amongst the authors of

the paper (a physician in training and two

information systems professors) and by the authors

with the extent literature. The challenge was to

construct an ontology which is logical,

parsimonious, and complete. It had to be logical in

the deconstruction of the domain, parsimonious yet

complete in the representation of the domain. It had

to be a closed description of the mHealth domain.

The challenge was also to adapt the information

system terminology to mHealth. This was done by

iterating with the literature and creating a glossary of

terms (Appendix). In this context, we should note

that the ontology presented is one of many possible

ontologies of the mHealth domain. A complex

domain like mHealth can be studied from many

points of view, each with its own ontology. It is a

‘wicked’ (Churchman, 1967) problem with many

potential formulations. Each ontology can be seen as

a lens by which one may study the domain – ours is

one of many possible lenses.

2.2 Dimensions of the Ontology

The mHealth ontology is detailed in Cameron et al.,

(2015). The ontology deconstructs the domain of

mHealth into three dimensions: mHealth System,

Stakeholders in the healthcare system, and the

Outcomes of the healthcare system. (Note: words

which refer to the dimensions and sub-dimensions of

the ontology are capitalized. We will also capitalize

references to elements of a dimension – its

categories and subcategories.) The dimensions are

represented by columns or a concatenation of

columns in Figure 1. The definitions of mHealth

discussed earlier include these dimensions

implicitly; we have explicated them in the ontology.

The mHealth System is the system built around the

mobile technology to manage healthcare

information. The Stakeholders are those with a stake

in the delivery/receipt of healthcare whose role

includes the associated management of information

using mobile technology. The Outcomes are the

desired results of healthcare sought through the

meaningful use of mobile technology for the

management of healthcare information, extending

the concept of meaningful use of healthcare

information systems (Ramaprasad et al., 2014,

Centers for Medicare & Medicaid Services).

The ontology further deconstructs the mHealth

System into three sub-dimensions: Structure,

Function, and Semiotics. The Structure defines the

physical and organizational objects constituting the

system; the Function defines the actions of the

system; and the Semiotics the information objects

managed by the system. The structural/functional

deconstruction is widely used in analysis of

physical, biological, and logical systems. The

explicit identification of the Semiotics dimension

recognizes the centrality of management of the

morphology, syntax, semantics, and pragmatics of

information (Ramaprasad and Rai, 1996) in

mHealth.

Each dimension is articulated by a two-level

taxonomy of elements. These taxonomies can be

extended by adding more elements, reduced by

deleting elements, refined by adding more levels,

and coarsened by aggregating existing levels. The

elements and the number of levels in the taxonomy

define the scale and granularity of the dimension.

2.2.1 mHealth System – Structure

The first-level taxonomy of elements is based on the

common body of knowledge in information systems

(Rainer and Cegielski, 2012). The structure of an

information system is commonly described in terms

of Hardware, Software, Networks, data, Processes,

people and Policies. To limit the redundancy of

elements, we have excluded data and people from

Roadmap for mHealth Research

Figure 1: Ontology of mHealth.

this level given their inclusion as fundamental

components of the Stakeholder and Semiotics

dimensions respectively.

The second-level elements are particular to

mHealth. Thus, Sensors and Devices are the focus of

mHealth Hardware; Platforms and Applications are

the focus of Software; Local Wireless and

Telecommunication networks are the focus of

Networks; Manual and Automated processes are the

focus of Processes; and, Privacy and Regulation are

the focus of Policies. The five categories and the ten

subcategories define the elements of Structure for

performing the Functions of mHealth described next.

2.2.2 mHealth System – Function

We started with the commonly used taxonomy of

information system Functions: acquisition, storage,

retrieval, processing, and distribution. These

functions are relevant to mHealth but do not fit well

with the focus of mHealth in research and practice.

Hence, we modified the first-level taxonomy of

Structure Function Semiotics Stakeholder Outc ome

Hardware Acquisition Data HealthcareProviders Efficiency

Sensors Storage Stati c Physicians Cost

Devi ces Encrypted Streaming Nurses Ti me

Software Non‐Encrypted HealthRecords Pharmacists Resource

Platform Analysis Current CareTeams Quality

Applications Quantitative Historical Organizations Standard

Networks Qualitative Knowledge Hospitals/Clinics Accuracy

LocalWireless Interpretation Current Government/HealthAgencies Efficacy

Te lecommunication Diagnosti c Tradi tional I nsure rs Safe ty

Processes Predictive GeneralPopul ation Parity

Manual Interve ntional Indi vi dual s

Automated Application Families/Groups

Policies Adoptive Communities

Privacy Prescriptive

Regulation Scholastic

Distributive

Deletion/Erasure

Local

Systemic

[of/inhealthcare]

[of]

[tomeaningfullymanage]

[formobile]

[by]

mHealthSystem

Poli ciesformobileapplicationofknowle dgebyorgani zati onstomeaningf ully managequalityofhealthcare.

Ex ample:Governmentregulatorycontrol(e.g.,FDAsafetyandinnovationact),mHealthRegulatoryCoalitionguidelines.

Proce sses

manual

formobiledeleti on

local

ofdata

static

byheal thcare providers

physicians

tomeaningfullymanagesafetyin

healthcare.

Ex ample:Def aultexpirationdatesforpatientdatadownloaded/entered/storedonmobiledevices.

Illustrativecomponents:

Hardwareformobil eacquisiti onofdatabyheal thcareprov iderstomeaningfullymanageefficiencyofhealthcare.

Ex ample:WirelessDataAcquisitionModule(WDAM)forcontinuousmonitoringofpatientdataderivedfromwearable

sensors.

Softwareformobile

interpretationofhealthrecordbygene ralpopulationtomeaningfullymanagesafetyofhealthcare.

Ex ample:PersonalHealthRecords(PHRs),Applicationsprovidingmedicalsupport/healthinformationtoolsforgeneral

population(e.g.,WebMD,MedicineNet,Healthline)

Ex ample:Clinicaldescision‐supporttoolspromotingadherencetoevidence‐basedguidelines(e.g.,e‐checklist,UpToDate,et

Softwareformobileapplicationofknowle dgebyhealthcareprovi derstomeaningf ullymanagequali ty ofheal thcare .

Ex ample:Applicationsfortracking/flagginghealthdata(e.g.,fitness,bloodpressure,glucose,etc.).

Softwareformobileinterpretationofdatabygeneralpopulationtomeaningfullymanagequalityofhealthcare.

Networksformobileappli cationofknowledge byhealthcareprovidersto

meaningfullymanageefficiencyofheal thcare.

Ex ample:Real‐timecommunicationstoolsbetweenproviders(e.g.,text‐based,voice‐based,cloud‐based,etc.).

Ex ample:Bluetooth‐embeddedmobiledevicesforremotedatatransmission(vitals,GPScoordinated,etc.)

HEALTHINF 2016 - 9th International Conference on Health Informatics

Functions to include: Acquisition, Storage, Analysis,

Interpretation, Application, and Deletion/Erasure.

The modified taxonomy overlaps with but also

extends the common taxonomy.

The second-level elements are particular to

mHealth, as with the second-level elements of

Structure. Thus, Storage can be Encrypted or Non-

Encrypted; Analysis can be Quantitative or

Qualitative; Interpretation can be Diagnostic,

Predictive, or Interventional; Application can be

Adoptive, Prescriptive, Scholastic, or Distributive;

and Deletion/Erasure can be Local or Systemic.

2.2.3 mHealth System – Semiotics

Here we use the variant of the traditional taxonomy

of data, information, and knowledge. We substitute

information with Health Records and keep Data and

Knowledge. These correspond to the morphological,

syntactic, and semantic levels (Ramaprasad and Rai,

1996) of semiotics. It must be noted that there is no

element corresponding to the pragmatic level.

The second-level elements are again customized

to mHealth. Thus, Data can be Static or Streaming;

Health Records can be Current or Historical; and

Knowledge can be Current or Traditional.

2.2.4 mHealth System

The mHealth System is defined by the combination

of elements from its Structure, Function, and

Semiotics. It includes, for example: (a) hardware for

mobile acquisition of data – possibly a smartphone;

(b) software

applications

for mobile interpretation of

health records

current

– possibly a decision support

app; and (c) policies

privacy

for mobile

deletion/erasure of data

static

– possibly policies for

storing patient data on personal devices. (Note:

Second-level elements are shown as subscripts.) The

ontology encapsulates 90 potential first-level

components of the mHealth System and 780

potential second-level components. These

components constitute a complete, closed

description of a mHealth system.

2.2.5 Stakeholder

There are three broad stakeholders in the mHealth

System. They are: (a) the Healthcare Providers, (b)

the healthcare Organizations, and (c) the General

Population who receive healthcare. The Healthcare

Providers include the Physicians, Nurses,

Pharmacists, and Care Teams. The Organizations

include Hospitals/Clinics, Government/Health

Agencies, and Insurers. The General Population

includes Individuals, Families/Groups, and

Communities.

A mHealth system may cater to the selective

needs of a subset of stakeholders. Continuing with

the three illustrative components of a mHealth

system, one may think of: (a) hardware for mobile

acquisition of data for healthcare providers

physicians

;

(b) software

applications

for mobile interpretation of

health records

current

for general population

individuals

;

and (c) policies

privacy

for mobile deletion/erasure of

data

static

for organizations

hospitals/clinics

. Each of the 90

potential first-level components and the 780

potential second-level components of mHealth may

be concatenated with the Stakeholder groups or

subgroups to enumerate the potential requirements

of mHealth for the stakeholders. It will be a very

large number. In designing a mHealth system one

will have to be selective.

2.2.6 Outcome

Efficiency, Quality, Safety, and Parity of healthcare

are the dominant concerns of healthcare information

systems, at least in the USA (Centers for Medicare

& Medicaid Services, Ramaprasad et al., 2014).

They define the meaningful use of healthcare

information systems. It would be appropriate to seek

the same outcomes for mHealth systems. Efficiency

may be measured in terms of the Cost, Time, and

other Resources utilized by stakeholders in the

delivery of healthcare – these three components

constitute the second-level elements. Quality may be

measured in terms of the adherence to Standards,

Accuracy of diagnosis and treatment, and the overall

Efficacy of care. Extending the illustration of the

three components of a mHealth system one may

consider the following three components of

mHealth: (a) hardware for mobile acquisition of data

for healthcare providers

physicians

to meaningfully

manage safety in healthcare; (b) software

applications

for mobile interpretation of health records

current

for

general population

individuals

to meaningfully manage

efficiency

cost

of healthcare; and (c) policies

privacy

for

mobile deletion/erasure of data

static

for organizations

hospitals/clinics

to meaningfully manage quality

standard

healthcare.

2.3 Components of mHealth

The dimensions (and sub-dimensions) of the

ontology are arranged left to right with adjacent

words/phrases with a purpose. The concatenation of

an element from each dimension with the adjacent

words/phrases creates a natural English sentence

illustrating a potential component of mHealth. The

Roadmap for mHealth Research

concatenation has been demonstrated with the three

examples carried through the discussion of the

dimensions of the ontology as well as the four

illustrative components with examples listed below

the ontology.

At the most detailed level, the ontology

encapsulates 67,200 potential components of

mHealth. For an aggregate view, one may consider

only the first-level of the taxonomies. The

components and fragments (of these components)

define the domain of mHealth. It would be laborious

and voluminous to enumerate all the components.

The ontology provides a convenient and concise ‘big

picture’ of mHealth. It helps visualize the

combinatorial complexity and make the ‘elephant’

visible.

It may be possible to instantiate a component in

many different ways. Consider the first example

above: hardware for mobile acquisition of data for

healthcare providers

physicians

to meaningfully manage

safety in healthcare. Instantiations may vary in terms

of the hardware used, data acquired, and safety

criterion addressed. The same logic can be extended

to the other examples.

A particular mHealth research may instantiate

only a small number of components encapsulated in

the ontology. Further, some components may be

instantiated frequently and some infrequently. We

will call those frequently instantiated as ‘bright’

spots, those infrequently instantiated as ‘light’ spots,

and those uninstantiated as ‘blind/blank’ spots. A

component may be ‘bright’ because of its relative

value to the field and/or ease of study/

implementation; it may be ‘light’ due to its lack of

value and/or difficulty for study/implementation; it

may be ‘blind’ if it has been overlooked; or, it may

be ‘blank’ due to infeasibility of study. By mapping

the state-of-the-research and the state-of-the-practice

onto the ontology one can discover the ‘bright’,

‘light’, and ‘blind/blank’ spots in each, thereby

demonstrating deficiencies existing both between

and among research and practice. Further, since the

possible explanations for the luminosity of a

component is equivocal, one must dig deeper to find

the underlying cause. An important ‘bright’ spot

would be functional but an easy one would be

dysfunctional. Similarly, an unimportant ‘light’ spot

may be acceptable but a difficult, highly valued

‘light’ spot may be unacceptable. Last, a ‘blind’ spot

has to be investigated deeper lest it be important,

and a ‘blank’ spot clearly demarcated so as not to

waste one’s effort. In the next section we will

discuss how the ontology can be used as a lens to

study the topography of mHealth research

(Ramaprasad and Syn, 2014).

3 METHOD

We searched PubMed for all the journal articles

using the search string: mHealth[Title/Abstract] OR

"mobile health"[Title/Abstract] OR "mobile

healthcare"[Title/Abstract] OR ("delivery of health

care"[MeSH Terms] AND ("wireless technology"

[MeSH Terms] OR "cellular phone"[MeSH Terms]

OR "mobile applications"[MeSH Terms]))The

search string was developed through a number of

iterations. Our objective was to be inclusive in

obtaining the relevant articles. The search yielded a

total of 808 articles (excluding those without an

abstract), out of which 364 are from 2014. These

364 articles were mapped onto to the ontology as

described below.

We downloaded the title and abstract of the

articles into an Excel tool developed by one of the

authors to aid coding. Using the tool a coder can

map each article, based on its title and abstract, to

the elements of the ontology the article addresses.

Only elements which are explicitly addressed are

coded; elements which are implicitly addressed or

could be expected to be addressed in a particular

context are not coded. For example, one may expect

that almost all mHealth systems will have some

form of Storage. However, if the Storage Function is

not mentioned in the title or abstract, it is not coded.

The articles were first coded by one author and then

validated by another.

An article may instantiate multiple components,

a component, parts of multiple components

(fragments), or part of a component (fragment) of

the ontology. There is no restriction on how many

elements of the ontology could be encoded with

reference to an article, or a requirement that an

article should be encoded with reference to all the

dimensions of the ontology. Thus an article can be

encoded to: (a) an element from each dimension, (b)

multiple elements from each dimension, (c) an

element from some dimensions, or (d) multiple

elements from some dimensions.

The coding is binary – whether the element (or

its synonym) is present or not in the title and

abstract. The coding is not weighted; each article

and each element was assigned equal weight.

The data were analyzed using the same Excel

tool used for coding to generate an ontological map

of the mHealth research domain monads – the

frequency of occurrence of each element (monad) in

the ontology. This map is presented and discussed in

the section below.

HEALTHINF 2016 - 9th International Conference on Health Informatics

Figure 2: Ontological Map of 2014 mHealth Research Monads.

4 RESULTS

The ontological map of monads in research papers

on mHealth published in 2014 is shown in Figure 2.

The number in parentheses adjacent to each element

is the frequency of its occurrence in the corpus. The

bar below the element is a visual representation of

the same scaled to the maximum frequency (in this

case 219 for Software-Applications).

The monad map is very uneven. There are two

‘blind/blank’ spots – Deletion/Erasure-Local and

Deletion/Erasure-Systemic. Thus almost all the

monads in the ontology are instantiated in the

research – in other words, the 2014 corpus covers

the mHealth domain defined by the ontology almost

completely. There are also a few ‘bright’ spots and

many ‘light’ spots in each dimension. The

distinction is subjective and visual.

The dominant focus of the research in terms of

mHealth Structure is on Software-Applications (219)

and Hardware-Devices (109). This reflects the

dominant focus on the use of apps and smartphones.

These may be called the ‘bright’ spots. Among the

rest, the focus on Hardware-Sensors (28) is the

highest. This reflects the focus on use of smartphone

based sensors. There is very little (but some) focus

on Software-Platform, Network-Local Wireless and

Telecommunication, Processes-Manual and

Automated, and Policy-Privacy and Regulation.

These may be called the ‘light’ spots.

The dominant focus of the research in terms of

mHealth Functions is, in descending order, on

Interpretation-Interventional (126), Acquisition

(108), Application-Distributive (81), and

Application-Adoptive (74). Storage, Analysis, and

other forms of Interpretation have been given very

little attention. A large number of the studies focus

on use of smartphones, mobile phones, apps, and

SMS to assure adherence to a treatment regimen by

acquiring data, interpreting it and intervening when

necessary, translating the interpretation into action,

and distributing the recommendation to the

appropriate stakeholders.

The dominant focus of research in terms of

mHealth Semiotics is, in order, on Data-Static (82),

Knowledge-Traditional (57), Knowledge-Current

(45), Data-Streaming (39), and Health Records-

Current and Historical (25 each). This reflects a

focus on acquiring data (usually through smartphone

and mobile phones) and translating it into

knowledge for action. The intermediate step of

organizing the data in electronic health records and

extracting information is less emphasized.

Among the Stakeholders, the very dominant

focus is on the General Population-Individuals

(169). There is some focus on Healthcare Providers-

Physicians (42) and Healthcare Providers-Care

Teams (24). And, there is a smattering of focus on

the other Healthcare Providers (Nurses (11) and

Pharmacists (2)), Organizations (Hospitals/Clinics

(9), Government/ Health Agencies (12), and Insurers

(1)), and members of the General Population

(Families/Groups (10), and Communities (4)). The

dominant focus is individual-based recipients and

providers. It is narrow but understandable because of

the focus on smartphones and mobile phone which

are primarily individual-based devices.

Structure Function Semio tics Stakeholders Outcome

Hardware‐ Sensors(28) Acquisition(108) Data‐Static(82) HealthcareProviders‐Physicians(42) Efficiency‐Cost(31)

Hardware‐ Devices(109) Storage‐Encrypted(5) Data‐Streaming(39) HealthcareProviders‐Nurses( 11) Efficiency‐Time( 22)

Software‐Platform(17) Storage‐Non‐Encrypted(4) HealthRecords‐Current( 25) HealthcareProviders‐Pharmacists(2) Efficiency‐Re source(15)

Software‐Applications(219) Analysis‐Quantitative(11) HealthRecords‐Historical(25) HealthcareProviders‐CareTeams(24) Quality‐Standard(5)

Networks‐

LocalWireless(14) Analysis‐Qualitative(8) Knowledge‐Current(45) Organizations‐Hospitals/Clinics(9) Quality‐Accuracy(18)

Networks‐Telecommunication(18) Interpretation‐Diagnostic(31) Knowledge‐Traditional(57) Organizations‐Government/HealthAgencies(12) Quality‐Eff icacy(133)

Processes‐Manual(7) Interpretation‐Predictive(12) Organizations‐Insurers(1) Safety(17)

Processes‐Automated(11) Interpretation‐Interventional( 126) GeneralPopulation‐Individuals(169) Parity(29)

Policies‐Privacy(12) Application‐Adoptive(74) GeneralPopulation‐Families/Groups(10)

Policies‐Regulation(9) Application‐Prescriptive(36) General

Population‐Communities(4)

Application‐Scholastic(38)

Application‐Distributive(81)

Deletion/Erasure‐Local(0)

Deletion/Erasure‐Systemic(0)

[of/inhealthcare]

mHealth System

[formobile]

[of]

[by]

[tomeaningfullymanage]

Roadmap for mHealth Research

The very dominant Outcome of concern is

Quality-Efficacy (133) – perhaps a necessary first

step for smartphone apps before moving to the other

objectives. The other outcomes studied are, in order,

Efficiency-Cost (31), Parity (29), Efficiency-Time

(22), Quality-Accuracy (18), Safety (17), Efficiency-

Resource (15), and Quality-Standard (8). Many of

these researches address the question of how these

other objectives can be achieved using mHealth.

Thus, the ontological map of monads

summarizes the topical coverage of the population of

mHealth research articles indexed in PubMed in

2014, through the lens of the ontology. In the next

section we will discuss these results with a view to

develop a roadmap for mHealth research.

5 DISCUSSION

The ontology of mHealth (Figure 1) is a complete,

closed representation of the system. It represents

mHealth’s combinatorial complexity, systematically

and parsimoniously. The ontological map (Figure 2)

of 2014 mHealth research is a comprehensive

mapping of the corpus on to the ontology. As we

have summarized earlier, there are a few ‘bright’

spots in the map, many ‘light’ spots, and a couple of

‘blind/blank’ spots. Overall, while the coverage of

the corpus with reference to the ontology is

extensive, the variation in luminosity among the

elements within a dimension and across dimensions

is high. Thus, the corpus of 2014 research on

mHealth is selective and not systemic. In the

following we will discuss the selective and

asystemic emphasis in each of the five dimensions

of the ontology. We will start from the right and

move left.

The four Outcomes – Efficiency, Quality, Safety,

and Parity are all important for the meaningful use

of any healthcare system, including a mHealth

system. Their relative priority may vary by context.

The heavy emphasis on Quality-Efficacy may be

natural and necessary in the early stages of mHealth

development, but ultimately the domain has to

assure a balance between Efficiency, Quality,

Safety, and Parity of mHealth-based care. It is a

good sign that there is some research on each of the

outcomes in the corpus; it indicates recognition of

their importance. Yet, Safety is the focus of the

fewest (17) articles. The highly selective emphasis

on Quality-Efficacy may be detrimental to the

advancement of mHealth systems. It may be an easy

and convenient starting point, but the focus has to be

expanded and balanced to attain meaningful use of

mHealth.

The Stakeholders are all part of the mHealth

system. The success of providing healthcare via

mHealth to the General Population –Individuals

(169) by Healthcare Providers-Physicians (42) – the

two dominantly emphasized in the corpus – will

depend upon the inclusion and the performance of

many of the other Stakeholders. Moreover, each of

the Stakeholders, individually and interactively, is

likely to be concerned with using mHealth for

improving Efficiency, Quality, Safety, and Parity.

The corpus minimally recognizes all the

stakeholders (at least in one article). Again, the two

focuses may be easy and convenient starting points

but the corpus has to expand and balance the

coverage if mHealth is to transform healthcare.

Interestingly, the emphasis in Semiotics is

heavier at the extremes (Data and Knowledge) and

less in the middle (Health Records – information).

Comparatively, the emphases among the Semiotics

categories are more balanced than in all the other

dimensions. The corpus clearly recognizes all the

Semiotics elements. The centrality of Health

Records in the future may require greater study of its

role in mHealth too. The records, after all, are the

anchor of meaningful use of healthcare information

systems, including mHealth systems.

In terms of the Functions, the emphasis on

Interpretation, Acquisition, and Application is

understandable. And, so is perhaps the lack of

emphasis on Analysis at the early stage of

development of mHealth systems. However, given

the importance of HIPAA (in the US) and similar

laws in other countries it would be difficult to

explain the lack of emphasis on Storage (Encrypted

and Non-Encrypted) and no emphasis on Deletion

(Local and Systemic). The taxonomy of Function is

ordinal – Acquisition precedes Storage, Storage

preceded Analysis, Analysis preceded Interpretation,

Interpretation preceded Application, and Application

preceded Deletion. A systemic approach had to have

a balanced emphasis on all the stages – Storage,

Analysis, and Deletion in mHealth have to be

addressed better by the research corpus.

The emphasis on the mHealth Structure elements

is very highly skewed. It is biased towards the

technology and fails to address the infrastructure

(Networks) and soft (Processes and Policies) issues

necessary to be addressed in the design of an

effective mHealth system. Processes and Policies

have been shown to be the Achilles heel in the

implementation of information systems in general –

mHealth systems are unlikely to be an exception.

Thus, overall, there are significant gaps in the

HEALTHINF 2016 - 9th International Conference on Health Informatics

coverage of the mHealth research corpus of 2014.

They are strongly indicative of the gaps in the

corpus as a whole.

The gaps are unlikely due to sampling bias. We

have mapped all the articles from the year.

Moreover, these articles constitute 45% of the

corpus for all the years. While it is likely for the

focus of the corpus to have changed over time, it is

unlikely that the gaps evident in the 2014 corpus will

have been addressed earlier. One may also argue the

choice of PubMed itself as a source of sampling

bias. It is possible that that PubMed has not or does

not index some of the articles which address the

gaps in the ontological map. Yet, PubMed is a

broadly accepted, curated database in healthcare.

The choice of PubMed may have introduced some

errors of omission, but these errors are likely to be

small compared to the scale of the gaps in the

ontological map. The articles from other sources can

be mapped in the future.

Last, there are no norms about what the relative

emphases on the elements should be. While the

ontological map is Figure 2 is visibly skewed, it

would be difficult to specify what it should look

like. Moreover, the norm or specification may

change with new technologies, requirements,

regulations, etc. It has to be a context-specific,

subjective assessment – but yet systematic and

systemic. The ontology, by making visible the core

logic of the system, can help articulate both the

errors of omission and of commission in the research

corpus. Such a discussion will help assess and

articulate a roadmap for mHealth research.

The present analysis has focused only on the

monads in the corpus. The same data can be used to

map all the dyads, triads, and components of the

ontology. We are unable to present them due to

space constraints. The ontological maps of monads,

dyads, triads, and components provide perspectives

of the corpus at different levels of granularity. The

dyad map, for example, will highlight the co-

occurrence of elements within a dimension and of

elements across dimensions. Thus, for example, it

can be used to analyze how often the Outcomes co-

occur in a paper. A high density Outcome x

Outcome dyad submatrix would indicate a more

systemic approach to the Outcomes than a sparse

matrix would. Similarly, a high density Stakeholder

x Outcome dyad map would indicate a strong

integration of Outcomes between Stakeholders,

whereas a sparse map may indicate a differentiation

of Outcomes among Stakeholders. Analysis at the

different levels of granularity will provide insights

and inputs into developing a roadmap for mHealth.

These analyses will be presented in a subsequent

paper.

6 CONCLUSIONS

The ontology itself (Figure 1), by making the logic

of mHealth explicit and visible, can serve as a

roadmap for research on the topic. It can be used to

define the focus and priorities of research. In a

sense, each component or fragment (part of a

component) encapsulated in the ontology can be the

object of research. Defining the research topics

using the ontology also has the advantage of making

it easy to integrate the results. One will be able to

visualize how the parts fit to form a whole.

The present ontology can be refined by adding

additional categories and subcategories to the

taxonomies. It can also be coarsened by combining

the categories and subcategories of the taxonomies.

Thus, the ontology as a roadmap is adaptable – it can

be adapted to the changing needs of and

developments in the domain. For example, in the

future it may be necessary to add a Robot with

artificial intelligence as a Provider. The addition

would be easy because the ontology is modular. A

single addition like that would also increase the

components encapsulated in the ontology by a very

large number. One has to be careful in adding

elements to balance the validity of the ontology with

its parsimony. Adding an element like the Robot will

also immediately pose questions for research, for

example: How will it contribute to the Outcomes?

What will be its Semiotic capabilities? How will the

Structure and Functions of the mHealth System need

to be reconfigured?

While the ontology itself (Figure 1) presents a

plain roadmap, the ontological map (Figure 2)

presents the topography of the domain based on the

research corpus. The topography, and the reasons for

the same, has to be explicated and considered to

develop an effective roadmap. The topography of

the corpus of 2014 research on mHealth may be due

to the: (a) importance of the topic, (b) ease of doing

research on the topic, (c) history/stage of research on

the topic, and (d) the interaction of the three. The

ontological maps of monads (Figure 2), dyads,

triads, and components (not shown) highlight how

much each element/fragment/component

emphasized in the corpus. They do not explain why.

It is important to explore the reasons in formulating

a roadmap for mHealth research.

A frequently researched topic like the use of

smartphones and apps to assure adherence may be

Roadmap for mHealth Research

important, but it may also be simply easy,

convenient, and overemphasized. The profusion of

studies on this topic to the exclusion of the others

highlighted by the ontology raises the possibility of

a herd effect driven by the relative ease and

convenience of doing research on the topic. It would

be for the gatekeepers of the domain to answer the

question whether a topic is important because it is

frequently researched (and hence frequently cited);

or, whether it is frequently researched and cited

because it is important. The ontology and the

associated maps make it convenient to pose these

questions.

At the other extreme, using the ontology and

associated maps similar questions can be posed

about the ‘blind/blank’ spots. Is the absence of focus

on Deletion due to oversight or infeasibility? A

patient’s right for Deletion and modification are

built into the HIPAA requirements while there too it

has been rarely researched – they are essential to

assuring the integrity of a healthcare record.

(Integrity along with confidentiality and availability

is a cornerstone of HIPAA.) Research on the topic

may be difficult but feasible, and necessary in the

age of the ‘right to be forgotten’. The ontology and

the associated maps make it convenient to pose these

difficult but important questions.

REFERENCES

Bashshur, R., Shannon, G., Krupinski, E. & Grigsby, J.

2011. The taxonomy of telemedicine. Telemedicine

and e-Health, 17, 484-494.

Börner, K., Chen, C. & Boyack, K. W. 2003. Visualizing

knowledge domains. Annual Review of Information

Science and Technology, 37, 179-255.

Cameron, J. D., Ramaprasad, A. & Syn, T. 2015. An

Ontology of mHealth. Proceedings of the 21st

Americas Conference on Information Systems (AMCIS

2015). Puerto Rico, USA.

Centers for Medicare & Medicaid Services. Meaningful

Use [Online]. Available: https://www.cms.gov/

Regulations-and-Guidance/Legislation/EHRIncentive

Programs/Meaningful_Use.html.

Churchman, C. W. 1967. Wicked Problems. Management

Science, 14, B-141.

Cimino, J. J. 2006. In defense of the Desiderata. Journal

of Biomedical Informatics, 39, 299-306.

Gruber, T. R. 1995. Toward Principles for the Design of

Ontologies Used for Knowledge Sharing.

International Journal Human-Computer Studies,

43,907-928.

Gruber, T. R. 2008. Ontology. In: LIU, L. & OZSU, M. T.

(eds.) Encyclopedia of Database Systems. Springer-

Verlag.

Nacinovich, M. 2011. Defining mHealth. Journal of

Communication in Healthcare, 4, 1-3.

Quine, W. V. O. 1961. From a Logical Point of View,

Boston, MA, USA, Harvard University Press.

Rainer, R. K. & Cegielski, C. G. 2012. Introduction to

Information Systems: Supporting and Transforming

Business, Hoboken, NJ, Wiley.

Ramaprasad, A. & Papagari, S. S. 2009. Ontological

Design. Proceedings of DESRIST 2009. Malvern, PA.

Ramaprasad, A., Papagari, S. S. & Keeler, J. 2009.

eHealth: Transporting Information to Transform

Health Care. In: AZEVEDO, L. & LONDRAL, A. R.

(eds.) Proceedings of HEALTHINF 2009 – Second

International Conference on Health Informatics.

Porto, Portugal: INSTICC Press.

Ramaprasad, A. & Rai, A. 1996. Envisioning management

of information. Omega-International Journal of

Management Science, 24, 179-193.

Ramaprasad, A. & Syn, T. 2013. Design Thinking and

Evaluation Using an Ontology. Proceedings of the

European Design Science Symposium (EDSS) 2013.

Dublin, Ireland.

Ramaprasad, A. & Syn, T. 2014. Ontological Topography:

Mapping the Bright, Light, Blind/Blank Spots in

Healthcare Knowledge. Proceedings of Big Data

Analysis in Healthcare 2014. Singapore.

Ramaprasad, A. & Syn, T. 2015. Ontological Meta-

Analysis and Synthesis. Communications of the

Association for Information Systems, 37, 138-153.

Ramaprasad, A., Syn, T. & Thirumalai, M. 2014. An

Ontological Map for Meaningful Use of Healthcare

Information Systems (MUHIS). In: BIENKIEWICZ,

M., VERDIER, C., PLANTIER, G., SCHULTZ, T.,

FRED, A. & GAMBOA, H. (eds.) Proceedings of

HEALTHINF 2014 – International Conference on

Health Informatics. Angers, France: SCITEPRESS.

HEALTHINF 2016 - 9th International Conference on Health Informatics

APPENDIX

mHealth System: Mobile health system used to meaningfully manage healthcare.

1. Structure: The structural elements of a mHealth system -- the nouns describing the system.

1.1. Hardware: The physical elements of the mHealth system.

1.1.1. Sensors: Hardware used to measure and input a variety of data for healthcare.

1.1.2. Devices: Hardware used to perform a variety of other information management functions in

healthcare.

1.2. Software: Computer programs used to manage healthcare information.

1.2.1. Platform: The foundation for software such as an operating system.

1.2.2. Application: Software used to perform a variety of other information management functions in

healthcare.

1.3. Networks: Wired and wireless connections for transfer of information.

1.3.1. Local Wireless: Wireless networks with limited range, confined to a facility.

1.3.2. Telecommunication: Wired and wireless connections with virtually unlimited range.

1.4. Processes: Processes used by the stakeholders to manage information

1.4.1. Manual: Processes handled almost entirely by people.

1.4.2. Automated: Processes handled almost entirely by computers.

1.5. Policies: Stakeholder rules guiding the management of information

1.5.1. Privacy: Policies regarding privacy of information

1.5.2. Regulation: Policies regulating the management of information.

2. Function: The functions of the mHealth system -- the verbs describing the behavior of the system.

2.1. Acquisition: The function of obtaining information.

2.2. Storage: The function of storing information.

2.2.1. Encrypted: Storing the information with encryption to limit its readability.

2.2.2. Non-Encrypted: Storing the information as is, without encryption, and hence directly readable.

2.3. Analysis: Processing the information to discover relationships within.

2.3.1. Quantitative: Processing of numerical information.

2.3.2. Qualitative: Processing of non-numerical information.

2.4. Interpretation: Discovering the meaning of relationships within the information.

2.4.1. Diagnostic: The meaning of relationships for diagnosis.

2.4.2. Predictive: The meaning of relationships for prediction.

2.4.3. Interventional: The meaning of relationships for guiding intervention.

2.5. Application: The use of the interpreted information.

2.5.1. Adoptive: Translating the interpretation into action.

2.5.2. Prescriptive: Prescribing action based on the interpretation.

2.5.3. Scholastic: Using the interpretation for study or further analysis.

2.5.4. Distributive: Propagating the interpretation to others.

2.6. Deletion/Erasure: Removal of the information.

2.6.1. Local: Removal of the information locally on a device.

2.6.2. Systemic: Removal of the information everywhere.

3. Semiotics: The transformation of symbols constituting the information.

3.1. Data: The raw symbols -- numerical, textual, graphical, etc.

3.1.1. Static: Time invariant data, acquired and stored.

3.1.2. Streaming: Time variant data, acquired in real time.

3.2. Health Records: Organization of data to render healthcare.

3.2.1. Current: Record of the current health data.

3.2.2. Historical: Record of historical health data.

3.3. Knowledge: Understanding of the logic of health and healthcare.

3.3.1. Current: Current, on-the-point knowledge about health and/or healthcare.

3.3.2. Traditional: Commonly accepted or evidence-based knowledge about health and /or healthcare.

4. Stakeholder: Entity with a stake in healthcare.

4.1. Healthcare Providers

: Providers of healthcare.

4.1.1. Physicians: Doctors in clinics and hospitals.

Roadmap for mHealth Research

4.1.2. Nurses: Nursing staff in clinics and hospitals.

4.1.3. Pharmacists: Preparers/dispensers of pharmaceutical products in clinics, hospitals, and

pharmacies.

4.1.4. Care Teams: Teams of providers.

4.2. Organizations: Organizational entities involved in the provision of healthcare.

4.2.1. Hospitals/Clinics: Facilities of in-patient, out-patient, urgent, and ambulatory care.

4.2.2. Government/Health Agencies: Entities regulating and providing auxiliary healthcare services.

4.2.3. Insurers: Organizations providing insurance to healthcare recipients.

4.3. General Population: The general recipients of healthcare.

4.3.1. Individuals: Individual recipients of healthcare.

4.3.2. Families/Groups: Recipient families or collections of individuals sharing some activity, interest

or quality.

4.3.3. Communities: Communities receiving healthcare.

5. Outcome: The outcomes of healthcare

5.1. Efficiency: The efficiency of healthcare delivery.

5.1.1. Cost: The cost efficiency of healthcare delivery.

5.1.2. Time: The time efficiency of healthcare delivery.

5.1.3. Resource: The efficiency in terms of other resources like space, people, material, etc.

5.2. Quality: The quality of healthcare.

5.2.1. Standard: Quality of adherence to standards.

5.2.2. Accuracy: The accuracy of diagnosis, treatment, etc. in healthcare.

5.2.3. Efficacy: The success of care.

5.3. Safety: The safety of recipients and providers of healthcare.

5.4. Parity: The parity of healthcare delivered by the providers to the recipients.

HEALTHINF 2016 - 9th International Conference on Health Informatics