A
CADEMIC
M
EDICAL
C
ENTER
D
EPARTMENT OFM
EDICALI
NFORMATICSMaster Thesis
Mobile support for
ambulatory multidisciplinary teams
in mental healthcare
A user-centred approach for requirements gathering
L.J.M. Heerink BSc.
Mobile support for ambulatory multidisciplinary teams in mental
healthcare
This master thesis provides the literature review, methodologies, results and conclusions of the Scientific Research Project which I carried out at PinkRoccade Healthcare. This thesis is the final product of a two year academic Medical Informatics masters programme at the Academic Medical Center (AMC), the medical faculty of the University of Amsterdam (UvA).
Student BSc. L.J.M. (Lisette) Heerink Student ID number: 10995161 E-mail: lisetteheerink@hotmail.com SRP Mentor ir. L. Kemp
User Experience Designer PinkRoccade Healthcare Business Unit GGZ SRP Tutor Dr. F.J. Wiesman Assistent professor Faculty of Medicine
Department of Medical Informatics
Academic Medical Center - University of Amsterdam
Location of Scientific Research Project
PinkRoccade Healthcare Business Unit GGZ Fauststraat 3 7323 BA Apeldoorn
Practice teaching period
Table of Contents
Acknowledgement 4 Abstract 6 Samenvatting 7 1 Introduction 8 1.1 Background information . . . 8 1.2 Problem description . . . 91.3 Objective and research questions . . . 11
1.4 Outline of the thesis . . . 11
2 Methods 12 2.1 Requirement elicitation . . . 12
2.2 Requirement analysis . . . 12
2.3 Requirement specification . . . 13
2.4 Requirement validation . . . 13
3 Care processes within the FACT working method 14 3.1 Method . . . 14
3.2 Results . . . 15
3.2.1 Main care processes . . . 15
3.2.2 Treatment . . . 16
3.2.3 Evaluation . . . 18
3.3 Conclusion . . . 18
4 Converting end user needs to requirements 20 4.1 Method . . . 20
4.1.1 Questionnaire . . . 20
4.1.2 Observations . . . 22
4.1.3 Converting data to needs . . . 22
4.1.4 Converting needs to requirements . . . 22
4.2 Results . . . 23
4.2.1 Calendar . . . 25
4.2.2 Contact details and communication . . . 28
4.2.3 Patient related information . . . 30
4.2.4 Reminders . . . 35 4.2.5 FACT-board . . . 35 4.2.6 Technical related . . . 37 4.3 Conclusion . . . 38 5 Prototyping 40 5.1 Method . . . 40 5.2 Result . . . 41
5.2.1 Menu structure of the prototypes . . . 41
5.2.2 Core functionalities of the prototypes . . . 42
5.3 Conclusion . . . 44 6 Requirements validation 46 6.1 Method . . . 46 6.1.1 Participant selection . . . 46 6.1.2 Task allocation . . . 46 6.1.3 Data collection . . . 46 6.1.4 Data analysis . . . 47 6.2 Results . . . 49 6.2.1 Calendar . . . 49
6.2.3 Patient related information . . . 51
6.2.4 Reminders . . . 52
6.2.5 Data on the FACT-board . . . 53
6.2.6 Technical related . . . 53
6.3 Conclusion . . . 53
7 Comparing satisfaction with the prototypes and the currently used EHR 54 7.1 Method . . . 54 7.2 Results . . . 55 7.2.1 Overall satisfaction . . . 56 7.2.2 System usefulness . . . 57 7.2.3 Information quality . . . 57 7.2.4 Interface quality . . . 57 7.2.5 FACT-board prototype . . . 58 7.3 Conclusion . . . 58
8 Discussion, recommendations and conclusions 60 8.1 Discussion . . . 60
8.1.1 Principle findings and relation to existing literature . . . 60
8.1.2 Strengths and limitations . . . 61
8.2 Recommendations . . . 63
8.3 Conclusions . . . 64
References 66
Appendices
A Description and BPMN diagrams of the FACT care processes . . . A-1 B Questionnaire . . . B-8 C Requirement prioritization method . . . C-30 D Requirement based prototypes . . . D-31 E Requirement validation . . . E-43 F Satisfaction with the currently used EHR and prototypes . . . F-56 G Supplementary data files . . . G-62
Acknowledgement
This thesis is the final result of my scientific research project about mobile support for ambulatory teams within the mental healthcare. This thesis allowed me to combine my interest in performing end-user research and designing solutions to improve healthcare. I would like to express my gratitude to everyone who supported me during the completion of this thesis.
First, I would like to express my sincere gratitude to my mentor Laurens Kemp at PinkRoccade Healthcare for guiding and directing my scientific research project. Your critical eyes and perfectionism really contributed to the quality of this thesis. Thanks for all your advice, feedback and help during this period whenever I needed it. I would also like to express my gratitude to my tutor Floris Wiesman. Your critical thoughts and suggestions during the meetings we had contributed to the scientific level of this thesis. Furthermore, I would like to thank PinkRoccade Healthcare for providing this project and all the colleagues of the business unit GGZ who helped me during this period. Special thanks to the mobility team for all your support and the discussions we had. It was a pleasure to be part of this team.
Moreover, I want to thank Remmers van Veldhuizen for his interest in my project. I appreciate your feedback on the questionnaire and your help with distributing the questionnaire on the websites of ‘F-ACT Nederland’ and the ‘Centrum Certificering ACT en FACT’ (CCAF).
However, without all mental healthcare providers (FACT-members) who participated in this study, this thesis would not have been possible. I would like to express my deepest gratitude to all who took time out of their busy schedules to participate in the questionnaire, observations or interviews. You gave me in-depth insight into the FACT way of working and your highest needs. I have a great respect for how you manage to help people with their mental problems in their own environment, without even having access to all the information you need. Hopefully, the results of this thesis will contribute to a mobile solution which can support and relieve you.
Finally, I would like to thank my parents for all the years you have supported me in everything I did. In addition, a very special thanks to my boyfriend Omar for always being there for me. Without your support, your positivism and your help, this thesis would not be there.
Lisette Heerink July 2017
Abstract
Background
The Dutch mental healthcare system has been changed over the last years. Cost reductions and new insights into how good quality mental healthcare should be delivered, have resulted in an increasing number of multidisciplinary Flexible Assertive Community Treatment (FACT) teams operating in the Netherlands. FACT-teams provide long-term ambulatory care of at least two years to around 200 to 220 severely mentally ill patients within a region of around 40,000 to 50,000 inhabitants. As a result, mobile EHR support is becoming increasingly important to support FACT-teams in their daily activities. However, until now, no end-user research has been performed about end-users’ needs for such a mobile application. The aim of this study is to provide an in-depth insight into the end-user requirements for a mobile application to support FACT-teams in their daily operations.
Methods
A literature review was used to determine which care processes should be supported by the mobile application. Next, end-user’s required functionalities for the mobile application were derived from this review, a questionnaire, and non-participant observations. The requirements were prioritized according to the MoSCoW method and were strongly related to the reported frequency of each requirement. Requirements were validated by means of two high fidelity interactive prototypes which were used during semi-structured interviews with end users. End-user satisfaction ratings of the prototypes were assessed by means of the CSUQ questionnaire and were compared to the satisfaction ratings of the currently used EHR.
Results
The literature review found that the mobile application should be confined to the functionalities related to the treatment and evaluation processes. This was confirmed by the results of the questionnaire and observations. All reported functional end-user needs were related to the treatment and evaluation process. The required functionalities were categorized into: calendar, contact details and communication, patient related information, FACT-board, reminders and technical related needs. In total, 79 main and 148 validated sub requirements were found. The most required ambulatory functionalities according to end users include a full functioning calendar that synchronizes with the EHR; access to contact details of people within the patient’s network; access to the patient’s medication, reports, and treatment plan; and the possibility to complete ROM questionnaires. Furthermore, creating to-do lists and an emergency button were important functionalities to support the ambulatory way of working. Although the FACT-board was initially found to be important, no ambulatory need was found after the validation. Non-functional requirements as described by the ambulatory mental healthcare providers were related to usability, performance, security and interoperability. The mobile application should be easy to use, the time it takes to log on should be short and the mobile application should respond fast. Furthermore, the mobile application should be highly secured to protect patient related data and should synchronize data between the mobile application and the EHR. The appropriateness of the requirements was confirmed by high end-user satisfaction ratings with the requirement based prototype. Participants who validated the prototype were significantly more satisfied with the prototype compared to the currently used EHR. On a scale from 1 to 5, the overall end-user satisfaction increased from 2.5 to 4.5 (p < 0.001; n=20).
Conclusion
The increasing number of ambulatory multidisciplinary FACT-teams in the Dutch mental healthcare has resulted in a high need for mobile support during their ambulatory activities. This is the first research available about the requirements of ambulatory mental healthcare providers for such a mobile application. In this study validated end-user requirements were specified and translated into a prototype of a mobile application. The high satisfaction ratings with the prototype confirmed that the interpretation of the end-user needs was essentially correct. This prototype has the potential to better support FACT-members in the treatment and evaluation processes, thereby increasing their efficiency.
Keywords
Samenvatting
Achtergrond
De Nederlandse geestelijke gezondheidszorg is de laatste jaren aan het veranderen. Bezuinigingen en nieuwe inzichten in hoe kwalitatieve zorg zou moeten worden geleverd hebben geleid tot de opkomst van multidisciplinaire Flexible Assertive Community Treatment (FACT) teams. Deze teams verlenen langdurige ambulante zorg van tenminste twee jaar aan 200 tot 220 patiënten met ernstige psychiatrische aandoeningen binnen een regio van 40.000 tot 50.000 inwoners. Als gevolg wordt mobiele EPD-ondersteuning steeds belangrijk is om FACT-teams in hun dagelijkse activiteiten te ondersteunen. Echter, tot op heden is er geen eindgebruikersonderzoek gedaan naar de behoeften voor een dergelijke mobiele applicatie. Dit onderzoek bevat een uitgebreide analyse naar de eisen van de eindgebruikers voor een mobiele applicatie om FACT-teams in hun dagelijkse activiteiten te ondersteunen.
Methoden
Een literatuurstudie is uitgevoerd om te bepalen welke zorgprocessen moeten worden ondersteund door de mobiele applicatie. Vervolgens zijn de behoeften van de eindgebruikers bepaald aan de hand van deze literatuurstudie, een enquête en observaties. De eisen die zijn gespecificeerd op basis van deze behoeften zijn geprioriteerd aan de hand van de MoSCoW methode. De prioriteit is sterk gerelateerd aan de gevonden frequentie waarmee behoeften werden genoemd. De eisen zijn gevalideerd met eindgebruikers door middel van twee high fidelity interactieve prototypes die gebruikt zijn tijdens semigestructureerde interviews. De CSUQ vragenlijst werd gebruikt om de tevredenheid met het prototype te beoordelen en werd vergeleken met de tevredenheid met het huidige EPD.
Resultaten
Uit de literatuurstudie bleek dat de mobiele applicatie beperkt moest worden tot de functionaliteiten gerelateerd aan de behandel- en evaluatieprocessen. Dit werd bevestigd door de resultaten van de enquête en de observaties. Alle door de eindgebruikers vereiste functionaliteiten waren onderdeel van de behandel- en evaluatieprocessen. De gevonden functionaliteiten werden gecategoriseerd in: agenda, contactgegevens en communicatie, patiënt gerelateerde informatie, FACT-bord, herinneringen, en technische eisen. In totaal werden er 79 hoofd- en 148 sub-eisen gespecificeerd na validatie. De belangrijkste ambulante functionaliteiten volgens de eindgebruikers omvatten een volledig functionerende agenda die synchroniseert met het EPD; toegang tot contactgegevens van personen binnen het netwerk van de patiënt; toegang tot de patiënt zijn medicatie, rapportages, en behandelplannen; en de mogelijkheid om ROM vragenlijsten in te vullen. Verder werden een to-do lijst en een noodknop belangrijke geacht om de ambulante manier van werken te ondersteunen. Alhoewel het FACT-bord in eerste instantie belangrijk leek, bleek er na validatie geen ambulante noodzaak voor te zijn. De genoemde niet functionele eisen hebben betrekking op gebruiksvriendelijkheid, prestaties, beveiliging, en interoperabiliteit. De mobiele applicatie moet eenvoudig te gebruiken zijn, de eindgebruiker moet snel kunnen inloggen, en de mobiele applicatie zelf moet snel zijn. Verder moet de applicatie streng beveiligd zijn om privacygevoelige informatie van de patiënt te beschermen. Daarnaast moeten gegevens worden gesynchroniseerd met het EPD. De juistheid van de eisen werd bevestigd door de hoge tevredenheid onder eindgebruikers met de prototypes. Eindgebruikers die de prototypes valideerden waren hier significant meer tevreden mee dan met het EPD dat ze dagelijks gebruikten. Op een schaal van 1 tot 5 steeg de algehele tevredenheid van 2,5 naar 4,5 (p < 0,001; n=20).
Conclusie
Het stijgende aantal ambulante, multidisciplinaire FACT-teams in de Nederlandse geestelijke gezondheidszorg heeft geleid tot een hoge behoefte aan mobiele ondersteuning tijdens de dagelijkse activiteiten van FACT-teams. Dit is het eerst beschikbare onderzoek naar de eindgebruikersbehoeften van ambulante, multidisciplinaire FACT-teams in de GGZ. In dit onderzoek zijn gevalideerde eisen voor een mobiele applicatie gespecificeerd en vertaald naar een prototype van een mobiele applicatie. De hoge eindgebruikerstevredenheidsscores voor het prototype bevestigden dat de interpretatie van de vereisten correct was. Dit prototype heeft de intentie om de FACT-behandelaren beter te ondersteunen in de behandel- en evaluatieprocessen, en hiermee de efficiëntie te vergroten.
Keywords
Geestelijke gezondheidszorg (GGZ), FACT, ambulant, eisen, mobiele ondersteuning, eindgebruikersonderzoek
1 INTRODUCTION
1
Introduction
1.1
Background information
According to the NEMESIS-2 research performed by the Dutch Trimbos Instituut, 43.5 percent of the Dutch adult population aged 18 to 64 years, has had a mental disorder in their life (De Graaf et al., 2010). In 2014, a total of 1.2 million patients were treated in the Dutch mental healthcare, of whom around 736,000 patients were treated in the specialized mental healthcare (Zorgprisma Publiek Vektis, 2015). Delespaul and de consensusgroep EPA (2013) estimated the number of patients with severe mental illnesses in the Netherlands at 216,000. Since 2002, FACT-teams deliver ambulatory care to patients with severe mental illnesses.
FACT is defined as Flexible Assertive Community Treatment (van Veldhuizen et al., 2008). Initially, FACT-teams were introduced as a result of new insight in high quality healthcare. A stay at a clinic was found to be non-beneficial for the quality of life, treatment and rehabilitation of the patient, since patients are separated from their own environment (Projectgroep Plan van Aanpak EPA, 2014). In addition, patients with severe mental illnesses have a strong preference for independent living and ambulatory assistance (Trimbos Instituut, 2012). While reducing symptoms was the primary aim of the Dutch mental healthcare, these new insights have shown that more support was needed to be able to participate in society. Furthermore, good care for people with severe mental disorders should be characterized by an integrated care approach in which both treatment, rehabilitation, and somatic care are involved (Van Hoof et al., 2015; Projectgroep Plan van Aanpak EPA, 2014; Ministerie van VWS, 2012). FACT-teams organize care around the patient and are able to deliver this type of care.
A FACT-team is a multidisciplinary ambulatory team consisting of 10 to 11.5 FTE providing long-term care (at least 2 years) to around 200 to 220 severely mentally ill patients within a region of around 40.000 to 50.000 inhabitants (van Veldhuizen et al., 2008). Beside psychiatric problems, these patients have many limitations in their social functioning, such as difficulty with housing, self-care, employment, education, and finances (Projectgroep Plan van Aanpak EPA, 2014). Their support systems and contacts are often limited. Members from a wide variety of disciplines are needed to provide treatment to patients with their psychiatric problems and symptoms, but also to support them in their daily life tasks. Therefore, the team may consist of psychiatrists, psychologists, community psychiatric nurses, nurse practitioners, case managers, peer support workers, agogic workers (e.g. social worker), addiction experts, employment specialists or rehabilitation specialists. FACT-teams provide care to the group of people who previously have been admitted to psychiatric hospitals and can now function independently in the society with adequate support and treatment. They provide care to the 20 percent of the most severe cases, but also to the other 80 percent who need less intensive treatment and support.
FACT-teams are "flexible" because of their ability to switch between two modes of care delivery: (1) individual case management, (2) and intensive (ACT) team care. For more stable long-term patients, FACT provides coordinated multidisciplinary treatment and care by individual case management. In this case, one team member is responsible for the organisation of care around the patient. This team member, may also request other team members to deliver care to a patient when needed. A psychiatrist is always involved. Unstable patients at risk of relapse are followed with intensive (ACT) care by the same team. In this case, the team adopts a shared caseload approach for the group requiring intensive care. Patients requiring intensive care are listed on a digital FACT-board. Every morning, the team meets to discuss the patients listed to decide which form of care should be provided and which team member will visit which patient. The FACT-team will switch to individual case management when a patient no longer belongs to one of the groups that are supposed to go on the FACT-board. Patients who receive individual support are not listed on the FACT-board. The FACT-team will switch to intensive team care if the situation worsens (van Veldhuizen et al., 2008). In both situations, care is provided at the patient’s place of residence. The growth of FACT-teams since 2002 drew the attention of insurers and policy makers. Mental healthcare expenses in the Netherlands have been rising from 3.4 billion euros in 2002 to 6.3 billion in 2011. While the mental healthcare was responsible for 5.9 percent of the total healthcare expenses in 2002, this has increased to 7.1 percent in 2011 (Centraal Bureau voor Statistiek, 2016). These expenses are high because of the relatively large inpatient capacity compared to other countries. In 2009, the Netherlands had 139 beds per 100,000 population excluding sheltered housing according to the Organisation for Economic Cooperation and Development (OECD, 2014).
1 INTRODUCTION 2002 2012 2016 2020 FACT-team
1
300
FACT-teams 200937,255
Inpatient bedsInstitutionalization Ambulatory care
30%
Inpatient beds Agreements
Figure 1.1: Important developments within the Dutch mental healthcare
Verbeek et al. (2015) reported a total inpatient capacity of 37,255 beds including sheltered housing facilities (Verbeek et al., 2015). As a result, at least half of the mental healthcare expenses are spent on inpatient mental healthcare (Trimbos Instituut, 2012). To prevent a further rise in the mental healthcare expenses, the government believes that there is a need to intervene in the rising costs. FACT-teams appeared to be an option for higher quality care which was less clinical and possibly cheaper as well (van Veldhuizen et al., 2008).
Therefore, in 2012, agreements were made between the trade organisations, the Ministry of Health, Welfare and Sports (VWS), healthcare providers, healthcare insurance companies, and patient and family organisations, aimed at ensuring high quality and financial affordable mental healthcare. To accomplish this, it was agreed that the number of beds within mental health institutions should be reduced by a third in 2020 compared to the number of beds in 2008 (Ministerie van VWS, 2012). This means around 10,000 beds, potentially saving 1 billion euros in expenses (Trimbos Instituut, 2012). Further, agreements were made to substitute inpatient care with ambulatory care (Ministerie van VWS, 2012). In 2012, the Council for Health and Society (Dutch: "Raad voor Volksgezondheid en Samenleving, RVS") proposed to increase the number of certified ambulatory FACT-teams to between 400 and 500. Increasingly, health insurers have included in their terms the recommendation or obligation for mental healthcare organisations of having certified FACT-teams. Both the higher demand for ambulatory care and new insights have led to the growth of FACT-teams in the Netherlands. In 2016, around 300 teams were certified by the CCAF (CCAF, nd). Figure 1.1 provides a short overview of the important developments within the Dutch mental healthcare. FACT-team members have to register all their activities in the Electronic Health Record (EHR). The GGZ business unit of PinkRoccade Healthcare is the market leader in the Dutch mental healthcare with their Electronic Health Record (EHR) called mijnQuarant. This desktop application supports all mental health staff in the entire care process. This means both support for the primary care processes as well as administrative functionalities. However, mijnQuarant does not support mobile working, which is important for providing ambulatory care. Therefore, PinkRoccade Healthcare developed mijnQuarant Onderweg as an extension of mijnQuarant. This extension supports mobile working, but is a limited version of mijnQuarant in which simple registration of basic care is possible. Appointments and reports created with mijnQuarant Onderweg are directly accessible via mijnQuarant and vice versa. However, mijnQuarant Onderweg has only just been released in the market.
1.2
Problem description
Because of the transition of inpatient care to ambulatory care over the last years, the number of ambulatory FACT-teams is growing. Currently, PinkRoccade Healthcare provides around one-third of all 300 certified FACT-teams with their current EHR solution called mijnQuarant. However, ambulatory mental healthcare providers are facing multiple problems related to mijnQuarant. First, mijnQuarant is not prepared for ambulatory work, since mijnQuarant is a desktop application and does not support mobile access. Second, mijnQuarant is too complex for the ambulatory mental healthcare worker. It has many functionalities and
1 INTRODUCTION
therefore supports all mental healthcare staff in the entire process. As a result, in-depth training is required and end-users are experiencing usability problems resulting in low satisfaction ratings. mijnQuarant Onderweg does support ambulatory work with mobile working support. However, it does not support all daily operations, making concurrent usage of both software solutions necessary. With an increasing number of operating FACT-teams in the Netherlands working with mijnQuarant, PinkRoccade Healthcare has set a goal to work towards a software solution to optimally support them. Since redesigning a whole EHR is costly, PinkRoccade Healthcare has opted to develop separate applications next to their main product, mijnQuarant. One of these applications would be a specific "FACT" application which should be highly simplified and should provide only the functionalities that are needed to support ambulatory FACT-teams in their daily operations. However, until now no end-user research had been performed about end-users needs for a new mobile application. Without a thorough understanding of the end-users’ needs, there will be a high chance that the new application will not be accepted by mental healthcare providers within FACT-teams, resulting in an application that will not be used.
A well-known model related to technology acceptance and use is the Technology Acceptance Model (TAM), originally proposed by Davis in 1986 (Davis, 1989). According to TAM, perceived usefulness and ease of use are the most important determinants of actual system use. Davis (1989) defined perceived usefulness as "the degree to which a person believed that using a particular system would enhance his or her job performance". Perceived ease of use is defined as "the degree to which a person believes that using a particular system would be free from effort". Furthermore, perceived usefulness of the system is predicted to be positively influenced by its ease of use. Another well-known model to describe technology acceptance is the Unified Theory of Acceptance and Use of Technology (UTAUT) developed by Venkatesh et al. (2003) based on TAM and seven other user acceptance research approaches. The UTAUT suggest that four variables are direct determinants of the behavioural intention to use a technology, suggesting the actual use of the technology: performance expectancy, effort expectancy, social influence, and facilitating conditions. As show in figure 1.2, performance expectancy is strongly related to perceived usefulness in the TAM and is defined by Venkatesh et al. (2003) as "the degree to which an individual believes that using the system will help him or her to attain gains in job performance". Effort expectancy is strongly related to ease of use in the TAM and is defined as "the degree of ease associated with the use of the system".
Figure 1.2: Relation between Technology Acceptance Model (TAM) and Unified Theory of Acceptance and Use of Technology (UTAUT). External variables influencing the determinants were not displayed for clarity. Dashed lines
1 INTRODUCTION
Additionally, the UTAUT suggest that social influence defined as "the degree to which an individual perceives that important others believe he or she should use the new system" and facilitating conditions defined as "the degree to which an individual believed that an organisational and technical infrastructure exists to support use of the system" are determinants of the behavioural intention to use a system. To prevent a low acceptance of the new application by the end users, determinants for technology acceptance should be considered from the start of the application development. According to Kim et al. (2015), who performed an analysis of the determinants influencing healthcare professionals’ adoption of new mobile electronic medical records by combining the TAM and UTAUT model in a tertiary hospital, intentions to use a mobile EHR were particularly influenced by performance expectancy. Kim et al. (2015) recommended that performance expectancy should be considered as a determining factor in the adoption of new mobile EHR systems. They recommended that end-users’ needs should be deeply analysed to identify useful functions for their workflows. Therefore, this thesis will mainly focus on performance expectancy. Additionally, effort expectancy (ease of use) will be considered.
1.3
Objective and research questions
The aim of this study is to provide an in-depth insight into the end-user requirements for a mobile application to support FACT-teams in their daily operations. Technical feasibility and non end-user requirements were out of scope of this study. The main research question is:
What are the end-user requirements for a mobile application to support FACT-teams by taking into account their ambulatory way of working within the mental healthcare?
Three research questions were defined to find an answer to the main research question.
RQ1. Which care processes should be supported by the mobile application in the FACT ambulatory way of working?
RQ2. What are the required functionalities for the mobile application?
RQ3. What are the perceptions and satisfaction of end users about the requirement based mobile application?
1.4
Outline of the thesis
Chapter 3 describes the care processes within the FACT working method. It answers the first research question. Chapter 4 describes the end-user needs for a mobile application. In this chapter end-user needs are converted into end-user requirements which were used to develop a mobile application. This chapter contributes to the answer to the second research question. Then, chapter 5 describes a visual prototype for a mobile application based on the end-user requirements. It provides the structure and user interface for a mobile application that will support FACT-teams. This chapter contributes to the answer to the second and third research question. Chapter 6 provides the updated requirements based on the validation of the initial requirements by means of the mobile application. This chapter provides the final answer to the second research question. Chapter 7 describes the satisfaction ratings of end-users with the requirement based prototype. It compares the prototype to the currently used EHR to show the appropriateness of the requirement based prototype. Additionally, it helps to verify whether the requirements were implemented correctly. This chapter answers the third research question. Finally, chapter 8 discusses the results and presents the main conclusions of this study. Furthermore, it provides recommendations for further research.
2 METHODS
2
Methods
The main goal of this thesis is to specify requirements that meet the end-user’s needs for a mobile application to support FACT-teams in their daily care processes. Therefore, this thesis will focus on the requirement development phase of the requirement engineering process. The requirement development phase consists of the requirements elicitation, requirement analysis, requirement specification, and requirements validation as shown in figure 2.1 (Wiegers and Beatty, 2013). This chapter describes the methods used during each part of the requirement development phase.
Figure 2.1: Requirement development process (Wiegers and Beatty, 2013).
2.1
Requirement elicitation
Requirements for a mobile application to support FACT-teams in their daily care processes can only be specified after having a thorough understanding of what FACT-teams are, how their care processes looks like and what functionalities they need. Requirement elicitation is defined by Wiegers and Beatty (2013) as "the process of identifying, discovering requirements from various sources through interviews, workshops, focus groups, observations, document analysis and other mechanisms".
Therefore, literature was reviewed to obtain information about FACT-teams and the associated care processes. The Business Process Modelling Notation (BPMN) was used to describe the care processes. Then, field research was performed between December 2016 and February 2017. Full-day observations with four end-users were used to observe exactly what activities take place during a day. A questionnaire was used to survey a larger group of end-users to understand their needs for a mobile application and to collect additional data about FACT-teams. The questionnaire was also used to measure the level of satisfaction with their currently used EHR by using the Computer System Usability Questionnaire (CSUQ).
2.2
Requirement analysis
In the requirement analysis phase, the information received from end-users from the questionnaire and the observations was analysed and transcribed. End-user needs were defined based on this data and the literature review. Needs were categorized and descriptive statistics were used to report their frequencies, representing their importance.
2 METHODS
2.3
Requirement specification
In the requirement specification phase, the collected end-user needs were translated into an initial list with categorized requirements. The MoSCoW method was used to prioritize the requirements. The priority was strongly related to the number of times a need was reported by the end users.
2.4
Requirement validation
Requirement validation is important to ensure that the the end-user needs were interpreted correctly by the researcher. The requirements were validated by means of semi-structured interviews. Two high fidelity interactive prototypes were used to guide the interviews. The requirements were updated based on the feedback of end-users.
Furthermore, the CSUQ was used to measure the end-user satisfaction with both prototypes. These satisfaction ratings provided additional information about the correctness of the requirements. End-user satisfaction ratings with the prototype and their currently used EHR were compared.
3 CARE PROCESSES WITHIN THE FACT WORKING METHOD
3
Care processes within the FACT working method
As described in chapter 1, user acceptance of a mobile application is strongly influenced by the perceived usefulness. Therefore, it is important that the mobile application supports the FACT care processes and the most occurring events within these processes. In this chapter, the care processes of FACT-teams will be described by using the Business Process Model and Notation (BPMN).
3.1
Method
A literature review was used to collect information about the FACT care processes. Initially a literature search was performed in PubMed, Embase, and PsycINFO. However, it turned out that literature related to the FACT-way of working was scarce. Therefore, the ‘Handboek FACT’ (van Veldhuizen et al., 2008) and FACT manual (van Veldhuizen and Bähler, 2013) served as a basis. Additionally, quality statutes from Dutch mental healthcare organisations were included. Among other things, these quality statutes describe general care processes within the mental healthcare. To increase the chance of obtaining information about the FACT processes, quality statutes were analysed for mental healthcare organisations who had 10 or more certified FACT-teams as of December 2016. These institutions are shown in table 3.1. Together, these institutions represented 66% of all certified FACT-teams in the Netherlands (CCAF (nd), December 2016). In addition to the quality statutes, available FACT brochures from these mental healthcare institutions were included for the literature review.
Each document was inventoried to retrieve the main care processes. A synthesis matrix, as can be found in appendix G.1, was used to review and classify the relevant information to each main care process. Information related to these processes was categorized for further analysis into subprocesses. The subprocesses which were reported most frequently were included in the BPMN diagrams. The literature used to describe the subprocesses within each main care process can be found in table 3.1.
Table 3.1: Literature used to describe the subprocesses within each main care process. Bullets represents that the literature contained information regarding a main process. Adm. = admission, int. = intake, trt. = treatment, eval. =
evaluation, term. = termination.
Type of information Reference Adm. Int. Trt. Eval. Term.
Quality
statues
Altrecht (Altrecht, 2016) •
Antes (Czyzewski, 2016) • • • • •
Arkin (Muller, 2016) • • • • •
GGZ Breburg (van Reekum, 2017) • • • • •
GGZ InGeest (Stichting GGZ inGeest, nd) • • • • •
GGZ Noord-Holland Noord (van Putten and Brinkmann, 2016) • • • •
GGZ Friesland (Teer, 2016) • • • •
GGZ Oost Brabant (Hanegraaf, 2016) • • • • •
GGZ Rivierduinen (Poodt et al., 2016) • • • • •
Lentis (Raad van bestuur, 2016) • • • • •
Mondriaan (Mondriaan, 2016) • • • • • Parnassia (Kwidama, 2016) • • • • • F A CT brochures GGZ inGeest (GGZ inGeest, 2016) • • • •
GGZ Noord-Holland Noord (GGZ Noord-Holland Noord, nd) • • • • •
GGZ Oost Brabant (GGZ Oost Brabant, nd) • • •
GGZ Rivierduinen (GGZ Rivierduinen, nd) • • • •
Mondriaan (Mondriaan, nd) • • •
Other
"Handboek FACT" (van Veldhuizen et al., 2008) • • • • •
3 CARE PROCESSES WITHIN THE FACT WORKING METHOD
Besides a description of the care processes, the Business Process Model and Notation (BPMN 2.0) was used to schematically describe the main and sub care processes. Collaboration diagrams, a specific type of BPMN diagram, were used to model the interactions between the FACT-team and involved stakeholders in the care processes. Each stakeholder is represented by a pool. Specific roles within a stakeholder are represented by lanes.
Emphasis was placed on the care processes within FACT-teams. Therefore, all other stakeholders were modelled by black boxes. Message flows between the FACT-team and stakeholders within the mental healthcare organization were represented by dashed arrows.
3.2
Results
According to the literature review, five main care processes can be distinguished: (1) admission, (2) intake, (3) treatment, (4) evaluation, and (5) termination. Within each of these care processes, one or more of the following stakeholders are involved: the referrer (a supply chain partner, often a general practitioner), the mental healthcare organisation where the roles of the central application department or secretary and the FACT-team are relevant, the patient, close relatives of the patient, external organisations, and crisis services or inpatient care clinics.
Multiple roles exists within each FACT-team. First, the role of the case manager who is responsible for providing and organizing care for one or multiple patient(s). Second, the role of a practitioner within a FACT-team who can be requested on demand by the case manager for providing care to a patient. Third, the role of a team where all practitioners together are responsible for providing and organizing care for a patient who is being placed on the FACT-board (intensive care). Furthermore, the role of a practitioner is performed by different disciplines, each having their own activities in the care process.
Although each role performs different activities, the BPMN diagrams do not represent the different roles within a FACT-team because of three reasons. First, the literature did not describe all care processes in detail, resulting in insufficiently available information to model the care processes for each role. Second, care processes can be performed by multiple roles, resulting in too complex, incomprehensible diagrams. Third, modelling the care processes within each role will not be relevant for answering the main research question, since all roles within the FACT-team should be supported.
3.2.1 Main care processes
The main care processes and the involved stakeholders are schematically presented in figure 3.1. The admission process starts when the central application department or secretary of the mental healthcare institution has received the application from the referrer. When the patient is found to be eligible for FACT, the patient will be admitted and an intake interview will be scheduled with the patient and his close relatives, if possible. The total admission will be completed in a few days. Information requests between the admission and intake will be answered by the general practitioner or the central application department. During the intake period, the patient’s care needs and diagnosis will be determined by one or two FACT-members. At the end of this period, the patient will receive a treatment advice which is recorded in a preliminary treatment plan. The total duration of the intake can vary between one day and multiple weeks, depending on additional diagnostics. When the patient has agreed with the proposed treatment, its core process will start. After the patient has been introduced to the FACT-team, different types of care can be provided as defined in the patient’s treatment plan. At least two years are required to treat patients with severe mental illnesses. The treatment will be evaluated as soon as the patient meets the evaluation criteria. Multiple evaluations can take place in a treatment, but in any case a treatment plan evaluation is performed once a year. The treatment will be continued based on an updated treatment plan. When the termination criteria are met, care will be transferred to the general practitioner or basic mental healthcare.
3 CARE PROCESSES WITHIN THE FACT WORKING METHOD
Figure 3.1: Collaboration diagram showing the main care processes from referral to termination of care. Pools represent the different stakeholders. Message flows represent the communication with stakeholders per process.
In the next part of the chapter, emphasis is placed on the treatment and evaluation processes because of two reasons. First, it was found that FACT-teams were not involved during the admission process. Therefore, a thorough description of this process is irrelevant since there is no need for support by the mobile application. Second, the intake and termination processes have a significantly shorter duration than the treatment and evaluation processes. Therefore, they were considered to be less important compared to the processes within the treatment and evaluation. A description and the BPMN diagrams of all care processes can be found in appendix A.
3.2.2 Treatment
The treatment process consist of an introduction period and the actual treatment. The BPMN diagram of the treatment process can be found in appendix A.3.
Introduction period in the FACT-team
The treatment will start after a patient’s file in the EHR has been created, care (DBC) has been allocated, and the preliminary treatment plan has been made. This plan describes which team members will see the patient based on his diagnosis and first care needs. One of these team members is the case manager. At the start of the treatment, the new patient will be introduced to the entire team and will be added to the FACT-board in the category ‘new’. Figure 3.2 shows an example of a FACT-board and its content as described by the ‘Handboek FACT’ (van Veldhuizen et al., 2008).
In the first weeks at least four different disciplines will visit the patient. Every day, the patient will be discussed during the FACT-board meeting and new information as provided by these disciplines will be added. This will ensure that the team makes a more accurate assessment of the patient’s care and treatment needs. The plan is finalized through an evaluation process and will guide the treatment of the patient.
3 CARE PROCESSES WITHIN THE FACT WORKING METHOD
Figure 3.2: Example of a FACT-board containing fictional data. Reprinted from van Veldhuizen et al. (2008).
Treatment based on the final treatment plan
After the introduction period, it will be decided whether low intensive care is sufficient. In this case the patient is removed from the FACT-board and the case manager will become responsible for providing and organizing care around the patient, together with the main care provider. When high intensive care was found to be required, the category on the FACT-board will be changed from ‘new’ to one of the following categories: (1) crisis prevention, (2) intensive short-term, (3) intensive long-term, (4) admission, (5) treatment avoider, (6) high-risk treatment avoider. Because the patient has been placed on the FACT-board, all team members are familiar with the patient and can provide high intensive care.
Patients who require high intensive care will be discussed daily during the FACT-board meeting. In this meeting, the team will decide who will visit the patient and which interventions have to be performed. The case manager of a patients who require low intensive care may decide to add the patient on the cases-to-discuss list on the FACT-board. This is used as a single moment to share information with or to obtain information from team members about this patient. Together, it can be decided whether it is necessary to add the patient on the FACT-board because high intensive care is required. Then the patient’s crisis plan will be used to prevent a crisis, agreements will be made regarding the shared caseload, and the psychiatrist will decide within 24 hours whether the patient should be examined to optimize his medication and a safety assessment will be performed. At the same time, team care can be terminated when low intensive care is suitable. Then the patient will be removed from the FACT-board. This will initiate the evaluation process. Together with the patient, the period of high intensive care will be evaluated.
After the FACT-board meeting, every discipline will go their own way and will meet the scheduled patients. The ambulatory way of working ensures that most appointments will take place at the patient’s home. Therefore, FACT-members also have contact with close relatives of the patient. At the patient, the care or interventions as agreed in the treatment plan will be performed. All activities related to the patient are registered in the EHR. FACT-teams provide three different types of care which can be performed simultaneously, but depends on the actual situation of the patient:
First, destabilization interventions will be applied to prevent admissions in a psychiatric hospital. Patients will be added to the FACT-board and high intensive care is provided, meaning multiple visits a day. When this proves to be insufficient, the patient will be admitted to an inpatient care clinic and is still supervised by the case manager, until the crisis is over. Before admission and after termination an evaluation takes place.
Second, treatment interventions are provided by one or multiple team members according to the multidisciplinary guidelines with the goal to stabilize symptoms. Besides pharmacotherapy, also psychological, or addiction related interventions may be performed. Treatment serves to support the goals formulated by the patient.
Third, recovery interventions are aimed at helping the patient with his participation in society. FACT-members have contact with organisations providing, among others, housing and protected living, daily activities and a paid job. Additionally they help to create a social network for the patient.
3 CARE PROCESSES WITHIN THE FACT WORKING METHOD
3.2.3 Evaluation
The evaluation process, as visualized in the BPMN diagram in appendix A.4, can start at any moment during the treatment when one of the following evaluation criteria is met:
The patient refuses to receive care and wants to terminate The introduction period of a new patient has been finished The patient’s treatment plan will expire within 2 months The patient’s treatment plan is not up to date
The patient has been removed from the FACT-board Inpatient care has been terminated
Inpatient care is required
When the introduction period of a new patient has been finished, this period will be evaluated and the preliminary treatment plan of a new patient will be adapted based on the findings of the team members. This plan should be finalized within six weeks after the start of the treatment. A treatment plan evaluation may also be scheduled when the treatment plan is not up to date. However, in any case, at least once a year the treatment plan should be evaluated. Two months prior to expiration, the case manager will schedule a treatment plan evaluation with the patient and the patient’s close relatives. Prior to this evaluation, the case manager will evaluate the patient’s situation by completing ROM questionnaires (such as HoNOS or MANSA) with the patient. Furthermore, a somatic screening will be performed or results may be requested from the GP. During the treatment plan evaluation the preceding period and the results from the ROM questionnaires will be discussed with the patient to confirm whether the previously formulated goals have been reached. The case manager, psychiatrist and other team members involved in the treatment will attend the meeting. Often, the patient and close relatives are invited. The treatment plan will be updated in conjunction with the patient and includes, among others, the patient’s wishes and the provided treatment and medication. Often a crisis or alert plan (Dutch: "signaleringsplan”) is included. The treatment continues when the patient and psychiatrist have signed the treatment plan. The patient can receive a copy of the treatment plan and the case manager will inform the referrer. Then the updated treatment plan will be registered in the EHR.
During the treatment plan evaluation, a patient’s wish to terminate FACT care will be considered. When the termination criteria are met, the termination process will be initiated. Otherwise the team will talk with the close relatives to convince the patient to continue the treatment. When termination will not result in danger or risk of serious disadvantage, the patient’s wish to terminate the care will be accepted. If there is a threat, relapse or danger, pressure and compulsion may be used by means of a juridical authorization. When a crisis situation occurs and inpatient care is needed, the case manager will contact the inpatient care clinic to schedule a Care Harmonisation Meeting (Dutch: "zorgafstemmingsgesprek - ZAG"). The case manager, patient and inpatient care clinic will discuss the goals of the admission and will make agreements. The patient’s crisis plan can be used to check what types of interventions have stabilized the crisis in the past.
Furthermore, an evaluation will be scheduled when the patient has been removed from the FACT-board or when inpatient care has been terminated. The period of intensive care will be evaluated and the patient’s crisis plan and alert plan. Then the treatment will continue.
3.3
Conclusion
FACT-teams deliver care to patients with severe mental illnesses who need at least two years of treatment. The main care processes within FACT-teams include: the admission, the intake, the treatment, the evaluation, and the termination of care. FACT-members are not involved during the admission. Therefore, it is irrelevant to support this process with the mobile application. Furthermore, the processes related to the intake and termination of care are considered to be less important compared to the processes within the treatment and evaluation, because the intake and termination have a significantly shorter duration. Therefore, the mobile application should be confined to the functionalities to support the sub-processes within the treatment and evaluation. This conclusion has been confirmed by the results of field-research as described in chapter 4. End users reported needs related to the treatment and evaluation, but did not report any specific needs related to the admission, intake, or termination processes.
4 CONVERTING END USER NEEDS TO REQUIREMENTS
4
Converting end user needs to requirements
Chapter 3 concludes that the treatment and evaluation processes within FACT should be supported by the mobile application. However, it is unknown which functionalities are needed to support these care processes. Therefore, field research was performed to collect end-user needs which were then converted into requirements. End-user needs describe want the end user want to achieve, while requirements tell what the mobile application should do to satisfy the end user needs. Since end-user needs are strongly related to end-user requirements, both will be discussed in this chapter.
4.1
Method
Both a questionnaire and observations were used to gather information from FACT-members within various FACT-teams in the Netherlands in addition to the literature used in chapter 3. The main goal of the questionnaire was to obtain insight into the end-user’s needs for a software solution which will support the FACT-members during their work. The aim of the observations was to gain a more detailed understanding of the information needs.
4.1.1 Questionnaire
Two focus groups were organized to obtain topics and questions for the web-based questionnaire. Each focus group consisted of five Pinkroccade Healthcare employees (familiar with FACT) and contained at least one consultant, one developer, one information analyst and one designer. All focus groups were voice recorded. Topics and questions were categorized to: end-user characteristics, used technologies, working method, end-user needs, and satisfaction with mijnQuarant.
The web-based questionnaire contained 25 qualitative and quantitative questions based on the topics retrieved from the focus groups. The sequence of answering possibilities on categorical questions were randomized to ensure it did not affect the results.
Prior to distribution, the questionnaire was pre-tested internally and externally by four FACT- experts and two non-experts. The purpose of this test was to assess the time required to answer the questions and to improve the comprehensibility, correctness and completeness of the questions. The questions and answering possibilities were evaluated by three employees within PinkRoccade who participated in the focus-groups, and the founder of FACT (Veldhuizen van, R.). Additionally, two non-experts reviewed the questions and type of questions for comprehensibility. All reported ambiguities in the questionnaire were corrected. The final questionnaire contained 23 closed questions and 2 open ended questions for mijnQuarant users. For other EHR users, the final questionnaire contained 21 of the closed questions and the 2 open ended questions. The questionnaire can be found in appendix B.2.
Participant selection
The population of interest for this study consisted of all FACT-members within certified FACT-teams in the Netherlands. In December 2016, 296 certified teams existed within 52 organisations, according to the CCAF (nd). Literature did not report the actual number of FACT-members in the Netherlands. However, an ideal FACT-team consists of 11 to 12 FTE (van Veldhuizen et al., 2008). To account for part-time employees, it was estimated that each team consists of 14 to 15 FACT-members. The population size was therefore estimated to be 4101 to 4395. The minimum sample size required to draw accurate conclusions about the total population was 354, based on a population of 4395 with a 5 percent margin of error and a confidence level of 95 percent.
Data collection
A convenience sampling technique, in combination with the snowball effect, was the only possibility to collect data, since the CCAF did not provide a list with email addresses of all FACT-teams in the Netherlands. Participants were selected based on availability of email addresses.
A total of 110 email addresses of FACT-teams or FACT-members within 32 mental healthcare institutions were found on the website of the CCAF or on the institutions’ websites. Since no email address was
4 CONVERTING END USER NEEDS TO REQUIREMENTS
available for the FACT-teams or FACT-members of 20 mental healthcare institutions, they were contacted through a general email address of these institutions. In total 130 FACT-teams, FACT-members, or institutions were personally contacted by email. The invitation email can be found in appendix B.1. All recipients of the email were asked to spread the questionnaire among other FACT-members. In total all 52 mental healthcare institutions in the Netherlands were reached by email. Additionally, two online invitations were used to reach FACT-teams in the Netherlands. First, CCAF and FACT-Nederland published a news item on their website with a hyperlink to the online questionnaire. The questionnaire was also published on a mental healthcare forum called “GGZ Connect”. Data was collected from December 2016 to January 2017.
Data analysis
A total of 300 respondents participated in the questionnaire of whom 225 were recruited by email. In total, 269 participants were included for analysis. Participants were excluded when they, either: did not use an EHR, did not work in a FACT-team, did not treat any patients in or outside the office, or completed less than 50 percent of the questionnaire. Pairwise deletion was used to deal with missing data. Data was analysed using Excel (version 1706) and descriptive statistics were used to describe the results. Open ended questions were coded by means of a bottom-up approach. Detailed results from the questionnaire and participant characteristics can be found in appendix B.3 and B.4.
Figure 4.1: Questionnaire: Participant selection, data collection and data analysis
4 CONVERTING END USER NEEDS TO REQUIREMENTS
4.1.2 Observations
A convenience sampling method was used to select FACT-members to observe after which six were invited for participation in the observation. All six worked in different mental healthcare institutions. Full day observations were performed on-site at various mental healthcare institutions with four FACT-members, after they gave their consent. These observations were non-participant, meaning the researcher observed the end-user in their natural environment without taking an active role. Participants were aware of being observed and knew about the aim of the observations. The observations were unstructured and all events were monitored by the researcher. Field notes were obtained since voice or video recording was not allowed. Field notes of the observations were transcribed the same day and each unique event was coded.
4.1.3 Converting data to needs
A bottom-up approach was used to determine the end-user needs from the results of the questionnaire, the events from the observations, and the literature as stated in chapter 3. Needs were captured in user stories according to the Connextra template as described by Cohn (2004). The Connextra template answers the who, the what, and the why from the user’s perspective.
"As a <user/persona/role> I want <desired feature/do something> so that <benefit for implementing the feature>"
Each need was categorized and consisted of a need-ID, a user story, a frequency, and a source. Frequencies were based on the open-ended questions in the questionnaire and the events from the observation. Sources could include the questionnaire (open-ended or closed questions), observations, and literature. Needs will be described in section 4.2. Appendix G.2 provide a detailed description of all needs including the raw data on which the need is based on.
4.1.4 Converting needs to requirements
Requirements were obtained by combining one or multiple needs. Main and sub requirements were specified to deal with both the high-level and more detailed needs retrieved from the questionnaire, observations and literature. A main requirements represent the high-level need, while the sub-requirement represent a more detailed need related to this main requirement. Each requirement contained a requirement-ID, a description, a frequency, and a priority. Additionally, it contained the need-IDs and the data sources on which the requirement was based on. A traceability matrix can be found in appendix G.2. The requirement-ID contains information about whether it is a functional (FR) or non-functional requirement (NFR). Frequencies were calculated for the main and sub requirements, representing the number of unique participants from the questionnaire and observations who reported this requirement. The reported frequencies were used to prioritize requirements according to the MoSCoW method, where each requirement is defined as a must have (M), should have (S), could have (C), or won’t have (W) requirement.
Limits were determined by interquartile ranges, since the distribution of frequencies for the requirements was not expected to be normally divided. Categorical limits were defined by using the first to fourth quarter. M-requirements represent the fourth quarter, while the third, second and first quarter represent the S-, C-, and W-requirements. The initial priority was based on the end-user needs from the open-ended questions and observations. To account for the results from the questionnaire’s closed-questions and the literature, the priority could be adapted. A priority was also adapted when one requirement was necessary to meet another that had a higher priority or when a requirement was self-explanatory to be a ‘must have’ (e.g. providing a patient’s name). Based on the above approach, a main requirement could have a higher priority than the highest prioritized sub requirements. The effort of implementing each requirement was not considered. A schematic representation of the prioritization method used can be found in appendix C.
4 CONVERTING END USER NEEDS TO REQUIREMENTS
4.2
Results
In total, 247 end-user needs were identified based on the results of the questionnaire, observations and literature. Because of vagueness, 21 needs were excluded. All included needs were related to activities in the treatment and evaluation process as defined in chapter 3. The included needs were categorized into six subjects: (1) calendar, (2) contact details and communication, (3) patient related information, (4) FACT-board, (5) reminders, and (6) technically related. Subjects 3 and 6 contained additional sub categories. Figure 4.2 shows the division of the end-user needs among the main and sub categories.
Figure 4.2: Sankey diagram representing the division of needs among the categories. Each number represents the number of needs which were specified for each category.
The reported needs are related to the results of a closed question (Q19) from the questionnaire. Here, end users were asked to indicate which 5 out of 10 predetermined topics of information (retrieved from the focus groups) were most needed at the office, on the road, and at the patient. Figure 4.3 and table 4.1 show the results where percentages indicate the percentage of respondents who said this information is most needed at a certain location.
All topics were found to be important at the office (60% to 82%). Figure 4.3 shows that access to contact details, the calendar, reports and medication were found to be most important when end users are on the road. When the end user is with the patient, access to the calendar, medication, reports, diagnosis and treatment plan, social network of the patient and progression of the patient, were almost equally important as they were at the office. A lower need exists for access to: treatment history of the patient, information on the FACT-board, and the caseload of the end user (e.g. number of patients treated by the end user).
4 CONVERTING END USER NEEDS TO REQUIREMENTS 0% 25% 50% 75% 100% Calendar Caseload FACT-board details Contact details
Treatment history of the patient
Progression of the patient Social network of the patient
Diagnosis and treatment plan Reports
Medication
At the office On the road At the patient
Figure 4.3: Radarchart representing the information need of 10 predefined categories in the office, on the road, and at the patient.
Table 4.1: Answers to question Q19: Which information do you want to access at the office, on the road, and at the patient?
At the office On the road At the patient Total average Total average
(O) (R) (P) (O,R,P) (R,P)
Calendar 76% 79% 75% 77% 77%
Reports 82% 59% 73% 71% 66%
Medication 77% 53% 78% 69% 66%
Contact details 71% 77% 56% 68% 66%
Diagnosis and treatment plan 80% 45% 72% 66% 58%
Progression of the patient 74% 46% 65% 62% 55%
Social network of the patient 60% 40% 54% 51% 47%
Details on the FACT-board 64% 38% 39% 47% 38%
Treatment history of the patient 69% 22% 34% 42% 28%
4 CONVERTING END USER NEEDS TO REQUIREMENTS 20 24 7 16 17 23 15 39 20 21 30 45 24 17 54 2 0 10 20 30 40 50 60
Initial Adapted Initial Adapted
Main requirements Sub requirements
Num be r of r eq ui rem en ts M S C W
Figure 4.4: Bar chart representing the number of requirements prioritized as M, S, C, W prior and after adaptation
In total, 226 needs were converted into 81 main requirements and 106 sub requirements. Frequencies for both the main and sub requirements were not normally divided. Only the main requirements were incorporated for determining the limits, since most sub requirements were only obtained from the four observations. M-requirements represent the fourth quartile (n > 14), while the third, second and first quarter represent the S- (6 < n ≤ 14), C- (3 < n ≤ 6), and W- (n ≤ 3) requirements. Figure 4.4 represents the number of requirements prioritized according to the MoSCoW method prior and after adaptation. After adaptation, 40 M-, 62 S-, 66 C-, and 19 W-requirements were defined.
Needs of the end user will be discussed, by category, in sections 4.2.1 - 4.2.6 in relation to the specified requirements. Also, results from the closed questions from the questionnaire will be used to substantiate the results and assigned priority.
Because of the large amount of data, a traceability matrix is available in appendix G.2. It contains a description of each requirement and the need-IDs on which it is based. Furthermore, it contains a description of each need, the reported frequency, and one or multiple source(s) the need is based on. Therefore, the coded open-ended questions and the coded events from the observations are available in the same traceability matrix, making it possible to trace how requirements have been established. Detailed results on the closed questions from the questionnaire can be found in appendix B.4.
4.2.1 Calendar
In total 22 calendar related needs were defined based on literature, the questionnaire and observations. These needs were converted into 13 main and 10 sub requirements.
Need to view, add, edit and delete calendar appointments
A large number of end users (77%) indicated that they want to have access to their EHR calendar on the road and at the patient (Q19). Also, in the open-ended questions, the possibility to have access to the end user’s calendar appointments was reported by 37% of the respondents. This may be important since 90% see multiple patients outside the office and 42% see multiple patients at the office. Most end users see an average of 4 to 7 patients each day at different locations. Currently, end users are using a paper (53%) or digital calendar (33%) next to the EHR, to view their appointments while being outside the office (Q17). It was observed that end users visit multiple patients after each other without going back to the office. Therefore, it is important that end users are able to view their calendar appointments out of office. According to the results of the open-ended questions, end users do not only want to see which calendar appointments they have today, but would also like to be able to schedule new appointments when they are out of office (21%). This need, including the need to check their future availability, was also observed in all four observations. Furthermore, appointments were cancelled or rescheduled regularly. Currently, end
4 CONVERTING END USER NEEDS TO REQUIREMENTS
users have to write these appointments in their paper calendar or digital calendar on their smartphone or tablet when they are out of office, since the EHR calendar cannot be accessed.
As shown table 4.2, the detailed needs regarding adding a new calendar appointment were primarily found during the observations. When adding a calendar appointment in the paper or digital calendar, end users searched for an available time slot on a certain day in their calendar. They also might add a title/description, which contains the subject of the appointment. An often used description is "depot medication", since this is one of the most used interventions to deal with symptoms. During two observations the end user brought a blood pressure gauge, body weight monitor, or measuring tape to the patient’s home to perform one or multiple measurement(s). In both cases, there was a need to be able to add this information to the calendar appointment. The need to select attending participants (either patients or other team members) when adding an appointment was mentioned by 3% of the participants but was found to be important during observations. To schedule an appointment with other team members, 6% explicitly mentioned the need to be able to view their calendar appointments to check for availability. During an observation, a FACT-member said:
“
I had to plan an appointment for the patient together with the psychiatrist. However,when I am on a house visit I cannot check the psychiatrist’s availability because I do not have access to the EHR calendar. I tried to call the psychiatrist to ask for her availability, but she did not answer the phone. Therefore, I had to call the secretary to ask whether the psychiatrist was available. The secretary said she was occupied on that day and I had to ask the secretary for available time slots. As you may understand, this is very time consuming and not efficient.”
Since multiple team members may schedule appointments with one patient, there may also be a need to view the calendar appointments of a patient including those with other team members who are involved in the treatment. Only 1% of the participants from the questionnaire mentioned this need. However, this need was observed in 3 out of 4 observations. The end user suggested a time and date for the patient. However, since the patient already had an appointment with another team member on that time or on that day another moment in time was chosen.
Because of the ambulatory character of the end users, the option to add a location to an appointment seems obvious and was confirmed by all 4 observations. Additionally, it was observed once that travel time was added to a calendar appointment. Furthermore, time should be available in the end user’s calendar in order to perform intensive ACT-care (van Veldhuizen et al., 2008). Although non of the end users reported it, there might be a need to indicate an appointment as busy, tentative or free. Furthermore, it was observed that different types of appointments exist, such as: FACT-board or patient meetings and phone calls. Providing this type of information could give an indication to the location of the appointment.
Need to approve calendar appointments
When the appointment is finished, the end user should approve the appointment in the EHR. In short, this means that the right type of care is being registered in the EHR. This is important to justify which care is delivered to a patient and to receive the correct funding. In the questionnaire, 6% of the participants reported the need of having the functionality to approve calendar appointments when they are out of office. Two observations confirmed this need, since all calendar appointments were approved at the end of the day. As a result, end users should remember a lot of information about each appointment. Furthermore, in order to approve an appointment, the administration time, also known as indirect time, should be registered. An appointment cannot be approved when no report is attached to it. 4% of the end users also described the need to be able to add a report from the calendar. Furthermore, appointments are cancelled regularly by patients or a patient will not show up for an appointment (no show), which should be added to the appointment (1%).
Need to synchronize calendar appointments
Another important need is to be able to synchronize calendar appointments with the EHR calendar. Currently, 70% of the FACT-members view calendar appointments in the EHR (Q17). However, 52% see the calendar appointments in a paper calendar, or digital calendar (33%). However, all appointments written in calendars outside the EHR should be added to the EHR for registration in the end, resulting in shadow registration.
