Keywords

1 Introduction

Digital health can best be regarded as an encompassing term covering a wide range of ICTs applied to healthcare, wellness and ambient-assisted living [1]. It is a rapidly progressing field and, while spending on pharmaceuticals has declined recently, global spending on ICT in healthcare is predicted to have grown to 18 billion Euros by 2017. Digital healthcare initiatives, especially the virtualisation of healthcare, is high on the agenda of most national governments within European, with a view to managing resources and budgets [2], particularly in response to growing and aging populations. According to Thummler [1] the growth of the digital health industry has been rapid in recent years, facilitated by a move towards distributed patient-centered care, where the need for physical contact between patients and professionals is reduced.

Mobile health (m-health) refers more specifically to mobile computing, medical sensor and communication technologies for health [3]. According to Istepanian [4], the concept of m-health was first introduced in 2003 and has since been of increasing importance in key areas of healthcare policy, including wellbeing, disease management and diagnostics. Given that mobile technologies have become increasingly commonplace in the everyday lives of the population and more accessible in terms of cost [5], the use of these technologies present a potentially affordable technological solution to epidemiological and health-based challenges.

2 User Behaviour Analysis Software and the Diagnosis and Monitoring of Autism Spectrum Disorders Within the UK’s National Health Service

According to the UK’s National Autistic Society, approximately 700,000 people in the UK are living with autism, with many remaining undiagnosed and unsupported [6]. Whilst the average age of diagnosis of autism has reduced [7], early intervention remains key to improving prognosis. Given the importance of early diagnosis and with estimates of prevalence being between 1 in 68 and 1 in 88 children [8], accurate and effective identification of ASD in young children remains a pressing public health issue [9]. As there is currently no single biological marker or test to diagnose autism, cases in the NHS are typically discussed at multi-disciplinary panel meetings, during which a number of healthcare professionals, including speech and language therapists, pediatricians and psychologists, will present their findings based on their interactions and observations of the child (Fig. 1). Where there is agreement amongst the majority, a diagnosis of autism may be reached [10].

Fig. 1.
figure 1

The diagnosis of ASD within the NHS

Full size image

The accuracy and stability of a diagnosis is dependent, therefore, on reliable and comprehensive information being obtained from multiple sources [11]. It is not a process without difficulties, however, particularly when observing children under 36 months [9], as it relies heavily on snap-shot observations and accurate reporting. Within the NHS, there is considerable pressure on resources, meaning that the period of time between appointments is increasing. This can result in a subsequent delay in achieving a diagnosis, which is usually necessary for families and schools to be able to access many support services. The ability to gather evidence between appointments, both at home and within an educational setting, therefore, may provide a valuable way to hasten the diagnosis process and reduce pressure on stretched publicly funded healthcare services [5]. Consequently, there is an emerging area of research and a number of recent initiatives in using mobile technology to collect evidence to support the diagnostic process and the ongoing observation of autism in children, with a view to identifying support strategies and managing their effectiveness [12,13,14].

The wide availability of touchscreen technology means that children are now able to interact with computing devices from a much earlier age. User-behaviour analysis tools such as Harimata [12] claim to be able to collect data about how the user, in this case, the child, interacts with the device in terms of physical gestures or games designed specifically to detect possible signs of autism [5, 13]. Similarly, m-health software solutions such as NODA [13] can be used to guide the parent or care-giver through the collection of video evidence of behaviours within the home or educational setting, which can then be uploaded via a wireless communication link and subsequently evaluated by a health-care professional in advance of an appointment (Fig. 2) [12].

Fig. 2.
figure 2

Communication link between mobile device and healthcare professional

Full size image

Although critical evaluation of the effectiveness of such software products falls outside of the scope of this paper, such m-health solutions offer a number of potential benefits, including:

  • A reduction in expenditure for appointment times,

  • A reduction in the number of appointments needed to secure a diagnosis,

  • The ability to collect evidence outside of the health care professional’s office.

In order for these software products to support the National Health Service, it is vital that the user-requirements engineering processes effectively capture the unique and evolving needs of the various professionals working within a dynamic organisation such as the NHS [5].

3 Requirements Engineering and Semantics

Software requirements are those properties a software solution must exhibit in order to address an organizational problem that the software solution aims to address [15]. Requirements engineering aims to bridge the gap between the social and technical worlds [1] and is a critical part of the software engineering process. Any errors at this stage of the software development process may result in negative effects on subsequent states of the project and a reduction in quality of the final software product [16]. Consequently, requirements engineering has become a well-established discipline, with a range of techniques and approaches having been developed over time [17], the popularity of many fluctuating in response to evaluation of their effectiveness and the evolving nature of the domains within which they are deployed.

Requirements engineering can be simply described as having two broad sub-disciplines of Requirements Management and Requirements Development (Fig. 3), which can be further broken down [18] as:

Fig. 3.
figure 3

Requirements Engineering (Wiegers and Beatty 2013) [18]

Full size image

  • Elicitation: activities associated with discovering requirements (e.g. stakeholder discussion, document analysis and prototyping).

  • Analysis: striving for a more precise understanding of each requirement and representing sets of requirements in various ways.

  • Specification: representing and storing the collected requirements knowledge in an organized manner.

  • Validation: confirmation that the requirements information will enable the development of a solution that meets stakeholder requirements.

Requirements management describes activities including:

  • A review of approved functional and non-functional requirements.

  • Evaluating the impact of proposed requirements changes and the incorporation of approved changes to the project in a controlled manner.

  • Ensuring the project plans match requirements as they evolve.

  • Tracing and tracking specific requirements within the project, including source code, design and tests.

4 Requirements Engineering Within Digital Health

Whilst digital health solutions demonstrate considerable potential for supporting healthcare professionals in patient-centred work [19], this is dependent on information systems and software solutions meeting the specific needs of clinical staff based within complex health organisations. The deployment of poorly designed systems within the context of healthcare can result in a failure to realise the anticipated benefits of digital health solutions, the squandering of already pressured financial resources and, potentially, the compromise of patient safety [17, 19]. For software engineers, then, the highly specialised nature of healthcare and the critically important nature of digital healthcare solutions in ensuring patient welfare, can present unique challenges at this critical phase of the software development process.

Given these challenges and the need for robust requirements engineering processes, there is increasing call from the various funding agencies in North America and Europe for industry-university collaboration project proposals on multidisciplinary research in to ways in which healthcare agencies are able to draw on the technological and financial benefits associated with digital health solutions [1, 17]. The European Union, however, recognise the need for further research in to Requirement Engineering strategies in order to ensure that digital health projects meet the robust standards that are required to ensure acceptance and adoption of new technologies [1, 2]. As is the case with other domains, requirements engineers may well encounter healthcare professionals or managers within the health service sectors who have different understandings and attitudes towards technology. Robust requirements engineering processes are more likely to result successful implementation of software solutions, increasing the likelihood of the adoption of new technologies.

The highly regulated aspect of digital health can, at least in part, be attributed to the need for consideration of legal and ethical issues surrounding responsibility towards patient safety, along with confidentiality, data protection and data security. Consequently, the software requirements process must ensure compliance and compatibility with the various EU directives and ISO standards that govern these concerns [24].

We suggest that user-behaviour analysis software to support the diagnosis of autism spectrum disorders presents a unique and useful case study for research in to requirements engineering processes. In the absence of a single biological marker to identify ASDs, diagnosis is dependent on a portfolio of evidence, which is then evaluated by a multidisciplinary team of healthcare professionals before a consensus is reached regarding a diagnosis. Furthermore, understanding of autism is continually evolving, with new diagnostic criteria and definitions of ASD and sub-categories of the condition being published as recently as 2013 [20,21,22]. The requirements engineering processes, therefore, should be iterative in nature and accommodate changes in clinical needs, criteria and knowledge. Whilst securing an accurate diagnosis of ASD is of paramount importance, there is less scope to compromise a patient’s physical safety in the case of error.

4.1 The Trend Towards Participatory Design and Stakeholder Involvement

Given the specialised and highly-regulated nature of the healthcare sector, it could be argued that methods of requirements engineering that draw on regular input from stakeholders are the most likely to be beneficial to the requirements engineering process, particularly during the first and critical phase of elicitation. Fricker et al. [23] conducted a survey on the software requirements engineering processes of software projects from multiple domains during 2012. There were 419 valid respondents and multiple answers were possible where more than one method was used. Requirements elicitation processes included:

  • Workshops (79% of respondents)

  • System Archeology (70% of respondents)

  • Requirements Reuse (64% of respondents)

  • Interviews (63% of respondents)

  • Document Analysis (50% of respondents)

  • Creativity (Workshops, idea castings, idea databases) (44% of respondents)

  • Surveys (12%)

  • Data Mining (6%)

  • Other (3%)

Although this survey included development projects from multiple domains, the results highlight the current popularity of stakeholder involvement in the requirements engineering process.

Within the context of digital health solutions to support the diagnosis of ASD in young children, however, the coordination of multidisciplinary teams with distinct organizational features can be challenging. Furthermore, time is a resource under considerable pressure, and so there may be little time to devote to interviews, workshops and other participatory methods of eliciting and validating requirements.

A small window of opportunity may exist in the regular cross-disciplinary meetings that occur, where paediatrics, psychology and speech and language therapy meet to discuss individual patients and agree on diagnoses where appropriate. These meetings are likely to have busy agendas and therefore may lend themselves to more esoteric methods of requirements elicitation such as observation.

Sørby [19] proposes that observation as a method of requirements elicitation might be carried our by medical students who are a natural feature of clinical appointments. Sørby goes on to suggest that students are likely to possess sufficient domain knowledge, whilst being able to devote more time and motivation to facilitate digital health projects. Within the context of the diagnosis of ASD, students are a frequently presence in appointments within the various stakeholder health services. Whilst this presents an interesting solution, it requires further exploration to evaluate its effectiveness within the context of the UK’s NHS.

5 Conclusions

There is a growing emphasis on digital health solutions to support changing healthcare models, with an increasing emphasis on patient-centred and patient-devolved healthcare. The relatively accessible cost of mobile technology such as smartphones and tablet computers, make m-health solutions a particularly interesting area of research and development. Despite the established nature of requirements engineering as a discipline, there is so far limited research specifically in to the requirements engineering within the domain of healthcare, where it could be argued that its success is critically important, with the potential for stretched finances to be squandered and patient safety to be compromised by poorly implemented software solutions.

We propose that further research in requirements engineering processes for healthcare is required and suggest that the development of user-beahviour analysis software to support the diagnosis of autism spectrum disorders in the NHS presents an interesting case study for such research. As this autism spectrum disorders require the intervention and observation of a multi-disciplinary team of healthcare professionals within a stretched public health service, novel methodologies can be explored within a complex organisational structure whilst supporting a pressing public health issue. It is likely that a mixed-methods approach to eliciting, modeling and managing software requirements will be required, including a return to methods that have since fallen out of favour (e.g. observation and surveys) in combination with novel approaches that emerge from this interesting field of research.