Requirements for a dashboard optimized for melanoma patient care through user-centered context exploration

Abstract

For time-sensitive treatment of a patient with malignant melanoma, physicians must obtain a rapid overview of the patient’s status. This study aimed to analyze context-specific features and processes at the point of care to derive requirements for a dashboard granting more straightforward access to information. The Think-Aloud method, contextual inquiries, and interviews were performed with physicians from the Department of Dermatology at the University Hospital Essen in Germany. The user statements and observations that were obtained were grouped and categorized using an affinity diagram. Based on the derived subjects, requirements were defined, confirmed, and prioritized. The resulting affinity diagram revealed four topics of importance at the point of care. These topics are “Identifying and Processing the Important”, a comprehensive “Patient Record”, tasks and challenges in the “Clinical Routine”, and interactions and experiences with the available “Systems”. All aspects have been reflected in 135 requirements for developing context- and indication-specific patient dashboards. Our work has elucidated the most important aspects to consider when designing a dashboard that improves patient care by enabling physicians to focus on the relevant information. Furthermore, it has been demonstrated that the aspects most often mentioned are not context-specific and can be generalized to other medical contexts.

Full text

1
Vol.:(0123456789)
Scientic Reports | (2024) 14:17471 | https://doi.org/10.1038/s41598-024-67857-2
www.nature.com/scientificreports
Requirements for a dashboard
optimized for melanoma patient
care through user‑centered context
exploration
Eva Maria Hartmann
1*, Alisa Küper
2, Jessica Swoboda
3, Georg Christian Lodde
4,
Elisabeth Livingstone
4, Catharina Lena Beckmann
1, Dirk Schadendorf
4 & Sabine Sachweh
1
For time‑sensitive treatment of a patient with malignant melanoma, physicians must obtain a rapid
overview of the patient’s status. This study aimed to analyze context‑specic features and processes
at the point of care to derive requirements for a dashboard granting more straightforward access
to information. The Think‑Aloud method, contextual inquiries, and interviews were performed with
physicians from the Department of Dermatology at the University Hospital Essen in Germany. The
user statements and observations that were obtained were grouped and categorized using an anity
diagram. Based on the derived subjects, requirements were dened, conrmed, and prioritized. The
resulting anity diagram revealed four topics of importance at the point of care. These topics are
“Identifying and Processing the Important”, a comprehensive “Patient Record”, tasks and challenges
in the “Clinical Routine”, and interactions and experiences with the available “Systems”. All aspects
have been reected in 135 requirements for developing context‑ and indication‑specic patient
dashboards. Our work has elucidated the most important aspects to consider when designing a
dashboard that improves patient care by enabling physicians to focus on the relevant information.
Furthermore, it has been demonstrated that the aspects most often mentioned are not context‑
specic and can be generalized to other medical contexts.
Keywords Melanoma, Dashboard, Requirements, User experience, Electronic health records, Context
exploration
During the treatment of patients diagnosed with melanoma (black skin cancer), it is crucial for dermato-oncol-
ogists (dermatologists specialized in cancer) to obtain a complete understanding of the patient’s status imme-
diately. erefore, accessibility and timeliness of the relevant data are in focus. In recent years, various medical
information systems have been used increasingly in the EU to support the process of treatment and documenta-
tion at the point of care1; however, the usability of many of these systems has been generally poor2–7. Usability is
dened by the accuracy and completeness with which the physician can reach the desired goal (eectiveness),
the eort that is needed for task completion (eciency), and how enjoyable the interaction is throughout the
process (enjoyment of use)8. Lack of usability can lead to errors that can be life-threatening to patients3,9,10 and
numerous kinds of workarounds, where physicians use the information system dierently, than it was intended,
to reach their desired goal10. Without addressing the issue of optimizing soware for the context in which it will
be used, these problems will remain11.
To counteract this well-known problem, methodologies such as user experience12 that take the user, the set-
ting, and the situation of a soware use into the focus of the implementation have been introduced. Such a user-
centered design can address the problem of high mental load, especially insituations in which many dierent
types of information need to be gathered, combined, and compared under time pressure13,14. Early involvement
of users in the development process and an initial, thorough context exploration can lead to the creation of
OPEN
1Department of Computer Science, University of Applied Sciences and Arts Dortmund, 44227 Dortmund,
Germany. 2Department of Social Psychology: Media and Communication, University of Duisburg-Essen,
47057 Duisburg, Germany. 3Institute for Articial Intelligence in Medicine, University Hospital Essen, 45147 Essen,
Germany. 4Clinic for Dermatology, University Hospital Essen, 45147 Essen, Germany. *email: eva.hartmann@
-dortmund.de
Content courtesy of Springer Nature, terms of use apply. Rights reserved

2
Vol:.(1234567890)
Scientic Reports | (2024) 14:17471 | https://doi.org/10.1038/s41598-024-67857-2
www.nature.com/scientificreports/
systems with easier accessibility that support physicians in clinical routine and specic tasks15,16, thus increasing
productivity14. However, this step is oen skipped during the development of most systems17.
Prior research has also revealed common factors that inuence the acceptance or rejection of medical infor-
mation systems2,11,18–20. For the acceptance of a system, users have specied ease of use as a key factor. e ability
of the system to integrate into a context-specic workow and its helpfulness in achieving a set goal have also
been labeled as essential. Privacy issues20,21, poor design, long system downtimes, and long response times have
led medical sta to reject systems5,19,20.
Initiating soware development by placing a focus on context exploration has proven to prevent developers
from deriving (dening) inadequate and incomplete requirements22,23. Granting users inuence on an application
through participation in its development process24 leads to higher acceptance25 and can create enriched designs
by including dierent user insights26. Such designs oen focus especially on user-relevant factors and therefore
reduce mental load and information loss27. By overcoming the challenges of time constraints in clinical routines
and recruiting a sucient number of participants to represent the context28, user-centered design can improve
soware acceptance if the identied key factors are interwoven into the solution29.
To exploit the advantages of a user-centered design, our approach involved a combination of methods from
the eld of user research to explore the context and workows in which the soware would be used. For this
purpose, user statements and insights were gathered and combined to gain contextual knowledge. e derived
requirements were phrased and ranked according to their impact on the user’s ability to achieve their objective.
Following this approach, a complete set of requirements has been established based directly on observations of
the context or user statements. ese requirements, which form the basis of dashboard development, consider
user-related factors, place a focus on data relevant to the treatment of melanoma patients, and oer contextual
knowledge to enable workow integration.
Our study aimed to dene a reproducible starting point for context-sensitive dashboard development using
early user involvement. erefore, in this paper, we introduce a set of functional (FR) and non-functional
requirements (NFR) for the context of melanoma treatment. Furthermore, we uncovered the underlying user’s
intention related to the dened requirements by linking them with the important aspects of this context through
an anity diagram (AD). To address real-world problems in the context, we introduce the unique combina-
tion of using the insights gathered from the think-aloud method (TA) and contextual inquiry (CI) in an AD to
dene requirements.
Methods
Ethics statement
is study was approved by the Ethics Committee of the Medical Faculty (approval number 22-10814-BO for
CI and survey) and the Faculty of Engineering (approval number 2111SPKA9493 for TA) of the University of
Duisburg-Essen. All procedures were performed in accordance with the ethical standards of the institutional
research committees, the 1964 Helsinki Declaration, and its later amendments or comparable ethical standards.
All subjects provided their informed consent for inclusion on the TA in written form. e CI and survey protocols
did not include any personal data.
Approach
For the denition of requirements, user phrases obtained by the TA method, CI, and continuous feedback
regarding derived context descriptions were collected to serve as foundation of an AD revealing the topics most
important to the context (Fig.1). e requirements were then draed and subsequently ranked regarding their
priority by three experts. Physicians with various levels of expertise from the Department of Dermatology at
the University Hospital Essen (UME) in Germany participated in these qualitative methods. Senior physicians,
specialists, and residents who had just begun working in this department contributed their domain knowledge
and personal input (Table1). Finally, the requirements were reviewed with regard to their relationships to the
hospital and excluded if not generally applicable.
Think‑Aloud method
e TA30,31 method is common in user-centered approaches and has been used frequently to reveal problem
areas and factors important to an inspected context32. It is conducted by asking participants to fulll a task and
at the same time express their thoughts verbally. ese actions and thoughts are recorded and analyzed to depict
the context and build designs based on this knowledge. is method is applicable to any scenario33, has been
shown to be highly eective, and allows modeling and design based on voices of real users rather than external
interpretations33.
e TA method was conducted with 10 participants from the UME in the eld of melanoma treatment. e
explored task was the preparation of a ctitious tumor board for a patient in a possibly metastatic setting. Task
execution was captured via computer screen and voice recording. To simulate real-world circumstances, this
process occurred in the clinic using real patient data from the hospital information systems. e time was limited
to 15min, and no interaction with the conductors occurred other than reminders to think aloud.
e TA provided deep insights into the interactions with the soware, the relevant data, how they relate to
one another, and how physicians translate the information into decisions. Nevertheless, the time required is
very high, especially in this time-critical context. e setting and the task were as realistic as possible, and the
participants were informed in advance that the study focused on their interaction with the soware and not on
their medical decisions. Despite this, some physicians were nervous, felt uncomfortable expressing their profes-
sional thoughts out loud, and maybe ltered their statements.
Content courtesy of Springer Nature, terms of use apply. Rights reserved

3
Vol.:(0123456789)
Scientic Reports | (2024) 14:17471 | https://doi.org/10.1038/s41598-024-67857-2
www.nature.com/scientificreports/
Figure1. Pipeline derivation and evaluation requirements with a combination of qualitative user-centered
methods.
Table 1. Methods used to derive and evaluate requirements in the context of melanoma patient treatment,
their purposes in the information-processing pipeline, the numbers of participants, and the methods used to
collect the data.
Method Purpose in information processing Focus of exploration Number of participants Data collection method
ink-Aloud
Context exploration
Preparation of tumor board 10 Screen recording, voice
recording
Contextual inquiry Ambulant treatment 2Protocol
Initial presentation 2 Protocol
Interviews Dras of context models 2 Protocol
Survey Evaluation of derived requirements Prioritization of derived requirements 2 Online survey
Content courtesy of Springer Nature, terms of use apply. Rights reserved

4
Vol:.(1234567890)
Scientic Reports | (2024) 14:17471 | https://doi.org/10.1038/s41598-024-67857-2
www.nature.com/scientificreports/
e data gathered was anonymized by voice alteration and transcription of the recorded voices. Aerwards,
relevant phrases were extracted from the transcripts and used anonymously as part of the AD.
Contextual inquiry
CI16 is a participatory method in user research, which involves the user in the development process and takes
an entire context into focus. By accompanying physicians in conducting the tasks supported by soware and
observing their interactions, the nature of situations can be revealed. With this approach, direct insights into
the setting, intents of usage, and utilization of available IT systems can be gathered2. is knowledge enables the
design of soware that uses context-specic wording and helps to identify standard solutions that might cause
conicts in this context. Even facts that are subconscious and dicult to articulate can be revealed using this
method17. Revealing true needs is a strong basis for deriving requirements based on real insights rather than
interpretation by external factors28. Conducting a CI is relevant for a holistic view of the context15,34,35.
CI was conducted with two participants each for the tasks of outpatient care and the initial presentation of
new patients. e information gathered was documented in prepared protocols that focused on the setting, inter-
ruptions, and interactions with IT systems or colleagues. No personal information regarding the participating
physicians was documented.
e CI gave an unltered view of the observed tasks, usual settings, and interactions with the medical sta
and patients without impacting the physician’s time. e physicians were used to introducing new colleagues
to their tasks and being accompanied, which made the CI very realistic and unvaried. Observations were only
limited if the patient felt uncomfortable with an observer, or the observer did not want to accompany the medi-
cal treatment.
To facilitate empathy during the AD modeling process, user phrases were extracted from the protocols by
rephrasing the insights in the rst person. In addition, any questions that arose during the modeling phase
were collected and discussed in semi-structured interviews with two dermato-oncologists. ese insights were
similarly extracted from the protocols and inserted into the AD.
Anity diagram
As part of contextual design, the AD35 was developed to reveal the topics important to an explored context.
Building an AD begins with sorting user phrases and insights gained from qualitative methods according to their
content. Obtaining a maximum number of statements per group leads to critical reection, discovery of deeper
insights, reorganization, and rephrasing of the groups. Aerwards, these groups are clustered into sub-topics,
which again are grouped into topics. e specied groups, sub-topics, and topics are called anities, from which
the name of the diagram originates. During the modeling process, all groups, sub-topics, and topics are given
descriptions in I-perspective, which supports empathy during the design process. is structuring of messages
leads to the identication and clarication of areas of interest separated into manageable groups36,37 and serves
as a solid foundation to derive user-founded requirements38.
Requirements
In computer science, it is important to formulate a need that soware must fulll under given circumstances
and known limitations39 in order to ensure the quality of the implementation and determine the purpose of
the task. ese needs and limitations are dened as requirements and exist in a hierarchical order with more
specic sub-requirements. A distinction can be made between FRs, which dene a functionality a soware must
provide, and NFRs, which describe characteristics a soware must integrate. To dierentiate their importance,
a requirement can be prioritized into three levels. Functionalities or characteristics that are necessary to fulll a
task supported by the dened soware have the highest priority and shall be implemented. Useful features that
are not essential for task completion are requirements that should be included. Aspects facilitating work but not
necessary for reaching the set goal may be supported by the soware40.
Using these user-centered methods, we have derived a set of requirements for patient dashboard development
and optimization in the context of melanoma treatment.
Deriving requirements
To derive requirements based on qualitative data, the transcriptions of TA sessions and CI protocols were split
into shorter phrases containing only one message. e user statements were then grouped into three hierarchies
and labeled in I-perspective regarding their shared content by modeling the AD. Requirements were determined
based on the resulting topics, sub-topics, and groups. Starting with the most abstract level (topics) of the AD, each
level down to the very practical user statements was considered individually. e core message of the anity was
extracted and its inuence on the dashboard was evaluated. In the next step, this insight was phrased as a new
requirement or assigned to an existing one. Aerward, all requirements were examined to determine whether
they described a functionality or a feature. Finally, the requirements were grouped by their focus in a hierarchi-
cal order, with more specic sub-requirements. e majority of requirements were derived from sub-topics and
groups. In very few cases, general requirements were linked to single phrases or specialized sub-requirements
referred to a topics.
Evaluation of derived requirements
e derived requirements were evaluated for generalizability; those directly tied to the organization and its
specic workows were excluded. Furthermore, during a survey, the requirements were either prioritized or
excluded to ensure correct interpretation of the user phrases by the derived requirements. In this process, two
physicians and an IT specialist rated the requirements regarding their prioritization. e following four options
Content courtesy of Springer Nature, terms of use apply. Rights reserved

5
Vol.:(0123456789)
Scientic Reports | (2024) 14:17471 | https://doi.org/10.1038/s41598-024-67857-2
www.nature.com/scientificreports/
were available to classify the requirements, the corresponding values of which are given in brackets: Functionali-
ties or characteristics necessary to fulll a task supported by the dened soware have the highest priority and
shall (3) be implemented. Useful features that are not essential for task completion are requirements that should
(2) be included. Aspects facilitating work but not necessary for reaching the set goal may (1) be supported by the
soware. Participants could also mark a requirement as not necessary (0) to check for or add missing aspects.
Aer adding the priorities, the arithmetic mean of the prioritization was nally applied to the list of requirements.
Overall, this study combined the TA method and CI to collect user-statements during the work process.
ese statements were subsequently sorted in an AD regarding their shared topics. ese topics and statements
were used to derive requirements that were directly related to the context. To prevent misinterpretation of these
statements within the requirements, they were nally ranked regarding their prioritization or ltered out by
conducting a survey.
Results
Anity diagram
Overall, 507 user phrases were extracted from the qualitative data (text from transcripts and protocols) and
combined in an AD. e resulting topics were then used to dene 135 requirements. Considering the results side
by side, it revealed not only required functionalities and features but also underlying user intentions.
Analysis of 507 user phrases organized in an AD revealed four main topics relevant to the context (Fig.2).
ese topics included identication of important data related to treatment (“Identifying and Processing the
Important”), the importance of a comprehensive patient record (“Patient Record”), integration with clinical
routine and experience (“Clinical Routine”), and interaction with available systems (“Systems”). e following
section only focuses on AD’s rst top hierarchies. e complete set of anities is included in the supplement
(excel sheet tab: “1-overview-anities”).
Containing 214 sub-elements, “Identifying and Processing the Important” was the most-oen mentioned
aspect of the task of treating melanoma patients. Outlined by eight sub-topics, it encompasses the challenges of
nding the proper starting point, collecting data, and searching for details important to the case even under time
Figure2. Four main topics (colored areas) and sub-topics of the anity diagram. e boxes containing the
sub-topics have been scaled based on the number of underlying groups.
Content courtesy of Springer Nature, terms of use apply. Rights reserved

6
Vol:.(1234567890)
Scientic Reports | (2024) 14:17471 | https://doi.org/10.1038/s41598-024-67857-2
www.nature.com/scientificreports/
pressure. All the information gathered must be evaluated for pertinence (behavior over time) and combined
with data from other sources. While maintaining a focused view of the current case, the disease’s progression
must also be considered.
A comprehensive “Patient Record” displaying all the required information was the second-most frequently
referenced aspect. Information that must be included in a melanoma-specic dashboard was identied by 203
sub-elements in six sub-topics: staging, adverse events, internal and external reports, therapies, determining the
patient’s status, and details on the melanoma itself.
e subject of “Clinical Routine” was mentioned in 179 sub-elements. e six sub-topics consider the setting
and the level of work experience of the physicians. Having the patient in focus reects the responsibility of physi-
cians towards their patients, the aim of personalizing treatment, and communication between both physicians
and colleagues and physicians and patients. Furthermore, the importance of side tasks during treatment was
emphasized.
e last main topic relates to the “Systems” available and interactions with them. In ve sub-topics containing
107 sub-elements, pain points (pitfalls) in soware interaction, the inuence of personal preferences and habits,
data quality, and the possibilities of reusing data already known by the system(s) were in focus. is topic also
includes references to the dashboard as a new system.
Requirements
A total of 426 of 507 user phrases were reected in 135 requirements for a dashboard supporting the treatment
of melanoma patients, whereas 81 user statements could not be used to dene requirements for a dashboard,
and three requirements were excluded due to their strong relationship to the workow at the hospital itself.
e 135 derived requirements could be further classied into 97 which dened functional aspects, and 38
which referred to non-functional characteristics that must be considered. rough prioritization, 39 of the 97
functionalities were marked as indispensable (shall) for the treatment of melanoma patients. To facilitate the
process, 52 more of the 97 requirements should be implemented, and six may be an opportunity to simplify
the workow and information retrieval further. e functionalities were grouped into 13 main requirements,
which are shown in Table2 in conjunction with the anities from which they were derived. In the following
description, only the top hierarchy level of requirements with the most frequent assignments to anities has
been presented in detail. e complete catalog of requirements and sub-requirements has been included in the
supplement (excel sheet tab: “2-overview-requirements”).
Table 2. e 13 main FRs and ve main NFRs and their relationships to the user statements and topics in
the anity diagram. Requirements have been represented by their ID and their specic requirement text.
e anities have been reected in the counts of anities associated with the requirement group (main
requirement with sub-requirements), alongside assigned rst sub-topics.
Main requirement ID Requirement “e dashboard shall/ should/may
include…” Count anity per requirement group Anity-1st sub-topics
FR00 An all-encompassing view of all a patient’s data 69
Determine patient’s status, usage of data available,
responsibility, side tasks, personalization of medicine,
level of work experience, data collection, identifying
important aspects, combining information, searching
for details, focused view
FR01 e current staging 22 Staging
FR02 Ensuring access to external and internal ndings 51 Internal and external reports, responsibility, side tasks
FR03 e master data of the patient 15 Data quality
FR04 e latest tumor board protocols 12 Determine patient’s status, starting points
FR05 e medication 6 Determine patient’s status, side tasks
FR06 e current laboratory values 16 Determine patient’s status
FR07 Progress documentation 29 Determine patient’s status
FR08 e histology of the tumor 9 Determine patient’s status
FR09 An overview of all melanoma-specic aspects 45 Melanoma
FR10 e therapy 42 erapy
FR11 e reference to external documents needed for the
fulllment of the tasks 24 Communication, level of work experience
FR12 Searching in and ltering lists 55 Searching for details, treatment factor time
NFR00 Enable the user to get an overview even when time is
short 111 Information processing
NFR01 Meet the requirements for data protection 10 Data quality
NFR02 Limit the respective view to the use case‐dependent
essential information 29 Focused view
NFR03 Arrange elements based on the logic of melanoma
treatment 15 Focused view
NFR04 Optimize work in any task‐appropriate usage setting 24 Personal factors, communication
Content courtesy of Springer Nature, terms of use apply. Rights reserved

7
Vol.:(0123456789)
Scientic Reports | (2024) 14:17471 | https://doi.org/10.1038/s41598-024-67857-2
www.nature.com/scientificreports/
Based on the number of user phrases associated with the functional aspects, four key factors could be identi-
ed. e rst factor (FR00), associated with 69 user phrases, states that an all-encompassing view of all a patient’s
data, with straightforward access, is the most important functionality. A second consideration is the importance
of sorting and ltering functionalities to search available data for necessary information and to reect the patient’s
status in chronological order. is aspect was mentioned in 55 user statements (FR12). Mentioned by 51 users,
access to original external and internal reports ranked third. ese reports are main sources of information and
are useful for identifying information regarding documentation of progress and fulllment of side tasks related
to patients (FR02). e fourth aspect, mentioned 45 times by participants, refers to obtaining an overview of
the melanoma itself (FR09). is overview includes the details of the primary tumor, in particular its location,
tumor diagnosis, classication, lymph node status, location and conrmation of metastases, and the develop-
ment of the tumor over time (Table3).
Apart from the functionalities required, 38 NFRs were also derived to describe the characteristics that a
dashboard should exhibit. According to the prioritization by two domain experts and one IT-expert, 18 of these
attributes are indispensable (shall), 18 could simplify (should), and two may enrich the process of melanoma
patients’ treatment. e characteristics have been grouped into ve main requirements, along with their associa-
tions with the anities from which they were derived.
Mentioned most oen, with 111 assigned anities, is the requirement (NFR00) for support of information
processing through an overview that not only contains all necessary information but also is especially easy to
interpret. Assigned to 29 user phrases, a view adapted to the task at hand can assist in obtaining a focused view
of the relevant information (NFR02). e adaptation of the soware to dierent settings was mentioned in 24
anities (NFR04). Such adaptation includes exibility with personal preferences and habits and support for
communication. Optimizing a view while considering melanoma domain knowledge can provide experts with
a focused and more easily interpretable view (NFR03), as highlighted by 15 user statements. According to 10
anities, a dashboard must also ensure data protection, quality, and reproduction true to the original informa-
tion (NFR01).
Discussion
Our work has provided a set of important requirements at the point of care in the treatment of melanoma
patients. ese requirements were derived from user phrases using an AD to identify and clarify the most
important aspects. Using CI and the TA method, insights were gained by observing the working routine rather
than making assumptions.
In contrast to other publications that have employed user-centered approaches only for nal evaluation, this
approach emphasized the value of early involvement and thorough context exploration before designing and
implementing the system. Although the benets of direct insights into context have been shown previously,
user-centered methods have remained sparsely used in the eld of medicine, especially at the initial stages of
the development process. For example, CI has been used to gain insights into the workows of telecardiology
and derive requirements based on these41. e AD has been used as a basis for determining topics that need
to be investigated in further detail for daily morning surgical rounds in intensive care units (ICUs)42. Another
publication has described two studies that applied a combination of CI and AD to derive requirements for the
dictation process of physicians and a nursing documentation system43. By bringing these approaches to the eld
of melanoma treatment, unique requirements for this context were derived in the present study. To our knowl-
edge, no other work has combined the TA, CI, and AD in one study to derive requirements for the development
of a patient dashboard.
e results reported here demonstrate the strength of this approach. ey have highlighted generalizable
aspects of dashboard development and have also provided detailed insights into domain-specic needs. e
factors mentioned most oen refer to general aspects, such as gaining a comprehensive view even under time
pressure, which would be transferable to other dashboard projects. Additionally, detailed insights into the medical
aspects of melanoma have been highlighted. is includes specic prioritized data and a comprehensive view of
Table 3. Melanoma-specic sub-requirements, represented by ID, priority, and a specic requirement text.
e user phrases have been reected in the counts of statements associated with each requirement.
Requirement ID Priority Functionality Count statement per requirement
FR09.01 SHALL e current status of the primary tumor 5
FR09.01.01 SHALL e localization of the primary tumor 1
FR09.02 SHALL e tumor diagnosis 7
FR09.02.01 SHOULD e conrmation status of the diagnosis 4
FR09.03 SHALL e TNM classication 7
FR09.03.01 SHALL e tumor stage 3
FR09.04 SHOULD e change of the tumor stage over time 8
FR09.05 SHOULD e current status of the lymph nodes 4
FR09.06 SHALL Information regarding possible metastases 2
FR09.06.01 SHOULD e type and location of the metastasis 1
FR09.06.02 SHOULD e status of the conrmation of metastasis ndings 2
Content courtesy of Springer Nature, terms of use apply. Rights reserved

8
Vol:.(1234567890)
Scientic Reports | (2024) 14:17471 | https://doi.org/10.1038/s41598-024-67857-2
www.nature.com/scientificreports/
the patient’s information that is needed due to the high impact of cancer on the patient’s entire body. Dierent
types of cancer have dierent markers and values, such as typical genetic alterations, which need to be considered
in diagnosis and treatment. However, similar diagnostic procedures are oen used, resulting in the same data
types. is implies that the very context-specic requirements are also highly reusable for other types of cancer.
Further research will have to evaluate the generalizability of information-related requirements as well as those
referring to general aspects. Addressing the related contexts of (skin) cancer treatment will give rst valuable
insights into the scalability of the requirements.
One limitation of this approach is that each context must be investigated separately to obtain context-specic
insights. Context exploration must be performed for each discipline and does not oer a generally valid solution
for every application. Dierent contexts might involve dierent settings the soware will be used in, like mobile
usage or limited soware interaction possibilities as usual in operation rooms. Dierent diseases will lead to dif-
ferent data being prioritized during decision-making. However, the generalizable aspects identied can be used
to focus primarily on domain-specic details in future projects. Requirements referring to getting an overview
of the patient’s status or searching and ltering functions are most likely to be transferable even to other disci-
plines. More specialized aspects, like the information prioritized, might be partly reusable for other cancers and
highly reusable for other skin cancers. ose dierences will always need to be evaluated in dierent settings.
A further limitation is that these results were derived based on a single hospital. Whether our requirements
can be implemented directly in other hospitals needs to be evaluated. Dierences in workows and related data
acquisition might as well be hindering the transferability of the requirements, as might dierences in the user
group regarding the working experience and the user’s technical anity. ose aspects might lead to dierent
data needed during the treatment and shi focus on their prioritization. As treatment for melanoma follows
guidelines, the transferability of the requirements might strongly depend on the implementation of the guidelines
in dierent hospitals.
Overall, the applicability of the TA method and especially CI have proven to be valuable in this time-critical
context. Combining, on the one hand, the TA, which has a specic task in a staged setting in focus, with the
CI, where physicians are accompanied during working routines, has opened a broad view of the context from
several directions. ey have demonstrated utility in gaining deep insights into this complex context, making it
accessible even for people not directly involved in that context, such as developers, through an AD.
e derived requirements can serve as a foundation for iteratively incorporating these needs into a dashboard
design, allowing the developer to reect on the design with the user’s intentions in mind. Deriving require-
ments with a user-centered approach was only the rst step in the development of a context-, patient- and
user-optimized dashboard for the treatment of melanoma. Future research needs to explore how the relevant
data can be termed, grouped44,45, and visualized45,46 while addressing dierent, even contradictory personal
preferences47,48. Data coming from dierent clinical information systems might be, duplicated, incomplete, and
contradictory. e challenge of preventing the user from overload while evaluating the combined information
will need to be addressed49.
Varying soware interfaces of the dierent information systems can cause problems in the merging of data.
It needs to be explored how interoperability between these systems can be established while ensuring data
quality20,49. Combining this research with continuous user feedback and testing for developed concepts, proto-
types, and the end product, can ensure the correct implementation15 and the usability of medical systems can
be sustainably improved.
In summary, this study made two main contributions to the eld of medical informatics. On one hand,
it identied critical requirements for melanoma patient treatment at the point of care through user-centered
methods. rough early user involvement and thorough context exploration, our approach provided valuable
insights into workows and specic needs. e highlighted generalizable aspects can, furthermore, be used as a
foundation for dashboards in dierent medical domains. On the other hand, the study demonstrated the utility
of CI and TA in understanding complex contexts, making the knowledge gained accessible to developers through
an AD and reusable by the denition of requirements.
It points out a combination of methods that are proven to be applicable in the time-critical and complex con-
text of medical treatment to dene an implementation instruction for a dashboard that is aware of the patient’s
context and the user. is user-centered focus in development ensures that the dashboard will address real-world
needs and counteract errors related to missing context integration. ereby, making the access to data easier for
the physicians allows them to focus only on the important aspects and make decisions based on them.
Data availability
e authors conrm that the data supporting the ndings of this study is available within the article and its sup-
plementary materials or upon reasonable request to the corresponding author.
Received: 8 March 2024; Accepted: 16 July 2024
References
1. European Commission, RAND Europe, Open Evidence, BDI Research. Benchmarking Deployment of eHealth Among General
Practitioners: Final Report (Publications Oce, 2018).
2. Viitanen, J. et al. National questionnaire study on clinical ICT systems proofs: Physicians suer from poor usability. Int. J. Med.
Inform. 80(10), 708–725. https:// doi. org/ 10. 1016/j. ijmed inf. 2011. 06. 010 (2011).
3. Nielsen Norman Group. Medical Usability: How to Kill Patients rough Bad Design. https:// www. nngro up. com/ artic les/ medic
al- usabi lity/ (Accessed 7 December 2023).
Content courtesy of Springer Nature, terms of use apply. Rights reserved

9
Vol.:(0123456789)
Scientic Reports | (2024) 14:17471 | https://doi.org/10.1038/s41598-024-67857-2
www.nature.com/scientificreports/
4. Viitanen, J., Tyllinen, M., Tynkkynen, E. & Lääveri, T. Usability of information systems: Experiences of outpatient physicians, out-
patient nurses, and open care social welfare professionals from three large cross-sectional surveys in Finland. Int. J. Med. Inform.
165, 104836. https:// doi. org/ 10. 1016/j. ijmed inf. 2022. 104836 (2022).
5. Hudson, D., Kushniruk, A., Borycki, E. & Zuege, D. J. Physician satisfaction with a critical care clinical information system using
a multimethod evaluation of usability. Int. J. Med. Inform. 112, 131–136. https:// doi. org/ 10. 1016/j. ijmed inf. 2018. 01. 010 (2018).
6. Topaz, M. et al. Nurse informaticians report low satisfaction and multi-level concerns with electronic health records: Results from
an International Survey. AMIA Annu. Symp. Proc. 2016, 2016–2025 (2016).
7. Vainiomäki, S. et al. Better usability and technical stability could lead to better work-related well-being among physicians. Appl.
Clin. Inform. 8(4), 1057–1067. https:// doi. org/ 10. 4338/ ACI- 2017- 06- RA- 0094 (2017).
8. Ergonomics of Human–System Interaction: Part 11: Usability: Denitions and Concepts, 9241-11:2018(en) (International Organiza-
tion for Standardization, 2018).
9. Kushniruk, A. W., Triola, M. M., Borycki, E. M., Stein, B. & Kannry, J. L. Technology induced error and usability: e relationship
between usability problems and prescription errors when using a handheld application. Int. J. Med. Inform. 74(7–8), 519–526.
https:// doi. org/ 10. 1016/j. ijmed inf. 2005. 01. 003 (2005).
10. Blijleven, V., Hoxha, F. & Jaspers, M. Workarounds in electronic health record systems and the revised sociotechnical electronic
health record workaround analysis framework: Scoping review. J. Med. Internet Res. 24(3), e33046. https:// doi. org/ 10. 2196/ 33046
(2022).
11. Kaipio, J. et al. Usability problems do not heal by themselves: National survey on physicians’ experiences with EHRs in Finland.
Int. J. Med. Inform. 97, 266–281. https:// doi. org/ 10. 1016/j. ijmed inf. 2016. 10. 010 (2017).
12. Norman, D., Miller, J. & Henderson, A. What you see, some of what’s in the future, and how we go about doing it. In Conference
Companion on Human Factors in Computing Systems—CHI’95 155 (1995).
13. Belden, J. L. et al. Designing a medication timeline for patients and physicians. J. Am. Med. Inform. Assoc. 26(2), 95–105. https://
doi. org/ 10. 1093/ jamia/ ocy143 (2019).
14. Ergonomics of Human-System Interaction—Part 210: Human-Centred Design for Interactive Systems 9241-210:2019 (International
Organization for Standardization, 2019).
15. van Gemert-Pijnen, J. E. W. C. et al. A holistic framework to improve the uptake and impact of eHealth technologies. J. Med.
Internet Res. 13(4), e111. https:// doi. org/ 10. 2196/ jmir. 1672 (2011).
16. Karen, H. & Sandra, J. Contextual inquiry: A participatory technique for system design. In Participatory Design: Principles and
Practices 1st edn (eds Schuler, D. & Namioka, A.) 177–210 (CRC, 1993).
17. Kip, H., Beerlage-deJong, N. & Wentzel, J. e contextual inquiry. In eHealth Research, eory, Development: A Multi-disciplinary
Approach (eds van Gemert-Pijnen, L. et al.) 168–186 (Taylor and Francis, 2018).
18. Bleich, H. L. & Slack, W. V. Reections on electronic medical records: When doctors will use them and when they will not. Int. J.
Med. Inform. 79(1), 1–4. https:// doi. org/ 10. 1016/j. ijmed inf. 2009. 10. 002 (2010).
19. Huryk, L. A. Factors inuencing nurses’ attitudes towards healthcare information technology. J. Nurs. Manag. 18(5), 606–612.
https:// doi. org/ 10. 1111/j. 1365- 2834. 2010. 01084.x (2010).
20. Schopf, T. R., Nedrebø, B., Huhammer, K. O., Daphu, I. K. & Lærum, H. How well is the electronic health record supporting
the clinical tasks of hospital physicians? A survey of physicians at three Norwegian hospitals. BMC Health Serv. Res. 19(1), 934.
https:// doi. org/ 10. 1186/ s12913- 019- 4763-0 (2019).
21. Steininger, K. & Stiglbauer, B. EHR acceptance among Austrian resident doctors. Health Policy Technol. 4(2), 121–130. https:// doi.
org/ 10. 1016/j. hlpt. 2015. 02. 003 (2015).
22. S chön, E.-M., omaschewski, J. & Escalona, M. J. Agile requirements engineering: A systematic literature review. Comput. Stand.
Interfaces 49, 79–91. https:// doi. org/ 10. 1016/j. csi. 2016. 08. 011 (2017).
23. Maguire, M. Using human factors standards to support user experience and agile design. In Lecture Notes in Computer Science,
Vol. 8009, Universal Access in Human-Computer Interaction: 7th International Conference, UAHCI 2013, Held as Part of HCI Inter-
national 2013, Las Vegas, NV, USA, July 21–26, 2013; Proceedings (eds. Stephanidis, C. & Antona, M.) 185–194 (Springer, 2013).
24. Martikainen, S., Kaipio, J. & Lääveri, T. End-user participation in health information systems (HIS) development: Physicians’ and
nurses’ experiences. Int. J. Med. Inform. 137, 104117. https:// doi. org/ 10. 1016/j. ijmed inf. 2020. 104117 (2020).
25. Groeneveld, S. W. M., den Ouden, M. E. M., van Gemert-Pijnen, J. E. W. C., Verdaasdonk, R. M. & van Os-Medendorp, H.
Underestimated factors regarding the use of technology in daily practice of long-term care: Qualitative study among health care
professionals. JMIR Nurs. 6, e41032. https:// doi. org/ 10. 2196/ 41032 (2023).
26. Harris, M. A. & Weistroer, H. R. A new look at the relationship between user involvement in systems development and system
success. Commun. Assoc. Inf. Syst. 24(1), 442. https:// doi. org/ 10. 17705/ 1CAIS. 02442 (2009).
27. Norman, D. A. ings at Make Us Smart: Defending Human Attributes in the Age of the Machine (Basic Books, 1993).
28. Kushniruk, A. & Nøhr, C. Participatory design, user involvement and health IT evaluation. Stud. Health Technol. Inform. 222,
139–151 (2016).
29. Bano, M., Zowghi, D. & da Rimini, F. User satisfaction and system success: An empirical exploration of user involvement in soware
development. Empir. Sow. Eng. 22(5), 2339–2372. https:// doi. org/ 10. 1007/ s10664- 016- 9465-1 (2017).
30. Simon, H. A. & Newell, A. Human problem solving: e state of the theory in 1970. Am. Psychol. 26, 145–159 (1971).
31. Lewis, C. Using the “inking-Aloud” Method in Cognitive Interface Design. https:// domin ow eb. draco. res. ibm. com/ repor ts/ RC9265.
pdf (Accessed 7 December 2023) (1982).
32. Maramba, I., Chatterjee, A. & Newman, C. Methods of usability testing in the development of eHealth applications: A scoping
review. Int. J. Med. Inform. 126, 95–104. https:// doi. org/ 10. 1016/j. ijmed inf. 2019. 03. 018 (2019).
3 3. Jacobsen, J. & Meyer, L. Praxisbuch Usability und UX: Was alle wissen sollten, die Websites und Apps entwickeln 3rd edn. (Rheinwerk
Verlag, 2022).
34. Kip, H. et al. Methods for human-centered ehealth development: Narrative scoping review. J. Med. Internet Res. 24(1), e31858.
https:// doi. org/ 10. 2196/ 31858 (2022).
35. Holtzblatt, K. & Beyer, H. Contextual Design: Dening Customer-Centered Systems 1st edn. (Morgan Kaufmann, 1997).
36. Simon, R. W. & Canacari, E. G. A practical guide to applying lean tools and management principles to health care improvement
projects. AORN J. 95(1), 85–100. https:// doi. org/ 10. 1016/j. aorn. 2011. 05. 021 (2012).
37. Beyer, H. & Holtzblatt, K. Contextual design. Interactions 6(1), 32–42. https:// doi. org/ 10. 1145/ 291224. 291229 (1999).
38. Coble, J. M., Matt, J. S., Orland, M. J. & Kahn, M. G. Contextual inquiry: Discovering physicians’ true needs. In Proceedings.
Symposium on Computer Applications in Medical Care 469–473 (1995).
39. International Standard—Systems and Soware Engineering—Life Cycle Processes—Requirements Engineering 29148 (ISO/IEC/IEEE).
40. Bradner, S. Key Words for Use in RFCs to Indicate Requirement Levels (1997).
41. Gil-Rodríguez, E. P. et al. Organizational, contextual and user-centered design in e-health: Application in the area of telecardiol-
ogy. In HCI and Usability for Medicine and Health Care: ird Symposium of the Workgroup Human–Computer Interaction and
Usability Engineering of the Austrian Computer Society, USAB 2007 Graz, Austria, November, 22, 2007. Proceeding 69–82 (2007).
42. Tripathi, S., Naevor, A. J., Henrekin, L. L. & Welke, K. F. Design and development of daily morning surgical rounds in ICU by
quality function deployment. Pediatr. Qual. Saf. 4(3), 171. https:// doi. org/ 10. 1097/ pq9. 00000 00000 000171 (2019).
4 3. Viitanen, J. Contextual inquiry met ho d for user-centred clinical IT system design. In User Centred Networked Health Care 965–969.
https:// ebooks. iospr ess. nl/ volum earti cle/ 14314 (Accessed 7 December 2023) (IOS Press, 2011).
Content courtesy of Springer Nature, terms of use apply. Rights reserved

10
Vol:.(1234567890)
Scientic Reports | (2024) 14:17471 | https://doi.org/10.1038/s41598-024-67857-2
www.nature.com/scientificreports/
44. Charbonneau, D. H. & James, L. N. FluView and FluNet: Tools for inuenza activity and surveillance. Med. Ref. Serv. Q. 38(4),
358–368. https:// doi. org/ 10. 1080/ 02763 869. 2019. 16577 34 (2019).
45. Tory, M. & Möller, T. Human factors in visualization research. IEEE Trans. Vis. Comput. Graph. 10(1), 72–84. https:// doi. org/ 10.
1109/ TVCG. 2004. 12607 59 (2004).
46. Padilla, L. M., Creem-Regehr, S. H., Hegarty, M. & Stefanucci, J. K. Decision making with visualizations: A cognitive framework
across disciplines. Cogn. Res. Princ. Implic. 3, 29. https:// doi. org/ 10. 1186/ s41235- 018- 0120-9 (2018).
47. Conati, C. & Maclaren, H. Exploring the role of individual dierences in information visualization. In Proc. Working Conference
on Advanced Visual Interfaces 199–206 (2008).
48. Janssen, A. et al. Electronic health records that support health professional reective practice: A missed opportunity in digital
health. J. Healthc. Inform. Res. 6(4), 375–384. https:// doi. org/ 10. 1007/ s41666- 022- 00123-0 (2022).
49. Alami, H. et al. Rethinking the electronic health record through the quadruple aim: Time to align its value with the health system.
BMC Med. Inform. Decis. Mak. 20(1), 32. https:// doi. org/ 10. 1186/ s12911- 020- 1048-9 (2020).
Acknowledgements
e authors thank the physicians of the Department of Dermatology (University Hospital Essen) for their dedi-
cated participation in the usability studies. ey also thank Prof. Dr. Peter Haas (University of Applied Sciences
and Arts Dortmund) and Dr. Sylvia Nürnberg (WisPerMed) for their comments on the manuscript and support-
ive discussions. ey thank Dr. Katharina Zeiner (Siemens, Munich) for her mentoring and fruitful discussions
regarding the user experience methodology. All gures in this manuscript were created by the rst author Eva
Hartmann using Miro board online (https:// miro. com/) for Fig.1 and Excel—Oce 365 version 2405 (https://
www. micro so. com/ en- us/ micro so- 365/ excel) for Fig.2.
Author contributions
EMH: conceptualization, methodology, investigation, data curation, visualization, formal analysis, soware,
writing—original dra preparation. AK: data curation, methodology, investigation, formal analysis, writing—
review, and editing. GCL, EL, and DS: conceptualization, resources, writing—review, and editing. JS and CLB:
methodology, data curation, writing—review, and editing. SS: supervision, conceptualization, methodology,
writing—review, and editing.
Funding
Open Access funding enabled and organized by Projekt DEAL. is work was funded by Ph.D. grants from the
DFG Research Training Group 2535, “Knowledge- and data-based personalization of medicine at the point of
care (WisPerMed)”.
Competing interests
e authors declare no competing interests.
Additional information
Supplementary Information e online version contains supplementary material available at https:// doi. org/
10. 1038/ s41598- 024- 67857-2.
Correspondence and requests for materials should be addressed to E.M.H.
Reprints and permissions information is available at www.nature.com/reprints.
Publisher’s note Springer Nature remains neutral with regard to jurisdictional claims in published maps and
institutional aliations.
Open Access is article is licensed under a Creative Commons Attribution-NonCommercial-
NoDerivatives 4.0 International License, which permits any non-commercial use, sharing,
distribution and reproduction in any medium or format, as long as you give appropriate credit to the original
author(s) and the source, provide a link to the Creative Commons licence, and indicate if you modied the
licensed material. You do not have permission under this licence to share adapted material derived from this
article or parts of it. e images or other third party material in this article are included in the article’s Creative
Commons licence, unless indicated otherwise in a credit line to the material. If material is not included in the
article’s Creative Commons licence and your intended use is not permitted by statutory regulation or exceeds the
permitted use, you will need to obtain permission directly from the copyright holder. To view a copy of this
licence, visit http:// creat iveco mmons. org/ licen ses/ by- nc- nd/4. 0/.
© e Author(s) 2024
Content courtesy of Springer Nature, terms of use apply. Rights reserved

1.
2.
3.
4.
5.
6.
Terms and Conditions
Springer Nature journal content, brought to you courtesy of Springer Nature Customer Service Center GmbH (“Springer Nature”).
Springer Nature supports a reasonable amount of sharing of research papers by authors, subscribers and authorised users (“Users”), for small-
scale personal, non-commercial use provided that all copyright, trade and service marks and other proprietary notices are maintained. By
accessing, sharing, receiving or otherwise using the Springer Nature journal content you agree to these terms of use (“Terms”). For these
purposes, Springer Nature considers academic use (by researchers and students) to be non-commercial.
These Terms are supplementary and will apply in addition to any applicable website terms and conditions, a relevant site licence or a personal
subscription. These Terms will prevail over any conflict or ambiguity with regards to the relevant terms, a site licence or a personal subscription
(to the extent of the conflict or ambiguity only). For Creative Commons-licensed articles, the terms of the Creative Commons license used will
apply.
We collect and use personal data to provide access to the Springer Nature journal content. We may also use these personal data internally within
ResearchGate and Springer Nature and as agreed share it, in an anonymised way, for purposes of tracking, analysis and reporting. We will not
otherwise disclose your personal data outside the ResearchGate or the Springer Nature group of companies unless we have your permission as
detailed in the Privacy Policy.
While Users may use the Springer Nature journal content for small scale, personal non-commercial use, it is important to note that Users may
not:
use such content for the purpose of providing other users with access on a regular or large scale basis or as a means to circumvent access
control;
use such content where to do so would be considered a criminal or statutory offence in any jurisdiction, or gives rise to civil liability, or is
otherwise unlawful;
falsely or misleadingly imply or suggest endorsement, approval , sponsorship, or association unless explicitly agreed to by Springer Nature in
writing;
use bots or other automated methods to access the content or redirect messages
override any security feature or exclusionary protocol; or
share the content in order to create substitute for Springer Nature products or services or a systematic database of Springer Nature journal
content.
In line with the restriction against commercial use, Springer Nature does not permit the creation of a product or service that creates revenue,
royalties, rent or income from our content or its inclusion as part of a paid for service or for other commercial gain. Springer Nature journal
content cannot be used for inter-library loans and librarians may not upload Springer Nature journal content on a large scale into their, or any
other, institutional repository.
These terms of use are reviewed regularly and may be amended at any time. Springer Nature is not obligated to publish any information or
content on this website and may remove it or features or functionality at our sole discretion, at any time with or without notice. Springer Nature
may revoke this licence to you at any time and remove access to any copies of the Springer Nature journal content which have been saved.
To the fullest extent permitted by law, Springer Nature makes no warranties, representations or guarantees to Users, either express or implied
with respect to the Springer nature journal content and all parties disclaim and waive any implied warranties or warranties imposed by law,
including merchantability or fitness for any particular purpose.
Please note that these rights do not automatically extend to content, data or other material published by Springer Nature that may be licensed
from third parties.
If you would like to use or distribute our Springer Nature journal content to a wider audience or on a regular basis or in any other manner not
expressly permitted by these Terms, please contact Springer Nature at
onlineservice@springernature.com