STOCKHOLM SVERIGE 2021,
Mobile cross-platform gesture- guided visual pain tracking for endometriosis
ALFIO BRANCOZZI
KTH
SKOLAN FÖR ELEKTROTEKNIK OCH DATAVETENSKAP
Abstract
Rapid growth in mobile technologies since the 2000s is reflected in continued smartphone adoption and the expansion of mobile health (mHealth) smartphone applications for pain assessment. Yet there exists a lack of research-based pain assessment apps for endometriosis, a prevalent yet
underrepresented disorder where pain management plays a vital role. The predominance of the iOS and Android smartphone operating systems has previously required developers to maintain two separate codebases and development environments in order to access a combined 99% market share.
Since 2015, cross-platform development softwares have allowed for maintenance of a single codebase and environment. This thesis explores the development of a cross-platform smartphone app for endometriosis pelvic pain assessment where design decisions are informed by endometriosis and pain assessment research as well as engineering particularities of the React Native framework. The
completed prototype along with this thesis’ design discussion indicate that research findings into endometriosis pain assessment can be successfully adapted via React Native into a visual, gesture- guided functionality for the self-assessment of endometriosis related pelvic pain.
Keywords
mHealth, smartphone, endometriosis, pain, React Native, gesture, symptom tracking
Sammanfattning
Den snabba tillväxten inom mobilteknik sedan 2000-talet återspeglas i en fortsatt ökning av smartphone-användare samt utvidgningen av mobilhälsoapplikationer (mHealth) för smärtbedömning. Ändå finns det en brist på forskningsbaserade smärtbedömningsappar för endometrios, en vanlig men underrepresenterad sjukdom där smärtlindring spelar en viktig roll.
Övervägande av operativsystemen iOS och Android har tidigare krävt att utvecklare underhåller två separata kodbaser och utvecklingsmiljöer för att få tillgång 99% av marknaden. Sedan 2015 har mjukvaror för plattformsoberoende utveckling av mobilapplikationer möjliggjort underhåll av en enda kodbas och miljö. Denna avhandling undersöker utvecklingen av en plattformsoberoende applikation för smarttelefoner för utvärdering av bäckenvärk relaterade till endometrios, där designbeslut baseras på forskning om endometrios och smärtbedömning samt tekniska särdrag i React Native-ramverket.
Den färdiga prototypen tillsammans med avhandlingens designdiskussion indikerar att
forskningsresultat kring bedömning av smärta i endometrios kan anpassas via React Native till en visuell, geststyrd funktionalitet för självbedömning av endometriosrelaterad bäckenvärk.
Nyckelord
mHealth, smartphone, endometrios, smärta, React Native, gest, symptomspårning
Table of Contents
Abstract ... i
Keywords ... i
Sammanfattning ... iii
Nyckelord ... iii
Table of Contents ... v
1 Introduction ... 1
1.1 Project background ... 1
1.2 Research background and problem statement ... 2
1.3 Purpose statement ... 2
1.4 Research methodology and methods ... 2
1.5 Project methodology and methods ... 3
1.6 Delimitations ... 3
1.7 Structure of the thesis ... 3
1.8 Source code ... 3
2 Literature Review ... 5
2.1 Clinical research considerations ... 5
2.1.1 Endometriosis and endometriosis-related pain ... 5
2.1.2 Pain measurement research and pain scales ...6
2.1.3 Pain assessment for endometriosis ... 8
2.2 Related research-informed software ... 9
2.2.1 Computerised pain body maps ...9
2.2.2 mHealth for endometriosis ...11
2.3 Engineering considerations ... 11
2.3.1 JavaScript, JSON and NodeJS ...11
2.3.2 React Native and React design principles ... 13
2.3.3 React Native architecture ... 14
2.3.4 React Native animation and gesture handling ... 15
2.4 Summary of findings ... 17
3 Methodology and Methods ... 19
3.1 Research methodology and methods ... 19
3.1.1 Case study methodology ... 19
3.1.2 Action research methodology ... 19
3.1.3 Characteristics of research methodologies ... 20
3.1.4 Adapted research methodology ... 23
3.1.5 Research method ...24
3.1.6 Research evaluation ...24
3.2 Project methodology and methods ... 26
3.2.1 Agile, Lean, and adapted project methodology ...26
3.2.2 MoSCoW analysis ...26
3.3 Development environment... 27
3.3.1 Expo... 27
3.3.2 Environment setup ... 27
3.3.3 Manual testing ... 27
4 Results ... 28
4.1 Software requirement definition ... 28
4.2 Research-informed application features ... 30
4.2.1 Prototype overview ... 30
4.2.2 CPBM design ... 31
4.2.3 Daily tracking and calendar... 32
4.2.4 Pain types ... 32
4.2.5 Pain intensity scale ...34
4.2.6 Pain frequency ...34
4.2.7 Factors ... 35
4.2.8 Bleeding scale ... 35
5 Discussion and Conclusion ... 37
5.1 Reliability and validity of methods and results ... 37
5.2 Reliability and validity of data ... 37
5.3 Research outcomes ... 37
5.4 Limitations and future work ... 38
References ... 39
Appendix: Code highlights ... 43
Screen navigation... 43
Draw UI state ... 44
Canvas implementation ... 44
Gesture handling ... 46
Stroke data model and styling ... 48
Factors data model and styling... 50
Persistence ... 50
1 Introduction
Mobile health (mHealth) is the use of wireless mobile technologies for supporting individuals’
wellbeing in medical and public health practice [1]. It has expanded rapidly since the early 2000s in countries surveyed by the World Health Organization, with 80% of low-income and 91% of high- income countries reporting at least one public mHealth initiative as of 2017 [2]. Ongoing adoption of smartphones worldwide [3] has allowed for an evolution in the sophistication of mHealth services from simple text messaging and automated phone calls to multi-feature applications. Smartphone health apps are a rapidly growing category of mHealth: over 318,000 were available from app stores with an estimated 200 being added each day in 2017 [4]. One subset of health apps aims to support individuals in their management of pain, often in the context of a particular diagnosis or treatment- related scenario such as cancer or post-operative monitoring. One 2015 study identified 901 pain- related smartphone apps available for download across various app stores [5].
The two predominant mobile operating systems today are iOS and Android, with a respective 28%
and 71% of market share as of 2020 [6]. The iOS and Android development environments are vastly different, and app developers wishing to access their combined 99% market share have traditionally been required to maintain two separate environments and codebases for each app. Consequently, software packages self-styled as ‘frameworks’ or ‘software development kits’ have emerged that enable the development of cross-platform versions of apps from a single code base and development
environment. This is achieved via implementation of custom runtime environments that can interface with platform-specific or ‘native’ APIs while executing ‘non-native’ code.
This thesis focuses on the development of an mHealth cross-platform smartphone pain tracking functionality for use in the context of a suspected or confirmed diagnosis of endometriosis.
Endometriosis is a painful disorder involving abnormal growth of hormonal tissue within the body that affects a significant population worldwide yet is relatively underdiagnosed and unrecognized even among medical professionals. An absence of effective non-invasive medical diagnostic methods or treatments leaves pain assessment as the most accessible method for diagnosing and managing endometriosis. Yet despite rapid growth in mHealth smartphone apps, there are few research-based examples targeted to tracking pain in an endometriosis context.
1.1 Project background
Endometrix is a health tech start-up that aims to improve the quality of life for those with a confirmed or suspected diagnosis of endometriosis. The cross-platform framework React Native is used by the Endometrix development team for the efficiency of being able to develop for both iOS and Android from a single codebase and development environment.
In the Endometrix mobile app, users can track a range of variables to gain insights into the patterns of their disorder and to share data with healthcare providers to assist with diagnosis and symptom management. Pain is measured in the app with a 1-100 scaled slider labelled ‘Overall pain’
accompanied by optional descriptive tags that indicate qualitative aspects of pain such as location, duration and intensity.
There is an opportunity to deepen user experience and add value to the Endometrix app by further developing the existing pain tracking functionality to better exploit the capabilities offered by mobile smart devices. This has led to the idea of developing a visual representation of endometriosis- related pain in the body which can be manipulated via smartphone touch interfaces.
1.2 Research background and problem statement
There exists medical and information systems research about the design, use and effectiveness of both mobile and non-mobile applications for recording and communicating pain. Computerised Pain Body Maps (CPBMs) are an area of research concerned with drawing pain within body models on digital interfaces, and there are mobile apps currently available that offer a gesture-guided pain drawing functionality.
However, there is a research gap from a software engineering perspective in documenting how such functionalities are developed. Another research gap exists in examining how CPBM development decisions are influenced by the context of a suspected or confirmed diagnosis of endometriosis. The research focus can be further narrowed by limiting scope to only pelvic-related pain which leads to the research question:
How can a cross-platform, visual, gesture-guided and research-informed mHealth application for measuring pelvic pain associated with endometriosis be developed?
1.3 Purpose statement
The thesis of this degree project aims to contribute to research at the intersection of endometriosis, pain assessment, mHealth and software engineering by presenting and discussing a design solution tailored to the specific context of pelvic pain connected to endometriosis. This contribution can potentially benefit future researchers interested in questions involving mHealth software tailored to endometriosis-related pain.
The purpose of the degree project itself is to deliver a new pain assessment functionality that can complement or replace the existing slider-based functionality in the Endometrix app. It is anticipated that users will benefit by having access to an additional tool that is potentially more effective than a slider in recording and communicating pain. Endometrix also stands to benefit from the added value this new functionality could potentially bring to the app.
1.4 Research methodology and methods
Thesis methodology is described as a process-descriptive case study informed by a preliminary literature review. It incorporates concepts from Case study and Action research methodologies, two of five ‘classes’ of software engineering research methodologies described by Easterbrook et al. [7].
Knowledge obtained from the literature review is used as a starting point for guiding iterative cycles of research and development. The method of data collection shall be documentation of software
requirements and with resulting features and their underlying source code source, which will inform
the presentation and discussion of results. The functioning prototype created from the development process serves as an evaluating example of the results, certified by a rigorous manual testing process.
1.5 Project methodology and methods
Project methodology is described as a hybrid of Agile and Lean software project methodologies and uses MoSCoW method to prioritize development goals. The relatively small nature of the project does not suit more sophisticated, Agile-influenced software project methodologies that promote responsive collaboration between teams, such as Scrum and Kanban. Instead, certain Agile and Lean concepts are adopted together with the use of MoSCoW analysis to guide software development.
1.6 Delimitations
This thesis answers a research question at the intersection of endometriosis, pain assessment and software engineering by detailing a cross-platform software solution. It does not attempt to present new research findings on endometriosis as a disorder, the effectiveness of different pain measurement methods, the comparison between native and cross-platform development, or the comparison
between different cross-platform development softwares. The effectiveness of the software solution is not researched in this thesis, this is the next logical research step as outlined in future work.
1.7 Structure of the thesis
Section 2 presents a literature review of the medical and software engineering knowledge required for development. Section 3 gives a brief overview of relevant methodologies and methods from a software engineering research perspective before introducing the adapted research methodology, research method, research validation and development design. Section 4 presents the major design features of code. Section 5 presents the results. Section 6 presents the discussion and conclusion.
1.8 Source code
The codebase for the prototype created from this thesis is available as an open-source repository on GitHub. The link to the source code is available in the appendix.
2 Literature Review
This chapter summarizes knowledge that informs the thesis research process and in doing so
addresses the first research subquestion presented in section 3.1.5 (p. 24): “What existing knowledge can inform development of the described application?”. Section 2.1 covers clinical research into endometriosis and pain assessment that informs design decisions. Section 2.2 covers related instances of research-informed software. Section 2.3 covers engineering knowledge required to develop the application. Section 2.4 summarizes the findings of the literature review.
2.1 Clinical research considerations
This section covers clinical research that informs aspects of feature design. Section 2.1.1 introduces endometriosis and describes pain related to a diagnosis of endometriosis. Section 2.1.2 begins with a brief overview of modern research into pain measurement before narrowing focus to self-reported pain scales. Section 2.1.3 examines research at the intersection of pain measurement and
endometriosis.
2.1.1 Endometriosis and endometriosis-related pain
Endometriosis is a disorder characterized by the abnormal presence of tissue similar to the innermost lining of the uterus (endometrium) in organs of the body other than the uterus [8]. Abnormal tissue forms as endometrial glands or lesions resembling connective material (stroma-like lesions) and are most commonly found in the membrane that lines the abdominal cavity (peritoneal lesions), the ovaries (endometrioma) or in organs enclosed by the peritoneum (deeply infiltrating endometriosis), though in rarer cases are found in many other organs of the body [8][9].
Endometriosis is underdiagnosed and underrepresented despite an estimated 5-10% of uterus carriers of reproductive age suffering from the disorder [10][11]. It is also rarely diagnosed with individuals born without a uterus [12]. Accounts of endometriosis-like symptoms and features have been recorded since antiquity [13], and while the disorder was first formally differentiated in the 1920s [14], current knowledge of its development, evolution and connection to infertility and pelvic pain is still deficient due to a lack of funding and multidisciplinary expertise [15]. The causes of endometriosis are not definitively known, there is no cure, the removal of affected organs does not guarantee remission, and there are currently no effective non-invasive diagnostic methods.
Consequently, average time to diagnosis in 10 surveyed countries is between 6.7 to 11.7 years [16][17], and it has been estimated to cost the US economy at least $18.8 billion and the UK economy £8.2 billion annually.
Common symptoms of endometriosis include chronic pelvic pain, painful menstruation
(dysmenorrhea), painful intercourse (dyspareunia), painful bowel movements (dyschezia) and painful urination (dysuria) [18][19][20]. Pelvic pain manifests most often in the loins, lower abdomen, lower back and thighs [21]. Pain severity can vary widely between patients and is uncorrelated with disease severity [18]. Endometriosis appears to be responsible for chronic pelvic pain symptoms in more than half of confirmed cases [22].
Sensation of pain can vary widely, for example from dull to sharp to throbbing, with some patients reporting burning and hypersensitivity [21]. Pain can be exacerbated by physical activity, often worsens over time and can change in sensation. Periods of particularly intense pain are dubbed ‘flares’
or ‘flare-ups’ [23]. Occurrence is unpredictable, and it can be either intermittent or continuous in relation to an individual’s menstrual cycle. The often metaphorical nature of endometriosis-related pain along with a lack of adequate assessment tools often frustrates its communication and
comprehension [24]. A “small but significant” correlation between symptom frequency and lowered subjective wellbeing for endometriosis sufferers is asserted in one study by Rush et al. [25].
2.1.2 Pain measurement research and pain scales
Chapman et al. [26] introduce a widely cited 1985 overview of pain measurement research by stating that progress in the field has been slow because pain is a complex perceptual experience that can be quantified only indirectly, a statement which holds true today as there are still no validated objective markers of pain that can be recommended for clinical use [27]. Four types of research procedures are identified by Chapman et al. for indirect quantification of pain that emerged from human studies in the 20th century: pain threshold definition, rating scale methods, magnitude estimation procedures and laboratory task performance measurement. Pain threshold research involves progressive stimulation of a human subject to identify a point on a continuum that separates painful and non- painful experience. A second point separating tolerable and non-tolerable pain can be identified to produce a pain sensitivity range between these two points. Rating scale methods ask subjects to rate an experienced stimulus on a structured, categorized scale which may or may not include a pre-pain range. Some scales attempt to be strictly quantitative (unidimensional), while others incorporate a qualitative aspect such as emotional or aversive effects of pain (multidimensional). Magnitude estimation attempts to elicit a mathematical relationship between different pain stimuli by deriving a unique power exponent for each stimulus that can be used to define relationships between stimuli.
Human performance measurement observes changes in subject behaviour in the presence of various stimuli.
Of these four categories, performance measurement and rating scale methods have the widest adoption in clinical practice due to the relative ease of their administration and their complimentary nature: they are often performed in parallel. Performance or behavioural measurement in a clinical setting involves observation and/or self-reporting of patient activities that are quantified with respect to varying levels of pain. Rating scale methods are administered in a clinical setting for patients to either self-assessed pain itself or self-assessed pain relief offered by analgesic treatment.
As research on clinical self-assessed pain scales has progressed, more attention has been afforded to the measurement of pain itself over measurement of pain relief, as well as to the emotional and reactional components of experienced pain. A range of research-based self-assessed pain scales now exist to measure pain, with many aimed at a specific demographic or diagnostic context.
Unidimensional scales are more widely adopted in a clinical setting over multidimensional scales despite arguments that they underestimate the complexity of pain experience [28] and confuse intensity with emotional aspects of pain [29]. This literature study identifies three general
unidimensional pain scales as having received the most research attention: Visual Analogue Scales (VASs), the Verbal Rating Scales (VRSs) and the Numerical Rating Scales (NRSs) [30][31][32].
VASs are presented graphically to the patient as a 100mm line on which they mark a vertical stroke, after which the millimetre distance from the left side of the line is measured, giving 101 discrete levels of pain. NRSs can be presented either verbally or graphically with patients either stating or marking a number on a discrete scale to convey ordinal levels of pain, alternate ranges with minimum values of 0 or 1 and maximum values of 10, 20 or 100 exist in various adaptations.
Graphical representation can vary from a scaled line as in Figure 1 to numbers enclosed in boxes.
VRSs can also be presented verbally or graphically and use ordinal adjectives, in some cases
numbered, to classify increasing levels of pain. Adaptations of VRSs noted in research have 4, 5, 6, 7 or 11 increments.
One general multidimensional pain scale, the McGill Pain Questionnaire (MPQ), is relevant to this literature review due to significant research attention in both general and endometriosis-related contexts [33]. Its standard form is interview-administered and consists of four parts: a diagram with front and back views of a human model on which to draw areas of pain (a Pain Body Map or PBM), a Pain Rating Index (PRI), questions relating to the temporal nature of experienced pain, and questions answered using a Present Pain Intensity (PPI) scale.
The PRI is 78 pain descriptors organised into 4 subscales and 20 subclasses: sensory (subclasses 1–10), affective (subclasses 11–15), evaluative (subclass 16), and miscellaneous (subclasses 17–20) [34]. Each subclass is an ordinal scale of 2-6 words with corresponding point values, subclass scores are summed per subscale to give 4 subscale scores. For the temporal aspect of pain, patients are asked to select one or more of nine descriptors grouped into three occurrence patterns: continuous,
intermittent and transient before being asked to specify in their own words what alleviates and aggravates their pain. The PPI scale is similar to the VRS in that it attributes a 1-5 score to five ordinal adjectives (mild, discomforting, distressing, horrible, excruciating) and is used to answer 6 questions relating to pain intensity. A short-form adaptation (SF-MPQ) also exists consisting of 15 words organised under 2 subscales and 2 subclasses, a one-questions PPI, and a VAS [35][34].
Figure 1: Graphical comparison of NRS-11, VRS-4 and VAS. Adapted from [28].
Much research exists studying the effectiveness of unidimensional pain scales for measuring pain in various contexts. VASs receive the most research attention due to their apparent precision and simplicity, however it is noted that most patients do not discriminate intensity with precision beyond 9 or 10 levels [30], often rounding to the nearest multiple of 5 or 10 [36]. The 0-10 NRS (NRS-11), the most used of its class, is thought to have adequate enough specificity [37] and good performance in its central 2-8 range [38]. Hjermstad et al. conclude a systematic literature review of pain scales stating that the VAS, NRS-11 and VRS-7 all perform well in different contexts and that the correct choice these depends on the conditions of its use [30].
2.1.3 Pain assessment for endometriosis
In a systematic literature review Bourdel et al. identify 9 scales used in the assessment of
endometriosis-related pain, the four most prevalent being VASs, VRSs, NRSs and the endometriosis- specific Biberoglu & Behrman (B&B) scale [39]. The 0 to 15 B&B scale [40] compares scores tabulated from patient self-assessment of pelvic pain, dysmenorrhea and dyspareunia together with professional assessment of pelvic tenderness and hardening (induration). Of these four, VASs and NRSs are recommended over VRSs and B&B scales for their balance of ease of administration, patient satisfaction, detection of response to treatment and low bias.
Optimal pain scale in endometriosis
• Takes account of endometriosis pain specificities (such as menstrual pattern, dyspareunia)
• Is adequately described, uniformly administered, validated and reliable
• Is easy to administer and score / not time consuming
• Can be self-administered
• Has the concept of responder feasible/ Minimal Clinically Important Difference (MCID) included
• Is appropriate to low literacy patients
• Has worldwide translation
• Access comorbidities should be captured
• Has a ‘not applicable’ box (for symptoms such as dyspareunia)
• Captures analgesia and complementary treatments
• Has the possibility of daily pain assessment
The 2008 international Art and Science of Endometriosis meeting convened by the National Institutes of Health and American Society for Reproductive medicine recommended daily ratings of pelvic pain and dysmenorrhea using an 11-point NRS and daily recording of bleeding using a ‘none, spotting, light, heavy’ scale for primary outcome measurements in clinical research [41]. Gerlinger et al. recommend daily electronic assessment using either VAS or NRS together with a bleeding diary and a disease-specific quality of life instrument [42]. Bourdel et al. propose criteria (see Figure 2) for an optimal pain scale in endometriosis that specify daily pain assessment and accounting for
“endometriosis pain specificities” such as menstrual pattern and dyspareunia [39]. Fabbri et al. argue that multidimensional approaches are required to analyse clinical histories of endometriosis patients and conclude that the MPQ appears valuable as a follow-up parameter to assessing postoperative improvement in pain [43]. Bullo identifies a need among endometriosis sufferers for assessment tools
Figure 2: Bourdel et al.’s criteria for an optimal pain scale in endometriosis. Adapted from [39].
that allow for better descriptions of pain beyond pain scales alone, such as indication of pain location and type [24]. Droz & Howard find that the SF-MPQ has a potential usefulness in ruling out diagnoses on chronic pelvic pain assessment [44], possible aiding more timely diagnoses of endometriosis.
Ballard et al. identify common adjectives and phrases used among one cohort of endometriosis suffers and find that throbbing pain and dyschezia are likely symptoms endometriosis [45].
2.2 Related research-informed software
This section describes existing research into software that measures pain via a visual drawing feature or concerned with endometriosis in particular. Section 2.3.1 details existing research on CPBMs and section 2.3.1 details existing mHealth apps targeted for an endometriosis context.
2.2.1 Computerised pain body maps
CPBMs are interactive, digital implementations of earlier paper-and-pen-based PBMs used as a diagnostic aid to pain management. CPBMs use a digital interface to indicate or draw areas of pain on a 2D or 3D model of a human body. Jaatun & Jaatun present a 2016 review of existing research driven CPBMs in the literature [46]. Of these, two aim to measure pain outside a particular demographic or diagnostic context, two are intended for patients with cancer-related diagnoses, one is aimed at both the aforementioned contexts, and one is aimed at wheelchair patients with lower back pain. One of the reviewed applications for breast cancer survivors digitizes drawings on PBMs but does not involve drawing using a digital interface and is therefore excluded from this analysis. The majority of applications are non-mobile and 2D, one is non-mobile and 3D, one is mobile and 3D, and one is designed for use on a tablet and is 2D.
Each application approaches implementation with a unique design method. Wilkie et al. [47]
provide a non-mobile digital implementation of the McGill Pain Questionnaire, a component of which involves drawing areas of pain on a 2D model using a mouse or touchscreen. Serif et al. [48], Ghinea et al. [49], Spyridonis and Ghinea [50], and Grønli et al. [51] present a series of research on a mobile implementation using a segmented navigable 3D body model. The latest design iteration is
implemented on the Android platform and incorporates gesture and accelerometer input to orient the model by pinching the screen to zoom and tilting the device to rotate. Users select one of five pain types and then indicate four levels of pain intensity by tapping repeatedly on the same segment.
Jamison et al. [52] present a non-mobile implementation with a fixed 3D model that is rotatable on mouse input. Users click to mark a single red point of worst experienced pain on the surface of the model and then indicate intensity by clicking on buttons to increment or decrement a 0-10 scale that is displayed to the right of the model. A cross-sectional view at the indicated point is then displayed on which users click again to mark point depth. Following indication of the point of worst pain, users are returned to the exterior view of the model on which they can click and drag to draw patterns of red points on the model. Dragging over existing points deepens their hue to indicate a greater pain intensity.
Lalloo and Henry [53] detail a non-mobile web-based implementation of 2D model with front (anterior/ventral) and back (posterior/dorsal) views on which users place icons that indicate different types of pain. These five types (burning, freezing, squeezing, lacerating or aching) were selected based on central poststroke pain literature which was the particular research context. From a panel
displayed to the right users drag-and-drop icons representing each pain type on to perceived points of pain on the model. Buttons displayed near the model’s hands and feet allow zooming for more precise placement on these areas. Users can navigate between four chronological views (Morning, Afternoon, Evening, Overnight) using tabs displayed at the top of the screen. Descriptions of the application in the original 2011 article detail a 1-10 scale for measuring intensity for each pain type, however this feature is absent when accessing the application in 2020 (available on flash-supported browsers at http://www.emiliemcmahon.ca/pain-tool.html).
Jang et al. [54] present a non-mobile implementation with four fixed views (anterior, posterior, left-facing, right-facing) of an anatomically accurate model on which users can draw pain in red colours. Users can navigate each view via panning and zooming, and drawing can be performed either freehand or using a ‘regional’ tool to draw rectangles. A dialogue box appears after drawing with options for indicating severity, anatomical location and frequency as well as an input box for recording notes. Pain severity is indicated with a 1-10 scale that is represented visually as progressively darker hues of red. Location options allow user to specify one or more anatomical organs using checkboxes (skin, bone, muscle/joint or neural). Radio buttons allow selection of one of three frequencies (brief, periodic or continual). Dialogue boxes appear in a timeline window to the right of the model where they can be dragged either left or right to indicate chronological order. Successive inputs are automatically grouped as one symptom instance, represented visually by lines connecting drawn areas, users can cancel automatic grouping by clicking on a button in the dialogue box.
Jaatun et al. [55] detail a mobile (tablet) implementation with static 2D anterior and posterior views presented on the same screen. Users first select a pain intensity from 1-10 by tapping on radio
Authors Interface View Drawing method Distinguishing features Pain scale Comments
Wilkie et al. Non-
mobile,
Mouse 2D, abstract Stroke - - Drawing feature not well
described Serif et al.,
Ghinea et al.,
Spyridonis and Ghinea, Grønli et al.
Mobile,
Touch 3D ,abstract Segment selection
Tilt to rotate Pinch to zoom Tap to increment Five pain types
4-step ordinal scale (VRS?) -
Jamison et al. Non-
mobile,
Mouse 3D, abstract Point series Cross-sectional view for
selecting depth 0-10 NRS
Lalloo & Henry Non- mobile,
Mouse 2D, abstract Drag-and-drop points Five pain types Iconographic
representation 0-10 NRS
Scale described in article, not present in current version of app Divisions of time not precise, subjective
Jang et al. Non-
mobile,
Mouse 2D, realistic Stroke
Freehand or rectangle selection
Pain duration Anatomical location Symptom grouping Timeline
1-10 NRS -
Jatuun et al. Mobile,
Touch 2D, abstract Stroke - 1-10 NRS Drawing feature not well
described Table 1: Design characteristics of CPBM apps in Jaatun & Jaatun [46].
buttons before drawing on the model. The implementation discussed here vary markedly in complexity, design and use case. Table 1 (p. 10) compares characteristics and includes research comments for aiding design.
2.2.2 mHealth for endometriosis
Instances of research-driven development of mHealth apps targeted for an endometriosis context are scarce. Gkrozou & Waters [56] present a survey of endometriosis-related mHealth apps available across app stores as of 2019, however the majority of apps reviewed are not evidence based (12 evidence based apps in total). Eight apps are identified as symptom trackers, but there is no mention of any app with a pain measuring feature. Searches for apps identified as evidence based by Gkrozou &
Waters as well as general searches in research databases for mHealth apps specifically for an endometriosis context during literature review yielded no research articles.
2.3 Engineering considerations
This section covers engineering knowledge pertinent to development of the cross-platform application prototype. Section 2.3.1 covers JavaScript, section 2.3.2 summarizes the design of the React library, section 2.3.3 details the React Native framework architecture, and section 2.3.4 details how gestures and animations are handled by React Native.
2.3.1 JavaScript, JSON and NodeJS
JavaScript (JS) is an interpreted, multi-paradigm programming language that incorporates first- class functions, closures, prototype-based object orientation and dynamic typing [57]. The constituent files of a JS program are called modules [58].
Functions [59] are first-class in that they may be assigned to variables as well as passed to or returned from other functions as references. Functions maintain references to the scope or lexical environment they are created in, forming closures. This allows a function reference to be passed to and called within other scopes without losing reference to the scope it was declared in. Functions may take default parameters that are used if no corresponding argument is provided.
Objects are prototype-based [60] in that instead of being instanced from abstract, pre-compiled class and inheritance declarations they are parsed at runtime and inherit their initial state directly from other objects. Objects are strictly collections of key-value pairs called properties that can be of any data type, and all objects have a hidden property that references another prototype object from which initial state is copied. Successive prototype references form prototype chains that allow objects to access properties from all ancestor prototype objects. The root of any prototype chain is the default Object prototype, and all non-primitive data types such as arrays and functions are themselves objects that inherit from this prototype. A class keyword exists in JS only as syntactic sugar for declaring prototypical objects in a class-like format [61].
JS was initially adopted for the purpose of dynamically updating web browser views and running client-side web application logic. Major implementations or engines include V8 (Chrome),
JavaScriptCore (Safari), SpiderMonkey (Mozilla Firefox) and Chakra (Internet Explorer). The JavaScript Object Notation (JSON) data model was created to facilitate communication between client-side JS and other server-side languages using the universal string data type [62]. JSON APIs available in each language convert between strings and each language-specific equivalent of the JS object data structure [63].
In web environments JS acts as a scripting language in the sense that it is interpreted by the browser engine for automating a range of tasks that require interfacing with a variety of external APIs.
NodeJS is a runtime environment that enables the execution of stand-alone JS programs by
embedding the V8 engine in a server runtime environment and providing a collection of open-source libraries that assist with range of program development tasks [64]. Libraries are groups of modules called packages by the NodeJS community; these are accessed via a CLI called the Node Package Manager (NPM) [65]. NPM and the package design pattern are not restricted to the NodeJS architecture and are used across many other frameworks and SDKs for managing third-party JS modules.
JS engines are single threaded in that only one command is processed at a time on a single call stack, though all JS runtime environments allow for asynchronous code execution by implementing a queueing system monitored by an event loop [66]. Instead of blocking, calls to external APIs specify callback functions named tasks that are scheduled to execute once the external API returns. Tasks from returning external API calls are pushed to a queue to be subsequently popped by the event loop onto the call stack whenever the call stack is empty.
JS provides a Promise API [67] as an implementation of the asynchronous callback pattern that offers additional functionalities and a more human-readable syntax. A Promise is a stateful object that encapsulates the status and return value of an asynchronous call. Asynchronous calls can immediately return a Promise with a status of ‘pending’ which subsequently changes to ‘fulfilled’ once the call completes successfully or ‘rejected’ if the call fails. Promise methods that themselves return Promises are used to handle state outcomes: .then and .catch handle fulfilled and rejected states, while .finally runs regardless of state outcome. JS provides the async and await keywords for coding functions that involve Promises. The async keyword is prepended before a function declaration or expression to allow the await keyword to be used within the function body. The await keyword is prepended to calls that return Promises.
In the JS runtime environment Promises are handled by the event loop as a separate queue of microtasks which take precedence over tasks: the microtask queue is always emptied before the task queue is accessed [66]. This API and architecture allow Promises to be chained for execution in a somewhat synchronous manner. Maintainers of external APIs choose themselves whether to return callback functions or Promises depending on use case.
2.3.2 React Native and React design principles
React Native is a development framework that allows for cross-platform execution of JS-coded applications. It offers efficiency in development of cross-platform apps by replacing multiple native codebases and development environments with a single JS codebase that is interpreted natively on each platform. Supported platforms include smart television operating systems AndroidTV and tvOS and personal computer operating systems macOS and Windows, though it is most widely adopted in mobile app development for Android and iOS.
React Native uses React, a JS library for web application and user interface (UI) development that is designed to optimise view rendering using the Document Object Model (DOM) specification.
The DOM is a mutable, tree-structured interface of nodes used in various web-related processing tasks, predominantly the rendering of views by internet browsers [68]. After parsing from an Extensible Markup Language (XML) or Hypertext Markup Language (HTML) file, each node in the DOM can be accessed and manipulated by scripting languages (predominantly JS) to dynamically change its structure. XML and HTML files convey tree structure by nesting units of code called elements which correspond to DOM nodes. Elements receive parameters called attributes and are delimited using symbols called tags. Start and end tags are used for elements that enclose nested content with attributes being declared in the start tag. Self-closing tags are used for elements that do not take any children.
React’s core concepts of reconciliation, state and component-based design are inspired by the design of the DOM, XML and HTML specifications and address inefficiencies particular to the DOM rendering environment. When the DOM is used to render views, each manipulation is followed by calls to a rendering API to update the appearance of affected nodes, making DOM manipulations programmatically expensive. Additionally, the DOM API by design favours more broad manipulations to groups of nodes over targeted manipulations to single nodes and offers no method to track DOM state. This can result in sub-optimal performance in more complex web applications where nodes that do not experience any state change are updated via the DOM due to poor state management.
React addresses this problem with reconciliation, introducing a custom tree-structured data model of the view and an algorithm to differentiate (diff) between tree model instances [69]. On application state change, React builds a new tree model of the updated view and diffs it against an existing tree model of the current view to obtain only those nodes that experience a net state change.
Only after reconciliation is the DOM accessed to update net state change nodes.
React organises code into nestable units called components, each component correlates to a cohesive UI element or feature and contains code for both its appearance and logic [70]. Component structure is coded using a custom markup language called JavaScript XML (JSX) which is based on the design of XML and HTML. Component elements are delimited by tags and take parameters dubbed properties or ‘props’ which are used to pass data unidirectionally from parent components to child components. Each component can be assigned a set of variables that constitute its state, and the mutation of any stateful variable triggers reconciliation.
Components are coded as functions or by using the JS class keyword to extend from the React.Component object prototype. Function components implement state and state-related procedures using a ‘hooks’ API [71]. Hooks of note to this degree project are dubbed useState, useEffect, useReducer and useRef. The useState call takes an initializing value, assigns it to a stateful variable and returns it along with an associated setter function. Variable and setter can then be unidirectionally passed as props between components to be used in events that either observe or cause state change.
The useEffect call is used to define events that trigger immediately after a component is
rerendered. The first parameter of useEffect is a callback function that defines the event. The second optional parameter is an array that can limit the event to triggering only if certain stateful variables have changed. If no array is provided, the effect is triggered only once after the component’s initial render. If an empty array is provided, the effect is triggered after every render.
The useReducer hook can be used to manage the state of more complex data types. Reducer functions receive a stateful variable and an action variable and return an updated state variable based on data contained in the action variable. The useReducer call takes a reducer function and an initial state and returns a stateful variable and a dispatch function. The dispatch function is then used to update state by passing in action variables.
The useRef call takes an initial value and returns a reference variable where the contained value can be accessed via the .current property. Reference variables of this type are used in React to pass data that is independent of state, such as animation values.
2.3.3 React Native architecture
React Native implements React design principles using a custom runtime environment that is designed to execute across multiple platforms in place of the web-specific DOM rendering
Figure 3: Flow of events between threads during state update in React Native architecture.
environment. It offers a JS API that interfaces with each platform’s native functionalities for performing many common development tasks. Custom APIs for accessing native platform
functionalities not exposed by the React Native API can be created using purpose-built modules called Native Modules.
The runtime environment of a React Native app (see Figure 3, p. 14) consists of a single JavaScript thread running on a JavaScriptCore engine that communicates via JSON with multiple native threads over an asynchronous bridge [72]. The bridge acts as an unprioritized message queue and has a finite capacity. On application initialization the JavaScript thread is spawned from a native main thread along with a thread for handling UI reconciliation and additional threads for running Native Modules. The JavaScript thread uses the React library to execute application logic, handle component state changes and perform reconciliation, the results of which are communicated to the native side via the bridge as a stream of commands. These are interpreted into native UI commands by the layout thread which uses tree data structures to reconcile the appearance and layout of each node. A native interface called View Manager is implemented by classes to consume commands from the JavaScript thread and produce corresponding shadow nodes which are structured into a shadow tree. A layout engine called Yoga consumes the shadow tree to produce a tree of Yoga nodes which include both appearance and layout data. The main thread then consumes the tree to render each node on screen. View events are captured by the main thread and communicated to the JavaScript thread via the bridge.
2.3.4 React Native animation and gesture handling
The React Native architecture encounters performance challenges when performing gesture and animation tasks. Animation in React Native involves the manipulation of UI elements that can be independent of the reconciliation process and occur over a series of intervals called frames. Displaying at least 60 frames per second (fps) or 1 frame per 16.67 milliseconds (ms) is the gold standard for ensuring that animations appear smooth to the human eye [73]. Mobile platform hardware synchronizes application rendering cycles with predefined display refresh rates to prevent a phenomenon called screen tear where data from multiple frames are displayed in the same render.
When an application fails to render a frame within the 16.67 μs time limit for a 60 fps refresh rate, platform hardware delays displaying the frame until a later refresh cycle and continues to display the preceding frame, a phenomenon called frame drop [74]. Frame drop results in animations appearing to lag or skip, or in animation jargon ‘jank’ [75], which contributes to a poor user experience.
Animations created with the default Animation API in React Native are coded declaratively and interpreted into a series of frame-by-frame operations by the JS thread, with each frame render requiring one pass through the React Native architecture. At the commencement of each new frame interval, the native main thread requests animation commands from the JS thread. The JS thread then executes the particular frame’s animation operations which are interpreted into a series of native commands via the bridge for the native thread to execute.
Animation tasks impose an extra workload on threads in addition to default React Native processes such as reconciliation. Performance is impacted by the number and complexity of
animations, the processing power of the device CPU and the fixed capacity of the bridge’s message queue. Slow JS thread execution and/or bottlenecks on the bridge can result in the 16.67ms time limit being exceeded and frames being dropped (see Figure 4, p. 16).
One solution to the animation performance limitation involves the JS thread serializing all operations and transmitting them as a single batch of interpreted commands to the native side when animations are triggered, allowing the native main thread to subsequently execute animation
commands independently of the JS thread. This ‘native animation’ solution is however limited to only a subset of animation calls in the default Animation API as a consequence of its design [76]. A more complete solution is offered by the third party React Native Reanimated package which allows serialization of any animation operation using a more complex and imperative API [77]. Animations are coded in JS using sequences of generic calls that interface more directly with native UI methods and are serialized as described above.
Gestures are predefined sequences of touches to a device screen that trigger application events. In React Native, interaction with the device screen is captured as a stream of touch events by the main thread, and sequences of touch events are interpreted into gestures by either the main thread directly or the JS thread via the bridge depending on gesture type. React Native provides a set of components for processing certain gestures that have cross-platform native support, where the native main thread can recognize the gesture directly before signalling the gesture event to the JS thread. Other gesture events are individually coded using the Gesture Responder System and PanResponder APIs for recognition by the JS thread [78][79]. The native main thread communicates the stream of touch events to the JS thread via the bridge which in turn consults gesture related code to recognize custom coded gesture events.
The default React Native architecture and gesture handling APIs encounter inconsistencies when UIs are guided by a combination of native and custom gesture events [74][80]. The native main thread and JS thread both monitor the single stream of touch events in parallel without any protocol for prioritizing or resolving gesture events that are triggered by identical touch sequences on the separate threads. This can result in unpredictable UI behaviour when layering native and custom gesture events that can share identical subsequences, for example embedding a slider controlled by a drag gesture in a side menu that is controlled by a swipe gesture.
Non-native animations suffer from poor performance when guided by gesture events as two traversals of the bridge are required to render every new animation frame: the first traversal from native to JS results in the interpreted gesture event, and the second from JS to native transmits the corresponding animation commands for the animation frame.
Figure 4: An example of frame drop in React Native, where hatch marks represent 16.67μs intervals, black boxes represent animation processes and the white box represents a non-animation processes.
Gesture performance limitations can be addressed using the same method as with animations: by serializing and transmitting gesture handler logic to the native main thread for execution independent of the JS thread. Combining native gestures with native animations allows execution of all related logic to be handled exclusively by the native main thread without the need for bridge traversal or processing by the JS thread while also avoiding the parallel monitoring problem. The third party React Native Gesture Handler package implements this approach by offering a set of gesture event components that execute on the main native thread [81]. It is designed to work together with the React Native Reanimated package to implement gesture-guided animations that can execute entirely in the native realm. Each component implements a unique gesture and is wrapped around the UI component that is to be guided by it. Gesture handler components can be layered and have props for fine tuning how gestures are interpreted, allowing for predictable behaviour where multiple gestures guide the same view. Gesture logic is pre-programmed, with the ‘plug-and-play’ nature of the components saving development time.
2.4 Summary of findings
Some design decisions can be informed from existing research into CPBMs as well as pain
measurement both generally and in the context of endometriosis. The NRS-11 appears to be the best suited pain scale and could be complemented with multidimensional elements such as adjectives from the MPQs PRI. Pain characteristics such as type, depth, period and grouping implemented by other CPBMs could also be incorporated. An indication of abnormal bleeding recorded in tandem with pain symptoms is recommended by several sources to be essential for the dysmenorrhea context of endometriosis. Recording of other activities related to endometriosis related specificities such as dyspareunia, dyschezia and dysuria. Bourdel et al.’s criteria (see Figure 2, p. 8) can also be used to inform design decisions.
Given the architectural considerations of React Native, it is essential to prioritise the use of native gestures and animations to achieve a smooth user experience. The packages React Native Reanimated and React Native Gesture handler will be used in development to achieve this.
3 Methodology and Methods
This chapter presents chosen methodologies and methods that guide thesis research and project development. Section 3.1 is concerned with research methodology, section 3.2 is concerned with project methodology and section 3.3 specifies the development environment.
3.1 Research methodology and methods
This section is concerned with research methodology and methods. Research methodology literature is vast and sometimes contradictory with many overlapping terms and concepts, those presented here are based on well-cited interpretations identified during the thesis literature review. Section 3.1.1.
introduces case study methodology, section 3.1.2 introduces Action research methodology, section 3.1.3 summarizes characteristics of research methodologies and sections 3.1.4 and 3.1.5 present the details of the adapted research methodology and data collection method for this thesis.
3.1.1 Case study methodology
Case study is a research methodology that aims to investigate contemporary phenomena in their natural contexts [82]. Research proceeds by defining a research question together with an instance of a particular phenomenon as a case comprising of one or more units of analysis. Data on each unit of analysis is then collected in accordance with predefined protocols, after which it is validated and analysed in light of the research question in order to report findings or outcomes. Yin [83] organises this process into five distinct steps as detailed in Figure 5. Yin also distinguishes between holistic case studies with a single unit of analysis and embedded case studies with multiple units of analysis (see Figure 6), where classification of a particular phenomenon as either a case or a unit of analysis is influenced by the scope and direction of the research question.
3.1.2 Action research methodology
Action research is a methodology characterized by direct intervention and reflection in addition to traditional hypothesis forming and observation as means for researching a proposed problem or question [84][85]. A formal definition by Reason and Bradbury states “[Action research] seeks to bring together action and reflection, theory and practice, in participation with others, in the pursuit of practical solutions to issues of pressing concern to people” [86]. It is a cyclical, iterative process
1. Case study design: objectives are defined and the case study is planned.
2. Preparation for data collection:
procedures and protocols for data collection are defined.
3. Collecting evidence: execution with data collection on the studied case 4. Analysis of collected data 5. Reporting
Figure 5: Case study research process.
Adapted from [52].
Figure 6: Holistic (left) and embedded (right) case studies.
Adapted from [52].
focused on incrementally improving a situation or solving a problem while simultaneously building upon academic knowledge.
The five steps of each Action research cycle are Diagnosing, Action planning, Action taking, Evaluation and Learning [87]. Figure 17 presents these steps along with inputs and outputs of the Action research process. Diagnosing replaces the detailed problem formulation traditionally performed at commencement of a research project by instead defining an immediately actionable issue from the prevailing context at the beginning of each cycle. Action planning defines protocols for collecting and validating data and decides which interventions shall be performed on the chosen issue during Action taking. Evaluation analyses data for potential outcomes that are then documented during Learning. Each cycle has the potential to produce new knowledge and insights that contribute to the next, and Action research is focused on accommodating changes to context that can occur from cycle to cycle. Staron [87] suggests each cycle of a software Action research project lasting 1 month, for a total project time of 3-6 months.
3.1.3 Characteristics of research methodologies
This section defines characteristics associated with various research methodologies, with particular focus on the context of software engineering research. These are not exhaustive or authoritative definitions as differences and overlaps in classification arise between different authors and branches of science. Section 3.1.3.1 outlines classifications of research purpose, section 3.1.3.2 presents a system of classifying research perspectives, section 3.1.3.3 defines data collection classifications and section 3.1.3.4 briefly defines the concept of research process.
3.1.3.1 Research purpose
Research purpose is what drives and defines a line of inquiry into a particular phenomenon. Purpose is essential to choosing a methodology that best serves the research process. Robson [88] classifies research purpose into four categories:
Figure 7: Action research methodology with inputs and outputs. Adapted from [57].
• Exploratory: finding out what is happening, seeking new insights and generating ideas and hypotheses for new research.
• Descriptive: portraying a situation or phenomenon.
• Explanatory: seeking an explanation of a situation or a problem, mostly but not necessarily in the form of a causal relationship
• Improving: trying to improve a certain aspect of the studied phenomenon.
Research purpose is reflected in the research question that is defined at the beginning of a research project. Easterbrook et al. [7] define a system of categorisation that connects purpose to question type as presented in Table 2 below.
Question category Question type Question example
Exploratory Existence “Does X exist?”
Description and Classification “What are the properties of X?”
Descriptive-Comparative “How does X differ from Y?”
Base rate Frequency and distribution “How often does X occur?”
Descriptive-Process “How does X achieve its purpose?”
Relationship Relationship “Are X and Y related?”
Causality Causality “Does X cause Y?”
Causality-Comparative “Does X cause more Y than does Z?”
Causality-Comparative Interaction “Does X or Z cause more Y under one condition but not others?”
Table 2: A categorisation of research questions. Adapted from Easterbrook et al. [7].
3.1.3.2 Research perspective
The validity of data and analysis depends on the research perspective which determines what is accepted as empirical truth. In questions of truth, philosophy distinguishes between the concepts of epistemology and ontology, or the nature of human knowledge and its acquisition versus the true nature of existence irrespective of how human understand it. Easterbrook et al. [7] defines four dominant philosophical stances on empirical truth:
• Positivism states that knowledge is incrementally built from inferences based on verified observations of a phenomenon’s component parts. Positivist methodology is based on precise theories from which hypotheses can be extracted and tested in isolation.
• Constructivism or Interpretivism asserts that human context cannot be separated from knowledge, and that interpretation of theory is as important as the truthfulness of the observations on which it is based. Methodology is focused on understanding how individuals and/or groups make sense of a phenomenon.
• Critical theory focuses on the role of scientific knowledge in freeing people from restrictive systems of thought. Research is conducted in order to empower a chosen community within society.
• Pragmatism acknowledges that all knowledge is incomplete, and its value depends on the methods by which it was obtained [89]. Truth is relative and based on consensus and rational argument, and knowledge is judged based on how it contributes to solving practical problems.
Research perspective is also formed from the method of reasoning used:
• Deductive reasoning aims to test an existing theory by proceeding from general principles to specific instances.
• Inductive reasoning aims to develop theories by proceeding from specific observations to general conclusions.
Research can be conducted from multiple perspectives in order to reduce bias. Triangulation is the practice of taking multiple perspectives on research objects [90]:
• Data (source) triangulation: using multiple sources of data and/or multiple instances of data collection
• Observer triangulation: enlisting multiple observers during research
• Methodological triangulation: using multiple methods for data collection (e.g. both quantitative and qualitative)
• Theory triangulation: examining multiple theories or viewpoints 3.1.3.3 Data collection
Research data is classified according to the following types:
• Quantitative data is measurable and is expressed numerically or ordinally. Quantitative methods examine data relationships and patterns using statistics and formulae to compare and contrast.
• Qualitative data is approximate and characterizing and is expressed in language or
symbology. Qualitative methods seek to identify patterns in data and/or to code meaning to data according to a stated theory or hypothesis.
Classifications also exist for sources of data. Lethbridge defines a classification system particular to software engineering field research [91]:
• First degree: data collection from direct involvement with subjects such as interviews, focus groups or questionnaires
• Second degree: data collection from indirect involvement with subjects such as keylogging or software monitoring
• Third degree: data collection via analysis of existing artefacts or compiled data such as documented systems, logs or databases
3.1.3.4 Research flexibility
Anastas & MacDonald [92] and Robson [88] classify research process as fixed or flexible, where in a fixed research process all parameters are defined at the beginning of research while a flexible process allows for parameters to be changed as research progresses.
3.1.4 Adapted research methodology
The adapted research methodology for this instance of research is inspired by Case study and Action research methodologies and is defined according to criteria outlined in section 3.1.3. It is a flexible process-descriptive case study incorporating elements of action research, supported by third-degree qualitative data. The unit of analysis is the feature developed during the engineering project. It takes a pragmatist, deductive research perspective in that it focuses on solving a specific practical problem by applying more generalised knowledge and theory obtained during a literature review.
Figure 8 outlines the steps of the adapted research methodology, where rectangles are steps and circles are inputs and outputs of the research process. Case study design and data collection protocols are defined during the Case selection step. Evidence collection is inspired by the iterative, cyclical design of Action research, but on a much smaller scale: each cycle represents the identification and solving of a design/development subproblem belonging to an engineering project, with a cycle
duration of days as opposed to months. Each planning step involves drawing upon existing knowledge obtained during the literature review and identifying any new required knowledge in light of the specific subproblem to be solved, as well as outlining a development strategy to be followed during
Figure 8: The adapted research methodology with inputs and outputs.
execution. The execution step involves actual development tasks undertaken to solve the subproblem.
The evaluation step involves testing and validating each solution. The collation of solutions to all subproblems is given in the presentation of results, which is analysed in the discussion step.
3.1.5 Research method
In following the adapted research methodology, this thesis extracts two subquestions from the
research question and addresses them in different steps of the methodology. The overarching research question is then addressed by addressing each subquestion separately. The research subquestions are detailed in Table 3.
Research question How can a cross-platform, visual, gesture-guided and research-informed mHealth application for measuring pelvic pain associated with endometriosis be developed?
Subquestion 1 What existing knowledge can inform development of the described application?
Subquestion 2 How can relevant application features be developed using acquired knowledge?
Table 3: Research question and subquestions
Subquestion 1 is addressed in the literature review step of the adapted research methodology, which is detailed in Section 2. The literature review summarizes relevant knowledge from two categories: existing pain, endometriosis and CPBM research that can be used to inform design decisions and software engineering knowledge required to implement design decisions as a cross- platform application prototype. The findings of the literature review are used as the basis for addressing Subquestion 2.
Subquestion 2 is addressed in the evidence collection step of the adapted research methodology, the results of which are presented in Section 4. Each evidence collection cycle represents the
definition, implementation and evaluation of a single research-informed software requirement. Each cycle’s planning phase involves the definition of a cohesive software requirement from the body of first category design-informing knowledge presented by the literature review. This is done with the assistance of a MoSCoW analysis as described in Section 3.2.2. The execution phase involves the application of second category software engineering knowledge to implement the software
requirement as a functionality in code as well as documentation of the process. The evaluation phase involves manual testing of the functionality for reliability as described in Section 3.3.3.
3.1.6 Research evaluation
Shaw [93] identifies 6 types of evaluation used in software engineering research, of which the
‘example’ method is employed to evaluate the results of this thesis. Evaluation by example is used in software engineering research that presents a new development method, where a functioning “slice of life” system or program validates the design and implementation outcomes discussed in the research text. The adapted methodology employs this evaluation method in each cycle of the evidence
collecting step via a thorough manual testing process as described in section 3.3.3. The completed and functioning prototype serves as an evaluating system for the collated result of the thesis, which describes a development method for a prototype for assessing endometriosis-related pelvic pain.
