# Co-designing a mHealth Application for Self-management of Cystic Fibrosis

Thomas Vilarinho, Jacqueline Floch, Erlend Stav

► To cite this version:

Thomas Vilarinho, Jacqueline Floch, Erlend Stav. Co-designing a mHealth Application for Self-management of Cystic Fibrosis. 16th IFIP Conference on Human-Computer Interaction (INTER-ACT), Sep 2017, Bombay, India. pp.3-22, 10.1007/978-3-319-67687-6_1 . hal-01717195

HAL Id: hal-01717195

https://inria.hal.science/hal-01717195

Submitted on 26 Feb 2018

**HAL** is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>
# Co-designing a mHealth application for self-management of cystic fibrosis

Thomas Vilarinho, Jacqueline Floch, and Erlend Stav

SINTEF Digital, Trondheim, Norway

**Abstract.** Self-management has the potential to improve patient care and decrease healthcare costs. It is especially beneficial for patients suffering from chronic diseases that require continuous therapy and follow-up such as cystic fibrosis (CF). Mobile phones have become pervasive and, therefore, are perfectly suited for self-management. However, due to the large amount of time CF patients spend in their treatment, usability and usefulness are critical factors for the adoption of an assistive mobile application (App).

In our work, we applied co-design in the development of high fidelity mockups for a CF Self-management App. The co-design was conducted as a series of workshops involving CF patients, theirs parents, as well as health professionals, from multiple countries in Europe. The results include design concepts and User Interface elements that conciliate the different perspectives between the stakeholders.

This paper describes the co-design process, the resulting design and further considerations which emerged along the process.

**Keywords:** human factors, HCI, self-management, m-health, user centered design, mobile computing

## 1 Introduction

Chronic diseases are responsible for most deaths in the world [26] and they affect a large part of the population. It is estimated that about half of the American adult population has at least one chronic disease [23]. Chronic diseases require long term therapy which poses a challenge for patient adherence and for the sustainability of health care systems. Self-management programs are seen as a possible solution to that challenge due to theirs potential to improve care quality and reduce health care cost [20].

Self-management corresponds to the active involvement of the patients in tasks related to his health care. It includes the management of symptoms and treatment, and deals with the consequences of the disease in daily life. Self-management is not about delegating all care management to patients, but rather about supporting a collaborative relationship where doctors empower patients in the day-to-day care as a complement to the traditional clinical treatment. Self-management strengthens the capabilities of the patients in terms of education, empowerment and confidence building [19].
ICT is a powerful tool to cost-effectively support self-management [8]. It can facilitate the communication between patients and carers and simplify the self-management tasks, leading to higher adherence. Indeed, different reviews [24, 12] show that ICT can positively affect self-management.

This work investigates the User Interface (UI) elements and design concepts necessary for a mobile application (App) supporting the self-management of Cystic Fibrosis (CF). CF is a chronic disease that causes the body to release thicker and stickier mucus, affecting both the digestive system and the lungs. CF patients undergo an extensive therapy including nutrition management, medicine intake, airway clearance techniques and physical activity [1]. The extent of the therapy is such that the patient's adherence to the different parts of the treatment varies significantly [11]. The comprehensive treatment and the varying adherence make CF an interesting case in the study of self-management.

This paper is organized as follows: Section 2 presents the context of this research work and the relevant knowledge base for the App design; Section 3 introduces the research methodology; Section 4 describes the co-design process; Section 5 presents and discusses the co-design results related to the mockups and core design concepts while Section 6 presents transveral findings streching across the whole App and self-management model; Section 7 concludes and presents future work.

## 2 Background

This section presents the context of this research work, and go through the current understanding of the stakeholders requirements for the self-management of CF. We present the requirements found in previous scientific works and contrast them with the existing CF self-management Apps available in the market. Due to a limitation of CF Apps in addressing those requirements, we stretch our investigations towards other Apps and works covering similar requirements.

### 2.1 Research Context

This work is rooted on a multidisciplinary project, MyCyFAPP [7], whose research aims at developing a mobile application ecosystem that addresses CF patients, parents of children with CF, as well as healthcare professionals involved in the treatment. The App described in this paper is the part of the system which will be used by patients who are about to start self-management of treatment routines, as well as by parents responsible for the management of the treatment of their children. A core research of MyCyFAPP is the development of an algorithm for the calculation of the enzyme dosage of enzyme. A well-adjusted enzyme intake during every meal is important for avoiding malnutrition and minimizing gastrointestinal complications [6]. The enzyme calculation algorithm will be implemented as part of the self-management App. In addition, the App will include features that support other aspects of the CF treatment. The App will be piloted in a six-month clinical trial in order to assess its impact in terms of
quality of life, nutrition, CF care education and development of gastro-intestinal
symptoms.

## 2.2 Requirements and Apps for CF Self-Management

The first step for designing the App came with the understanding of the users
needs leading to the identification of the potential features for the App and non-
functional requirements. We both conducted interviews as described in [13] and
took in consideration the single scientific work we found analyzing CF patients'
preferences for self-management via mobile applications [16]. [16] surveyed and
interviewed adult CF patients from a CF clinic in the United States while [13]
did a similar study across 7 different countries in Europe, including a wider pop-
ulation: both young and adult patients; parents; CF patient associations and
Health Professionals (HPs). In that work, a total of 466 requirements were iden-
tified across the different target groups interviwed. After analysis, we extracted
a set of core features and non-functional requirements.

Our findings show that CF patients’ main concern is of being able to live a
normal life, i.e. maintaining a good health and having time for daily activities
despite the time consuming treatment. Table 1 summarizes the core features and
non-functional requirements.

Despite the fact that there are some CF specific Apps in App stores such
as Google Play and Apple’s App Store, we could not find any research work
discussing the design concepts behind them. We found 24 Apps when searching
for the string "Cystic Fibrosis" in both App stores in March 2014. Most of those
Apps offer a time-consuming UI interaction and only cover a subset of the core
features (maximum of five and often no more than two or three), while CF
patients expressed the desire for an App to address them all.

The data registration they support is very simplistic and does not provide an
overview allowing patients or doctors to follow-up the treatment. For example,
My CF Free<fnref n="1" /> nutrition management only supports patient’s weight and height
recording. It provides no support for food recording. Both My CF Free and CF
Notebook<fnref n="2" /> support the recording of symptoms and treatment as notes, but not
the visualization of the health status over time. None of the identified CF Apps
provides food registration at detail level allowing patients to follow-up nutrition.
Just one App, CF Enzymen<fnref n="3" /> supports enzyme calculation, though in a per dish
basis instead of per meal, making it laborious for users. The calculation is not
personalised as is the aim in MyCyFAPP.

## 2.3 Design concepts from other Self-Management Apps

Due to the limited background available in terms of effective design concepts
for CF self-management apps, we looked into design practices and features ap-

<footnote n="1">¹ https://play.google.com/store/apps/details?id=com.mycffree.mycf</footnote>

<footnote n="2">² https://play.google.com/store/apps/details?id=com.OceanVector.CFnotebook</footnote>

<footnote n="3">³ https://play.google.com/store/apps/details?id=com.ncfs.cfenzymen</footnote>
<table><caption>**Table 1. Requirements for CF Self-Management App**</caption><thead><tr><th>Requirement</th><th>Description</th></tr></thead><tbody><tr><td colspan="2"><strong>Core Features</strong></td></tr><tr><td>Enzyme Management</td><td>Management of enzyme supplement intake: dosage calculation, recording and overview.</td></tr><tr><td>Nutrition Management</td><td>Due to the mal-absorption of fat, calories and proteins, CF patients need to closely manage their nutrition (especially children).</td></tr><tr><td>Recipes Advice</td><td>Support to share recipes appropriate to the CF diet.</td></tr><tr><td>Diary Keeping</td><td>Support to record symptoms and health condition</td></tr><tr><td>Treatment Follow-up</td><td>Support to CF patients and parents to visualize nutrition and health condition over time.</td></tr><tr><td>Treatment Organization</td><td>Reminders and follow-up of medicine intake, medical appointments and maintenance of treatment equipment.</td></tr><tr><td>Education</td><td>Learning about the disease, its treatment and dealing with symptoms.</td></tr><tr><td>Digital Meeting Place</td><td>Being able to communicate with other patients and or caregivers in order to: learn from each other, exchange tips and support each other.</td></tr><tr><td>Communication with HPs</td><td>Facilitating sharing of treatment data, exchanging messages and advances between patients/parents and HPs.</td></tr><tr><td colspan="2"><strong>Non-functional requirements</strong></td></tr><tr><td>Time Saving</td><td>Users want to be able to use the App features with few clicks, spend as little time as possible.</td></tr><tr><td>Motivation</td><td>Patients expressed that they would sometimes experience a lack of motivation and that some support could be useful.</td></tr><tr><td>Customization</td><td>Patients knowledge about health, nutrition and disease varies a lot requiring the App to be customizable.</td></tr><tr><td>Privacy</td><td>Users were inclined towards controlling the sharing of health data rather than making it automatically accessible to HPs.</td></tr><tr><td>One App</td><td>A mobile App is preferred over a web or desktop one. All features should be available in a single App rather than in multiple ones.</td></tr></tbody></table>

plied in other Apps related to the complex core features of Nutrition Management, Treatment Follow-up, Diary Keeping and Treatment Organization. Our search spanned the fitness, nutrition and health management Apps in the App Stores and scientific literature covering design concepts applied on mobile self-management in chronic diseases. For food intake registration as part of nutrition management, we did not consider approaches that register only food pictures [14] or food groups [3] as such information is not detailed enough for the level of nutrition assessment expected by CF patients and HPs.
The following Apps were consulted: Was ich esse<fnref n="4" />, FDDB Extender<fnref n="5" />, Lifesum<fnref n="6" />, Yazio<fnref n="7" />, Nutrino<fnref n="8" />, Fertility Friend<fnref n="9" /> and MyTherapy Meds & Pill Reminder<fnref n="10" />. The design concepts inspired from them are presented in Table 2.

## 3 Research approach

Our research in MyCyFAPP follows the design-science paradigm [18]. While behavioral-science approaches focus on the use and benefits of a system implemented in an organization, design-science approaches seek to create information systems to solve identified organizational problems. Design-science approaches follow a recursive process allowing a gradual understanding of the problem to be solved and the improvement of solutions. The creation and assessment of IT artifacts is central for understanding and improvement. The term IT artifact is used in a wide sense and denotes various items related to the creation of information systems, such as models, methods and software prototypes. The design-science paradigm does not impose any concrete research and evaluation method. The choice of a method depends on the nature of the problem to be solved and the type of IT-artifact being created. In MyCyFAPP, we plan to develop several IT-artifacts: mockups of the applications such as presented in this paper, intermediate versions of the apps to be assessed in a midterm evaluation, and final versions of the App ecosystem to be assessed in a clinical trial.

As the first step of our research, we aimed at understanding the user needs. The approach and results are presented in section 2.2. In a second step, presented in this paper, we aimed at concretizing these needs and sketching useful and easy-to-use solutions to fulfill these needs. The research question we had is:

* How can we design a mobile self-management App for CF that fulfills the identified user needs, that is appealing for the users, and that does not introduce additional burden for the patients? What needs to be taken into account so it satisfies all stakeholders (parents, patients and HPs)?

To answer this question, we adopt co-design towards the creation of the UI for app. By co-design, we mean that potential end-users, i.e. CF patients and parents, as well as health professionals participated actively in the design as the domain experts in cooperation with the researchers [21]. Research shows that involving end-users in the design process improves the level of acceptance of the final design product and it is more likely to accurately match the users requirements [17]. As shown in [15], the success of the introduction of a technical

<footnote n="4">⁴ https://play.google.com/store/apps/details?id=de.aid.android.ernaehrungspyramide</footnote>

<footnote n="5">⁵ http://fddbextender.de/</footnote>

<footnote n="6">⁶ https://www.lifesum.com/</footnote>

<footnote n="7">⁷ https://www.yazio.com/</footnote>

<footnote n="8">⁸ https://nutrino.co/</footnote>

<footnote n="9">⁹ https://www.fertilityfriend.com/</footnote>

<footnote n="10">¹⁰ https://www.mytherapyapp.com/</footnote>
<table><caption>**Table 2.** Design Concepts observed in relevant Apps</caption><thead><tr><th>Design concept or sub-feature</th><th>Source</th></tr></thead><tbody><tr><td colspan="2"><strong>Nutrition Management</strong></td></tr><tr><td>Determining portion sizes as handfuls</td><td>Was ich esse</td></tr><tr><td>Registering food item via bar code</td><td>FDDB Extender, Lifesum, Yazio, Nutrino, [10]</td></tr><tr><td>Visual representation of food attributes (e.g gluten free, vegan, etc)</td><td>FDDB Extender</td></tr><tr><td>Bookmarking meals or dishes</td><td>Yazio, Lifesum, Nutrino, [10], [22]</td></tr><tr><td>Custom portions per product (i.e. slice for cake) with gram equivalency</td><td>Yazio, Lifesum</td></tr><tr><td>Tips</td><td>Yazio, Lifesum, Nutrino, [3]</td></tr><tr><td>Auto-complete search</td><td>Lifesum, Nutrino</td></tr><tr><td>Set meals as recurrent</td><td>Nutrino</td></tr><tr><td>Tracking nutritional goals and percentage of completion</td><td>FDDB Extender, Yazio, Lifesum, Nutrino, [22], [3]</td></tr><tr><td>Physical activity logging as a complement to nutrition</td><td>FDDB Extender, Yazio, Lifesum, Nutrino, [22]</td></tr><tr><td colspan="2"><strong>Diary Keeping and Education</strong></td></tr><tr><td>Help buttons attached to symptoms with theirs explanations</td><td>Fertility Friend</td></tr><tr><td colspan="2"><strong>Treatment Follow-up</strong></td></tr><tr><td>Bar and line graphs for numerical data of small variation (nutrition, weight, etc)</td><td>FDDB Extender, Yazio, Lifesum</td></tr><tr><td>Table chart for non-numerical symptoms</td><td>Fertility Friend</td></tr><tr><td>Graphs to highlight data which is missing, marked as uncertain or out of the norm</td><td>Fertility Friend</td></tr><tr><td>Pie charts to display nutritional proportions</td><td>FDDB Extender</td></tr><tr><td colspan="2"><strong>Treatment Organization</strong></td></tr><tr><td>Custom dosages per intakes, recurrence and end-period for medication</td><td>MyTherapy</td></tr><tr><td>Possibility to register med intake from within main screen notification</td><td>MyTherapy</td></tr><tr><td>Bar-code scanning of medication</td><td>MyTherapy</td></tr></tbody></table>

artefact into health care is more strongly connected with the understanding of the complex dynamics of care and how it affects the stakeholders than with the technology. Therefore, applying co-design with all stakeholders is suggested as a solution to avoid the development of systems that fail to be adopted in the care practice. [4] also illustrates several success stories of the application of co-design for healthcare and advocates its further usage in the design of healthcare services.
Co-design was conducted in an iterative manner allowing a gradual refinement of mockups of the UI. In addition to collecting feedback after each iteration, an evaluation of the mockups was performed at a final step of the research.

Stakeholders from different countries in the North and South of Europe were involved allowing to handle different needs due to variations in the provision of healthcare services and cultural diversity. Participants to co-design were recruited in cooperation with CF competence centres and CF patient organisations in the participating countries. Regarding ethics, MyCyFAPP follows the European legislation on privacy and the ethical principle for medical research according to Declaration of Helsinki. All participants voluntarily accepted to participate, and could retract at any time. They were informed about the research and the way collected data are managed, and they all signed a consent form. In the case of participants under 18 years old, their legal guardians also signed a consent form.

# 4 Design process

The first step of the design process consisted in selecting the features which would be included in the application. Then, CF patients, parents of children with CF and HPs were involved in the co-design and evaluation of the UIs for the App.

## 4.1 Definition of the scope of features for the co-design

The requirements presented in Section 2.2 were analysed and weighted in terms of how frequently they were mentioned during interviews. Then, they were discussed and prioritised with HPs with different background: dieticians, pulmonologists, nurses and paediatricians. The involvement of HPs is essential because they have the medical knowledge and can advice what is important for the treatment and how self-management interplays with the organization of the health services in their hospitals. From the initial core features (see Table 1), only the Digital meeting place and the messaging part of Communication with HPs were discarded. The first was left out because existing dedicated CF forums and closed groups on social networks fulfil this need, and the second because hospitals provide well-functioning channels for communication with patients. However, the sharing of data collected by patients and parents was kept as a relevant for the App.

## 4.2 Co-design process

The co-design process was organized as an iterative process with data collection and prototyping refinement at each stage:

1. **Initial Workshops**: Workshops involving patients and parents were organized aiming at confirming the relevance of the selected core App features
and sketching the UIs. These sketches served as input for the development of initial mockups using Balsamiq<fnref n="11" /> (a computer-based prototyping tool).

2. **Refinement Workshops:** New workshops were carried out aiming at refining and validating the initial mockups.

3. **Validation by HPs:** HPs contributing to MyCyFAPP project gave their expert viewpoint on the refined mockups.

4. **Evaluation:** Videos (hosted on MyCyFAPP's youtube account<fnref n="12" />) presenting the final mockups were developed and distributed to patients and parents for evaluation and feedback.

Patients and parents involved in the research were recruited through HPs involved in the project and CF patient associations. Due to the risk of cross-infection between CF patients, the workshops involved a single CF patient, except for a few cases where patients with the same bacteria-flora could be recruited. Parents and HPs workshops were conducted as focus groups. Table 3. summarizes the sample. The workshops lasted 2-3 hours each.

<table><caption>**Table 3.** Distribution of participants on the workshops</caption><thead><tr><th rowspan="2">Workshop Set</th><th rowspan="2">Location</th><th colspan="5">Participants</th></tr><tr><th>Patient 13-17 yo</th><th>Patient 17+ yo</th><th>Parent 0-12 yo</th><th>Parent 12+ yo</th><th>HP</th></tr></thead><tbody><tr><td rowspan="4">Initial Workshops</td><td>Netherlands</td><td></td><td></td><td>1</td><td></td><td></td></tr><tr><td>Norway</td><td>1</td><td>1</td><td></td><td>1</td><td></td></tr><tr><td>Valencia</td><td></td><td>4</td><td></td><td></td><td></td></tr><tr><td>Madrid</td><td></td><td>1</td><td>4</td><td>1</td><td></td></tr><tr><td>Refinement Workshops</td><td>Portugal</td><td>3</td><td>1</td><td>4</td><td>3</td><td></td></tr><tr><td rowspan="2">HPs' Validation</td><td>Portugal</td><td></td><td></td><td></td><td></td><td>7</td></tr><tr><td>Netherlands & Belgium</td><td></td><td></td><td></td><td></td><td>5</td></tr><tr><td>Evaluation</td><td>Norway</td><td>1</td><td>2</td><td>1</td><td></td><td></td></tr></tbody></table>

The **Initial Workshops** were structured so that:

1. The concept and core features of the App were presented.

2. Participants were asked for feedback as to validate the relevance and applicability of the core features on the daily basis.

3. Moderators triggered the participants to imagine how the features could fit their daily life and to sketch interaction with the App.

4. The moderators suggested UI elements based in the background research, when participants were not able to sketch their ideas.

<footnote n="11">¹¹ www.balsamiq.com</footnote>

<footnote n="12">¹² https://www.youtube.com/channel/UCD63yFB92hwpnNJJmu5Dbgw</footnote>
The mockups produced after the **Initial Workshops** implemented use cases derived from the selected core features, while the UI elements were designed taking in consideration the non-functional requirements (see Table 1). The App mockups included five different menu entry points: one for registering meals, one for managing food recipes, one for diary keeping, one for graphs and goals and finally one for managing reminders. The App features could then be triggered from subsequent screens started from those entry points. For instance, enzyme calculation was triggered when registering a meal, physical activity registration was prototyped as a part of the diary, and the educational content was implemented through help probes attached to App components.

The mockups were tested in the **Refinement Workshops** with patients or parents interacting with them in a think-aloud fashion [5]. Moderators asked the participants to think of a recent or hypothetical experience related to one of the use cases supported by the App, and to execute it using the mockup while describing the process. For example, we asked participants to register symptoms they had recently and to add their last meal. When several participants were involved in a session, all were asked to follow the steps of the active participant and give complementary feedback in the cases they would have interacted differently. Moderators asked questions at the end of each use case in order to ensure that all participants were able to voice their opinions.

The **validation by HPs** followed a different process. The moderators walked through the mockups to present the different features. The HPs were asked to comment underway. And, after each use case, moderators asked for additional feedback.

The mockups were refined and submitted to a final **Evaluation** by 5 patients and parents. Descriptive videos of the different features implemented in the mockup were distributed and participants were asked to answer a questionnaire including both qualitative and quantitative questions. The qualitative questions were open questions inquiring what they liked, disliked or missed. Meanwhile the quantitative questions asked them to rate the usefulness of the different UI elements using a five-level likert scale.

In general, the feedback given by participants from the workshops and evaluations was positive. They considered that all the features they need were covered by the mockups and they were very eager to try using the App.

# 5 Results

In this section, we present some of the mockups and the rationale behind the UI elements (for a complete coverage of the mockups look at the videos - see footnote ¹²). We describe the different points of views captured through the workshops or evaluations leading to them.

## 5.1 Food Registration

Meals are composed of food items or dishes, and the latter are composed of different ingredients. It is necessary to support the identification of all those elements
for quantifying the nutritional composition of a meal. The co-design focused on
UI elements to support easy registering of meals assuming the availability of an
existing comprehensive food database. The UI elements include:

- Support for adding new food items by scanning their bar-code;

- Auto-complete search technology;

- Bookmarking favourite dishes and food items;

- Varied quantity units (e.g. grams or slices) and illustrative examples;

- Setting meals as recurrent;

- Creating variations of existing dishes.

Workshop participants often ate the same food, and suggested support for recurrent dishes and creation of variations of existing dishes. That would allow them to quickly register a new dish or meal instance. Another point requested by several patients was support for registering energy complements.

When it comes to quantifying food items, they suggested to provide units adapted to the type of food. For example, bread can be described in terms of slices and milk in terms of glasses. HPs suggested that non-standard units such as the ones above should be complemented with the equivalency to a standard unit such as grams or millilitres. HPs also suggested to size dish portions based on how much of a plate space they take, as illustrated in Fig.1. Evaluation participants really liked this feature.

Overall, the UI elements for quick registration were highly rated in the ques-
tionnaires' answers and positively noted during the **Refinement Workshops**.
The same applies for the food quantification, where all **Evaluation** participants
thought they would be able to estimate the food amount with the App.

5.2 Enzyme Management

The enzyme management was presented as part of the Food Registration UIs
as they go hand in hand. The quantity of recommended enzyme is displayed
together with the meal items and a stepper control is presented so that the
user can adjust the amount taken (as shown in Fig.2). An important feedback
was that different enzymes capsules or types contain different enzymes dosage,
making it necessary configuration of the enzyme supplement. In addition, some
patients suggested support for keeping track of the stock of enzyme capsules.

5.3 **Recipe Book**

Several participants often struggled to find energy rich recipes and welcomed advice for recipes. They suggested grouping recipes based on different characteristics: salty, sour, quick preparation, etc. They were also interested sharing recipes with other patients, commenting and rating. Dieticians in MyCyFAPP were however concerned that the App supports recipes curated by dieticians. They suggest a symbol to differentiate them from non-curated recipes.

Patients wanted the recipe book to be integrated with the food registration,
so a dish could be registered directly from the recipe book. Patients would also
like to create recipe variations and bookmark favourites.
<figure><img src="image_2.png" /><figcaption>Fig. 1. Selecting a portion size</figcaption></figure>

<figure><img src="image_3.png" /><figcaption>Fig. 2. Meal and enzyme overview</figcaption></figure>

5.4 Diary

A list of CF symptoms was developed with patients in the first workshops and validated by doctors. While patients consider all kinds of symptoms, HPs suggested to focus on gastrointestinal symptoms due to the scope of the project. The list from HPs included: pain in abdominal regions, diarrhoea, irregular stool, constipation, heartburn, vomiting and nausea. HPs stressed that context information should be defined for some symptoms. For example, for both heartburn and abdominal pain, it is important to know if it happens at night or before a meal.

The majority of the symptoms were suited for yes/no check-boxes and drop
down menus covering simple additional context. However, for pain, patients in
the **Initial Workshops** suggested to select the body area with pain from a body
drawing, and, then set the intensity and frequency (as illustrated in Fig.3). All
**Evaluation** respondents supported the idea of clicking on a visual representation
to localize pain, even if a few of them thought they would be able to describe it
as well without the visual cue.

Patients and HPs were asked about the possibility of using audio or camera
to record symptoms, such as audio for coughing and camera for mucus. HPs did
not find it very useful for their assessment. Patients were reluctant about taking
pictures of the mucus, and afraid they would be stored in theirs phone picture
gallery.

The diary mockup also included a Notes field for free notes. Participants
found it useful. Some would use it for detailing symptoms, and some for writing
personal notes. The latter were not so keen about sharing notes with doctors, or
between children and parents.

<figure><img src="image_4.png" /><figcaption>Fig. 3. Abdominal Pain in Diary</figcaption></figure>

<figure><img src="image_5.png" /><figcaption>Fig. 4. Registering Physical Activity</figcaption></figure>

5.5 Physical Activity Registration

Physical Activity Registration came out as a suggestion on the **Initial Work-shops** in connection with food intake registration. Some HPs highlighted the importance of this feature for quantifying the calories expenditure and ensure that patients would eat enough to compensate for days of high physical activity. Some paediatrics did however not find it useful as it is difficult to quantify the activity of small children.

We designed the registration of physical activity as an entry in the diary
which enabled the recording of multiple physical activities and steps (as illus-
trated in Fig.4). Both steps and activities can be inserted manually or by con-
necting the App to a physical activity platform or device (such as Google Fit<fnref n="13" />, FitBit<fnref n="14" />, etc). Some participants were users of such devices and appreciated such support.

Regarding the manual registration of physical activities, similarly to [9], par-
ents suggested the inclusion of daily activities within the registry options. They
suggested the inclusion of outdoor children games such as hide-and-seek and tag
with the activities. During the talk-aloud experiment participants were unsure
about which activity intensities theirs recent physical activity belonged to. Fi-
nally, they suggested to add an informative text that illustrates the types of
activity intensity.

5.6 Goals

Most of the patients and parents were interested in following nutrition goals. Given that CF patients need to consume higher energy food to achieve theirs daily energy requirements, we expected that calories and fat would be the main concern. Indeed, some parents were concerned by high-energy intake. However, many parents and patients were more interested in ensuring a balanced diet. Some were also interested in other types of goals, such as goals related to sport and adhering to the treatment, in particular inhalations. Overall, participants stated that setting up goals and tracking them would motivate them to follow their treatment.

Some patients and parents were happy to receive goals from dieticians while
some preferred to set up goals themselves. Dieticians on the other hand wished
to curate goals or to be involved in the goal selection. They want not only to
ensure that goals are sound and safe, but also adequate for a specific patient.

5.7 Treatment Explanation

Education was introduced in the App via explanation boxes attached to symp-
toms. The boxes were activated when pressing help buttons leading to a descrip-
tion of symptoms and possible causes. The information format was appreciated
by parents, patients and HPs.

However there were different opinions about what content is useful between parents/patients and HPs. While patients and parents would like to receive feedback about how to remedy the symptom, HPs were not in favour of giving recommendations. HPs argued that guidance can only be provided based on the whole patient context.

5.8 Health Visualization

Patients and parents were interested in visualizing both nutritional and health
status over time. Most patients were satisfied of being able to visualize only the

<footnote n="13">¹³ https://www.google.com/fit/</footnote>

<footnote n="14">¹⁴ https://www.fitbit.com/</footnote>
data they register. One parent also suggested access to the results from HPs examinations, such as bacteria infection levels.

Overall, they wished correlated aspects to be shown together, such as height, weight and nutrition. For those, they suggested that line graphs would be more suitable. For occurrence of symptoms, a tabular form was suggested. Each row would consists of a symptom, each column a calendar date and each cell a representation of that symptom in that date (colors or abbreviations could be used for the symptom state representation).

Participants expected to be able to select which data is displayed, and to zoom into periods, as well to access the details of a registration by selecting a value in the graphs.

## 5.9 Reminders

Patients and parents were interested in reminders for parts of the treatment not usual in the daily routine, such as new medication or consultation. They preferred reminders to be flexible to accommodate varied treatment aspects, rather than only support for medicine intake. They also favoured flexibility in the reminder creation to accommodate appointments with daily recurrence, end-dates or different medicine dosage. Most participants preferred to include reminders in the App rather than using the phone main agenda.

Regarding reminder alarms, participants wanted them to be discrete and easy to use. They wanted to be able to confirm the intake of medicine directly from the reminder notification; and to possibly snooze it (see Fig.5).

## 5.10 Weight and Height registration

Parents, and some patients, were especially concerned about height and weight recording since the malabsorption of nutrients by CF patients can affect the growth. However, HPs recommended to avoid recording weight every day because too much focus on growth is not good. They also would not use measurements done by patients themselves, because HPs could not verify how the measurement was done. Thus, they could not compare measurements done during consultations with those done by patients.

## 5.11 Sharing data with doctors

Both during our preliminary interviews (see Section 3) and the **Initial Workshops**, we noticed different views as for sharing data recorded by patients with doctors. Some patients and parents wanted to control what is shared while some wanted to share data automatically for simplicity, and because they expected that the shared data would allow HPs to make better diagnostics.

The designed solution allowed patients to decide which data to share, when to share and how to share it. The mockups enabled patients to share data in different ways. It allowed the automatically sending of data to HPs system,
<figure><img src="image_6.png" /><figcaption>Fig. 5. Medicine Notification</figcaption></figure>

<caption>Fig. 6. Sharing data</caption>

manually selecting which data and time range to send to HPs system or simply
to generate a pdf containing the data (illustrated in Fig.6). With the pdf option,
the patient could send it to the doctor or choose what to print and bring to the
consultation. This flexible approach was unanimously well received during the
**Refinement Workshops** and **Evaluation**.

HPs underlined that patients should be informed that shared data would only be seen during consultations (around every 3 months). They claimed not being able to cope with real time follow-up, as similarly observed in [25]. As several patients and parents had expectation that HPs would contact them rapidly if data indicate some health issue, it is important that the App makes it clear to patients how and when doctors will use shared data.

# 6 Discussion

Apart from concrete design concepts and UI elements, the workshops uncov-
ered transversal concerns that stretch across the different UIs and the CF self-
management model. We present those in this section together with reflections
on how they can be addressed and further investigated.
## 6.1 When to start using the App

Parents and doctors pointed out that it would be beneficial that children start using the App as soon as they are mature enough. When discussing, they agreed that the maturity level of children vary, and, therefore, parents, children and HPs should decide together when the children start using the App, instead of starting at a specific age.

In a first stage, when children start using the app, parents would like to use the App in parallel with their children in order to assume the responsibility for logging data in case the children do not. During the workshops, the concern about possible editing conflicts between parents and children was raised. Despite existing technical solutions to handle data conflicts, parents concluded that the best solution would be to refrain from editing data and rather talk with the children to clarify the discrepancy and ask the child to log data. Parents agreed that this is a better way to educate the children.

## 6.2 Customization

Both our initial interviews and the co-design workshops show a strong need for customization to different contexts and age groups. The knowledge about the disease increases as the patients grow up. At the same time, the health condition evolves leading to new requirements. Patients are different: some are compliant to the treatment, and some needs strong guidance. A factor that calls for customized support is that we target different user groups. While we initially consider two App user groups, i.e., parents managing the health of their children and patients managing their own health, we identified a new group, that of parents and children with CF cooperating.

Customization was proposed as a mechanism to simplify the UI allowing to include only the elements of interest. Some suggestions were selecting the order of the symptoms in the diary, removing symptoms, and selecting which data source to be present on the different graphs. Symptoms types and severity vary a lot from CF patient to patient and with the progress of the disease. For instance, some patients develop diabetes. The possibility to customize the symptoms in the diary would be especially important if the App is extended to include a complete list of symptoms, not only gastrointestinal symptoms.

The difference of age groups between users is also another aspect that calls for personalization. Growth tracking is important for children but it is not for adult patients. Younger users relate to mobile Apps differently. We noticed in our workshops that teenagers wanted to have a more playful interaction with the App. One of them, for example, expressed the wish to set the background colours of the App to match the ones of the football club he supports.

Participants voiced the importance of including all treatment aspects in a single App and customized for CF care. Patients described that they tried some of the available Nutritional Apps but gave up as the functionalities were directed towards weight loss and did not make sense for their case.
A special case of customization is that of parents with more than one child with CF. They would like to use the same App to manage both children.

When parents and their child are cooperating in health management, parents would like the child to receive reminders about medicine intake and, to receive themselves notifications that the child took the medicine. They also would like to configure the receipt of such notifications in case they become too annoying. The customization of what features are available in the App was also suggested as a mechanism to limit the App scope for children who start taking responsibility for self-management. In that way, new features could be unveiled little by little.

## 6.3 Data quality and control

During the co-design workshops, we noticed some divergences between patients and parents wish to decide on the management of their health, and HPs wish to curate the App content. While patients and parents wanted to freely define goals and create recipes, HPs wanted to ensure that those were medically valid. HPs were uncomfortable with the idea that an App would support goals and recipes that are not recommended by dieticians. Such divergence raises a compromise between supporting patients with their individual wishes that affect acceptance of the App, and the medical validity of the supported features. For recipes, HPs suggested to distinguish between dietician recommended recipes and user-generated recipes. For goals, HPs suggested that patients and parents could define those together with them during consultation.

HPs expressed some scepticism about the quality of the data entered by patients. They wanted patients to use an "I'm fine button" for days where they have no symptom, as to distinguish it from the absence of symptom registration. For the weight and height measurements, they would rather use the consultation measurements as they are performed on standard conditions (calibrated scale, without cloths, etc).

Retrieving health information reported by patients out of the consultation and without being able to enquire about the patients context, introduces a situation to which HPs are not used to. It is important to further study how HPs will cope with this type of information, and to understand how recording can be useful without increasing the treatment burden for the patient.

## 6.4 Treatment recommendation

During the workshops, most of the parents and patients voiced wishes of having treatment recommendations given by the App. They would like the App to indicate actions, such medicine intake, when symptoms are registered. They would also like the App to analyse the registered health patterns in order to detect correlations between events. HPs, on the other hand, were reluctant to such support. They argued that a lot of contextual information is needed to prescribe a treatment. They exemplified that several symptoms can be related to different diseases or conditions, and concluded that it can be dangerous to provide recommendations only based on the registration of symptoms.
# 7 Concluding remarks and future work

The usage of co-design with multiple stakeholders involved in the self-management of CF enabled us to: (1) identify divergences between stakeholders and develop solutions that tackle these divergences; and (2) create design concepts for the core features effectively rooted in the functional requirements and non-functional requirements, such as privacy and time saving. The resulting mockups are consistent with design findings uncovered in similar research work and popular Apps cited here, but they also introduce elements which, as far as we know, have not been yet explored. For instance, we propose flexible mechanisms to share data and to create new instances of food intake from dish variations. At the same time, the mockups bundle together the specific and varied requirements for CF self-management in a mobile application.

Although the findings described here relate to the self-management of CF, the discussion in this article applies more generally to the introduction of a self-management mobile application in healthcare. Many aspects of the CF therapy, such as continuous medicine intake, regular physical activity and nutritional follow-up, are common to other chronic diseases, thus potentially making many of our findings directly applicable to other self-management applications. For example, findings about optimizing food registration confirm and complement those for diabetes [2] or obesity [22] Apps, but also shed light in different aspects of nutrition management as the nutritional context of CF patients differs from other chronic diseases.

The positive feedback and the participants willingness to try an App based on the mockups indicate that the design concepts are ready to be implemented. We will continue this research as we develop the App, and conduct a mid-term evaluation and later on assess the App in a clinical study. These evaluations will help us to understand the usability and acceptability of the design concepts.

# Acknowledgments

Authors of this paper, on behalf of MyCyFAPP consortium, acknowledge the European Union and the Horizon 2020 Research and Innovation Framework Programme for funding the project (ref. 643806). Furthermore, we thank the participants to the workshops and the evaluation, and the project partners for the collaboration during participant recruitment and discussion of the results.

# References

1. Living with cf: Treatments and therapies. https://www.cff.org/Living-with-CF/Treatments-and-Therapies/, accessed: 2016-09-26

2. Årsand, E., Tufano, J.T., Ralston, J.D., Hjortdahl, P.: Designing mobile dietary management support technologies for people with diabetes. Journal of telemedicine and telecare 14(7), 329–332 (2008)
3. Arsand, E., Varmedal, R., Hartvigsen, G.: Usability of a mobile self-help tool for people with diabetes: the easy health diary. In: 2007 IEEE International Conference on Automation Science and Engineering. pp. 863–868. IEEE (2007)

4. Bate, P., Robert, G.: Experience-based design: from redesigning the system around the patient to co-designing services with the patient. Quality and Safety in Health Care 15(5), 307–310 (2006)

5. Boren, T., Ramey, J.: Thinking aloud: Reconciling theory and practice. IEEE transactions on professional communication 43(3), 261–278 (2000)

6. Borowitz, D., Gelfond, D., Maguiness, K., Heubi, J.E., Ramsey, B.: Maximal daily dose of pancreatic enzyme replacement therapy in infants with cystic fibrosis: a reconsideration. Journal of Cystic Fibrosis 12(6), 784–785 (2013)

7. Calvo-Lerma, J., Martinez-Jimenez, C.P., Lázaro-Ramos, J.P., Andrés, A., Crespo-Escobar, P., Stav, E., Schauber, C., Pannese, L., Hulst, J.M., Suárez, L., et al.: Innovative approach for self-management and social welfare of children with cystic fibrosis in europe: development, validation and implementation of an mhealth tool (mycyfapp). BMJ open 7(3), e014931 (2017)

8. Celler, B.G., Lovell, N.H., Basilakis, J., et al.: Using information technology to improve the management of chronic disease. Medical Journal of Australia 179(5), 242–246 (2003)

9. Consolvo, S., Klasnja, P., McDonald, D.W., Avrahami, D., Froehlich, J., LeGrand, L., Libby, R., Mosher, K., Landay, J.A.: Flowers or a robot army?: encouraging awareness & activity with personal, mobile displays. In: Proceedings of the 10th international conference on Ubiquitous computing. pp. 54–63. ACM (2008)

10. Consolvo, S., Klasnja, P., McDonald, D.W., Landay, J.A.: Designing for healthy lifestyles: Design considerations for mobile technologies to encourage consumer health and wellness (2014)

11. Dodd, M.E., Webb, A.K.: Understanding non-compliance with treatment in adults with cystic fibrosis. Journal of the Royal Society of Medicine 93(Suppl 38), 2 (2000)

12. Free, C., Phillips, G., Galli, L., Watson, L., Felix, L., Edwards, P., Patel, V., Haines, A.: The effectiveness of mobile-health technology-based health behaviour change or disease management interventions for health care consumers: a systematic review. PLoS med 10(1), e1001362 (2013)

13. Fricke, L., Weisser, T., Floch, J., Grut, Lisbeth, V.T., Stav, E., Schauber, C.: User needs in the development of a health app ecosystem for self-management of cystic fibrosis, manuscript submitted for publication at JMIR mHealth and uHealth

14. Frøisland, D.H., Årsand, E.: Integrating visual dietary documentation in mobile-phone-based self-management application for adolescents with type 1 diabetes. Journal of diabetes science and technology p. 1932296815576956 (2015)

15. Hardisty, A.R., Peirce, S.C., Preece, A., Bolton, C.E., Conley, E.C., Gray, W.A., Rana, O.F., Yousef, Z., Elwyn, G.: Bridging two translation gaps: a new information research agenda for telemonitoring of chronic disease. International journal of medical informatics 80(10), 734–744 (2011)

16. Hilliard, M.E., Hahn, A., Ridge, A.K., Eakin, M.N., Riekert, K.A.: User preferences and design recommendations for an mhealth app to promote cystic fibrosis self-management. JMIR mHealth and uHealth 2(4), e44 (2014)

17. Kujala, S.: User involvement: a review of the benefits and challenges. Behaviour & information technology 22(1), 1–16 (2003)

18. March, S.T., Storey, V.C.: Design science in the information systems discipline: an introduction to the special issue on design science research. MIS quarterly pp. 725–730 (2008)
19. Nolte, E., McKee, M.: Caring for people with chronic conditions: a health system perspective. McGraw-Hill Education (UK) (2008)

20. Pearson, M.L., Mattke, S., Shaw, R., Ridgely, M.S., Wiseman, S.H.: Patient self-management support programs (2007)

21. Sanders, E.B.N., Stappers, P.J.: Co-creation and the new landscapes of design. Co-design 4(1), 5–18 (2008)

22. Tsai, C.C., Lee, G., Raab, F., Norman, G.J., Sohn, T., Griswold, W.G., Patrick, K.: Usability and feasibility of pmeb: a mobile phone application for monitoring real time caloric balance. Mobile networks and applications 12(2-3), 173–184 (2007)

23. Ward, B.W.: Multiple chronic conditions among us adults: a 2012 update. Preventing chronic disease 11 (2014)

24. Webb, T., Joseph, J., Yardley, L., Michie, S.: Using the internet to promote health behavior change: a systematic review and meta-analysis of the impact of theoretical basis, use of behavior change techniques, and mode of delivery on efficacy. Journal of medical Internet research 12(1), e4 (2010)

25. van der Weegen, S., Verwey, R., Spreeuwenberg, M., Tange, H., van der Weijden, T., de Witte, L.: The development of a mobile monitoring and feedback tool to stimulate physical activity of people with a chronic disease in primary care: a user-centered design. JMIR mHealth and uHealth 1(2), e8 (2013)

26. Yach, D., Hawkes, C., Gould, C.L., Hofman, K.J.: The global burden of chronic diseases: overcoming impediments to prevention and control. Jama 291(21), 2616–2622 (2004)