Value Specification

The value specification phase elaborates on the issues (problems or points for improvement) that were identified in the contextual inquiry. The outcomes of the contextual inquiry provide a general idea on the added values that a certain technology should have (e.g., users want to be able to use it whenever they want or need). However, these outcomes are not concrete enough to specify what is needed from an actual technology, so the value specification narrows down these identified issues. This is done by focusing on the exact added value of a technology, specifying the demands from the implementation context, and finding out what is required from the design of the technology by the identified key stakeholders (e.g., provide easy access via an online platform). A proper value specification assists in finding out what kind of goals the technology should reach according to stakeholders, and what should be done to reach these goals. Also, the value specification forces the development team to be precise, which helps them to deal with many implementation-related issues like adoption, financing, and use on the short and long term in time [1].

To achieve this fit between the demands from the context and the technology, it first has to be determined what added value a technology should bring to the current situation. In other words: what exactly should be improved or supported by means of an eHealth technology? What should its main goals be, according to the involved stakeholders? These so-called values can differ per key stakeholder, so it is up to the development team and stakeholders to prioritize them, and make decisions on how to cope with conflicting values. Based on this, a value map is created [2], this can be represented on a table which links every value with potential ways eHealth could serve it.

The value map is a subpart of another overarching activity that is relevant for the entire design process and which starts in the value specification phase: business modelling. A business model describes how the organization involved in the eHealth development creates, delivers and captures values. To put it simply: it describes how an organization conducts its business concerning the eHealth technology. A business model can be used to deliberate, plan, and operationalize the implementation of eHealth, by means of discussing the added value of an eHealth technology and what resources are required for the actualization of these values in practice. Therefore, business modelling, should already start in this phase of eHealth development, in which these values are being identified [3].

The identified values serve as input for the more specific requirements of the design of a technology, which state what exactly is required from the technology with respect to matters like software, hardware, content and design/presentation. Requirements prescribe design details like what a technology should do, what content it should display, what kind of data is used, and what kind of user experience it should provide in order to achieve the values. They serve as the blueprint for the to-be-developed technology [2].

The value specification phase is essential for good eHealth development, since the goals and scope of the technology should be clear before it is actually designed and used in practice. The entire development team should have a thorough understanding of what is required from a technology, to prevent mismatches between the context in which it will be used, the wishes of the stakeholders, and the technology.

What is the aim of the Value Specification?

The value specification process elaborates on the outcomes of the contextual inquiry. It is aimed at exploring what healthcare improvements are foreseen and what the possibilities or expected limitations are to realize the values. In this process the key stakeholders determine first their values (economical, social, and behavioral) and then rank them based on their importance for solving the identified problem(s). After specifying and ranking the stakeholders’ values, the eHealth goals can be formulated. The next step is to define the requirements to realize the values.

All in all, the value specification has several main objectives:

• The values from all involved key stakeholders have to be identified, and it should be clear what – according to them – the added value should be.
• All identified values have to be prioritized and categorized into a value map.
• A business model for the eHealth technology has to be created.
• The values have to be translated into specific technology requirements that state what is required from the technology.

What are the outcomes of the value specification?

The value specification has two main outcomes, the first of which is a value map that contains the values that the technology should address. If a technology focuses on these identified values, it has a higher chance of being used, since it actually has added value for the current context and stakeholders. The second outcome is a list of requirements. These requirements will be used to develop the actual technology and serve as concrete tools to make sure that the wishes of the stakeholders and context are incorporated in the technology. Again, this increases the chances of the technology being used, since it fits the intended users.

The values and requirements should logically arise from the contextual inquiry. This ensures that the issues identified there are addressed, and that the context and stakeholders are constantly being kept in mind. If the value specification is conducted in a proper way, it assists in creating a good fit between the technology, context and stakeholders. As said before, this contributes to a successful implementation by delivering actual added value to practice, which, in its turn, increases the chances of reaching the intended goals.

References

[1] Van Gemert-Pijnen, J. E., Nijland, N., van Limburg, M., Ossebaard, H. C., Kelders, S. M., Eysenbach, G., & Seydel, E. R. (2011). A holistic framework to improve the uptake and impact of eHealth technologies. Journal of Medical Internet Research, 13(4): e111.

[2] Van Velsen, L., Wentzel, J., & Van Gemert-Pijnen, J. E. (2013). Designing eHealth that matters via a multidisciplinary requirements development approach. JMIR Research Protocols, 2(1):e21.

[3] Van Limburg, M., van Gemert-Pijnen, J. E., Nijland, N., Ossebaard, H. C., Hendrix, R. M., & Seydel, E. R. (2011). Why business modeling is crucial in the development of eHealth technologies. Journal of Medical Internet Research, 13(4): e124.

What is identifying values from all stakeholders?

The values should be related to the issues that were identified in the contextual inquiry. Values should logically arise from the contextual inquiry, since they elaborate on the issue that was identified by stating what is needed to improve that issue, partly by involving the already identified stakeholders. Because eHealth development is an iterative process, stakeholders can still be added or removed from the list at this point. The values of the involved key stakeholders can be discovered through several methods [1, 2, 3].

What is the aim of identifying values from all stakeholders?

The aim is to create a list with values of all stakeholders, either related to economic, social, behavioural or healthcare issues. They can, for instance, focus on an improvement of people’s mental health or better social functioning. Values can also have a more cognitive nature, for example, influencing attitude or knowledge about a health topic or increasing motivation to change a health-related behaviour. Other kinds of values can be increased access to healthcare, adherence to protocols and guidelines, and improved decision support.

Reference list

[1] Van Velsen, L., Wentzel, J., & Van Gemert-Pijnen, J. E. (2013). Designing eHealth that matters via a multidisciplinary requirements development approach. JMIR Research Protocols, 2(1):e21.

[2] Van Woezik, A. F. G., Braakman-Jansen, L. M. A., Kulyk, O., Siemons, L., & van Gemert-Pijnen, J. E. W. C. (2016). Tackling wicked problems in infection prevention and control: A guideline for co-creation with stakeholders. Antimicrobial Resistance and Infection Control, 5, 20.

[3] Wentzel, J., van Velsen, L., van Limburg, M., de Jong, N., Karreman, J., & Hendrix, R. (2014). Participatory eHealth development to support nurses in antimicrobial stewardship. BMC Medical Informatics and Decision Making, 14(1), 45.

What is prioritizing and categorizing identified values?

During the value specification, many different kinds of values will be identified, since many different kinds of stakeholders are involved. Once these values have been identified, a hierarchical analysis of values is required since some values might be more important than others. These so-called critical values have to be addressed by the eHealth technology in any case. The development team has to decide what these critical values are, possibly in collaboration with stakeholders. This can be done by methods like focus groups with the development team and/or other stakeholders, and/or via techniques like Analytic Hierarchy Process (AHP) [1] that can assist in complex decision making. Software can be used to rank values from the involved stakeholders into a value map.

What is the aim of prioritizing and categorizing identified values?

Often, conflicting values arise, for example when the values from an insurance company differ rigorously from those of an end-user. In those cases, the development team has to decide on how to cope with these conflicting values, for example by discussing this with involved key stakeholders. The importance of the stakeholders as was identified in the contextual inquiry should be kept in mind: the values from the most important stakeholders might be more relevant in in most – but not all – cases. All of the prioritized values are visualized in a value map.

References

[1] Saaty, T. L. (1988). What is the analytic hierarchy process? In: Mathematical models for decision support (pp. 109-121). Springer, Berlin, Heidelberg. 

What is creating a business model?

The value map that was developed is part of a business model. A business model can be defined as ‘the rationale of how an organization creates, delivers, and captures value’ [1]. It is essential during the entire eHealth development process since it guides the implementation processes and clarifies the costs and benefits (values) for stakeholders. Because the development team has to account for implementation from the start, the creation of the business model should also start at the beginning of the development process, and not merely during the implementation itself. The early development of a business model enables the development team to identify matters that might come up during implementation before the actual implementation in practice has started. In this way, information from the model can be used to account for possible pitfalls. A frequently used method to create a business model is the business model canvas [1], which consists of several building blocks.

What is the aim of creating a business model?

The creation of a business model is an iterative research process, so open-ended ideas can gradually become more substantiated during the development process. Also, ideas can be discarded or rigorously changed along the way. Multiple methods should be used to create the business model, and information from the contextual inquiry and value specification is used to make sure that the business model matches the entire development process, the context, and its stakeholders. Since a business model is more of a generic overview instead of a set of predetermined methods, the way it is filled in depends on the skills and preferences of the development team. But independent of the methods being used, it is always essential to carefully describe and document the process and rationale behind the filled in business model [2].

References

[1] Osterwalder, A., & Pigneur, Y. (2010). Business model generation: A handbook for visionaries, game changers, and challengers: Hoboken, NJ: John Wiley & Sons.

[2] Van Limburg, M., Wentzel, J., Sanderman, R., & van Gemert-Pijnen, L. (2015). Business Modeling to Implement an eHealth Portal for Infection Control: A Reflection on Co-Creation With Stakeholders. JMIR Research Protocol, 4(3):e104.

What is translating into specific requirements?

The value map itself is not yet concrete enough to use for the actual design of the eHealth technology. Therefore, values are translated into specific requirements for the new technology. A broad categorization of possible types of requirements is:

• Content requirements. They state what information the technology should present to the user, e.g. information on the symptoms of a minor depressive disorder.
• Usability and user experience requirements. These requirements concern the user perspective and specify the interface and interaction design of the technology. Think of requirements on the size of symbols and the clarity of the navigation. 
• Functional and modality requirements. These requirements specify technical features and prescribe the kind of technology and operating systems. They are mainly focused on the programmer’s point-of-view. These might be requirements that state that an eHealth intervention should run on both Apple and Android systems.
• Service requirements. These requirements state the best way to organize the services that support the technology. They are mainly relevant for managers who make decisions on matters like marketing or user support. This might refer to issues such as a 24-hour helpdesk in case of problems with a technology.
• Organizational requirements. These requirements concern the integration of the technology into the organizational structure and working routines. Again, they are mainly aimed at managers. An example is requirements on scheduling time in nurses’ schedules to answer questions in an eHealth intervention.

What is the aim of translating into specific requirements?

The elicitation of requirements is part of the value specification since requirements state what is required of the technology for it to achieve the added value [1].

References

[1] Van Velsen, L., Wentzel, J., & Van Gemert-Pijnen, J. E. (2013). Designing eHealth that matters via a multidisciplinary requirements development approach. JMIR Research Protocols, 2(1):e21.