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

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).


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. Selfmanagement 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. Selfmanagement 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 selfmanagement 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 accross the whole App and self-management model; Section 7 concludes and presents future work.

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.

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.

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 nonfunctional 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 population: both young and adult patients; parents; CF patient associations and Health Professionals (HPs). In that work, a total of 466 requirements were identified 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 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 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 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.

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- Patients expressed that they would sometimes experience a lack of motivation and that some support could be useful. Customization Patients knowledge about health, nutrition and disease varies a lot requiring the App to be customizable. Privacy Users were inclined towards controlling the sharing of health data rather than making it automatically accessible to HPs.

One App
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.
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 selfmanagement 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.

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 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 codesign 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 principal 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.

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.

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.

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 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 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 crossinfection 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. 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.
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.

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 12 ). We describe the different points of views captured through the workshops or evaluations leading to them.

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 questionnaires' 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.

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.

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.

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.

Physical Activity Registration
Physical Activity Registration came out as a suggestion on the Initial Workshops 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 illustrated 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 13 , FitBit 14 , etc). Some participants were users of such devices and appreciated such support.
Regarding the manual registration of physical activities, similarly to [9], parents 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. Finally, they suggested to add an informative text that illustrates the types of activity intensity.

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.

Treatment Explanation
Education was introduced in the App via explanation boxes attached to symptoms. The boxes were activated when pressing help buttons leading to a description 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.

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 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.

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).

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.

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, 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.

Discussion
Apart from concrete design concepts and UI elements, the workshops uncovered transversal concerns that stretch across the different UIs and the CF selfmanagement model. We present those in this section together with reflections on how they can be addressed and further investigated.

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.

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.

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 usergenerated 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.

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.
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 selfmanagement 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.