Keywords

These keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.

8.1 Introduction

When confronted with a real-world challenge, a manager quickly tries to zoom out to comprehend the bigger picture: who are the stakeholders, what are their needs, who will be the end users and what are the project constraints. This provides the foundation for everything that needs to be developed and serves as guidance for finding the right balance in the project management triangle, where a trade-off has to be made between the required time, quality and the cost of the project.

However, in the case of a digital health solution, the dynamics between the stakeholders is not one of a simple two-sided market, and the stakes are much higher than in typical consumer-facing projects. Indeed, a poorly designed, developed and deployed digital health solution can not only cause financial losses, wasted time and inconvenience, but also endanger lives and cause physical, as well as psychological damage (e.g. through leaked data due to inappropriate data security). This presents significant challenges and forces the project into the time-tested “slow development” paradigm, which tries to tread lightly through the project realisation, learning about and adapting to the development, regulatory, legal, ethical, data privacy and other challenges as the project progresses. The problem is further exacerbated by the fact that not many people possess the big picture of the digital health domain; thus, doctors are typically oblivious to developmental or regulatory issues and an analogous statement can be made about engineers. Several studies have shown that even certified medical equipment and devices can be easily reverse engineered and compromised, leading to severe consequences for patient privacy and safety.

The goal of this chapter is to outline the challenges in requirements engineering that are specific to digital health solutions and address them in the form of a guideline. The material is presented in the form of a recipe, further explained through a specific real-world case of a digital health application developed in cooperation between industry partners and health providers, which is currently being deployed in the University Hospital of North Norway.

Thus, this chapter tries to guide the reader through this multi-sided domain, through lessons we have learned the hard way and through months of time stuck in red tape. The remainder of the introduction gives a brief overview of the requirements engineering (henceforth RE) specifics in digital health and the digital health stakeholder landscape that can serve as a basis for the RE process. Section 8.2 provides a cookbook for the RE process, describing concrete steps for elicitation, analysis and requirements validation in more detail. Section 8.3 provides the lessons learned in a real-world implementation of a digital health solution and Sect. 8.4 reflects on how the implemented use case benefited from the recipes provided in Sect. 8.2. Section 8.5 provides the final summary and conclusions.

8.1.1 Defining the Domain

Digital health is an emerging field that brings together healthcare, medicine and modern information and communication technologies (ICT) to help patients manage illness and address their health-related problems, as well as enable medical personnel to help patients more efficiently. By relying on a plethora of digital technologies and solutions, most notably wireless sensors and devices, mobile connectivity and the Internet, social networking, genomics, medical imaging, big data processing techniques and use of health information systems [11], it helps eliminate the inefficiencies in the healthcare system and medical processes. In addition, it serves as the underlying enabler for increasing the general well-being of the population, prolonging life expectancy and enhancing the quality of life.

8.1.1.1 Requirements Engineering Perspective

In essence, the RE process tries to bridge the gap between the stakeholders and the project team through the steps of gathering (eliciting), analysing (documenting) and validating the requirements [2]. For each of those phases, a variety of methods can be used; typical methods of requirement elicitation include workshops, interviews, surveys, document analysis, reusing requirements of similar projects, system archaeology (i.e. study of poorly documented or undocumented legacy systems), data mining (inferring requirements from large datasets), observation, introspection and using the creative thinking process to arrive to a set of requirements. Once requirements are elicited, the analysis can be performed by modelling or prototyping the system, or using structured, object-oriented, problem domain-oriented or viewpoint-oriented techniques. Finally, the requirements and assumptions should be agreed upon, confirmed and validated. This is usually done through walkthroughs, simulations and reviews.

However, as illustrated, the RE practice is a very varied discipline in itself and when it comes to applying selected methods, a customised approach is needed for each individual domain. In this respect, digital health is fundamentally different in subtle ways from most mainstream domains, and has the following specialities [2–4]:

  1. 1.

    The context of use and the technology to be used are often poorly matched and balanced.

  2. 2.

    The stakeholder list is long and includes many possibly conflicting relations. This amounts to a lot of work with requirements elicitation, analysis and checking, and can introduce significant delays. Also, there is a high possibility of stakeholder resistance, which is usual in slow-changing and heavily regulated fields. For example, doctors are not always willing to invest the time and work necessary to adopt the solution that would in the long run benefit all stakeholders.

  3. 3.

    Since doctors and nurses, as well as the patients, together represent two of the most prominent user groups for the digital health application, their specific use cases need to be given a strong emphasis. Patients typically encompass the entire population with significantly diverse requirements; for example the elderly that may have little experience with digital technology have oftentimes poor eyesight and hearing, and can come into contact with the solution in different settings (in the hospital, in the office, at home, etc.). Meanwhile, the caregivers already have a workflow that may encompass clinic hours in their office, performing examinations or direct supervision, domiciliary visits, etc. Using observation as a requirements elicitation technique may prove especially valuable in such varied environments, and using modern tools to capture stills, audio or video of the process can be of great help in later requirements analysis phase.

  4. 4.

    Business case is typically a complicated one reaching beyond regular provider-consumer relationship in the fact that typically digital health services are offered free of charge to individuals as part of a greater care concept by a not-for-profit medical organisation, but involving also for-profit providers such as insurance companies and technology providers.

  5. 5.

    It is therefore vital for successful requirements development and delivery of an acceptable and useful solution to have good understanding of digital health specifics and contexts, as well as to understand social and emotional implications associated with the required socio-technological alignment.

To successfully cope with the digital health challenges, requirements should be developed by a multidisciplinary team that together possesses good understanding of the technology and the context and can cooperatively apply human-centred requirements development in a well-organised but flexible and creative process.

8.1.1.2 Stakeholder Landscape

Digital health is a truly multi-disciplinary domain that involves many stakeholders with different backgrounds, ranging from medical and healthcare to engineering, legal and social sciences. Before the requirements investigation phase it is crucial that the stakeholders and any possible conflicts among them be identified. Involving the stakeholders in the process of designing a solution is important regardless of the domain. This is to ensure that the end result is both usable and useful. However, due to the fact that medicine and, by extension, healthcare are heavily regulated, it is even more important that the stakeholder list also includes regulatory bodies, security, legal and ethics experts, as well as manufacturers and supply chain specialists. This can ensure that the final solution is also secure, safe to use, economically viable as well as legally and ethically sound.

Many stakeholder classification approaches exist in the literature, however [5] providing a nice basis for understanding the healthcare ecosystem by dividing the stakeholders into the following four groups:

  • Entities accepting care—Members of this group are the single most important reason for existence of the healthcare system; therefore they must be given special attention to ensure that the solution benefits them (directly or indirectly). In digital health, the group is represented by:

    • Patients: Not only hospital patients and outpatients, but also anyone that could require medical assistance in the future; the latter group is especially relevant in non-clinical, preventive and well-being use cases.

    • Next-of-kin: In most cases next-of-kin represents a secondary stakeholder group, except where they take on additional roles, such as being payers or caregivers.

  • Entities providing care—Providers are at the heart of medical decision-making. In particular, clinicians are expected to provide accurate diagnosis, choose appropriate therapy and monitor the resulting health outcome while maintaining good doctor-patient relationship and bedside manner. Providers can be further broken down into individuals and institutions. Individuals include medical personnel: clinicians (doctors, nurses, medical students), outpatient care providers and medical researchers. However, in the case of a digital health solution, this group also extends to the non-medical personnel, such as IT administrators and IT operation managers.

  • Supporting entities—They enable the health care system to function smoothly. The payers group does that by financing the providers (most commonly this means insurance companies and employers that pay for health insurance). Manufacturers group does it by designing and developing the solutions and the technology to enable new, better and more efficient processes, while the distributors take care of the delivery of goods and services to the users (either clinicians, their institutions, or the patients). This includes manufacturers of tangible products: pharmaceutical companies, biotechnology, medical devices and infrastructure, as well as manufacturers of intangible products (software): developers, designers and solutions architects.

  • Controlling entities—This group regulates the ecosystem in multiple ways to ensure that the standard of health care is high, and that the safety of the patients, as well as their security and privacy, is not compromised. Best practices are established based on the available scientific evidence that serve as guidelines for other stakeholder groups.

During the RE process, identified stakeholders are prioritised. Key stakeholders are the ones with significant influence and impact on the project, required resources or other stakeholders (e.g. a diabetology department that is setting up a digital health solution for their patients). Also, they are typically categorised as primary or secondary, depending on the way they are affected by the process and the solution: the primary group is directly affected (for example diabetes patients using the application), while the secondary group only feels the consequences of the actions and decisions indirectly (for example, next-of-kin). The digital health stakeholder landscape is presented in the diagram in Fig. 8.1.

Fig. 8.1
figure 1

Digital health stakeholder landscape breakdown

Full size image

Key challenges of each of the identified stakeholder groups are presented in Table 8.1, together with their expectations with regard to digital health solutions.

Table 8.1 Key digital health stakeholder groups, and their challenges and expectations with regard to digital health solutions
Full size table

8.1.1.3 Promising Digital Health Technologies

Recent technological trends in digital health consumer end indicate increasing adoption of self-care and health monitoring solutions that combine smart sensing devices (such as glucometers, pedometers, smart scales, and pulse-oximeters, with Bluetooth or other similar standard interfaces), cloud computing, smartphone and tablet-based applications based on Android and iOS platforms, as well as powerful web-based technologies (such as HTML5). In healthcare provider domain, electronic health record (EHR) systems, centralised web-based patient management and communication portals as well as intelligent healthcare ambient (such as sensor-supported operation theatre, digitised pharmacy) are gaining momentum. The importance and increasing strength of this technological field are in part driven by advancements and increasing availability of the latest commercial off-the-shelf technologies, and vice versa.

8.2 Requirements Inquiry in a Clinical Environment

In this chapter, we provide a balanced set of guidelines for implementation of the RE process in a project that has the following characteristics:

  • The targeted solution is one in the digital health domain, where the quality implications of poor requirements handling are particularly serious.

  • The targeted system is software intensive and human centred rather than market driven, and it comes together with a business model that is typical for hospital-provided healthcare services; it consists of applications, centralised server-side components as well as legacy IT infrastructure specific to healthcare, and it utilises web and cloud technologies.

  • The project is constrained in time with well-set boundaries and requires fast, efficient and rather creative RE process with possibility to reiterate selected or all RE sequences in later phases of system engineering.

The guidelines are based on own experience of implementing RE best practice in software-intensive digital health. The guidelines are prepared as recommendations for engineering practitioners with a particular focus on challenges and specialities that are characteristic for digital health domain. Different aspects are addressed and crucial RE elements are discussed that will help in delivering a successful digital health solution, as summarised in Fig. 8.2.

Fig. 8.2
figure 2

Digital health RE elements and aspects

Full size image

There is one guiding principle underpinning the guidelines: the pragmatic approach focusing on the minimum feature set that is still able to satisfy the stakeholders. In today’s fast-paced and competitive environment, the key to success is to deliver the best possible solution in the shortest amount of time and with minimum spending. To be able to do so, use the RE process as a way to understand who your target stakeholders are, generate new ideas, design the solution, prototype it, expose it to the real world as soon as possible and learn.

8.2.1 Project Preparation

First, a multidisciplinary RE team needs to be assembled. In addition to RE engineers, architects, developers and designers, selected stakeholder representatives should also be part of your team. Consider involving a well-balanced mixture of healthcare specialists, patients and personnel, legal, regulatory and social sciences experts as well as business domain representatives. The multi-disciplinarity of the team will help you understand digital health expectations and challenges from different specialised perspectives and will lead you towards establishment of communication and shared understanding within the team itself as well as towards different stakeholder groups.

Due to the fact that digital health use cases present many interdisciplinary challenges, this will dictate the need not only for good intra-team, but also inter-team collaboration and communication.

Once the team is assembled, prepare a high-level description of the targeted digital health system. Called also a vision statement, it identifies the driving technologies to be considered and any major constraints related to your system, for example security and standardisation guidelines to be followed and potential ethical issues expected. This will be your guiding target for the remainder of the RE process, continuously evolving as you progress.

Discover which technologies are crucial for your system. Also, in bespoke software-intensive systems, such as digital health system, you should follow the established international standards and recommendations in preparing the architecture descriptions of systems and software. Security, privacy and data handling are of paramount importance, and you should take into account applicable regulation on national and EU levels. For EU, the European Legislation and specific national jurisdictions set guidelines for data handling and protection as well as provisions for its applicability to digital health. If you discover that actions are needed to obtain ethical approval or other similar permissions for your project, initiate the respective procedures immediately as they might take a considerable amount of time. Investigate standardisation and certification landscape for your digital health system. In particular, focus on standards and guidelines that refer to healthcare systems and medical devices. And finally, consider referring also to established standards and recommendations for implementing RE itself.

Next, plan for a project-specific RE. To cope with the challenging digital health characteristics and achieve high-quality outcomes, the requirements engineering process should be systematic and disciplined [3] yet flexible and open to accommodate creativity and innovation as well as to respond to project particularities and unexpected developments. Prepare the RE model and plan the requirements development sequence carefully. It is important to be explicitly aware of the particular steps in the RE sequence, even if they will be implemented implicitly. This will lead you to a well-organised and systematic RE implementation.

Plan your RE process iteratively and incrementally, with at least two cycles of design, prototyping and evaluations, as shown in Fig. 8.3. Use a hybrid process model that combines one comprehensive RE phase at the beginning of the project, which facilitates establishment of in-depth understanding of the digital health context and its particularities, and continuous RE iterations later in the project as part of the realisation of the system, which allows for agility with lightweight RE activities planned (at least) throughout system design and development phases. This might seem to contradict the agile approach but it allows for early discovery and comprehension of all relevant particularities that have vital impact on the design and prototyping of the system.

Fig. 8.3
figure 3

Iterative and incremental RE process

Full size image

Inside each cycle, consider implementing your RE iteration as a combination of the following activities:

  • Establishment of the vision and system context, stakeholder identification and profiling.

  • Requirements inquiry that confirms and details the vision and system context.

  • Requirements analysis and prototyping.

  • Vision, context and requirements documentation.

  • Requirements validation, negotiation and refinements to assure appropriate level of quality and trust.

The goal of these steps is to explicitly define, document and understand all relevant requirements at an appropriate level of detail, as explained in more detail in later sections. As you will proceed through the iterations, the steps will become more in-depth and intermediate deliveries will be more frequent. To cope with the complexity of the goal, allow iterations inside or across steps in the RE process as necessary and acceptable for the project timeline.

The plan should include also continuous monitoring of the RE process throughout the entire system life cycle, facilitating small adjustments rather than drastic changes and deviations. However, the planned RE process probably will not go entirely smoothly. Be prepared to continuously evolve and improve your selected model to accommodate particular developments of the project. Throughout the entire process, you should allow room for ad hoc opportunistic moments, requiring restructuring of the planned sequence or even reiteration of certain activities due to increasing complexity of the process.

Hereafter, different elements of RE practice are explained in more detail in the context of specialities related to the healthcare domain.

8.2.2 Identification and Profiling of Stakeholders

Account for involvement of end users. Human-centred design implies that targeted end users are actively involved in the process from the very beginning, taking continuous part in context discovery and prototype evaluations. Hereafter, we provide guidelines that are based on recommendations of references [2], [4], which we have adapted based on our personal experiences in developing digital health systems.

Once you have initiated your project, the first step is to identify the stakeholders for the targeted solution. In digital health, targeted stakeholders are in most cases known from the beginning of the project (e.g. patients with type 1 diabetes, nurses on a pulmonology ward). Stakeholders are all persons and organisations that either have a role in or are affected by the targeted digital health system. End users are a sub-group of stakeholders, representing people who will use the solution.

To identify the stakeholders, begin with discovery of established processes in the healthcare environment that are in the context of the targeted system. Identify relevant procedures and responsible persons and organisations. To do that, use a combination of organised interviews with the client and selected end users, consult healthcare experts and if needed refer also to available documentation. Make sure to involve patient representatives, medical personnel, IT specialists in the targeted healthcare environment, security officers, representatives of national regulatory bodies, etc. This should lead you to an initial list of patients, medical personnel and regulators who will be representing your core stakeholder group.

Once identified, prioritise the stakeholders by power, legitimacy and urgency, and validate the list with the stakeholders themselves. This is a very important step since the healthcare processes are typically very complex and involve stakeholders in different contexts. Later on, at stakeholder workshops organised during requirements elicitation, the stakeholders’ list and prioritisation should be updated based on newly discovered facts. Also, new stakeholders might be discovered, and if so, they should also be invited to participate and their roles must also be verified.

Finally, profile the stakeholders in their professional setting. This process should lead you towards understanding of the particular sub-groups of patients, professionals and regulators with specific needs and expectations towards the digital health system. Depending on the nature of the system, a sub-group could be an entire population, a particular age group, highly specialised experts with (or without) IT skills, etc. Good understanding of the targeted sub-groups is important for success since it helps understanding the needs and motivations that drive (or slow down) the adoption of the delivered system.

However, gaining such insight is not a straightforward task. Rather, one has to begin with “getting to know” the persons and discover their day-to-day routines, behaviour patterns, reactions, attitudes, etc. This so-called tacit knowledge should be gained as soon as possible, preferably even before the actual requirements data collection begins, and Table 8.2 summarises some techniques that might be considered.

Table 8.2 RE techniques that can be used for establishment of tacit knowledge in digital health
Full size table

When discovering the domain and gaining tacit knowledge, consider using multimedia as one of the communication channels. For example, video film stakeholder’s story playing, take pictures of the healthcare environment and medical personnel and record value statements during individual interviews with doctors, nurses and patients. This will add an innovative angle into the process while allowing returning back to individual situations and scenes anytime later in the RE project to (re)establish, confirm or even deepen your understanding.

Since researchers, stakeholders and end users will be actively involved, requirements elicitation and negotiation must be carefully managed to achieve cooperation and consolidate any conflicting opinions and interpretations of the identified requirements as early as possible. Early detection of conflicts and sufficient agreement about the requirements between the involved stakeholders and end users is a key factor for the realisation of the vision and acceptance of the resulting system [8].

8.2.3 Requirements Inquiry

Once you have profiled the patients, medical personnel and regulators and have gained sufficient tacit knowledge, the documentable requirements elicitation begins.

To elicit requirements, consider using the techniques explained earlier in the tacit knowledge acquisition stage, as well as those explained in Table 8.3 (please refer to [2] for further details as well as further techniques that can be used during RE inquiry).

Table 8.3 Further RE techniques that can be used for requirements inquiry in digital health
Full size table

Elicit requirements iteratively according to the (re)planned RE plan, each time resulting in more in-depth requirements specifications. In each iteration, make use of a combination of techniques that suits best, and allow for flexibility to change the combination as you advance. Consider using creative ones in the initial iterations (observations, brainstorming, introspection, prototyping), gradually adding complex and more formalised ones that will lead to in-depth RE establishment (system archaeology, document analysis). Engage stakeholders from the very beginning and at all later stages of RE inquiry. Plan for dedicated workshops with patients and medical personnel and with customer representatives, specially those from the IT department and legal/security office, to demonstrate and evaluate prototypes, and to review, refine and validate already elicited requirements and discover new ones. As you proceed to more in-depth levels, consider involving other specialised actors in addition to patients, medical personnel and customer representatives, in particular legal experts, standardisation bodies and domain experts.

8.2.4 Requirements Specification and Analysis

Requirements must be consistently documented, as well as any other important artefacts influencing the inquiry process or affecting the resulting requirements specifications (for example major decisions, workshop minutes and visual materials, persons involved).

The quantity and depth of RE materials are case specific and should be decided by the project team based on the requirements for such documentation and its use by the developers (for example, application GUI snapshots needed for prototyping) as well as stakeholders (for example, system vision document required by the healthcare institution, use case description needed for further RE workshops with targeted stakeholders). However, keep in mind that agile development without any documentation only works for small projects with limited number of stakeholders and limited number of developers. Even in most extreme agile development projects with minimum documentation, it is the establishment of system vision that helps considerably in maintaining focus throughout the entire engineering and delivery of an acceptable and exciting system.

When extracting requirements from the information collected throughout the elicitation processes, you might want to consider an approach, where the elicited requirements are specified along the dimensions shown in Table 8.4.

Table 8.4 Dimensions along which the elicited requirements are specified
Full size table

Document the requirements incrementally as they are defined. Consider initiating documentation with less formal forms, such as notes, sketches, simple diagrams and checklists that later become part of the formal RE specifications document. Later in the process, prepare documentation in compliance with established project formats and rules, including prescribed modelling languages, templates and forms. Also, consider using multimedia materials to support and contextualise RE documentation, such as video interviews with stakeholder representatives, video clips from healthcare environment observation, or pictures and snapshots of early prototype evaluation workshops and planned applications. Having such multimedia materials will allow the project team to return to different stages of RE whenever needed, and can be used also for innovative dissemination and marketing.

Table 8.5 summarises some additional tips that might help you discover just the right amount of information throughout the RE process.

Table 8.5 Tips how to balance the scope of requirements discovery and specification
Full size table

Finally, quality of the resulting requirements is vital. To avoid jeopardy and failure to deliver an acceptable system, elicited requirements must be continuously checked and validated. Bear in mind that errors, inconsistencies and misunderstandings can (and probably will occur) at anytime and as part of any of the above processes. Erroneous artefacts can entail inconsistencies and defects in all subsequent system engineering activities, including system architecture and functional design, development, implementation and verification, and must therefore be identified and eliminated as soon as possible. In part checking and validation will happen naturally throughout the RE process, in particular through prototype evaluations and introspection, system architecture drafting and scenario definitions. However, you should take additional measures by checking the produced documents through inspections (e.g. walkthroughs, peer/advisor reviews) and through establishment and confirmation of shared understanding of the elicited requirements at stakeholder workshops [9]. This will proactively engage stakeholders, allow them to contribute and help them understand the true value of the system, which altogether considerably increases chances of successful acceptance of the delivered system.

8.3 Example of an RE for a Digital Health System

In this chapter, we showcase a practical example of guidelines implementation for a new Internet-based diabetes share system (DSS).

8.3.1 Case Study: The Diabetes Share System (DSS)

The system addresses the problem of inadequate blood glucose levels of diabetes type 1 patients, which affects both patients and next-of-kin, doctors and nurses. The impact of this problem is severe complications for the patient and high treatment costs. A successful solution enabled the patient in effectively balancing intake of insulin and carbohydrate, physical activity and stress, using consumer-grade smartphone applications that are integrated into the digital health environment at a hospital.

The proposed DSS solution was a result of concrete real-world needs, ideas and propositions from patients, clinicians and researchers themselves, recognising it as a natural extension of the self-care smartphone applications already in use by patients. Its architecture was designed to fulfil those expectations, as well as to meet the requirements on security, data protection and operational practice (Fig. 8.4).

Fig. 8.4
figure 4

Case study: Patient and physician discuss benefits of using mobile technology to manage self-care (photos taken with consent)

Full size image

The DSS is a solution that integrates self-care applications on smartphones used outside the hospital with clinical systems located in the secure hospital domain. It is intended for diabetes patients, next-of-kin and physicians and nurses who train, monitor and consult an empowered diabetes patient. The solution is cloud based and enables mobile recording of health and biometrical parameters, remote counselling and comparison with other patients’ anonymous observations. Unlike in-clinic treatment based upon manually recorded or lacking health parameters, DSS increases evidence to support treatments, increases the patient’s knowledge base, assists in maintaining a healthy lifestyle, reduces the number of in-person appointments and hence contributes to improving the patient’s diabetes condition, well-being and health. Its major features are:

  • Self-reporting of diabetes and lifestyle-related parameters in a self-care smartphone application.

  • Sharing of diabetes data with clinicians through its transfer from the smartphone application into a hospital EHR.

  • Decision support service for clinicians through access to and visualisations of diabetes parameters, accessible through an enhanced EHR client.

We, a multi-disciplinary team working in the digital health domain, have been working with diabetes patients and caregivers in 2013 and 2014 to realise the DSS. The team comprised a broad skill set within software development, innovation, project management and research. Senior software developers and architects, project managers, graphics artists and researchers with backgrounds from industry, government, start-ups and academia are represented in the team, whose members are affiliated with the University of Ljubljana and the University Hospital of North Norway.

The following sections describe how requirements engineering for the DSS system was performed and which techniques and approaches contributed most to establishing shared understanding and an agreement between engineers, patients, clinicians and regulators.

8.3.2 Project Preparation

The DSS product was developed in an EU-funded project FI-STAR [10]. Following the description of an initial concept and general features of the solution in the project proposal phase, at the time the project was granted funding we specified a coarse project plan with budget allocations, work descriptions and milestones based upon the envisioned solution and expected deliverable dates. This information was necessary for identifying the skill set needed and suitable team member candidates. We formed the teams iteratively by profiling the project and letting senior staff members with expertise in selected disciplines (e.g. requirements engineering, software engineering, digital health security) review the project description.

The team had previous positive experience with iterative-incremental software development processes (Scrum agile), so we chose to design a customised RE plan accommodating this to benefit from already established processes. To align the RE activities with the development process we decided to distribute and iterate some of them over time, team and system features. Figure 8.5 shows the requirements activities over time (sequence of increments and iterations shown only as an example of the agile process).

Fig. 8.5
figure 5

Case study: RE activities over time (illustrative)

Full size image

Getting access to the stakeholders working in the hospital (medical personnel, hospital IT department) was a challenge because of their limited availability. However, this was expected and we found the agile process in a digital health context to be an advantage in this respect because it allowed us to be flexible about planning.

  • As shown in Fig. 8.5, the different requirements engineering activities were performed iteratively and incrementally, distributed over the course of the project, per system feature and aligned with stakeholder availability.

  • At one point we had a requirements inquiry session with clinicians regarding new user interface items in an EHR client application. New interesting functionality was revealed in that session (data aggregation methods) and we chose to use that opportunistic moment to give room for creativity and continue an informal discussion around this.

  • Naturally, this took additional time and we had to finish the session without having time to visit all the items on the agenda. Following this event, ideally, we could just have had another session the day after or so to cover the rest of the session. In reality though, this group of stakeholders needed a few weeks’ notice to schedule a considerably long session. Consequently, since we did not have more than just a rough idea of our activities for the next 6 weeks, the developments at the last session did not have big implications for us to postpone some of the ensuing EHR client development to a later date. This in fact made it possible for us to better utilise RE results for this feature in development.

  • The lesson learned was that this situation could have lead us to a suboptimal product if it were developed within a process with up-front and detailed plans with little room for change (e.g. if subsequent RE or development activities would have had to start without sufficient input).

8.3.3 Identification and Profiling of Stakeholders

In the project, representatives from two target user groups, patients and physicians, were involved from the very beginning. The DSS system was a response to needs uncovered in previous projects where the same stakeholder representatives were involved, so these naturally formed the stakeholder baseline used for initial inquiry.

During a series of observations, interviews and workshops with the patients and physicians, and selected digital health domain experts (e.g. security experts that were part of the project owner organisation) we identified additional stakeholders having concerns about the DSS. Nurses were for example identified in an interview with a patient and the data protection officer was revealed in a workshop with the security expert.

We have then completed an impact analysis and ordered the identified primary stakeholders according to their priority and urgency as shown in Table 8.6.

Table 8.6 Case study: Primary stakeholders identified for the DSS system
Full size table

  • In our case we neglected to realise the importance of two stakeholder groups initially, namely the researchers and the administrators. Not being primary end users their importance was being underestimated when in fact they had an important impact on successful delivery of the solution.

  • For example, the process of installation of the DSS system into the hospital environment would have been much more difficult without administrators’ engagement and approval, and the success would have been hard to verify without scientific evidence supporting the researchers’ needs.

  • The consequence of this was excess RE and development effort that needed to be reiterated and redone at a later stage.

In addition to primary stakeholders (end users), organisations with concerns affecting the DSS system were identified in initial workshops and interviews. These represented governing and regulatory bodies with a passive interest in the solution and had varying degrees of impact on it. They are found in Table 8.7.

Table 8.7 Case study: Additional stakeholders identified for the DSS system
Full size table

These lists were revised and approved by the project teams and stakeholder representatives from the primary stakeholder group. This helped create an initial sense of ownership and commitment in the solution necessary for the inquiry activities to be prioritised.

However, we found difficulties in approaching and engaging these additional stakeholders. This was primarily due to lack of available capacity on their side, and also established internal policies that caused reluctance or inability to take decisions and responsibilities related to deployment and integration of the DSS system into the hospital environment. This had an unfortunate impact on the development progress since their engagement was found to be critical for successful delivery. As it turned out, the hospital network and equipment administration unit had severe capacity problems and was not available for requirements inquiry to a sufficient extent, resulting in delayed delivery.

8.3.4 Requirements Inquiry

8.3.4.1 Interviews and Workshops

During the inception phase of the project we spent significant effort on requirements inquiry and elicitation to establish the system context, high-level system features and the quality properties of the solution. We find these items to be rarely changing and even while adopting an agile process they still are useful to cover and agree upon early since they help in keeping the target and scope in focus.

To capture the end users’ expectations and concerns on the solution we held a series of interviews and workshops with the patients and physicians, which were recorded digitally (photos, audio, video) as well as manually (note-taking). We also used role-playing within their own environment to elicit tacit knowledge on the patient consultation process and various artefacts involved (Fig. 8.6).

Fig. 8.6
figure 6

Case study: Snapshots from the stakeholder workshops at the University of Northern Norway in Tromsø

Full size image

Throughout the process, we always allowed for enough flexibility to re-schedule or modify the planned activities. This proved necessary, in particular if proactive engagement of hospital and Norwegian healthcare representatives was needed. Flexible planning of stakeholder workshops and interviews allowed us to involve and engage crucial stakeholder representatives. However, this also required us to continuously update the RE plan and at some points even abandon certain planned steps.

We also completed an investigation of systems interfacing with the DSS. A list of specific requirements for the interfaces or expectations on responsibilities was prepared, which was later used for initial DSS system architecture drafting and prototyping (Fig. 8.7).

Fig. 8.7
figure 7

Case study: (a) The Diabetes Diary smartphone app (left), the DeStress Assistant smartphone app (right), (b) 2in1SMART glucometer (left), and FitBit physical activity monitor (right)

Full size image

8.3.4.2 Document Analysis

The DSS is a digital health solution handling sensitive, personal data and is by nature subject to a vast and detailed regulatory and legislative framework. Accompanying this are both national and international standards, policies and guidelines for how to realise solutions in the healthcare domain. A significant effort was thus put on document analysis in order to capture these kinds of requirements and constraints for the solution context. It was mainly the governing authorities found in the additional stakeholders list that owned these requirements and we did surveys of these organisations’ web sites to identify document candidates for this process, as is shown through the below example.

  • The Norwegian Data Protection Office offers a set of guidelines explaining how to design technology integration architectures that are within the Norwegian legal boundaries. These are very concrete in certain aspects and can oftentimes be directly transferred to a specific system requirement. For example:

  • “All authorized access and failed access attempts to the service must be registered and stored for at least 2 years” (about information systems used for interaction with patients, freely translated from Norwegian).

8.3.4.3 System Archaeology and Prototyping

To identify constraints and requirements on the DSS interfaces towards other systems, we used system archaeology and held interviews where documentation was missing. To fully comprehend the impacts of certain interfaces we also implemented proof-of-concept prototypes.

For example, to learn about the significant details of the authentication protocol used between the patient’s client application and the identity provider service, we found that the most efficient method was to “code it out”, i.e. create a proof-of-concept application. As this was considered a high-risk interface (architecturally significant and high cost of overlooked requirements), creating such a prototype was useful to reconfirm that we had covered all vital details.

As expected, prototype evaluations were the crucial element, always resulting in considerable requirements refinements, identification of additional features and refinements to the applications interaction design. However, this required also continuous scope updates and feature prioritisation.

8.3.5 Requirements Specification and Analysis

8.3.5.1 Initial Vision Specification

We started to establish a product vision and feature scope in the beginning of the project. This was documented in a Vision Document and agreed upon by all primary stakeholders.

We prepared a walkthrough of all requirements elicited from initial stakeholder interviews, system archaeology, document analysis and prototyping, and normalised them into “stakeholder expectations” and the system context. These formed the basis for the initial requirements analysis, in which we used informal modelling and object oriented analysis to identify and specify the high-level functional requirements (system features and use cases) as well as quality properties and how they support the solution in fulfilling goals for the stakeholders.

From a project management perspective it was necessary to define also the minimal feature set that would be designed and developed in the first development stage. This included an informal risk vs. benefit vs. cost analysis that also indicated an ordering of features useful for project planning.

Vision Document: Table of Contents

1 Solution Positioning

 

1.1 Problem Statement

A section explaining what is the problem to be addressed.

1.2 Position Statement

A section explaining what is the targeted solution and how it would contribute to resolving the problem.

2 Use Case Stakeholders

A section explaining which users, interfacing systems and other stakeholders are affected by the solution.

2.1 Users

Identified users, their background, role and expectations.

2.2 Interfacing Systems

System boundary, identification of relevant interfacing systems.

2.3 Other Stakeholders

Identification of other stakeholders that do not directly interact with DSS.

3 DSS Solution: Value Case

Establishment of the value case for the proposed solution, i.e. what are the goals in terms of effectiveness, efficiency, safety, satisfaction, etc.

4 DSS Solution Overview

An overview of system, its main components, scope of planned prototypes in phases, and specification of features including goals to be achieved, external interfaces, and expected usage scenarios.

The minimal solution scope was agreed upon in consensus between the project team and stakeholders, and proved to be very useful to help in keeping development focus and not spend effort on unwanted or extraneous features. The agreed upon scope definitions for DSS features documented in the Vision Document are shown in Fig. 8.8.

Fig. 8.8
figure 8

Case study: Feature scope definition of one part of the DSS system from the Vision Document

Full size image

8.3.5.2 Iterative Feature and Architecture Analysis

The initial DSS deployment architecture was defined using object-oriented analysis to the level of external interfaces and a component-oriented deployment scenario, as shown in Fig. 8.9a. This was specified in an architecture document, which was used in further communications with (technical) stakeholders, and was later on used as a basis for the DSS system design.

Fig. 8.9
figure 9

Case study: (a) UML DSS architecture, (b) UML Sequence diagram of the DS1.14.1 Patient Privacy feature

Full size image

Further per-feature analysis was performed in an agile fashion, during the development process and subject to opportunities, impediments and availability of critical resources. Analysis and specification of requirements per feature was the responsibility of the development team and was performed to a level necessary for development progress. UML diagrams of system architecture, system deployment, component structuring, and use case scenarios, as well as informal drawings (sketches and white-boards), Wiki and text documents were used informally to specify and detail requirements.

For the DSS system, we prepared and continuously refined the deployment diagram, which was a result of several workshops with IT administrators at the hospital as well as DSS design work of the engineering team. For each feature, we prepared sequence diagram that corresponded to the designed architecture and its components.

8.3.5.3 Iterative Prototype Analysis and Review

  • For example, for development of the DeSA graphical user interface screens, we have used both kinds of artefacts successfully. We first presented paper-based and whiteboard sketches (monochrome wireframes) during initial requirements inquiry to help focus on overall functionality rather than design details. These were recorded as photos (Fig. 8.10a) and used in preparations for the next increment during which we presented digital wireframes first (Fig. 8.10b), followed by interactive prototype screens on the smartphone (Fig. 8.10c) based upon consensus and ideas resulting from the wireframe session.

  • Figure 8.10c shows on the left hand side two screens from the first interactive prototype demoing the DeSA GUI idea from Fig. 8.10a. This variant was later on refined and re-organised based on patients’ feedback and additional interaction designer inputs as shown on the right hand side of Fig. 8.10c.

Fig. 8.10
figure 10

Case study: (a) Initial low-fidelity wireframes (sketches) of the DeSA GUI, (b) digital wireframes of the DeSA GUI, (c) interactive prototype of the DeSA GUI

Full size image

As part of the requirements analysis and validation process we employed prototyping in the workshops with end-users to elicit new requirements and also to validate previously specified ones (prototype reviews). We used wireframes with varying fidelity and interactive prototypes incrementally and per system feature (with graphical user interface mock-ups). These became both specifications and a basis for analysis. At the time, the prototypes did not meet all feature and quality properties but were fully functional. For evaluation of the stakeholders’ degree of delight or annoyance (quality of experience) we used questionnaires and digital recordings of the sessions.

8.3.5.4 Tools

We used a mix of software tools for specifying and managing the requirements. Different team members used them for different purposes and requirements were specified on different levels of detail in the process. To avoid inconsistency and managerial chaos we implemented a simple scheme for traceability based on application-native hierarchical structures and labelling of requirements with numbers. This labelling was applied already in the vision statement definition (in the Vision Document) and present down to code unit level and logging. Table 8.8 gives an overview of these tools.

Table 8.8 Case study: Used requirements specification tools
Full size table

The tools were chosen pragmatically according to needs and available usage skills and were used to the extent necessary for progress. However, as we were building the medical applications we were also obliged to meet requirements on traceability and documentation as stated by the IEC 62304 [11] standard and implemented that as described.

8.4 Discussion

As presented in the case study, we made an effort to implement all basic RE steps as defined in the guidelines. Key lessons learned from this experience and some crucial take-away messages to practicing engineers, developers, researchers and stakeholders are provided hereafter.

The guidelines propose preparation of project-specific RE plan, which allows for optimised dynamics planning. However, we had prepared the project’s time plan at the time of EU project proposal preparation. This had imposed considerable time constraints on the RE, resulting in a plan for engineering and development dynamics for the duration of 24 months. The approach was incremental, organised into two major iterations (alpha and beta), and using a pragmatic engineering approach with agile elements as recommended. Compared to waterfall methodology, this allowed for flexibility and adaptability at all times, which was particularly important during stakeholders interactions and engagement. Also, it facilitated prototype-driven engineering, which was an important excitement element for all involved parties and was positively stimulating the progress. However, the chosen approach required additional RE management efforts in order to assure that all important RE elements were covered and that the process converged according to plan.

Good understanding of domain specifics is emphasised in the guidelines, and this was re-confirmed in our case (Table 8.9). We recommend to plan for one comprehensive RE phase at the beginning of the project to establish in-depth understanding of the context. Also, in our case one of the team members was a digital health expert and a type 1 diabetic, and we had the benefit of already established tacit knowledge from previous projects. This was extremely beneficial as it allowed us to shorten the tacit knowledge establishment phase and outline the vision statement and value case very early in the process.

Table 8.9 Healthcare-specific aspects of RE that the engineers and developers should pay attention to
Full size table

The case confirmed also the importance of stakeholder involvement. We had an already established link to some stakeholders in the hospital (diabetology department personnel, diabetes patients) as well as a user base of diabetes type 1 patients from a previous project, which again was very beneficial as it allowed us to shorten slightly the stakeholders’ profiling phase. However, this bore a negative consequence in the fact that we did not analyse the stakeholder landscape thoroughly enough, and underestimated the importance of two types of stakeholders, IT administrators and researchers. This imposed delays to the RE process due to late identification, profiling and engagement of these stakeholders, and due to limited availability and some reluctance to participate in the RE activities from their side. We therefore recommend all practitioners to pay considerable attention to stakeholders’ identification early on and double-check that they have identified all relevant players in the domain. Also, we advise the involved stakeholders to engage proactively in the RE processes and try to be available. This will enable the RE team to have deeper understanding of the problem and better chances to deliver an applicable and useful solution.

For research, the implications are on new methodologies and processes that will facilitate motivation of stakeholders and establishment of good-enough understanding on their side. This will lead to proactive stakeholders’ engagement and hence increased adoption of the solutions. Furthermore, specifics of digital health come from the fact that the domain is heavily regulated. Presently, digital health infrastructure in Europe is heavily fragmented. Healthcare infrastructures are implemented based on individual choices of individual institutions and there is a lack of national and cross-border regulation. Further research is necessary in the context of European and national legislations, and guidelines for global regulation strategies are needed. RE research should focus also on development of concrete security and data handling requirements patents.

8.5 Summary

With rising trends on diabetes prevalence and further transfer of treatment responsibility upon patients, awareness of “self-care treatment” is becoming increasingly important. In this context, new technologies present immense opportunities for innovative digital health solutions and novel patient pathways, by putting high computing, integrating and presenting power into the hands of the patient, hence helping them to become more autonomous and achieve increased quality of life.

This chapter provided an insight into requirements engineering specific in digital health domain from a practical perspective. It provided guidelines for implementation of requirements inquiry in a clinical environment. This included recommendations for project-specific preparation of RE plan with incorporated elements of iterative, incremental and agile engineering, an insight into thorough stakeholders’ landscape research, tips how to establish comprehensive tacit knowledge and how to identify and engage crucial stakeholders, and how to elicit and document requirements pragmatically yet to appropriate level of detail. Next, a real-world case study was shown for the case of the diabetes share system, which was engineered and implemented at the Hospital of the University of North Norway in Tromsø. Experience gained through this case have shown that the key to succeeding and achieving high adoption rates in daily practice lay in the following requirements:

  • Digital health systems can only reach long-term patients’ and caregiver needs and provide acceptable and trustworthy services if integrated into the official healthcare services.

  • The key to successful adoption into daily practice and establishment of trust lay in patients’ empowerment and ownership over their personal data, and assurance of high level of security and privacy.

  • Establishment of tacit knowledge, early identification and adoption of patients, medical personnel and regulators and establishment of shared understanding are crucial for success of such systems in practice.

  • Requirements engineering is a vital discipline in digital health systems engineering that establishes understanding and leads to fulfilment of goals and expectations, and should hence be studied and appreciated for its importance by practicing engineers, developers and researchers.

This opens also new avenues of research, in particular in the domains of security, privacy and data handling, legal aspects and regulation strategies in Europe, as well as innovative RE practice for digital healthcare. Advancements in these areas will help strengthen trust in digital health systems and will lead towards successful rollout of such systems into daily practice.