Universidade de Aveiro Departamento de Eletrónica,Telecomunicações e Informática 2020
FÁBIO DANILO
PINHAL CUNHA
Aplicação multiplataforma para apoiar o registo da
Avaliação Geriátrica Global
Multiplatform application to support the
Universidade de Aveiro Departamento de Eletrónica,Telecomunicações e Informática 2020
FÁBIO DANILO
PINHAL CUNHA
Aplicação multiplataforma para apoiar o registo da
Avaliação Geriátrica Global
Multiplatform application to support the
Comprehensive Geriatric Assessment
Dissertação apresentada à Universidade de Aveiro para cumprimento dos requisi-tos necessários à obtenção do grau de Mestre em Engenharia de Computadores e Telemática, realizada sob a orientação científica do Doutor Ilídio Castro Oliveira, Professor auxiliar do Departamento de Eletrónica, Telecomunicações e
o júri / the jury
presidente / president Professora Doutora Maria Beatriz Alves de Sousa Santos
Professora Associada C/Agregação, Universidade de Aveiro
vogais / examiners committee Professor Doutor Pedro Miguel dos Santos Beça Pereira
agradecimentos /
acknowledgements Primeiramente, quero agradecer ao Professor Ilídio Oliveira, orientador desteprojeto, pelo apoio dado, pelos conselhos, pela orientação e por estar sempre disponível para ajudar, bem como ao Doutor Samuel Silva, co-orientador deste projeto.
Quero também agradecer ao doutor Paulo Almeida, membro do Núcleo de Estudos de Geriatria da Sociedade Portuguesa da Medicina Interna (GERMI-SPMI), pelas opiniões dadas ao longo do projeto de modo a ser mais realista para a componente médica e aos médicos que colaboraram na validação das ferramentas. Agradeço a todos os meus amigos que fiz nesta etapa académica em espe-cial ao grupo QL e também àqueles que me acompanham há mais anos.
Palavras Chave Computação móvel; mHealth; Android; iOS; Web; ponto de tratamento; avaliação geriátrica global; geriatria.
Resumo A Avaliação Geriátrica Global (AGG) é uma ferramenta de diagnóstico
multi-disciplinar que avalia pessoas idosas em cinco áreas principais: clínica, física, mental, funcional e social. Para aplicar a AGG o clínico tem de responder a um conjunto alargado de questões e pode recorrer a orientações, em papel, para o guiar. Num trabalho anterior, relacionado com esta dissertação, foi desenvolvida uma aplicação móvel, para funcionar como um guia de bolso, em substituição do papel. A aplicação, Geriatric Helper, existia em versões nativas para Android e iOS. Neste trabalho, realizámos a reengenharia da aplicação existente, para usar uma abordagem multiplataforma, baseada em React Native. Para além das versões para smartphone, foi também introduzida uma versão web, com funciona-lidades acrescidas.
su-Keywords Mobile computing; mHealth; Android; iOS; Web; point-of-care; Comprehensive Geriatric Assessment; geriatrics.
Abstract The Comprehensive Geriatric Assessment (CGA) is a multidisciplinary diagnostic
tool that assesses older people in five main areas: clinical, physical, mental, functional and social. To apply the CGA, the clinicians must answer a wide range of questions and may use paper-based instructions to guide them.
In a previous work related to this dissertation, a mobile application was de-veloped to function as a pocket guide, instead of paper. The app, Geriatric Helper, existed in native versions for Android and iOS.
In this work, we reengineered the existing application to use a multiplat-form approach based on React Native. In addition to the smartphone versions, a web version has also been introduced, with added features.
re-Contents
Contents i
List of Figures iii
List of Tables v Glossary vii 1 Introduction 1 1.1 Motivation . . . 2 1.2 Objectives . . . 2 1.3 Dissertation structure . . . 2
2 State of the Art 5 2.1 Geriatric Assessment . . . 5
2.1.1 Comprehensive Geriatric Assessment . . . 5
2.1.2 Beers criteria . . . 7
2.1.3 Stopp/Start criteria . . . 8
2.2 Related Work . . . 8
2.2.1 Mobile applications for healthcare professionals . . . 8
2.2.2 Geriatric Assessment Applications . . . 10
2.3 Mobile Applications Development . . . 13
2.3.1 Android . . . 14
2.3.2 iOS . . . 15
2.3.3 Cross-platform Solutions . . . 15
2.4 Web Applications Development . . . 17
2.5 Previous Work . . . 19
2.5.1 Overview . . . 19
2.5.2 Architecture . . . 20
3 System Requirements 23
3.1 Domain activities and usage scenarios . . . 23
3.1.1 Outside usual medical appointment scenario . . . 23
3.1.2 Medical appointment scenario . . . 23
3.2 Requirements for the GeriatricHelper mobile app . . . 24
3.3 Requirements for the GeriatricHelper web app . . . 25
4 Implementation 27 4.1 System Architecture . . . 27
4.2 Rengineering the Geriatric Helper Mobile Application . . . 28
4.3 Web Application . . . 30 4.4 Data Model . . . 34 5 Results 39 5.1 Mobile Prototype . . . 39 5.2 Web Prototype . . . 41 5.3 Exploratory Usage . . . 46
6 Conclusion and Future Work 49 6.1 Work Performed . . . 49
6.2 Future Work . . . 50
References 51
Appendix 55
List of Figures
1.1 Life expectancy over the last few centuries[1] . . . 1
2.1 Categories of factors that can lead to prescription errors [12] . . . 7
2.2 Optimal use of the AGS 2015 Beers Criteria – A Case Example[14] . . . 8
2.3 Zocdoc physician screen . . . 9
2.4 PatientKeeper patient screen . . . 9
2.5 Índices Dependencia main screen . . . 11
2.6 Valoración de la Fragilidad main screen . . . 11
2.7 Exames Cognitivos patient screen . . . 11
2.8 Plus65 Med with START criteria for Cardiovascular system . . . 11
2.9 Escalas Geriatricas main screen . . . 12
2.10 Oncoscale main screen . . . 12
2.11 GeriatriApp main screen . . . 12
2.12 ElderCare scales screen . . . 12
2.13 Avaliação do Idoso main screen . . . 13
2.14 iGeriatrics main screen . . . 13
2.15 Distribution of different operating systems in Portugal . . . 14
2.16 Framework popularity survey results by Stack Overflow users[39] . . . 19
2.17 app tour guide depicting the different CGA areas . . . 20
2.18 GeriatricHelper help topics . . . 20
2.19 System Architecture diagram from the previous implementation . . . 21
4.1 System Architecture . . . 28
4.2 GeriatricHelper scales screen . . . 29
4.3 Lawton & Brody scale screen . . . 29
4.4 Results screen for a CGA session . . . 30
4.5 Scales Type Page . . . 31
4.6 Lawton & Brody Scale Page . . . 31
4.8 Default PDF for the treatment guide . . . 33
4.9 Alternative layout for the treatment guide . . . 34
4.10 Redux Architecture[44] . . . 35
5.1 Android version app flow diagram . . . 39
5.2 iOS version app flow diagram . . . 41
5.3 GeriatricHelper initial page . . . 42
5.4 Scales Areas page . . . 42
5.5 Nutritional State info page . . . 43
5.6 Lawton & Brody info page . . . 43
5.7 Nutritional Area Scales page . . . 44
5.8 Body Mass Index calculator page . . . 44
5.9 Mini-Mental State Examination page . . . 45
5.10 Session Result page . . . 45
5.11 Prescription Area page . . . 46
1 Katz Scale . . . 55
2 Lawton & Brody Scale . . . 56
3 Yesavage Geriatric Depression Scale: Short Version . . . 57
4 Mini-Mental State Examination (MMSE) . . . 58
List of Tables
2.1 Overview of CGA mobile solutions and their functionalities . . . 13
2.2 Overall comparative table between React Native and Flutter . . . 16
2.3 Quick Framework Overview . . . 18
3.1 Use Cases of the mobile application . . . 24
3.2 CGA scales present in GeriatricHelper . . . 24
3.3 Use Cases of the web application . . . 25
4.1 Differences between previous and current implementation . . . 30
4.2 Differences between mobile and web application . . . 32
4.4 Actions associated with respective Reducers . . . 36
4.3 System Reducers and its fields . . . 37
5.1 List of tasks asked to the physicians . . . 47
Glossary
WHO World Health Organization
CGA Comprehensive Geriatric Assessment GERMI Núcleo de Estudos de Geriatria da
Sociedade Portuguesa da Medicina
Interna
CNPD Comissão Nacional de Proteção de Dados
CHAPTER
1
Introduction
According to the World Health Organization (WHO), the average life expectancy worldwide in 2016 was 72.0 years old but, from 2000 to 2016 it raised 5.5 years, which represents a considerable raise (Figure 1.1).
Figure 1.1: Life expectancy over the last few centuries[1]
The average life expectancy extension causes an increase in the elderly population. With an aged population, comes several problems associated with the advanced age requiring adequate and sufficient conditions for proper treatment.
Geriatrics exist, precisely, to study and treat these diverse problems, not only the diseases but also certain disabilities that with the advanced age start to appear. Due to a higher
average life expectancy, geriatrics is an area that will continue to grow and in constant evolution in technology, scientific and infrastructure terms.
1.1 Motivation
Comprehensive geriatric assessment (CGA) is a process that assesses the elders in five major areas: clinical, physical, mental, functional and social.
For the previous work, the Núcleo de Estudos de Geriatria da Sociedade Portuguesa de Medicina Interna (GERMI) approached the University of Aveiro, seeking a collaboration to implement the CGA on a mobile platform. This platform would help the physicians to solve the current method issue of scales filling (the current method is still filling the scale in the paper).
The use of a mobile app mostly entails the consideration of the physician’s personal device, not always a desirable possibility. Thus, the main motivation that lead to this work is that the tool previously developed is less useful in a medical appointment in which it would not be possible or well-received to use a mobile device. The different target environments should include more than the existing mobile platform namely for the web platform.
The most common environment for a physician is its office and here using the personal mobile device may not be the best choice (and dedicated devices are not available). The desktop computer usually is the main technological work object provided and is in which most physicians and other professionals are more comfortable working with, rather than the mobile phone.
The fact that a simple guide to medicine taking, as is the case with e-prescription, is not enough and it puts barriers to its interpretation by an elderly population affected by various weaknesses: visual, literacy, etc. In this sense, it is important to have a proper approach. The current method does not have in mind the senior’s limitations namely, it has small letters and it does not have a simple design for better understanding. Thus, GERMI approached the University of Aveiro, seeking a collaboration to improve what has been already done and to create a solution to communicate with patients easier through a therapeutic plan.
1.2 Objectives
Given the motivation for this work, the main objectives set for this dissertation are:
• Considering previous work on a mobile pocket guide for CGA, propose a novel approach enabling its deployment for a wider range of platforms and devices.
• Understand current physician strategies to support the communication of the prescribed medication, in geriatric context, and propose methods to support them
• Implement a functional demonstrator for the CGA on mobile and web platforms.
1.3 Dissertation structure
This dissertation is organized into seven chapters: 2
• Chapter 1 presents the challenges and objectives of the present work that conducted to the development of the mobile and web approaches to the CGA.
• Chapter 2 describes the overall concepts about CGA and related work in the area, also about Start, Stopp and Beers criteria. It also introduces to mobile and web development and to the technologies that are associated with the development of both mobile and web applications. Also, it presents a quick overview of the previous work and what the limitations the previous implementation had.
• Chapter 3 presents and explain the system requirements for both platforms.
• Chapter 4 explain the system architecture and data model as well as the implementation for both mobile and web applications.
• Chapter 5 presents the results.
CHAPTER
2
State of the Art
2.1 Geriatric Assessment
"Geriatric Medicine or Geriatrics is the medical branch that focuses the study, prevention and treatment of disease and disability in advanced ages"[2]. And according to the WHO, a person is considered an elder when the person is 65 or more years old in developed countries and 60 years old in underdeveloped countries.
2.1.1 Comprehensive Geriatric Assessment
Comprehensive geriatric assessment (CGA) is a multidimensional and multidisciplinary process that identifies medical, social and functional needs and the development of integrated health care to meet those needs[3]. Unlike many people think, CGA is not only for checking on elder’s health status is also to identify patient’s resources, capacities, and preferences in a way that the physician can make a more personalized care plan considering if the patient has some limitations in any field. CGA is for all elder population, although the fitter elders do not need as much as the not as fit. For the fit ones, CGA is good for handling some future problems that can be avoided with some prevention treatments. However, for those not-so-fit, it is very important for checking on some decline in any capacity that can evince some imminent problem[4].
The senior community can gain a lot in very different ways with the continuous practice of the CGA. Firstly, a study made by Giuliano Piccoliori et al. shows that CGA identified multiple health problems after one year of usage, half of them were dealt successfully[5]. Furthermore, Min LC et al. study mentioned an increase in the care quality given to the patient[6]. Many studies, also mention that the overall patient’s life quality has raised. To conclude, Ekdahl AW et al. after using CGA for 36 months demonstrated a decrease in hospital admission rates as well as longer survival and fewer days in the hospital[7].
Nevertheless, for this superb benefits to be accomplished, CGA must assess the most critical domains to get the most of this process. Iliffe S. et al. conducted a study to find
which domains were more important to assess and they came to the realization of the five main domains[8]:
• Senses (mainly Hearing and Vision)
• Physical Ability (difficulties in the everyday normal activities) • Incontinence
• Cognition
• Emotional State (if patient has some kind of mental health issues like depression, dementia or anxiety)
There are several scales used in geriatric assessment in which they consist of a set of questions and/or some tasks depending on each scale and which area is assessed. An example of a scale that assesses the depression is the Yesavage scale in which consists of a list of questions for a Yes or No answer. An example of the questions asked:
• Are you basically satisfied with your life?
• Have you dropped many of your activities and interests? • Do you feel that your life is empty?
• Do you often get bored?
• Are you in good spirits most of the time?
Despite the many benefits and advantages in the continuous use of the CGA process, there are some limitations that, in some way, do not allow a better evolution of the process. Katie Palmer et al. made a study were they refer basically two major issues: firstly, there is a lack of standardization in the overall assessment and, secondly, there is also a lack of standardization in the care approach[9].
In Portugal, there is an association called Núcleo de Estudos de Geriatria da Sociedade Portuguesa da Medicina Interna (GERMI) that is dedicated to the study of Geriatric Medicine and spreading the concept of geriatrics across the country that currently is not very known and is not recognized as a specialty in national medicine. GERMI put together a set of different scales to make an overall geriatric assessment more adapted to the Portuguese reality[10]. Each scale has several questions and challenges that assess how the elder is in different domains like the described above. After the scale is complete, consonant the elder performance, the scale score is higher or lower, and there are different scores for every other scale. The lower the score, the worse is the person in that domain and there will be moments in which it is going to be necessary to prescribe some medicines to heal or improve the patient’s health.
Sometimes prescribing medication can be a complex task to perform on seniors, mainly because the older the person is, the more diseases the person is likely to have. This multimor-bidity makes the physician’s job harder and can lead to an error in the medical prescription and then to a bad reaction to a medicine for some conflict with another. The first step to reduce errors is to identify what causes the errors to happen. Dean B et al. searched exactly what mistakes are these and categorized in individual and team factors, patient-related factors, work-environment factors, and task-related factors[11] (Figure 2.1).
Figure 2.1: Categories of factors that can lead to prescription errors [12]
To reduce these errors, some techniques and methods exist to help and a study by Amanda H Lavan et al. listed some of these methods [12]:
• Education improvement • Medication reconciliation • Pharmacists
• Work environment improvement
• The role of information and communication technology • Prescribing-assessment tools
The method of the list with better results is Prescribing-assessment tools and within these tools, there are two that stand out: Beers criteria and Stopp/Start criteria.
2.1.2 Beers criteria
The Beers Criteria is a list of potentially inappropriate medication that should not be taken by older adults in most occasions or specific situations like in case of disease or some type of condition[13]. Formulated by a geriatrician called Mark Beers the criteria was first published in 1991 and currently is managed by the American Geriatrics Society. These criteria have some limitations, namely do not identify all existing cases, are not recommended in long term treatments and are not applicable for older adults receiving hospice or palliative care.
For a better understanding of these criteria, the following Figure 2.2 shows a practical example of a situation in which a few symptoms are manifesting in a patient that takes a certain medication present in Beers list[14].
Figure 2.2: Optimal use of the AGS 2015 Beers Criteria – A Case Example[14]
2.1.3 Stopp/Start criteria
Stopp/Start that stands for Screening Tool of Older Person’s Prescriptions (STOPP) and Screening Tool to Alert to the Right Treatment (START) was published for the first time in 2008. Since the first version, it was released several studies containing STOPP/START criteria have been published which makes these criteria very relevant to this category. It was applied in many countries divided by Europe, Asia, Australia, North America, and South America and an Australian study compared STOPP/START criteria with Beers criteria and concluded that STOPP/START was better represented in the number and scope of drug-related problems identified by pharmacists[15].
Denis O’Mahony et al. in a study about the STOPP/START criteria came to the conclusion that principally the list of potential prescribing omissions (START criteria) and the avoidance of mention of some Beers criteria drugs that are now absent from most European drug formularies are the main differences between STOPP/START criteria and Beers criteria[16].
2.2 Related Work
Technologies have known drawbacks and problems but when it is used to help the human being in aspects like its health become truly fascinating.
2.2.1 Mobile applications for healthcare professionals
Technology is increasingly present in medicine and a study by James Chase state that, in the United States of America, 99% of physicians use a desktop/laptop in the office, with 87% using a smartphone or a tablet device in the workplace[17]. A study made to health care professionals revealed efficiency in several mobile device functions namely, patient documentation, patient care, information seeking, and professional work patterns[18].
Nowadays there are apps for every possible and imaginary segment in health sector and these apps are distributed by the different app stores and they are so many that Apple’s App Store in 2011 created a section called "Apps for Healthcare Professionals” in their store and, at that time, was a unique feature among mobile app marketplaces[19].
The health care professionals use apps mainly for 5 purposes: administration, health record maintenance and access, communications and consulting, reference and information gathering, and medical education[20].
The next examples have been chosen in order to illustrate different approaches for each purpose and the very large number of apps available for different application areas within the same purpose.
For administration purposes beyond the usual ones like note apps or cloud storage apps (e.g. Dropbox or Google Drive), there are apps like ZocDoc (Figure 2.3) that allow the patient to view information and make appointments with doctors[21].
For health record maintenance and access, there are apps like PatientKeeper (Figure 2.4), that give the physician access to the patients’ data, or MobileMIM, that allow watching remotely x-rays and medical images[22]. Also, there is Teamviewer but this is not health-special but can also be used for access remotely data.
Figure 2.3: Zocdoc physician screen1 Figure 2.4: PatientKeeper patient screen2 In terms of communication and consulting purposes besides the basic and normal apps used by everybody such as either voice or video calling apps or text/multimedia messaging apps or email, there is a health care professional only social network app called Doximity and its described as "Facebook for doctors"[21].
In reference and information gathering there are three subdivisions: the first is literature research and review in which there are search engines facilitating the health care professional job like PubMed/MEDLINE and in mobile there are several: PubSearch, PubMed on Tap, Medscape, MEDLINE Database on Tap (MD on Tap or MDoT), Docxphin, Docwise, Read by QxMD, askMEDLINE, PICO, and Disease Associations[23]. The second subdivision is drug reference in which exists Epocrates, Skyscape RxDrugs/Omnio, and FDA Drugs allow users to check multiple drug-drug interactions at the same time[23]. Most of these apps work as a pocket-guide to help the physicians to have information in any place they are. Additionally, the authors of the most used drug reference app, Epocrates, in a survey found that 90% of physicians access drug information via a mobile app, and 40% use a mobile app once or twice
1https://www.zocdoc.com/ 2https://www.patientkeeper.com/
a day[24]. The last subdivision is news acquisition in which MedPage Today is the main app to get news but there are also "Outbreaks near me" that provide news consonant the user geography[21].
For patient management there is again some subdivision: first is clinical decision-making in which the following list shows that there are apps for every imaginary situation:
• Provide information on infectious diseases, pathogens, diagnosis, treatment, medications, differential diagnosis etc.[23]
• Make exams to visual acuity and color test(color blind) called EyePhone[23] • Helps diabetic patients by calculating bolus insulin dose called Diabeo • Measure tremor frequency called iSeismometer[20]
• An app that has 20 types of heart murmur and the doctor can make correspondence[20] • Predict pregnancy[20]
• Treatment guides[20]
• Medical calculators to determine some results and indexes for prevent purposes in some diseases like heart diseases or carcinogenic[23]
The second, subdivision is patient monitoring and the more common are patient’s health and location monitoring for chronic diseases like Alzheimer or for patients that were unable to reach traditional hospital-based rehabilitation[21].
For medical education and training reasons there are QuantiaMD that has an app that provides well-scripted interactive case studies that can be shared with colleagues[21] and for simulated surgery training, there are apps such as Touch Surgery or vCath[22].
To conclude, C. Lee Ventola’s study listed the main benefits that mobile devices or apps have for health care professionals namely, convenience, better clinical decision-making, as well as improved accuracy but also increased efficiency and to finish the enhanced productivity[20].
2.2.2 Geriatric Assessment Applications
Geriatrics being a medicine branch also is a branch in which some solutions were created in order to help health care professionals.
But here we must have very clear who is going to use the application, because if it is for older adults then are needed some cautions in the app elaboration. The first thought is to be aware of the seniors limitations namely, worse cognitive capacities, hearing loss, declining vision, some mobility decrease and they are not used to interactive systems[25]. To help deal with those issues, Lorenz and Oppermann listed the main design characteristics to have in mind when developing to seniors[25].
A survey on geriatric assessment applications was done to discover which solutions already exist in the market. The major two app stores, Google’s Play Store and Apple’s App Store, were the search center in which the following keywords were searched: "geriatric", "geriatric assessment", "cga", "avaliação geriatrica" and "geriatria". The selection criteria were if at least one of the next features: contain CGA assessment scales (if so, have or have not scale information) or have any clinical criteria.
Índices Dependencia (Figure 2.5) is a Spanish application that has 11 scales that assess mental, functional and social areas, but they are not grouped by areas. In terms of scales
information, it has good information about each scale about how to perform as well as the result interpretation. It can save the scales individually with a keyword.
Valoración de la Fragilidad (Figure 2.6) is also a Spanish app, includes functional, mental, social and nutritional scales, grouped by areas. It has all the app’s used bibliography but it has very few or nonexistent texts for the scales. It is possible to generate a PDF with the current session.
Figure 2.5: Índices Dependencia main screen3 Figure 2.6: Valoración de la Fragilidad main screen4
Exames Cognitivos (Figure 2.7) is a Brazilian app, contains mental and functional scales in which a doctor must make an account to use the scales, track the patient evolution with graphics help in each scale, but only for two patients(previously created but editable); for more is required to buy a subscription. There is scale information well detailed as well as a bibliography.
Plus65 Med (Figure 2.8) is a pocket guide, with origin in the International Islamic University Malaysia, for the STOPP/START criteria with the ability to search for a specific disease or drug with the respective references.
Figure 2.7: Exames Cognitivos patient screen5Figure 2.8: Plus65 Med with START criteria for Cardiovascular system6
Escalas Geriatricas (Brazilian) (Figure 2.9) has 5 scales, 2 functional, 2 mental and 1 nutritional, not grouped by areas. The app does not have any informational text on how the scale works, only have the result description.
OncoScale (Figure 2.10 ) is a French/Swiss app with functional, mental and nutritional scales with good text on how to perform and also a bibliography.
Figure 2.9: Escalas Geriatricas main screen7 Figure 2.10: Oncoscale main screen8 GeriatriApp (Figure 2.11) is a Colombian app with functional, mental and nutritional along with STOPP/START criteria. It comes with positive descriptions and references. It is not possible to save any data.
ElderCare (Figure 2.12) with origin in the United Kingdom has basically mental scales with quite sparse scale descriptions. It has guidelines to treat a stroke or an acute heart failure with good descriptions and references.
Figure 2.11: GeriatriApp main screen9 Figure 2.12: ElderCare scales screen10
3https://play.google.com/store/apps/details?id=gr.trevenque.indicadoresdependencia 4https://play.google.com/store/apps/details?id=com.escalasdefragilidad 5https://play.google.com/store/apps/details?id=br.com.digos.examescognitivos 6https://play.google.com/store/apps/details?id=com.mam.plus65 7https://play.google.com/store/apps/details?id=com.wecando.geriatria 8https://play.google.com/store/apps/details?id=com.agmmultimedia.oncoscale 9https://play.google.com/store/apps/details?id=appinventor.aihbautistam.geriatrics decision 10https://play.google.com/store/apps/details?id=uk.co.agnate.eldercare 12
App Main Features Language Scientific Promotor
Índices Dependencia - Scales assessment(mental, functional and social)- Save(manually) each scale individually for further consult Spanish GrupoTrevenque Valoración de la Fragilidad - Scales assessment(functional, mental, social and nutritional)- Generate a PDF with the current session result Spanish Angelini Exames Cognitivos
- Scales assessment(mental and functional)
- Save each scale for each patient and track patient’s evolution with graphics help(limited to 2 patients in free version)
- Generate each scale evolution graphics in PDF
Portuguese
-Plus65 Med - START/STOPP criteria English
-Escalas Geriatrica - Scales assessment(functional, mental and nutritional) Portuguese -OncoScale - Scales assessment(functional, mental and nutritional) French F. Hoffmann-La Roche GeriatriApp - Scales assessment(functional, mental and nutritional)- STOPP/START criteria Spanish Universidade Nacionalde Colombia ElderCare - Scales assessment(mental)- Guidelines to treat a stroke or a acute heart failure English Royal Cornwall Hospital Avaliação do Idoso - Scales assessment(functional, mental and nutritional)- Medical decision making tips Portuguese UFRGS/Ministérioda Saúde Brasileiro iGeriatrics - Beers Criteria English American GeriatricsSociety
Table 2.1: Overview of CGA mobile solutions and their functionalities
Avaliação do Idoso (Figure 2.13) is also a Brazilian app with functional, mental and nutritional scales with valuable information as well as references. It does not have the ability to save the data. It also has some tips for medical decision making.
iGeriatrics (Figure 2.14) the American Geriatric Society developed app, does not have scales but it is available the Beers Criteria.
Figure 2.13: Avaliação do Idoso main screen11 Figure 2.14: iGeriatrics main screen 12
The following Table 2.1 resumes the overall functionalities from the previous mobile solutions to CGA.
2.3 Mobile Applications Development
Nowadays it is very rare a person that does not have a cell phone or some kind of mobile device because there are solutions for everyone and every age, namely, for the older generations simple
11https://play.google.com/store/apps/details?id=br.com.sisqualis.AMI 12https://play.google.com/store/apps/details?id=com.usbmis.reader.dwtf1
cell phones and cell phone with bigger letters/numbers exist to facilitate the comprehension and the usage of the electronic device.
With the cell phone evolution, operating systems emerged so we could create a computer on a smaller scale and that basically fits in whatever pocket. With the operating systems, we can also create more solutions for the day to day problems through mobile applications. Thus, several operating systems exist to compete between each other to be elected by the consumer, but, overall, the main are Android and iOS, and Windows appears on a much smaller scale. In Portugal, according to StatCounter, in July 2019 the market was split in the percentages (Figure 2.15): Android - 74,95%, iOS - 24,46%, Windows - 0,29%, the remaining were split for others operating systems. Comparing worldwide, the percentages do not vary greatly (interval of 1-2% in Android and iOS).
Figure 2.15: Distribution of different operating systems in Portugal
2.3.1 Android
In October of 2003, Android Inc was founded, some time before the launch of the first iPhone with the revolutionary iOS, with the intuit of developing "mobile devices more intelligent that are more aware of the location and the preferences of the owner"[26].
In 2005, the company was bought by Google and took the decision to start developing with base on Linux what made that Android became Open Source, that is, that became available to every person/company use freely the Android. This decision made that, some time later, it was an explosion of Android in the market, arriving until, nowadays, as the big leader.
In terms of application development, it is totally free and with no restrictions and can be developed in any environment using a tool like Android Studio. These applications can be developed using mainly two programming languages: Java or Kotlin. In one hand, the Kotlin has as main purpose the interoperability, being able to use Java libraries without any problem,
and it is a really clean and concise language, but in the other hand, Java is a language with great prestige and with an endless number of libraries at its disposal. Therefore, the choice for either of the programming languages will always have pros and cons.
The Android for security reasons implements what they call the principle of least privilege, in which the app only can access to components required to do its work, for more it needs to ask for permission[27].
Android has 4 main app components and they are the essential building blocks and the entry point through which the system or a user can enter your app [27]. These components are: Activity, is the entry-point for the user to interact with the app’s interface, Service, is what is running in the background and can be used in many different ways, Broadcast receivers, is a component that allows you to register for system or application events, Content providers, manages a shared set of app data that you can store in a persistent storage location that your app can access.
2.3.2 iOS
It was in 2007, that the first iPhone was presented, being this one of the most important gadgets ever, that brought its operating system, the iOS, that revolutionized what until there was known. Apple’s operating system was presented as OS X and later with the launch of iPhone SDK, the name of the operating system was changed to iPhone OS[28].
This operating system is known for its speed due mostly to its simplicity, that is, comparing with Android it is cleaner which makes it less heavy. On the other hand, unlike its main competitor, iOS is restricted, that is, it is only possible to find in Apple devices because it is not Open Source, and one of the consequences is that the development of the applications for iOS has to be exclusively in MacOS. The mobile applications for this system could be developed in Objective-C and Swift, being the Objective-C already a legacy language, Swift will be in the future the main language, despite much use of the Objective-C.
2.3.3 Cross-platform Solutions
With the constant growth of technology, mobile applications are also constantly growing and nowadays there are already millions of applications divided for multiple application stores, like Google’s Play Store, Apple’s App Store, and Microsoft Store. Although the millions of applications, only a few are not developed for a specific environment namely for iOS or Android. However, this required an evolution of the development technologies, in which alternatives were created to the existing tools in which development only was allowed for heterogeneous environments. These alternatives were the cross-platform development frameworks in which through these we can reuse code for multiple environments. Then the development for multiple platforms became faster nevertheless robustly and efficiently. Despite their benefits, cross-platform solutions have some disadvantages. A recent study by Andreas Biørn-Hansen et al.[29] went through some of the cross-platform disadvantages via a survey questionnaire. The participants identified the following disadvantages: loss in performance comparing with native apps, in which it is referred some studies in which the loss exists but it is not catastrophically bad quite the opposite it is very acceptable although the loss
of performance it is notable as already said; User Experience and few options to create a good User Interface, but the study refer that this disadvantage is mainly noticed only in some frameworks, therefore the most important aspect to have in mind it is the choice of the framework to use; The cross-platform tools and their community lack of maturity is also pointed as a disadvantage.
From the several solutions that have emerged, there are mainly two that currently stand out: React Native and Flutter.
React Native, designed by Facebook, was launched in 2015 and was the first major solution to gain some notoriety, having many companies started using this solution, being that Facebook products such as Instagram and Facebook app use React Native as well as Skype, Tesla, Bloomberg among others. The programming language used is JavaScript. Flutter appeared in 2017, design by Google, although the first stable version only was released recently, end of 2018. The programming language used is Dart. Similar to the relation with Java and Kotlin in Android, here we also have a competition between the two that has advantages to either one of them, but React Native takes a little advance because the fact that exists longer than its competitor, gives an important point in terms of tool stability. An overall comparative table between the two technologies is present in Table 2.2.
React Native Flutter Programming Language JavaScript Dart
Release March 2015 December 2018 Created by Facebook Google
Open Source Yes Yes Native Code Generation Yes No
Access to Sensors
Libraries Available Example:
"React Native Sensors" - Accelerometer - Gyroscope - Magnetometer - Barometer Plugins Available Example: "sensors" - Accelerometer - Gyroscope
UI Application components look
just like native ones
Flutter apps look as good on the up-to-date operating systems as they do on older versions.
Table 2.2: Overall comparative table between React Native and Flutter
After a brief introduction, let’s understand the strengths and the weak spots on each of them. An article written for the blog Droids on Roids[30] went through the following advantages and disadvantages of React Native and Flutter.
Starting with Flutter and its advantages: has Hot Reload feature, this is a functionality that developers can use to see instantly any change that occurs in the code what makes much faster and dynamic development; the ability of making one codebase can cover more that one platform; With less code and one application for both platforms it brings a reduction
in the tests because some tests can be used for both platforms which save time; faster apps due to a library called Skia Graphics Library, what it does is the UI is redrawn each time when a view changes; has very appealing designs for the reason that Flutter does not rely on native components and it has custom widgets instead what causes a more user-friendly UI; another advantage is the UI is the same for all devices even the older ones; the last is the ability to create the most spectacular minimum viable product which is perfect for presentations, in short time. Flutter has disadvantages: Community size, although not being the greatest disadvantage is relevant because is recent and Dart does not have that many time for being already heavily used against the Javascript that is a very well established programming language but Dart is gaining more and more users every day; the existing libraries and support is impressive for its short time but it still lacks some richness in these fields; lacks continuous integration support for the main platforms like Jenkins; and to finish, the app size is bigger than the native ones.
Moving to React Native and its pros: also has the Hot Reload feature, the same codebase for both platforms and less testing as a plus; the fact that Javascript is the programming language is a huge advantage due to being a very known and used language; Developer freedom of choice, that means that the developer can choose whatever library to use in whatever you need to get done according to developer preferences; Relative maturity, already has 4 years since the launch and they had made the framework quite stable; it has an active and vast community, with so many developers and so many libraries and tutorials that ease the understanding of the framework; if the developer has some background in React then it is easy and quick to learn React Native due to the similarities; For the cons: despite of its native code generation the fact that it is not a real Native app makes the app with some disadvantages of a normal cross-platform solution as referred above like performance-wise; React has very few components ready to use, that means that if the developer want others than the available, it has to resort to other libraries to get those components; the Developer freedom of choice is an advantage but also a disadvantage in the way that sometimes it is hard to choose which solution is better for the development scenario; there are so many libraries and packages available and, because of that, some of them are abandoned or/and with low quality; the last disadvantage is common between Flutter and React Native and it is the size of apps, although React Native is working at the moment to reduce the size of their apps.
2.4 Web Applications Development
According to Internet Live Stats, there are over 1.7 billion websites right now online ready to be accessed by anyone.
Web development frameworks became popular and three types of frameworks were defined: server-side frameworks, concerns the whole website logic, i.e. security, handling data, among others; client-side frameworks, concerns the website interface; and, the last one, the full-stack frameworks that combine the two above.
A quick overview containing the frameworks that will be discussed further ahead is present in the table 2.3.
Framework Django Rails Laravel Spring Angular React Vue.js Type Server-Side Server-Side Server-Side Server-Side Client-Side Client-Side Client-Side
Programming Language Python Ruby PHP Java JavaScript JavaScript JavaScript
Open Source Yes Yes Yes Yes Yes Yes Yes
Release 2005 2005 2011 2002 2010 2013 2014
Community Good Strong
Good but less than
Django Solid Strong Strong
Popular but not as strong as the previous two
Size Heavy Heavy Heavy Heavy 500+ KB 100 KB 80 KB
Table 2.3: Quick Framework Overview
Starting with server-side frameworks, Django[31] is a backend framework in which Python is the programming language, Python itself is a very clean and popular language which makes the learning curve smoother. Being a popular framework with around 6 000 sites built with this framework[32], Django is known for its great scalability, its flexibility, as well as for superior security measures, extensive community and documentation.
Rails or Ruby on Rails[33], is a framework that uses Ruby as its programming language, which offers a very clean syntax. Rails framework is known for its massive community and for its large number of plugins available however speed is not its strength and it is the only drawback. Big websites like Airbnb or Github are some of the more than 700 000 websites[34] that use this framework makes this one of the most used frameworks.
Laravel[35] is a PHP based framework, which is a popular programming language, and is acknowledged having good ORM, powerful template system, a simple and fast routing system, and have good security measures. Compared with Django, Laravel has a steeper learning curve but it has good documentation and, in heavy projects, the performance is not as good. Laravel has more than 100 000 websites according to Builtwith[36].
Spring or Spring Boot[37], is a framework that uses Java as the programming language, and Java being one of the most used languages brings Spring a big advantage in a way that Java community is massive as well as the support and documentation. It is micro-services prepared which means that it is a very scalable framework.
Now, the client-side frameworks, all three (Angular, React, Vue.js) use JavaScript as the elected programming language[38].
Stack Overflow made a survey (Figure 2.16) with 90 000 developers and came that React is the most appreciated framework really close followed by Vue.js and Angular only appear in 9th place.
Starting with Angular, created by Google and released in 2010, used by Google in their Google AdWords applications, and also used by Apple and Microsoft, have a strong community and it was created to be used with Typescript. It is a very complete framework in utility terms like templates, routing and testing but this makes this framework the heaviest of the three. Also is the hardest of the three to learn due to a variety of different structures.
React, created by Facebook in 2013, is known for being highly dynamic and being used in high traffic websites like Whatsapp, Instagram and Netflix. It has a huge community and
Figure 2.16: Framework popularity survey results by Stack Overflow users[39]
good documentation. It is easy to learn due to its simplicity and the skills learned in React can be used in React Native. Unlike Angular, React is a very light framework but it does not have all the utilities as Angular so it needs other libraries to make the routing and other tasks, which make a very flexible framework.
The last one is Vue.js, it is a new framework but already with a big interest in the web community. Launched in 2013 by an ex-Google engineer called Evan You, and practically removed the drawbacks of the other frameworks. Used by Gitlab or Alibaba, Vue.js does not have a big community in top companies and this reflects on the few knowledge sharing available, although in the open-source community it has huge popularity. It is the framework that is easier to learn and has more people interested to learn, additionally has very good documentation. It is the lighter of the three, a little lighter then React, and also very flexible.
2.5 Previous Work
The present dissertation project uses and evolves a pre-existent work [40]. To better understand the departing point, the chapter offers a characterization of the previous solution.
2.5.1 Overview
In the previous dissertation project [40], the GeriatricHelper mobile app was developed, using a user-centred design approach, now we are going to overview each of the 4 interactions that took place.
The first prototype started with the technology choice, in which the author considered native or hybrid solutions and chose the native approach because he considered that the hybrid
approach had some security issues for some complex security measures and some limitations for sending information for an external server or backend.
This prototype was developed in order to achieve some requirements, more specifically, CGA assessments, create and manage patients, track patient’s progress through graphics, and must have some help topics for CGA and clinical criteria (Figure 2.18).
After the usability test to the first prototype, in the second prototype, some problems detected in the first prototype were solved and added some features like authentication. In order to increase usability, some changes were conducted such as adding notes and create a tab to show the last patients.
Some requirements were added to the initial list: personal area (authentication), see patient profile, adapted design for smartphones and tablets, new assessments creation, patient data classified, save patient information.
On the third prototype, some usability problems were corrected and several functionalities were added in order to improve the overall usability. This was the first prototype tested by healthcare professionals and here, the evaluators stated that they would prefer a simpler application, with fewer features. Also, they informed that in order to use personal medical data the app should be registered in CNPD.
For the last prototype, some scales were removed, those who were not validated by GERMI, also the fact that some liked the complex app made that the author has done some hidden features and could be shown by the user preference. A suggestion made by them that consisted of generating a PDF with the session result was also implemented. Beyond the previous ones, it was also included taking pictures in some scales, multiple languages and an app tutorial (Figure 2.17) to the requirements list. To finish, the personal area and the medical criteria were removed.
Figure 2.17: app tour guide depicting the
differ-ent CGA areas Figure 2.18: GeriatricHelper help topics
2.5.2 Architecture
The following figure 2.19, obtained from the dissertation document, shows the system archi-tecture made by the author.
Figure 2.19: System Architecture diagram from the previous implementation
This architecture has a Frontend component, containing both Android and iOS mobile applications, and a Backend component, having Firebase as the main responsible for all the actions that occurred in this component.
Inside the Backend component, within Firebase there are 4 more intervenients: Remote Config, Cloud Storage and Database, and Authentication.
The first one, Remote Config, was developed in order to push updates, like updating text, differentiating the app behaviour according to the user or configure new languages, and this way avoids to create a new release each time some were updated.
The storage was divided into the Cloud Storage and Database. The Cloud Storage was for saving pictures and videos that some scales needed to be saved and, also, the different language versions for the scales needed to be accessed by the application. The database was composed of two main modules, public and users. The public one is the information that can be accessed without being logged in. The user’s one is the data that can be associated with each user. In the user’s area, the data was subdivided into 5 tables: choices (scales), patients, prescriptions, questions, scales and sessions.
And the last one, Authentication, was a normal authentication module wherein the app any person can registry their own credentials and, after registering and logging in, the user has its data in the Realtime Database fetched.
2.5.3 Limitations with the existing implementation
The previous implementation has some limitations. Being a mobile app requires a mobile device, not provided in a medical appointment environment. Some physicians are available to use a personal phone, but some do not.
Also, being the apps native, when any new feature needs to be created this implies a lot of work because it is needed to be made in both platforms, Android and iOS, as well as the
maintenance for both platforms is more difficult.
To finish, something that is not necessarily a limitation is that since the beginning of the project until the end of the previous implementation, the requirements list suffered many changes which created a few unused implementations, i.e, many features were discarded but kept in the code as an archive, with possible reusing in mind, but is possible that none of that code will have use in a near future.
CHAPTER
3
System Requirements
This chapter describes the application domain and the system use cases as well as its requirements for both mobile and web new generation of the GeriatricHelper applications.
3.1 Domain activities and usage scenarios
Despite all the technology that already exists, the CGA is still mainly applied using paper support and, later, transcribed to the medical informatics information systems. Not all scales are applied to every patient because of the time that would take, which would be very expensive in several aspects. The only scales that are always evaluated are the functional ones and the remaining depend on the patient’s needs.
The assessment using the defined scales can be more practical with the support of a digital approach, which should be effective for the specificity of two different scenarios. The overall work scenarios are for the physician in or out the office and this requires a mobile and a web version for the new generation GeriatricHelper.
3.1.1 Outside usual medical appointment scenario
The first scenario is when the physician is in a non-office situation, which means, the physician does not have a computer or the paper scales questionnaires. Additionally, the place where the physician is at probably has no Wi-Fi or internet connection because maybe he/she is in a rural location. The objective here is to have a pocked-guide app to help in this situation, as provided by a "stand-alone" mobile application. The mobile application can be useful for this situation in which the physician wants to make a quick CGA without having any additional tools.
3.1.2 Medical appointment scenario
The second scenario is when the physician is in the office containing all the traditional tools, like the desktop computer, and the doctor wants to evaluate the usual functional scales and also the nutritional scale because he/she thinks the patient is, for example, too thin. After
the scales assessment, the physician needs to prescribe medicines, for example, to increase the patient’s appetite. For a better understanding by the patient, the physician wants to make a treatment guide containing the medication and the different intakes along the day for each one. This scenario requires to use the desktop computer to facilitate the physician’s job and to make the most advantage of working tools that are already given and dismiss others like the paper questionnaires. The desktop computer usually has an internet connection and the purposed solution is to have a web version of the previous mobile application with advanced features that makes sense for this scenario, like the treatment guide generation.
3.2 Requirements for the GeriatricHelper mobile app
The mobile solution proposed, GeriatricHelper, aims at being a pocket-assistant application to help the doctors perform CGA. The main users to this app are going to be the geriatric physi-cians that need to execute CGA and, for that, the Table 3.1 has the functional requirements to the mobile app.
Use Case Description
Perform CGA evaluations Physician create new assessment session
Consult CGA guide Physician consults the CGA guides in each scale info button, browsing informationabout a certain scale. Export results report Physician generates a report containing the result of a CGA session.
Table 3.1: Use Cases of the mobile application
The "Perform CGA evaluations" use case implies a set of scales (composed with a set of questions) that the doctor must ask the patient or make the task requested in the scale and fill the scale with the patient’s answers. Some examples of the task that can be asked are: to tell what an object is, showing a picture (pictures present in the GeriatricHelper app); give a paper and ask to pick with one specific hand. The system has the scales presented in Table 3.2
Area Scales
Functional State - Katz Scale- Lawton & Brody Scale
Affective state - Yesavage Geriatric Depression Scale: Short Version
March - Holden March Functional Classification
Cognitive state - Mini-Mental State Examination(Folstein) Nutritional state - Nutritional Assessment: Global Evaluation- Nutritional Assessment: Screening
Table 3.2: CGA scales present in GeriatricHelper
For the "Consult CGA guide" use case it needed CGA explained and how to perform it for physicians that are not so familiarised or not as experts with CGA and need a little help. In each scale contains information about the respective scale that is relevant for physicians.
The "Export results report" use case demands the creation of a PDF document containing the CGA session results for an afterward share, print or send via email.
Besides the functional requirements, also are needed some non-functional requirements in order to apply some restrictions on how the app is supposed to be instead of how is supposed to do like in the functional requirements.
The GeriatricHelper non-functional requirements are listed below:
• Easy to maintain and easy to add new features, with one code base must be able to support Android and iOS.
• Work offline, the data must be available even when there is no Internet connection because this mobile app is not to be used at the doctor’s office.
• Do not collect patient identities, any medical data must be confidential and the better way to be confidential is to having nothing that can be associated to the patient in a way that can be identified.
• Previous work continuation, namely in terms of the functionality and user experi-ence.
3.3 Requirements for the GeriatricHelper web app
In terms of functional requirements, besides those of the mobile application, these are web-specific ones, presented in Table 3.3 (some mobile are present again because they also apply to the web):
Use Case Description
Perform CGA evaluations Physician create new assessment session
Consult CGA guide Physician consults the CGA guides in each scale info button,browsing information about a certain scale. Export results report Physician generates a report containing the result of a CGA session. Prescribe medicines Physician has a module in which s/he can prescribe drugs for the patientfor the different intakes along the day List of medicines already prescribed Physician must be able to use the drugs already prescribed beforewhen prescribing and to consult the list containing these. Export treatment guide Physician generates a treatment guide containing the drugs prescribed.
Table 3.3: Use Cases of the web application
For the "Prescribe medicines" use case, it is needed to have a page apart from the CGA scales in which the physician has the possibility to prescribe medicines to the patient.
The "List of medicines already prescribed" use case, demand the storage of the prescribed medicines to help the doctor being quicker to prescribe drugs that have been already prescribed before and also be able to manage that list.
The "Export treatment guide" should create a PDF document that works as a treatment guide containing the prescription made by the physician for the different intakes along the day.
Relative to the non-functional requirements, compared to mobile non-functional require-ments only have one in common (for purposes of non-repetition the description will not be present), being the list present next:
• Do not collect personal data.
• Reuse most of what has been implemented in mobile, avoiding creating the website from scratch.
• Last used medicines available for all the physicians, the data must be available in realtime for every physician and right after new drugs were prescribed.
• PDF more complete, GERMI requested a PDF with more detail for each scale.
CHAPTER
4
Implementation
This chapter presents the proposed architecture and data model for the system, and also the methods used in the GeriatricHelper implementation for the mobile and web versions.
4.1 System Architecture
The system architecture (Figure 4.1) has 3 major components that make the system, the mobile component that contains both Android and iOS applications and they work as the entry points to the system via mobile devices; the web component has the web application and work as the entry point to the system via desktop and personal computers, and the final component is the backend component that accommodates the databases that provide data storage and later data fetching.
In the Backend component, there are two different databases: Firebase and Redux. The Firebase is only linked to the web component due to the fact that only the web version has the Prescription feature and the Firebase is for saving the history of drugs that have been prescribed and must be available for other users. On the other hand, Redux works as the database for saving all the data that is user exclusive namely scales information and, in the mobile version, pdf information.
Figure 4.1: System Architecture
4.2 Rengineering the Geriatric Helper Mobile Application
The existing version of Geriatric Helper has been natively developed and deployed for Android and iOS. While this scenario served the first stages of work for supporting CGA, enabling a first validation of the concept, the resources required to maintain an updated version of the app for both platforms is high. This results from the need to double the development work whenever a new feature is added or updated, to address both platforms. Thus, the new mobile application was developed because it was felt the need to redo the mobile application due to the fact that the resources required to maintain an updated version of the app for both platforms is high and, for future new features would require a lot of work because it would be necessary to develop the feature for iOS and Android. Therefore, the first stage of our work consisted in the proposal and implementation of a novel approach that would optimize development resources while maintaining the support for multiple platforms.
To overcome these limitations were chosen the cross-platform solutions and the technology elected was React Native to the detriment of Flutter because, at the time of starting developing the app, Flutter had been released recently and React Native is older and more stable than Flutter, plus it has the advantage that after developing, some aspects can be reused to web apps more specifically ReactJS.
In terms of mobile app design, it was intended to keep the same design in order that users from the previous version, know how the app works and avoid the relearning on how to use the app all over again. With that being said, an app was developed in order to look as similar as possible with the existing components (Figure 4.2).
In order to reproduce the scale’s design more precisely, the scale’s question and answers display and, for this purpose, Radio Buttons were needed in which, with the help of the library "react-native-radio-buttons-group", resulted in the screen that can be viewed in the Figure 4.3. Initially, to save the app’s data it was thought that the React component State would be sufficient for all the data but as data become more complex was elected the Redux as the local database. The main problems that occurred with the State component were the constant delay on data updating, due to the fact that the setState method (used to update
Figure 4.2: GeriatricHelper scales screen Figure 4.3: Lawton & Brody scale screen
data natively) does not update immediately the data instead creates a pending state transition. This delay could not be supported because it was needed an instant update for scales. This topic is discussed with more detail in the Data Model section latter.
With all the scales design and functionalities completed the next step was to make the scale’s result screen in which you have a PDF generated with the results from the CGA session. For this screen, was used "react-native-pdf-lib" library that from all the existing ones was the only one working for this project although this library is not very easy. The reason why it is not easy is that for every text that you want to put on the PDF it is needed to situate in the x and y axis of the PDF. To create a template for this was quite challenging because it was needed to place every single line in a specific x and y coordinate, this limit the PDF in a way that if is needed a more complete one, is not easy to make.
Compared with the previous implementation, some changes occurred, nothing much significant, namely: the previous implementation had a screen containing all the theoretical text, also present in the respective scale info button, that was removed and now is only present on the scale’s info buttons; the former app, when the user first opened the app, had an initial tutorial explaining all the app’s functionalities which were not reproduced in this mobile solution; the flow to the session’s results screen from the prior implementation was changed because accessing this screen was not intuitive because the user needed to press "back" to access this screen which means that, if the user does not know the app, would be lost. The solution was to create a new screen for the results (previously was in the initial/home screen) and when some scale has already been completed it appears a button to finalize session. This brings a more fluid and intuitive flow to the app. In this screen (Figure 4.4) it shows the PDF generated; to download and to view the PDF in PDF-specific apps (with more functionalities like sharing, print, among others) there is a button with PDF symbol.
Figure 4.4: Results screen for a CGA session
Feature Previous Implementation Current Implementation
CGA scales(7 scales) Yes Yes
BMI calculator Yes Yes
Session’s result PDF Yes Yes
Help-specific area Yes No
Help for each scale Yes Yes
App tutorial Yes No
Return to session after finished No Yes
Table 4.1: Differences between previous and current implementation
4.3 Web Application
We choose to make the website in ReactJS because the intention was to reuse what was done in the mobile application, not only some code but the thinking, that in React Native is the same as in ReactJS in order to save some time either in programming or in learning a new development framework.
For the website design, we wanted to make the most similar possible to the app in a way that any user that used the previous version could navigate and use the website naturally. Therefore, the scale type cards, scale name cards, and the scales answers display are pretty similar to the app, only in website size. After a scale is completed, in the initial scales page for each scale that has already been completed a tag is added to the scale type card in order to help the user to know what is already have been done (Figure 4.5). The library used for the design elements was material-ui.
Figure 4.5: Scales Type Page
Each scale has a set of questions and multiple answers for the question and, as well as in mobile, is used a set of Radio Buttons to display each answer (Figure 4.6).
Figure 4.6: Lawton & Brody Scale Page
For adapting the mobile design to the web, we created a toolbar that is present in all the pages of the website. Although the necessity first emerged when in the Nutritional State page it has a body mass index calculator and to stick with where it was in the mobile version, a toolbar was required. This toolbar has a breadcrumb menu, along with a back arrow, to help the website navigation become more intuitive and easy.
The library used to generate PDF on the web is much easier than the one used on mobile. The main difference is the documentation and examples existing to this web library which