Usability of clinical decision support systems

Modern healthcare relies on complex software to organize and run its infrastructure. Increasingly, software is also used to support clinical decision-making. To this end, clinical decision support systems (CDSS) have been introduced into medical workflows. CDSS are “computer systems designed to impact clinician decision making about individual patients at the point in time that these decisions are made” (Berner and La Lande 2016, p. 1). They represent complex software designed for experts. Further, new technological developments such as machine learning (ML) and sophisticated algorithms promise to significantly enhance the capabilities of decision support systems in the healthcare domain. Yet, if these systems fail to provide an understandable rationale of the clinical decision-making process in the form of user-friendly interfaces the adoption of this technology will be difficult or even impossible. A CDSS must be efficient and effective to operate. Moreover, it must be able to explain how it produced conclusions or recommendations in the language of the users it addresses. If it fails to do so, it cannot be considered entirely fit to serve in a life-critical environment such as healthcare. In the medical domain, decisions about diagnosis and therapy necessarily must be made and accounted for by human physicians. This will not change within the foreseeable future. However, if done right, the potential is huge. The following examples illustrate some relevant use cases (Mucha and Robert 2020):

However, designing complex expert systems in such manner is hard. It becomes even harder if software designers will have to consider learning users as well as learning machines and find solutions for both actors to communicate with one another. In fact, robustly anchoring the user’s perspective by following a human-centered design (HCD) approach in software engineering processes remains a challenge (Nebe 2009). According to Wachter (2017) and Gawande (2018) and backed by more scientific research (Graber et al. 2017; Melnick et al. 2020), clinical software seems to especially suffer from poor usability and little appreciation of state-of-the art interface design.

This article is a call for exploring and making actionable research on understanding mental models as the foundation for systematically producing high usability in software for expert domains. We make this point by describing the example use case of CDSS, i.e., a complex application in a high-stakes domain.

To this end, the article is structured as follows: First, we explain what clinical decision support systems are and why they are vital to modern medicine. Second, we lay out why the usability of CDSS is a major success factor and which approaches to systematically produce usability are in place today. Yet, we also point towards the shortcomings of current practices. We provide an example in the form of a light-weight case study. Finally, we describe current and future challenges for designers of CDSS and propose a direction for future research.

Clinical decision support systems (CDSS) are understood to be information technologies that present knowledge and person-specific information in a processed form to medical or nursing staff, patients, or other individuals in the clinical decision-making process to improve health care (Osheroff et al. 2007). Accordingly, CDSS do not completely take over clinical decision making, but instead provide relevant knowledge and appropriate analyses in a task-oriented manner that allows for making more informed decisions (Musen et al. 2021).

In practice, CDSS range from simple (structured) reports to complex software applications for visualization and interaction in the form of interactive systems, e.g., dashboards. In order to classify this heterogeneous landscape of CDSS in a meaningful way, a number of dimensions have been established for targeted description. Accordingly, CDSS differ in the point in time at which they provide decision support (before, during, or after the clinical decision) and how active or passive the support is, i.e., whether the CDSS actively provides alerts or passively responds to input from (medical) staff or patient-specific information. Finally, CDSSs also differ in how easy it is for users to access information (Perreault and Metzger 1999).

Wright and Sittig (2008) provide a widely used taxonomy of CDSS: They classify CDSS into the following six types:

It quickly becomes clear that a strict separation is often not possible in practice and that a mixture of forms is more common. This can also be understood from a historical perspective. While early CDSS generally formed stand-alone architectures, today’s CDSS are increasingly integrated into clinical systems as an analytical component or are retrievable in the form of a service model.

In addition, CDSS can be categorized in terms of their algorithmic approach. In knowledge-based systems, rules (often in the form of IF-THEN statements) are usually created, which the system accesses at runtime, enriches with additional patient-specific data, and finally generates an action or output based on this rule. These rules, as the central component of the knowledge-based system, can be created based on, for example, literature, practical, or patient-based evidence.

CDSSs not built on an (explicit) knowledge base use ML methods and other statistical pattern recognition approaches as a source of information for decision support, in addition to a high-quality data base. They are a fast-growing use case for artificial intelligence (AI) in medicine worldwide but face multiple challenges besides the problem of data availability—including, most notably, problems with understanding the logic that AI uses to generate recommendations (so-called black boxes).

Despite the increasing importance of clinical decision support systems in improving care and reducing the cost of treatment, there is little reason to suggest that they have found widespread application to date. We see three possible explanations for this: In addition to a lack of knowledge bases and qualified personnel, a lack of usability in particular seems to stand in the way of improved healthcare delivery.

The usability of an interactive system is the degree to which specific users can achieve their specific goals efficiently, effectively, and with satisfaction in specific usage contexts (ISO 9241-210). The systematic approach to develop software in this way is summarized under the term Usability Engineering (UE). At the core of UE is human-centered (formerly user-centered) design (HCD). HCD describes the process and the associated methods to consider the needs of the target group, i.e., the users, in software development and design and to effectively address them. In other words, HCD anchors touchpoints with actual users in the software development process to ensure that legitimate user needs form the basis for design decisions. Data collection, e.g., interviews and field research, in the actual context of use and with actual users as well as systematic prototyping and testing play a central role here.

Medical IT particularly suffers from sometimes serious deficiencies with regard to usability. Therefore, in addition to the interoperability of medical systems, usability is seen as a central success factor of future (intelligent) clinical systems (Rödle et al. 2019; Gong and Kang 2016). This is not only about ease of use in terms of convenience but about potentially serious consequences when it comes to medical decision-making. For example, alert fatigue, i.e., overlooking or ignoring system warnings due to an excessive number of such alerts and the resulting desensitization, can lead to a severely reduced efficiency of CDSS (Strom et al. 2010). Immature user interfaces, i.e., the result of software development that is not human-centered, are potentially harmful to patients. For example, inadequate prioritization of displayed information, visualizations that are not task-appropriate, and the setting of unfavorable default values can lead to patients receiving incorrectly dosed medications or other unintended treatments (Agrawal 2016; Wachter 2017).

Regarding the systematic implementation of best practices of human-centered software development, it remains to be noted that significantly more research needs to be established on mental models of clinical users. A mental model is the notion a user has of how a system works. Especially in medical IT we often find significant mismatches between mental models and interface design choices due to a lack of human-centered design (cf. Zhang and Walji 2011). There is a pressing need to develop dedicated, tailormade HCD methods which support making expert knowledge accessible for designers and that account for such a knowledge-intensive domain.

Mental models are a well-known, well-established concept in HCI. Traditionally the purpose of a mental model is to enable a user to predict the operation of a target system (Norman et al. 1983). In the context of the subject of this article we might reframe this to the purpose of mental models of decision support systems is to decide whether the provided recommendation or advice is useful and will yield beneficial consequences if adhered to by a human decision-maker. Research distinguishes between functional models where users know how to use something but not how it works in detail and structural models where a detailed understanding of how and why something works is given (Rouse and Morris 1986). Especially psychology and HCI explore mental models through experimentation and observation. However, this a complex task where verbal and self-reporting is insufficient to describe mental models appropriately as Norman et al. (1983) also state. This very fact is amplified when dealing with complex expert systems such a CDSS. It becomes even more complex when these systems will increasingly rely on complex ML technologies. The latter, by their very nature, do not reveal their inner-workings and sense-making, not even to their creators.

Hence designers of CDSS (and other expert systems) face a situation where they sit in-between a complex domain and complex technology. In other words, we as designers find ourselves in the role of translators between two highly complex actors that do not speak the same language but need to take high-risk decisions in collaboration.

Henceforward, in order to design useful and usable interfaces for these systems designers need to have strong methods that allow for developing a working understanding of both the domain knowledge as well as the technology capabilities. Only through this it will be possible to fulfill the translation task.

Additionally, with learning systems we have to deal with an entirely new paradigm where not only the human users potentially change their behavior over time as they learn how to use a given system but also the (learning) system itself.

Therefore, the central question, especially in the context of the introduction of artificially intelligent systems, is how can complex medical knowledge and the mental models of the users be systematically and appropriately incorporated into CDSS while accounting for the needs of two constantly learning, behavior-changing entities?

Human-Centered Design is an approach to systems design and development that aims to make interactive systems more usable by focusing on the use of the system and applying human factors/ergonomics and usability knowledge and techniques. (DIN EN ISO 9241-210 2011)

We have stated previously that health IT in particular has grave problems to systematically produce a high standard in terms usability and interaction design. From our experience, there a several reasons for that:

First, the complexity of the research and design object: Medicine is complex and so is software engineering. Representing medical knowledge in software is extremely challenging and there is hardly any room for error due to its application in potentially life-critical situations. Including human-centered design principles into the complex software development process is often seen as not feasible on top within the resources available.

Second, the availability of clinical users (experts): HCD relies on access to the actual users of the system that needs to be developed. Developing software for expert users faces the challenge that the time of the expert is obviously very precious and thus a scarce good. In other words, it makes it even more complex to organize HCD activities.

Third, the sensibility of health data and a lack of clear medical data regulation: Especially recommender and decision support systems and even more so those which use ML technologies can only operate on sufficiently broad data samples. In medicine this data is sensible and must not be misused. As of today, especially in Germany, we lack a clear set of rules of how to make health data accessible for research in a safe and secure way.

Fourth, the nature of medicine: Medicine is a special case in terms of sitting in-between the sciences. As Wachter (2017, p. 243) puts it: “The implementation of health IT ‘is not a technical project, it’s a social change project’”. Medicine is not utterly formalizable which often causes clashes when medical thinking meets engineering and computer sciences thinking (Harrison et al. 2007).

Additionally, researchers and designers of medical software applications also face ethical implications: Working with health data requires utmost diligence and carefulness. The same is true for working in the context of e.g., a hospital and whenever patients are involved making sure that every research intervention and activity is done in consent and according to ethical standards.

We derived these challenges from our practical experiences made during a large-scale research project. MED²ICIN (n.d.) is a Fraunhofer lighthouse-project and as such a four-year consortium research project that seeks to demonstrate how previously separated medical data can be securely, effectively, and efficiently brought together and form a holistic patient-related data base. In this regard, we think of it as a digital twin system. A digital twin is a digital representation of a physical system or entity used to run simulations and derive predictions for its real-world counter-part behavior. This knowledge resource can then be used for technology-assisted data analysis and resulting decision support. Technology assistance can range from traditional statistical analysis to contemporary ML approaches. The results of these processes are then presented to clinical users through appropriate human-machine interfaces. Thus, MED²ICIN can be understood as a proof-of-concept of a human-centered CDSS.

The projects’ digital patient model focuses on inflammatory bowel diseases (IBD) and oncological diseases as example use cases. Both diagnoses are considered to be particularly cost-intensive due to the lengthy therapy and high treatment costs. The vision of MED²ICIN is a digital patient model: physicians enter patient-specific data and feed it into an analysis based on extensive cohort knowledge, clinical guidelines and health economic models. The result is a data-driven decision support tool that aims to find the best individual therapy while providing cost-effective care. The aim is to ensure that the handling of the data and the analysis results is tailored to the respective user and can be easily integrated into her daily work routine through user-friendly interaction design.

In summary, the project’s goals are two-fold. First, the project seeks to demonstrate the feasibility of technology-driven analysis methods and their fitness to serve as clinical decision support increasing the quality and effectiveness of medical decision-making. Second, it seeks to demonstrate how a human-centered approach to medical software development works in practice.

Effective design needs clear boundaries. Designing for usability requires specificity in order to produce appropriate solutions for problems. Hence, in MED²ICIN we focus on a specific use case that comprises two features. A medical condition and a medical setting. The condition is chronic inflammatory bowel diseases, and the setting is consultation hours for patients with this condition.

Inflammatory bowel disease (IBD) is a group of disorders that cause chronic inflammation (pain and swelling) in the intestines. IBD includes Crohn’s disease and ulcerative colitis. Both types affect the digestive system. Treatments can help manage this lifelong condition. (Cleveland Clinic n.d.)

It is well suited as a use case for this project as we anticipate measurable improvements in terms of therapy efficacy and cost efficiency due to systematic data analysis especially of longitudinal data.

A consultation hour is a conversation between a physician and her patient. Consultation hours are held at pre-defined times and follow an established structure and include anamnesis and decisions on therapy. On average, they take seven and a half minutes per conversation in Germany (Winnat 2017). A general goal for medical software designers is to support consultation hours by reducing the amount of time necessary to operate the associated software (data entry and retrieval) and thus increasing the time available for human-to-human conversation.

Emergency department physicians spent 44% of their time entering data into electronic health records, clicking up to 4000 times during a 10-hour shift. (Wachter 2015, p. 71)

In MED²ICIN our goal is to design a CDSS that supports decision-making during IBD consultation hours. To this end, we need to provide relevant information about a patient in an appropriate form.

Our solution approach is a clinical interactive dashboard. We define a dashboard as a visual display of all relevant data in a prioritized manner on one single screen per task. Consultation hours, as all suitable use cases, can be understood as a process which can be divided into individual tasks. The first task in a doctor-patient consultation is to take account of and assess the current state of the patient in terms of her condition. Hence, the dashboard shall display all information and data that support this assessment. From there, further information and data can be retrieved or entered through human-system interactions with one dedicated screen per task.

Now, how do we know which information or data is relevant at a given point in the process?

As with most design projects, one major challenge lies with externalizing the expert knowledge of the expert users (doctors), i.e., their mental models, making it actionable for all stakeholders, and ultimately translating it into visual representations that are appropriate for the given use case. It is a challenge because only rarely does it occur that one or—more realistically—many designers or developers have the highly specific technical and domain knowledge necessary for such a complex endeavor. Hence, we need appropriate design methods to fulfill the task. Traditional UE methods such as observation and interviews cannot entirely produce the knowledge designers need to design true user-centric interfaces.

Henceforward, we argue that designing CDSS must incorporate participatory and codesign methodology to design usable CDSS.

Participatory Design (PD) is an approach to research and design that seeks to establish agency in technology development processes for those who will ultimately be affected by the implementation of the very same technology It originates from Scandinavian movement for ‘workplace democracy’ in the 1970s. Simonsen and Robertson (2012) as well as Bødker and Kyng (2018) provide detailed accounts of PD. In the context of this article, we focus on a specific approach called codesign. While traditional user-centered design involves users of technology predominately as subjects for requirement or user-experience evaluation, codesign offers methods to actively involve users in design activities. The difference between PD and codesign or co-creation can be found in more politically motivated agenda of PD, which often works at the intersection of research and activism, often focusing on empowering marginalized people or communities.

During the project, we used codesign for externalizing mental models. We achieved this by having the actual users of our system (gastroenterologists) produce design solutions. Of course, we did not have them producing the final designs, but through systematic facilitation we were able to create an interface structure that served as the basis for all subsequent design decisions.

As a research project the goal is to explore in how far these methods are actionable in real-world settings especially in terms of scalability (limited availability of experts).

The design task was to define the basic information architecture of the initial view of our dashboard. This included identifying the interface elements (pieces of information) that must be visible first. Hence, we needed to prioritize. To this end, we ran what we call an Interface Sketching Workshop where we cocreated with our users.

Interface Sketching Workshops are a crossover of traditional card sorting and cocreation workshops, hence there is no standardized term yet.

Card sorting is a participatory design technique that you can use to explore how participants group items into categories and relate concepts to one another, whether for digital interface design or a table of contents. Participants are given cards with printed concepts, terms, or features on them, and are asked to sort them in various ways. One of the most common reasons to do a card sort is to identify terminology that is likely to be misunderstood, either because the terminology is vague or because multiple meanings are associated with it (Hanington and Martin 2019).

Design workshops are a form of participatory design consolidating creative codesign methods into organized sessions for non-designers to work with the design team members to create design artifacts that shall inform the design process from the perspective of the users (Martin und Harrington 2019).

Our contribution was to make this approach actionable for our context of use, i.e., a medical interface design problem.

The input for the method was derived from the user research phase. We were not starting with a blank space. Instead, we proposed elements and a basic structure that participants can reacted to and enhanced through their expert knowledge.

The central task of the designer in this activity was facilitation. Together with our users and project partners we worked on a design artefact, a sketch representation of our interface to be designed (Fig. 1). We found that it is a good idea not to start with a blank page. By starting with a design proposition that you developed from user research you can evoke reactions of your non-designer counterpart more easily.

The method produced design artefacts (Fig. 2) in the form of the interface (screen) canvas and ideally sketches generated by the users. These served as data that can be analyzed similarly to a thematic analysis. A core skill of designers is to elevate rough ideas and turn them into high-quality visualizations.

In summary, the goal of the method was to externalize the ideas that participants have of the future system beyond merely describing them verbally. The method helps in creating a design artefact or boundary object to serve as a communication tool between designers and users as well as between designers and stakeholders. Comparing Figs. 2 and 3 you can see how the dashboard design evolved from the codesign sketching phase into a fully designed front-end.

We have seen that consistently producing usability in medical software is still a challenge. With increasingly more complex technology, such as ML, making inroads into clinical decision support, this issue becomes even more important and urgent.

In order to access the latest medical information from patients as efficiently and effectively as possible and to sustainably improve the quality of care on the basis of integrated clinical decision support, a fundamental realignment of the IT architecture is required. By using scalable and modular platforms, it will be possible to meet the most diverse requirements for evidence-based medicine and the design of CDSS. In this reorientation and in face of new complex technology, the focus of technology development must be on those actually affected by this technology, i.e., patients and medical staff, in order to achieve a sustainable improvement in quality.

To become applicable and be useful in the real world, at some point these systems need to talk to users in a way that they can understand. In other words, these intelligent systems need well-designed interfaces that are usable as in effectively and efficiently understandable.

As stated previously, intelligent and learning systems represent a new challenge to their designers. At the core of this design problem is that designers must develop the ability to synchronize the conceptual model of a given CDSS with the user’s mental model of that very same system. This represents the basic requirement for a given user to assess whether she should follow a system’s advice, e.g., whether to agree with a machine proposed diagnosis based on a set of symptoms.

Traditional user research based on observation and verbal inquiry are probably not enough to match the enormous complexity of this design task as described in the previous chapters.

This brings us to the final point we want to make: The need for more inclusive and participatory software development processes as opposed to developer-centric technology development. We found that engaging with users in codesign activities creates more agency and thus allows for a deeper mutual understanding. Our first preliminary evaluation activities back this impression indicating a higher degree of usability.

Henceforward, we argue for user research that goes beyond traditional human-centered design and emphasizes participatory and codesign approaches. We remember, PD is a line of action research that originated in the Scandinavian movement for ‘workplace democracy’ in the 1970s. Codesign can be understood as a sub-movement that emphasizes the actual design methodology of running design activities over the political dimensions of PD as an approach towards the democratization of technology development and usage. However, both offer the methodological equipment of data collection, knowledge acquisition, and artifact creation necessary for this kind of complex design task. It enables designers to include the people most affected by a technology into the development process of this very same technology and making their needs the basis of all design decisions. In our case this would mean actively engaging with physicians, nurses, patients, and other stakeholders of CDSS in design activities as opposed to presenting them design solutions—or even worse “finished” systems—after the fact.

In this article, we first explained what clinical decision support systems are and why they are vital to modern medicine providing a taxonomy from literature. Second, we laid out why the usability of CDSS is a major success factor for medical IT and which approaches to systematically produce usability are in place today. We provided an example in the form of a light-weight case study describing one of our own projects. Finally, we described current and future challenges for designers of CDSS and propose a direction for future research, i.e., the integration of more human-centered and participatory design activities into the development processes of medical software.