Value Creation Roadmap for Diagnostic Developers

As product developers, we have all had high hopes that diagnostic products will result in dramatic improvements in health care outcomes. However, we also often see that their potential is not fulfilled, and their implementation in routine care delivery is not as effective as anticipated, or—even worse—fails to achieve any clinical benefit.

One key observation that we have made during our years in the diagnostics industry is that it is often not the diagnostic test itself that limited the clinical benefits that could have been achieved by a product. The problems arose because all the processes that occur upstream and downstream of the diagnostic test, such as sample collection and sample preparation, as well as results interpretation and dissemination, must all function together as a linked set of events that occur within a meaningful timeframe.

Challenges to obtaining a clinical benefit often stem from the fit of the diagnostic product within the overall medical practice, which can extend much farther out than the laboratory or the location where the test is performed. In other words, it is the fit of the product within the broader ecosystem that can limit the clinical (or societal) impact it can make. In some cases the challenges to fitting into the ecosystem are related to limitations of the physical environment. In other instances, the challenges lie in the timeliness of delivering the result to the health care provider, or the clinician’s access to other critical patient health information within the same time frame. Other common challenges are manual, time-consuming data processing steps that are still required to get the test result information from one device or information system to another. Finally, the opportunity to use the test results outside of immediate patient care, such as in health surveillance and in public health is often missed.

Many of these challenges are related to the needs of individuals within the ecosystem who are not the primary user of the diagnostic product. In many cases, we have observed that a product fails to meet the needs of all the users within the ecosystem.

How can the design process for diagnostic products be improved so that they achieve their full potential? The use of holistic design approaches has been shown to be quite effective in helping developers to specify, develop and deliver highly successful diagnostic products. This approach is also sometimes referred to as participatory design or User Experience Design (UXD), which had its beginnings in the realm of industrial design, and was later adopted in the software development industry, architectural design, and landscape design.

The application of holistic design approaches in the diagnostics industry is more recent, and is certainly far from universal. The adoption of these approaches in the design of diagnostic products comes at a time when healthcare organizations are recognizing that innovations are needed in the process of healthcare delivery, and that the overall procedural efficacy and the economics of diagnostics are critical considerations. ¹

Holistic design approaches advocate for the consideration of a product within its envisioned ecosystem, and shift the focus from designing a thing (product) to designing things that help facilitate actions, behaviors and experiences.2 It has been argued that User Experience Design approaches are more concerned with the situation than the product itself. This is important because User Experience Design practitioners are therefore concerned with holistic views on product ecosystems and user-product relationships.²

Traditionally, the primary “user” that is considered in the diagnostic product design process is the person who will operate the device to generate a test result (i.e. information). However, other types of individuals within the ecosystem may perhaps be even more important to consider than the formal “user”, such as the clinical decision maker, the funder or payer, and the patient. If we consider the experiences of these other individuals in the ecosystem, who use the information that is generated, but perhaps do not use the device itself, then we come up with additional product requirements that are often related to the dissemination and utilization of information.

Holistic design approaches consider the system being designed as an interconnected whole which is also part of something larger. These approaches can involve many tools, which may be selected and utilized based on the specific goals of a project.³

Halteres Associates has previously presented a holistic design process that has been used successfully to delineate the requirements for a broad range of diagnostic products (available here). A high-level overview of this process, including three steps in “opportunity assessment” step, is presented in the sections on this web page, and is illustrated in the figure on the right. The figure indicates when these activities typically occur within a larger product commercialization process that is aimed at creating both clinical and economic value.

D. Stripe, “To Design Better Medical Devices, Understand the User.” White paper available at https://www.formamedicaldevicedesign.com/white-papers/design-better-medical-products-understand-user/

M. Baskinger, “From Industrial Design to User Experience: The heritage and evolving role of experience-driven design.” (2010) UX Magazine, article 534, June 8 2010.

W. Hess, “10 Most Common Misconceptions about User Experience Design.” (2009) https://mashable.com/2009/01/09/user-experience-design/

The first step in the Opportunity Assessment phase of the process that is featured in the figure is the definition and selection of Use Cases. There are many definitions for use cases. One that we have favored is:1 “a use case is a description of all the ways that an end-user wants to use a system.” In this case the “system” is a medical test. More specifically, a diagnostic use case is defined as a high-level description of a particular use for a diagnostic product which specifies a particular environment, user type, and diagnostic decision to be informed by the results of the test. These three elements identify the ecosystem that will be considered, and are some of the major drivers for the product requirements.

Ideas for Use Cases are often generated by the product design team, though feedback and iteration on the initial ideas with experts and thought leaders is important as well. The types of environments might range from an advanced hospital setting, to a simple clinic without a laboratory, or even a patient’s home. The types of users might range from a highly-trained laboratorian, a minimally trained healthcare worker, or the patient themselves. The goals to be achieved through the use of the diagnostic product would include the diagnosis as well as the actions to be initiated based on the diagnostic information. Examples of different Use Cases that are relevant to SARS-CoV-2 are provided here.

In our experience, it is often difficult to satisfy the needs of very disparate environments, user types, or clinical decisions with a single diagnostic product. Product development timelines and resource requirements can be impractical when trying to meet too broad a set of requirements. Therefore, organizations with limited resources often must make prioritization decisions, which exclude certain Use Cases from further consideration in the product design process.

Formally defining Use Cases, as well as formally including or excluding them, helps makes it explicit among the design team members which types of environments, users and goals will be considered when delineating the product requirements. At the end of this step in the design process, one or a few Use Cases are selected to move forward for more detailed consideration in various Use Settings.

1. Larson, E. & Larson, R. (2004). Use cases: what every project manager should know. Paper presented at PMI® Global Congress 2004—North America, Anaheim, CA. Newtown Square, PA: Project Management Institute.

In the second step of the holistic design process that is featured in the figure, a broad understanding of the specific ecosystem(s) is developed and used to create Use Settings (in older presentations we have referred to them as Use Scenarios). These Use Settings are more detailed descriptions of how a product will be used by a specific user to attain a specific goal. Use Settings describe the processes involved in the decision to initiate a diagnosis, the steps in the diagnostic procedure itself, and the utilization of the information generated by the test. This information is best obtained by directly observing potential users and other actors in the targeted ecosystems. The observational research about the ecosystem should therefore aim to include the type of environment, its infrastructure, and the healthcare processes related to the indication being considered. In addition, it is critical to identify all the actors involved, their locations, the timing of events, the information needed by different actors during the processes, as well as the current challenges or inefficiencies.

The main reason for developing detailed descriptions of Use Settings is to assist the design team to envision and define the product requirements. Ideally, the Use Setting descriptions include the range of variation that might be encountered. Very often, a Use Setting description for “current practices” is developed, as well as a separate one for the anticipated future changes that might be enabled or required by the introduction of a new product. The Use Settings could be described in text format as a narrative story, though very often we find that a visual format, such as Storyboards or flow charts, to be a more effective method of communicating among the product design team. Generally, Use Settings in the form of Storyboards will illustrate how individuals, samples, as well as data and information move in both time and space within the ecosystem.

The level of detail provided about specific human actions and the ways in which data and information are transferred will depend on the needs of the project. Examples of Use Settings which use a Storyboard format that are related to diagnostic products for SARS-CoV-2 are presented here.

The Storyboards should strive to identify parts of the process where the designers need additional information on the current practices, which can help focus market research efforts. While the first drafts of the Storyboards might be created by the product design team, detailed input and feedback from different types of individuals within the ecosystem are critical for validation, and to understand what the barriers, challenges, motivators and benefits are for the current practices, and what they could be for a new product.
When delineating the Storyboards, challenges and gaps are often identified that are beyond the scope of the specific diagnostic test procedure. Some examples involve the areas of user training, quality control, and data analysis. However, perhaps the most ubiquitous challenges we uncover when we consider the broader ecosystem for a product concern the speed of getting results to the clinical decision-maker, which is driven by the dissemination and utilization of information via information and communications technology (ICT). This makes consideration of the entire ecosystem critical, especially the experiences and needs of the clinical decision-maker and the patient, who use the information from a test but not necessarily the diagnostic product itself.

Once the development team has decided which Use Setting(s) to focus on, the specific requirements that the product must meet can be defined in a document called a Target Product Profile.

A target product profile (TPP) document outlines the desired characteristics and requirements for a product. It is used as a planning tool to guide the development of the product. It is often created in an iterative process that involves many stakeholders. It may include both the “acceptable” characteristics as well as the ideal or optimal characteristics for many features.

The Use Cases and Use Settings (storyboards) that the development team has selected will lead to one or more target product profiles (TPP). For commercial reasons, product developers often hope to serve more than one Use Case and Use Setting with a single product. At the outset it may seem simpler to focus on only one Target Product with the hopes that it can serve many Use Settings, however development teams need to be very critical and realistic about the prospects for this and approach it with a deep understanding of the “deal breaker” features for specific Use Settings.

In this stage of the process, Halteres often aims to identify the fewest number of Target Product Profiles that could realistically serve the Use Settings that have been selected. The feasibility of serving more than one Use Setting with a single target product is driven by the Use Setting with the most challenging requirement for a specific feature (e.g., turnaround time, lower limit of detection, cost target, etc.) For instance, if a hypothetical Use Setting 1 requires a time-to-result (TTR) of no more than 2 hours and hypothetical Use Setting 2 requires no more than 30 min, then designing a product with a TAT of 30 min permits both Use Settings to be served by a single product. On the other hand, a product with a TAT of 2 hours serves only Use Setting 1. This might mean that the product development team decides that a product for Use Case 1 could be developed first, and the Use Case 2 product later (or not at all), or perhaps the market for Use Case 1 is too small to pursue on its own, so it’s worth waiting until a TTR of 30 min can be achieved before entering the market.

This brief discussion of Target Product Profile documents and how they are used in the product development process is meant only to provide a brief introduction. We will expand this discussion in the future.