A Domain-Specific Modeling Language for Specification of Clinical
Scores in Mobile Health
Allan F
´
abio de Aguiar Barbosa
1
, Francisco Jos
´
e da Silva e Silva
1
, Luciano Reis Coutinho
1
,
Davi Viana dos Santos
1
and Ariel Soares Teles
2
1
Federal University of Maranh
˜
ao, Brazil
2
Federal Institute of Maranh
˜
ao, Brazil
Keywords:
Clinical Scores, Mobile Health, Model Driven Development, Domain-Specific Modeling Language.
Abstract:
Clinical scores are a widely discussed topic in health as part of modern clinical practice. In general, these
tools predict clinical outcomes, perform risk stratification, aid in clinical decision making, assess disease
severity or assist diagnosis. However, the problem is that clinical scores data are traditionally obtained man-
ually, which can lead to incorrect data and result. In addition, by collecting biological/health data in real
time from humans, the current mobile health (mHealth) solutions that computationally solve that problem are
limited because those systems are developed considering the specificities of a single clinical score. This work
is part of the MDD4ClinicalScores project that addresses the productivity in developing mHealth solutions
for clinical scores through the use of Model Driven Development concepts. This paper focus in describing
DSML4ClinicalScore, a high-level domain-specific modeling language that uses the Ecore metamodel to de-
scribe a clinical score specification. To propose the DSML4ClinicalScore we analysed 89 clinical scores to
define the artifacts of this proposed Metamodel. In the end, a practical case study using this DSML is provided
to validate the DSML4ClinicalScore Metamodel, and to show how to use the proposal in a clinical situation
scenario.
1 INTRODUCTION
Clinical scores have been discussed as part of mod-
ern clinical practice in recent decades. In general,
these tools have been created to predict clinical out-
comes, perform risk stratification, aid in clinical deci-
sion making, assess disease severity or assist diagno-
sis (Aakre et al., 2017b). In the medical literature,
there are many formally defined clinical scores, in
which each one of them deals with a specific type of
disease, especially those considered as chronic. For
example, there are clinical scores for heart diseases,
infectious diseases, neurological diseases, and so on.
Recently, the importance of scores for clinical
practice within the hospital environment has been in-
vestigated with greater emphasis. For example, Aakre
et al. (Aakre et al., 2017a; Aakre et al., 2017b) exam-
ined the feasibility of including these scores within
the patient’s Electronic Health Record (EHR). In this
context, clinical scores data are traditionally obtained
in a manual way, which can lead to incorrect data
and result, and they can also involve complex math-
ematical calculations. Initiatives in the mobile health
(mHealth) field that currently arise to computation-
ally solve the problem are limited because a software
is developed considering the specificities of a particu-
lar clinical score.
In that scenario, the development process of mo-
bile solutions for clinical scores using traditional ap-
proaches requires building a new software for each
clinical score, even if they have similar character-
istics, repeating all development steps, which limits
productivity. To tackle this problem, we propose to
use Model Driven Development (MDD) concepts that
helps to simplify the process of developing mHealth
applications for clinical scores. MDD offers an ap-
proach to address the inability of third-generation lan-
guages to reduce platform complexity and express do-
main concepts effectively. In particular, we propose
a Domain-Specific Modeling Language (DSML) for
specifying clinical scores in general. With a DSML,
it is possible to develop a system using its elements
captured by metamodels and express its project in a
declarative and imperative way (Schmidt, 2006).
This work presents the DSML4ClinicalScore, a
high-level DSML that uses an Ecore metamodel to de-
104
Barbosa, A., Silva, F., Coutinho, L., Santos, D. and Teles, A.
A Domain-Specific Modeling Language for Specification of Clinical Scores in Mobile Health.
DOI: 10.5220/0007728101040113
In Proceedings of the 14th International Conference on Evaluation of Novel Approaches to Software Engineering (ENASE 2019), pages 104-113
ISBN: 978-989-758-375-9
Copyright
c
 2019 by SCITEPRESS – Science and Technology Publications, Lda. All rights reserved

scribe a clinical score specification. In general, a clin-
ical score specification contains a section for defining
its variables, a section for defining the rules for calcu-
lating its score, and a section for describing its eval-
uation models. Our DSML4ClinicalScore can cover
all these particular features and generalizes specific
details of different specifications.
This paper is structured as follows. In Section 2,
we explain some basic concepts used in the whole
paper. Section 3 discusses related work. Section 4
explains the proposed approach in which this work
is part and describes the central concepts of the
DSML4ClinicalScore. Section 5 validates the de-
scribed language. Finally, Section 6 concludes the
paper.
2 BACKGROUND
2.1 Clinical Scores
According to Thompson, clinical scores are based on
clinical prediction rules (CPRs), which are tools that
use specific criteria to establish probabilities of out-
comes or assist in management decisions (Thompson,
2012). Falk and Fahey summarize the critical element
of CPR as follows: “CPRs quantify the contribution
of symptoms, clinical signs, and available diagnostic
tests, and stratify patients according to the probability
of having a target disorder. The outcome of interest
can be diverse and be anywhere along the diagnostic,
prognostic, and therapeutic spectrum” (Falk and Fa-
hey, 2009).
In this context, some researchers have classified
three types of CPRs and, consequently, three models
of clinical scores: (1) Diagnostic CPRs that focuses
on factors related to the clinical diagnosis; (2) Prog-
nostic CPRs that predicts outcomes; (3) Prescriptive
CPRs that provides recommendations for clinical in-
tervention. The format of a CPR is variable and de-
pends on the purpose for which it is intended, but it
should include three or more variables obtained from
patient history, physical examinations, or necessary
diagnostic tests (Thompson, 2012). The combination
of these CPRs forms the clinical score specification
skeleton.
The process of establishing a clinical score within
the clinical practice is complex and requires consider-
able time. According to Adams and Leveson, only
to prove a CPR, the following steps are necessary:
development, validation, impact analysis and imple-
mentation. Development is the stage in which it is
identified the predictors from an observational study.
Validation is the stage in which it is tested the rule on
a separate population to see if it remains reliable. Im-
pact analysis is the stage in which it is measured the
usefulness of the rule in a clinical setting concerning
cost-benefit, customer satisfaction and time/resource
allocation. Implementation is the stage that there are
universal acceptance and adoption of the rule in clin-
ical practice (Adams and Leveson, 2012).
In general, a clinical score specification consists
of variables, rules for calculation of the score and
evaluation. Variables are precisely the predictors ob-
tained in the development phase of the model. Rules
define the punctuation of each variable in the specifi-
cation according to the methodology used in the val-
idation step of the model. Evaluation describes the
interpretation of a clinical score according to the re-
sult obtained by applying the rules for calculating the
score.
For example, the well-known Modified Early
Warning Score (MEWS) (Subbe et al., 2001), which
determines the degree of illness of a patient, has vari-
ables, rules for calculating score and evaluations as
detailed in Table 1. It is possible to see in the Table 1
the declared variables, the set of rules associated with
each specified variable and its respective score, and
the two types of evaluation of this clinical score. We
propose that mHeatlh applications can use a DSML to
specify different clinical scores, in which transforma-
tion rules will be applied to generate executable code
artifacts.
2.2 Domain-Specific Modeling
Languages
Domain-Specific Modeling Languages are part of the
MDD approach. According to Schmidt, MDD is an
approach that deals with platform complexity by com-
bining DSMLs with transformation engines and gen-
erators. DSMLs serve to formalize the structure, be-
havior, and requirements of an application and de-
scribe them using metamodels, which define the re-
lationships between concepts in a domain and pre-
cisely specify critical semantic and constraints asso-
ciated with these domain concepts (Schmidt, 2006).
Engineering models aim to reduce risk by help-
ing to better understand both a complex problem and
its potential solutions before undertaking the expense
and effort of a full implementation. To be useful and
effective, an engineering model must possess the fol-
lowing five key characteristics: abstraction, under-
standability, precision, predictiveness and inexpen-
sive. Abstraction is a reduced rendering of the sys-
tem that it represents by removing irrelevant details
from a given viewpoint. Understandability is a direct
function of the expressiveness of the modeling form
A Domain-Specific Modeling Language for Specification of Clinical Scores in Mobile Health
105

Table 1: MEWS score specification.
Variable Value Score
Systolic blood pressure
≤ 70 mmHg +3
71–80 mmHg +2
81–100 mmHg +1
101–199 mmHg 0
≥ 200 mmHg +2
Heart rate
< 40 bpm +2
41–50 bpm +1
51–100 bpm 0
101–110 bpm +1
111–129 bpm +2
≥ 130 bpm +3
Respiratory rate
< 9 bpm +2
9–14 bpm 0
15–20 bpm +1
21–29 bpm +2
≥ 30 bpm +3
Temperature
< 35
o
C +2
35–38.4
o
C 0
≥ 38.5
o
C +2
AVPU Score
Alert 0
Reacts to voice +1
Reacts to pain +2
Unresponsive +3
Evaluation Result
Not linked to death or an ICU admission ≤ 4
Linked to death or an ICU admission ≥ 5
used. Precision refers to a model that must provide
a true-to-life representation of the modeled system’s
features of interest. Predictiveness is related to use a
model to correctly predict the modeled system’s but
non-obvious properties, either through experimenta-
tion or some formal analysis. Inexpensive means that
the process of a model construction and analysis must
be significantly cheaper than other development pro-
cess approaches (Selic, 2003).
The definition of a modeling language usually be-
gins by capturing and identifying the main applica-
tion domain. The result of this activity produces the
abstract syntax of the modeling language, which cor-
responds to a metamodel with all the concepts iden-
tified at the meta-domain level. The concrete syn-
tax of modeling language refers to how users learn
and use it, whether by reading or writing and design-
ing the models. Finally, a modeling language can
be classified as General-Purpose Modeling Language
(GPML) or DSML. Different from DSML, a GPML
has broader and widespread use in several fields of
application (Fowler, 2010; Mernik et al., 2005). We
propose a DSML related to clinical scores domain in
the health field.
3 RELATED WORK
In the literature, there are several works on mHealth
applications for remote patient monitoring (Free et al.,
2013; Silva et al., 2015). On the other hand, there
have been some initiatives involving mHealth and
clinical scores in recent years. For example, Altini
et al. created and validated a mobile clinical score to
estimate the relative risk of a woman having a prema-
ture birth. With a database of four million pregnan-
cies, the authors created a model of risk estimation
that involves demographic and gestational character-
istics, as well as obstetric behavior and history (Al-
tini et al., 2017). Aminian et al. developed a mobile
application that provides quick and convenient ac-
cess to evidence-based clinical scores, specifically in
cases of bariatric surgery. The authors implemented
three scoring systems: a vertical gastrectomy risk as-
sessment score, a post-discharge thromboprophylaxis
risk score, and a score-based selection of evidence-
based metabolic surgery (Aminian et al., 2017). An-
drew et al. proposed the incorporation of real-time
data obtained through mobile devices for acute stroke
code evaluation. The authors used, among other fac-
tors, the National Institutes of Health Stroke Scale
(NIHSS) score as a criterion for assessing of stroke
risk (Andrew et al., 2017). Furberg et al. devel-
oped a mobile system for clinical decision support
to reduce pediatric cardiovascular risk. The authors
used a multilayer framework to convert clinical evi-
dence into specialized knowledge through integrated
risk assessment with body mass index, blood pressure
and lipid management (Furberg et al., 2017). Pereira-
Azevedo et al. created a mobile application for the
prostate cancer risk score of Rotterdam. With the ap-
plication, the authors improved the risk stratification
of prostate cancer, avoiding unnecessary biopsies and
reducing the time for diagnosis and unnecessary treat-
ment (Pereira-Azevedo et al., 2017).
Most of the works described above tackle the
problem of clinical scores in a restricted way, devel-
oping a computational system for a specific clinical
score. Their main focus is on solving the clinical
score or using it as a mean to address a more signif-
icant problem. They do not apply MDD concepts to
solve their clinical scores too. Different from those
studies, this paper approaches the issue more generi-
cally and comprehensively, employing a solution not
explored in the literature yet. By specifying differ-
ent clinical scores using a DSML, we standardize the
requirements of any application that fits within these
same characteristics and can use the code artifacts re-
sulting from our approach in other applications. In
this way, we present a solution that allows increasing
ENASE 2019 - 14th International Conference on Evaluation of Novel Approaches to Software Engineering
106

the productivity in the software development process
in this context.
4 PROPOSED APPROACH
This work is part of the MDD4ClinicalScores re-
search project that focuses on the development of
software to allow real-time remote patient monitoring
using the processing of data streams generated from
people and biomedical sensors. Unlike most previ-
ous works, which develop a computational system for
each specific clinical score, MDD4ClinicalScores
stands out by allowing the specification of several
clinical scores and the automatic generation of soft-
ware components through the use of model transfor-
mation techniques. The generated software compo-
nents allow real-time remote patient monitoring ac-
cording to the provided clinical score specifications.
Figure 1 illustrates the proposed approach.
The first part of Figure 1 (identified by the
(1) label) corresponds to the clinical score spec-
ification. This step is based in a DSML
(DSML4ClinicalScore) used to implement a high-
level graphical authoring tool for supporting health-
care professionals in providing clinical score speci-
fications. Based on the provided specification (con-
crete model), MDD4ClinicalScores applies trans-
formation rules for the generation of OWL ontol-
ogy classes that are based on Deklaer’s Declarative
Modeling Language (Pinheiro et al., 2018), an on-
tology used to describe IoT applications. The gen-
erated ontology describes the rules that will be used
for patient monitoring according to the provided clin-
ical score specification. The second part of Figure 1
corresponds to the execution environment step of the
proposed approach. This step involves the submission
of the generated Deklaer ontology to a middleware in-
frastructure called Scalable Data Distribution Layer
(SDDL) (Endler et al., 2011) for the automatic gen-
eration of software components comprising the IoT
mobile application. The process of an IoT applica-
tion generation and the deployment of the its software
components is described in (Pinheiro et al., 2018).
4.1 Domain Analysis
In order to propose a metamodel that allows to define
a DSML to develop clinical score specifications, we
needed to identify which concepts should be included
as artifacts in that metamodel. Consequently, the first
step was to identify data and functional requirements
to specify a clinical score. As the quantity of clinical
scores is undefined, in order to achieve this goal we
adopted the work of (Aakre et al., 2017a) as an initial
reference point, taking into account its relevance and
contemporaneity with the proposal in that paper. In
that work, the authors empirically surveyed 110 clin-
ical scores and submitted them to the assessment of
United States medical experts in relation to the im-
portance of having their scores automatically entered
into patient’s EHR. That evaluation was based on sub-
jective criteria, in which the clinical scores were clas-
sified as VERY IMPORTANT, NICE TO HAVE or
NOT IMPORTANT.
Therefore, to define the requirements with a focus
on the clinical scores, we analyzed those 110 clinical
scores by two viewpoints: (1) to develop a classifica-
tion in relation to how the variables of a clinical score
are obtained computationally; (2) elaborate a concep-
tual map to extract relevant concepts about clinical
scores from different specialties. The first step is
related to the purpose of the MDD4ClinicalScores
project proposal, and the second step is focused on the
development of the DSML4ClinicalScore proposal.
4.2 Domain Conceptual Map
In order to facilitate the interpretation of the domain
analysis and the elicitation activity, we developed a
Conceptual Map (see Figure 2) for clinical score spec-
ifications to clarify the main concepts that must be
included in the metamodel. This conceptual map
was elaborated from 89 of those 110 clinical scores
previously analyzed since we take into account only
those evaluated as VERY IMPORTANT or NICE TO
HAVE.
The Conceptual Map shows all the concepts iden-
tified. To classify these concepts we have answered
the following questions: (1) why do we want to de-
velop mHealth applications for clinical score?; (2)
how do we obtain inputs to develop these applica-
tions?; (3) what results do we want to obtain?
• Variables: this core concept identifies and repre-
sents the necessary clinical predictors that influ-
ence the final score of the clinical score. All pos-
sible electronic and manual variables provide the
specific classification of the variables.
• Rules: this core concept identifies and represents
the necessary rules for computing the score of
each previously defined clinical predictor. All
possible atomic and composed expressions pro-
vide the specific classification of the rules.
• Evaluations: this core concept identifies and rep-
resents the necessary assessments for interpreta-
tion of the clinical score. The result and assess-
ment information provide the specific classifica-
tion of the evaluations.
A Domain-Specific Modeling Language for Specification of Clinical Scores in Mobile Health
107

Figure 1: The proposed approach of which DSML4ClinicalScore is part.
Figure 2: Conceptual Map of a clinical score specification.
4.3 Language Design
The DSML4ClinicalScore metamodel design was
implemented on top of the Ecore metamodel and we
used the Eclipse Modeling Framework
1
(EMF), a dis-
tribution of the Eclipse community, to edit and cre-
ate case studies of clinical scores. EMF is a model-
ing framework and code generation facility for build-
ing tools and other applications based on a structured
data model, in addition to providing an API for the
Ecore dialect to UML. Ecore describes models and
runtime support for the models, including change no-
tification, persistence support with default XMI seri-
alization, and a very efficient reflective API for ma-
1
https://www.eclipse.org/sirius/overview.
html.
nipulating EMF objects generically (Irawan, 2010).
Therefore, the DSML4ClinicalScore metamodel
is defined from the concepts identified in the do-
main analysis and from the resulting Conceptual
Map. It is organized into four main classes
(see Figure 3) in order to separate the element
needed for identifying a clinical score specification
(Specification) from those related to each section
model definition (VariableSection, RuleSection
and EvaluationSection).
The Specification class of the Figure 3 rep-
resents a single clinical score specification, includ-
ing an identifier, a description and a type from the
SpecificationTypes class (Diagnostic, Prognostic
or Prescriptive). A Specification is composed by
one VariableSection, by one RuleSection, and by
at least one or by many EvaluationSection.
ENASE 2019 - 14th International Conference on Evaluation of Novel Approaches to Software Engineering
108

Figure 3: DSML4ClinicalScore Metamodel.
The VariableSection class of the Figure 3 de-
fines all variables in a clinical score specification.
These variables can be obtained through sensors, in-
formation of the patient’s EHR, interviews with the
health professional or patient, or information from
other clinical scores. A VariableSection is com-
posed by at least one or by many Variable, and
it is associated with a single RuleSection. The
Variable class signs an identifier and an unity of
measurement for each variable created within the
specification, and it can be a type of Electronic
or Manual. The Electronic class encompasses
the variables of the specification obtained electron-
ically, and it can be a type of Sensor or EHR. The
Manual class includes the variables of the specifi-
cation obtained manually, assigning to each one of
them its generating source from the ManualSources
class (Interview or Another Score). The Sensor
class identifies which type of sensor data is feeding
the specification, as described by the Sensors class
(Blood Pressure, Heart Rate, Oxygenation, Respira-
tory Rate, Temperature or Other). Finally, the EHR
class identifies which type of information from pa-
tient’s EHR is feeding the specification, as described
by the EHRInformation class (Age, Event, Exam,
Gender, Personal Measures or Other).
The RuleSection class of the Figure 3 defines all
rules for calculating the score of the clinical score, as-
sociated with each variable in the specification. Here
a rule can be represented by any possible expression
(logical, relational or mathematical). A RuleSection
is composed by at least one or by many Rule, and
it is associated with a single VariableSection, and
with at least one or with many EvaluationSection.
The Rule class describes how the rules for calculat-
ing the clinical score are defined, assigning to each
one of them an identifier and a score, and it is com-
posed by a single Expression. The Expression
class creates an atomic or composed expression for
a specific rule within the specification, and it can be
A Domain-Specific Modeling Language for Specification of Clinical Scores in Mobile Health
109

a type of Atomic or Composed. The Atomic class
creates an atomic expression within the Rule, and it
can be a type of RefVariable or Constant. The
Composed class creates a composed expression within
the Rule, and it can be a type of LogicalOperator,
RelationalOperator or MathematicalOperator.
The RefVariable class represents an atomic ex-
pression associated with a predefined variable in the
VariableSection, and it is associated with a sin-
gle Variable. The Constant class represents an
atomic expression associated with a constant. The
LogicalOperator class describes which logical op-
erator (And, Or, Not, Not And, Not Or, Or Exclu-
sive or Not Or Exclusive) is used in a composed ex-
pression, and it is composed by up to two Atomic,
by up to two RelationalOperator, and by up to
two LogicalOperator. The RelationalOperator
class describes which relational operator (Equal To,
Different From, Greater Than, Less Than, Greater Or
Equal Than, or Less Or Equal Than) is used in a com-
posed expression, and it is composed by up to two
Atomic, and by up to two MathematicalOperator.
The MathematicalOperator class describes which
mathematical operator (Addition, Subtraction, Mul-
tiplication, Division, Exponentiation, Square Root,
Factorial, Logarithm or Other) is used in a composed
expression, and it is composed by up to two Atomic,
and by up to many MathematicalOperator.
The EvaluationSection class of the Figure 3
defines all possible evaluation models for a clini-
cal score specification, and it can have more than
one model, identifying each one of them. A
EvaluationSection is composed by at least one or
by many Evaluation and by a single Result, and
it is associated with a single RuleSection. The
Evaluation class describes an evaluation of a clin-
ical score specification according to a range of pos-
sible values for its result, assigning an identifier, no-
tification, and minimum and maximum score values,
and it is associated or not with a Result. The Result
class obtains the final result of a clinical score specifi-
cation, and it is associated with a single Evaluation.
5 VALIDATION
According to Yin (Yin, 2014), a case study can be a
single case to evaluate a research theory in order to
obtain results that can generalize or improve this the-
ory. To demonstrate the robustness and expressive-
ness of DSML4ClinicalScore, from those list of 89
clinical scores analyzed in the subsection 4.1, we de-
veloped eight concrete case studies based on clinical
scores that exploit different characteristics regarding
variables, calculation rules and evaluations. The list
of selected clinical scores is described in Table 2 and
all specifications are available on the MD+Calc plat-
form (Mdc, 2005).
Table 2: List of clinical scores used in the case studies.
Clinical Score Disease
4T Score Thrombocytopenia
CHADS
2
Score Stroke
CPIS Score Pneumonia
CURB-65 Score Pneumonia
HAS-BLED Score Bleeding risk
MEWS Score Degree of illness
TIMI Index Acute coronary
Well’s Criteria for PE Pulmonary Embolism
Considering the available space in this section we
will illustrated the clinical score shown in Subsec-
tion 2.1 as our case study. To create the model of
the chosen clinical score, we used EMF metamodel
validation tool.
Figure 4 illustrates the modeling of the MEWS
clinical score using the DSML4ClinicalScore lan-
guage in an UML class diagram. To start modeling
a clinical score the user declares a set of attributes
(id, description and type) which are part of the
Specification object. After that, the user can de-
fine the clinical score variables, rules for calculating
the score and evaluations.
Concerning to the declaration of the MEWS clin-
ical score variables, Figure 4 illustrates how its vari-
ables and attributes can be modeled according to the
DSML4ClinicalScore metamodel. This specifica-
tion contains five objects of the type Variable related
to systolic blood pressure, heart rate, respiratory rate,
temperature, and AVPU score.
About the definition of the score calculation rules,
Figure 4 demonstrates how rules of the MEWS spec-
ification are defined according to the proposed meta-
model. This specification has a total of twenty three
scoring rules, with five objects of the type Rule as-
sociated with systolic blood pressure, six associated
with heart rate, five associated with respiratory rate,
three associated with temperature, and four associ-
ated with AVPU score. Figure 4 shows in detail only
the rules related to systolic blood pressure and AVPU
score variables of this clinical score. For example, to
compose the rule with “id = SBP=[71-80]”, we per-
formed the following:
1. We first created a LogicalOperator of the type
And;
2. From that logical operator, we created two
RelationalOperator, one of the GreaterThan
ENASE 2019 - 14th International Conference on Evaluation of Novel Approaches to Software Engineering
110

Figure 4: MEWS specification according to DSML4ClinicalScore metamodel.
type and one of the LessOrEqualThan type;
3. From the GreaterThan relational operator, we
created an instance of RefVariable associated
with the variable with SystolicBP identifier, and
a Constant with value 70;
4. From the LessOrEqualThan relational operator,
we also created an instance of RefVariable as-
sociated with the variable with SystolicBP identi-
fier, and a Constant with value 80.
Figure 4 also represents the evaluation model
attributes of MEWS specification according to
DSML4ClinicalScore metamodel concepts. For
simplicity, Figure 4 describes only two possible ob-
jects of the type Evaluation, which are part of the
MEWS specification, including their scoring range
and respective interpretation, and one object of the
type Result, which represents the final result of this
clinical score.
5.1 Discussion
The provided case studies illustrates the expressive-
ness of the DSML4ClinicalScore language to de-
scribe different clinical score specifications. In the de-
veloped case studies, DSML4ClinicalScore allowed
the user to correctly model any variable that serves
as input for a clinical score specification, regardless
of whether it is obtained manually or electronically.
For example, we can express patient’s age and gen-
der, heart rate or blood pressure measurements, test
results, history of several diseases, among others. In
addition, the language also can express the attributes
needed to identify a variable within any clinical score,
regardless of how this variable is represented (nu-
meric or textual).
Moreover, DSML4ClinicalScore allowed the
user to correctly model several mathematical, rela-
tional and logical rule formats. For example, we
A Domain-Specific Modeling Language for Specification of Clinical Scores in Mobile Health
111

can express the mathematical formula that calculates
the TIMI risk index represented in the formula 1,
which uses three variables related to heart rate, age,
and systolic blood pressure to compose its calcula-
tion rule. We can also express a logic rule of the
CURB-65 Score, described in the formula 2, which
is composed of two relational expressions involving
systolic blood pressure and diastolic blood pressure
variables of this clinical score. Finally, one can ex-
press a rule that contains multiple choice options as
the example shown in the formula 3 which is part of
the 4Ts Score for Thrombocytopenia. In this way,
DSML4ClinicalScore can express any Boolean rule.
T IMI = Heart rate ∗ (Age/10)
2
/Blood pressure
(1)
IF SystolicBP < 90OR DiastolicBP ≤ 60 T HEN + 1
(2)


Other causes = None apparent +2
= Possible +1
= De f inite 0


(3)
Finally, DSML4ClinicalScore allowed the user
to correctly model several evaluation models. From
those simpler ones such as the TIMI Risk Index as-
sessment that defines only a probability as result, to
more complex assessment models such as the Well’s
Criteria for Pulmonary Embolism, which presents a
three-tier and two-tier evaluation model. Thereby,
DSML4ClinicalScore can express any information
associated with an evaluation of a clinical score spec-
ification considering the 89 clinical scores that served
as reference for the DSML4ClinicalScore meta-
model specification. One can obtain the plugins con-
taining the proposed metamodel and the modeling of
these mentioned case studies by following the URL
https://bit.ly/2zXwhkd.
6 CONCLUSION
This paper presented a novel approach for the devel-
opment of mHealth applications targeting the evalu-
ation of clinical scores based on the use of Model
Driven Development concepts. It is based on provid-
ing a DSML, called DSML4ClinicalScore, that al-
lows end users to specify relevant clinical scores and
on a transformation process that automate the gener-
ation of the software components that comprise the
mHealth application.
This paper focus in describing
DSML4ClinicalScore that was developed from
the analysis of a set of 89 clinical scores selected
by criteria of relevance and contemporaneity. From
that set, we chose eight clinical scores to validate the
proposed language by modeling the specifications.
These specifications have been selected because
they have different characteristics regarding the
formatting of variables, scoring rules and evaluations,
which allowed us to illustrate DSML4ClinicalScore
expressiveness. In addition, we took one of those
selected specifications as our case study to describe
how its characteristics are modeled according to
DSML4ClinicalScore metamodel.
The future steps of our work include the de-
velopment of a graphical authoring tool for as-
sisting end users (health care professionals) in the
task of modeling clinical score specifications using
DSML4ClinicalScore and the development of the
transformation rules for partially automating the de-
velopment process of generating mHealth applica-
tions targeting the monitoring of clinical scores.
ACKNOWLEDGEMENTS
This research is part of the INCT of the Future In-
ternet for Smart Cities and was financed in part by
the Coordenac¸
˜
ao de Aperfeic¸oamento de Pessoal de
N
´
ıvel Superior - Brazil (CAPES) - Finance Code 001,
Conselho Nacional de Desenvolvimento Cientifico e
Tecnol
´
ogico - Brazil (CNPq) proc. 465446/2014-0,
and Fundac¸
˜
ao de Amparo
`
a Pesquisa do Estado de
S
˜
ao Paulo - Brazil (FAPESP) proc. 14/50937-1 and
proc. 15/24485-9.
REFERENCES
(2005). Md+calc. https://www.mdcalc.com.
Aakre, C., Dziadzko, M., and Herasevich, V. (2017a). To-
wards automated calculation of evidence-based clini-
cal scores. World Journal of Methodology, 7(1):16–
24.
Aakre, C., Dziadzko, M., Keegan, M., and Herasevich, V.
(2017b). Automating clinical score calculation within
the electronic health record. Applied Clinical Infor-
matics, 8(2):369–380.
Adams, S. and Leveson, S. (2012). Clinical prediction rules.
British Medical Journal, 344:1–7.
Altini, M., Penders, J., Dy, E., and Lyell, D. (2017). 384:
37: a mobile preterm birth calculator. American Jour-
nal of Obstetrics and Gynecology, 216(1):S231.
Aminian, A., Clemence, S., Alberts, J., Schauer, P., and
Brethauer, S. (2017). Bariatric surgery decision-
making calculator: A novel mobile app for evidence-
based clinical practice. Journal of the American Soci-
ety for Metabolic and Bariatric Surgery, 13(10):S147.
Andrew, B., Stack, C., Yang, J., and Dodds, J. (2017).
mstroke: Mobile stroke–improving acute stroke care
ENASE 2019 - 14th International Conference on Evaluation of Novel Approaches to Software Engineering
112

with smartphone technology. Journal of Stroke and
Cerebrovascular Diseases, 26(7):1–8.
Endler, M., Baptista, G., Silva, L., Vasconcelos, R.,
Malcher, M., Pantoja, V., and Pinheiro, V. (2011).
Contextnet: Context reasoning and sharing middle-
ware for large-scale pervasive collaboration and social
networking. ACM/USENIX Middleware Conference.
Falk, G. and Fahey, T. (2009). Clinical prediction rules.
British Medical Journal, 339(2):b2899.
Fowler, M. (2010). Domain-specific languages. Addison-
Wesley Professional, 1st. edition. 640p, ISBN 978-0-
321-71294-3.
Free, C., Philips, G., Galli, L., Watson, L., Felix, L., Ed-
wards, P., Patel, V., and Haines, A. (2013). The effec-
tiveness of mobile-health technology-based health be-
haviour change or disease management interventions
for health care consumers: A systematic review. PLoS
Medicine, 10(1):1–45.
Furberg, R., Williams, P., Bagwell, J., and LaBresh, K.
(2017). A mobile clinical decision support tool for
pediatric cardiovascular risk-reduction clinical prac-
tice guidelines: Development and description. JMIR
Mhealth and Uhealth, 5(3).
Irawan, H. (2010). Ecore. https://wiki.eclipse.org/Ecore.
Mernik, M., Heering, J., and Sloane, A. (2005). When
and how to develop domain-specific languages. ACM
Computing Surveys, 37(4):316–344.
Pereira-Azevedo, N., Os
´
orio, L., Fraga, A., and Roobol, M.
(2017). Rotterdam prostate cancer risk calculator: De-
velopment and usability testing of the mobile phone
app. JMIR Cancer, 3(1).
Pinheiro, V., Neumann, G., Endler, M., and Silva, F. (2018).
Deklaer: An ontology-driven framework for generat-
ing iot applications using contextnet. IEEE Sympo-
sium on Computers and Communications, pages 608–
614.
Schmidt, D. (2006). Guest editor’s introduction: Model-
driven engineering. IEEE Computer, 39(2):25–31.
Selic, B. (2003). The pragmatics of model-driven develop-
ment. IEEE Software, 20(5):19–25.
Silva, B., Rodrigues, J., D
´
ıez, I., L
´
opez-Coronado, M., and
Saleem, K. (2015). Mobile-health: A review of cur-
rent state in 2015. Journal of Biomedical Informatics,
56:265–272.
Subbe, C., Kruger, M., Rutherford, P., and Gemmel, L.
(2001). Validation of a modified early warning score
in medical admissions. Monthly Journal of the Asso-
ciation of Physicians, 94(10):521–526.
Thompson, G. (2012). Appendicitis, chapter 4, pages 63–
86. Clinical Scoring Systems in the Management of
Suspected Appendicitis in Children. InTech, Europe,
1st. edition. ISBN 978-953-307-814-4.
Yin, R. K. (2014). Case Study Research. Applied Social
Research Methods. SAGE Publications Inc.
A Domain-Specific Modeling Language for Specification of Clinical Scores in Mobile Health
113