Roadmap for mHealth Research
Joshua D. Cameron
1
, Arkalgud Ramaprasad
2
and Thant Syn
3
1
Miller School of Medicine, University of Miami, Coral Gables, FL, U.S.A.
2
Department of Information and Decision Sciences, University of Illinois at Chicago, Chicago, IL, U.S.A.
3
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.
28
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
Copyright
c
2016 by SCITEPRESS Science and Technology Publications, Lda. All rights reserved
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
29
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 HealthcareProviders Efficiency
Sensors Storage Stati c Physicians Cost
Devi ces Encrypted Streaming Nurses Ti me
Software NonEncrypted HealthRecords Pharmacists Resource
Platform Analysis Current CareTeams Quality
Applications Quantitative Historical Organizations Standard
Networks Qualitative Knowledge Hospitals/Clinics Accuracy
LocalWireless Interpretation Current Government/HealthAgencies Efficacy
Te lecommunication Diagnosti c Tradi tional I nsure rs Safe ty
Processes Predictive GeneralPopul 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/inhealthcare]
[of]
[tomeaningfullymanage]
[formobile]
[by]
mHealthSystem
Poli ciesformobileapplicationofknowle dgebyorgani zati onstomeaningf ully managequalityofhealthcare.
Ex ample:Governmentregulatorycontrol(e.g.,FDAsafetyandinnovationact),mHealthRegulatoryCoalitionguidelines.
Proce sses
manual
formobiledeleti on
local
ofdata
static
byheal thcare providers
physicians
tomeaningfullymanagesafetyin
healthcare.
Ex ample:Def aultexpirationdatesforpatientdatadownloaded/entered/storedonmobiledevices.
Illustrativecomponents:
Hardwareformobil eacquisiti onofdatabyheal thcareprov iderstomeaningfullymanageefficiencyofhealthcare.
Ex ample:WirelessDataAcquisitionModule(WDAM)forcontinuousmonitoringofpatientdataderivedfromwearable
sensors.
Softwareformobile
interpretationofhealthrecordbygene ralpopulationtomeaningfullymanagesafetyofhealthcare.
Ex ample:PersonalHealthRecords(PHRs),Applicationsprovidingmedicalsupport/healthinformationtoolsforgeneral
population(e.g.,WebMD,MedicineNet,Healthline)
Ex ample:Clinicaldescisionsupporttoolspromotingadherencetoevidencebasedguidelines(e.g.,echecklist,UpToDate,et
c
Softwareformobileapplicationofknowle dgebyhealthcareprovi derstomeaningf ullymanagequali ty ofheal thcare .
Ex ample:Applicationsfortracking/flagginghealthdata(e.g.,fitness,bloodpressure,glucose,etc.).
Softwareformobileinterpretationofdatabygeneralpopulationtomeaningfullymanagequalityofhealthcare.
Networksformobileappli cationofknowledge byhealthcareprovidersto
meaningfullymanageefficiencyofheal thcare.
Ex ample:Realtimecommunicationstoolsbetweenproviders(e.g.,textbased,voicebased,cloudbased,etc.).
Ex ample:Bluetoothembeddedmobiledevicesforremotedatatransmission(vitals,GPScoordinated,etc.)
HEALTHINF 2016 - 9th International Conference on Health Informatics
30
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
of
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
31
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
32
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) HealthcareProviders‐Physicians(42) Efficiency‐Cost(31)
Hardware‐ Devices(109) Storage‐Encrypted(5) Data‐Streaming(39) HealthcareProviders‐Nurses( 11) Efficiency‐Time( 22)
Software‐Platform(17) Storage‐NonEncrypted(4) HealthRecords‐Current( 25) HealthcareProviders‐Pharmacists(2) Efficiency‐Re source(15)
Software‐Applications(219) Analysis‐Quantitative(11) HealthRecords‐Historical(25) HealthcareProviders‐CareTeams(24) Quality‐Standard(5)
Networks‐
LocalWireless(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/HealthAgencies(12) Quality‐Eff icacy(133)
Processes‐Manual(7) Interpretation‐Predictive(12) Organizations‐Insurers(1) Safety(17)
Processes‐Automated(11) Interpretation‐Interventional( 126) GeneralPopulation‐Individuals(169) Parity(29)
Policies‐Privacy(12) Application‐Adoptive(74) GeneralPopulation‐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/inhealthcare]
mHealth System
[formobile]
[of]
[by]
[tomeaningfullymanage]
Roadmap for mHealth Research
33
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
34
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
35
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
36
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
37
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
38