Document [original]

Kevin Wiggert

The Role of Scenarios in Scripting

(the Use of) Medical Technology

The Case of Data-driven Clinical Decision Support Systems

Master’s Thesis

Technische Universität Berlin

Supervision:

First Supervisor:

Prof. Dr. Ingo Schulz-Schaeffer

Technische Universität Berlin

Second Supervisor:

Dr. Cornelius Schubert

University of Siegen

Date of Submission:

20.07.2020

Berlin 02/2021

I 
 
 
Content 
Acknowledgement .................................................................................................................................. III 
Abstract ..................................................................................................................................................... IV 
Zusammenfassung ................................................................................................................................... V 
Introduction ................................................................................................................................... 1 
The Epistemological Interest ....................................................................................................... 3 
The Perspective: The Role of Scripts and Scenarios in Technology Development ............. 5 
1. Users and Use Contexts in Technology Development – The Concept of the Script ... 7 
2. The Guiding Role of Scenarios in Technology Development ...................................... 13 
3. Scenarios in Context of Data-driven Clinical Decision Support – Three Additions . 19 
3.1. Direct Representation of Multiple Scientific Disciplines ................................... 19 
3.2. Specificity of Medical Regulations and Guidelines ............................................ 21 
3.3. Specific Schemes of Medical Work Arrangements ............................................. 22 
The Subject: Data-driven Clinical Decision Support Systems .............................................. 23 
1. Software as Medical Product and the Current Regulation of Machine Learning and 
Simulation in Medical Devices .............................................................................................................. 24 
2. Data-driven Clinical Decision Support Systems ............................................................ 26 
The Case Study: A Clinical Decision Support System for Decision-making and Therapy-
planning of Cardiovascular Diseases ................................................................................................... 31 
1. The Methods of Conducting and Interpreting the Empirical Data ............................. 32 
1.1. The Challenge of Anonymisation ....................................................................... 33 
1.2. Combining Qualitative Content Analysis and the Grounded Theory Method ... 34 
2. The Disease and Its Conventional Treatment................................................................. 35 
3. The Underlying Concept of the Digital Patient – Using Big Amounts of Data ......... 37 
4. The Prototypical CDSS and how it Operates .................................................................. 39 
The Analysis: An Implicit Scenario under Negotiation ........................................................ 42 

II 
 
1. Wherefrom Do the Developers have the Assumptions?............................................... 43 
2. Assumptions about how Cardiologists Conventionally Decide ................................. 44 
3. Implications of the Digital Patient Concept .................................................................... 49 
4. Imaginations of Use, the Scenario behind Them and Its Scripting into the CDSS .... 55 
4.1. The Dominant Narrative Scenario ..................................................................... 55 
4.2. The Different Role of the Patient ........................................................................ 57 
4.3. Different Envisions about the Clinical User of the CDSS .................................. 59 
4.4. The Cardiological and the Engineering Sub-scenario ....................................... 60 
Conclusion ................................................................................................................................... 62 
1. Summary .............................................................................................................................. 62 
2. Discussion ............................................................................................................................ 63 
3. Outlook ................................................................................................................................ 65 
Bibliography ............................................................................................................................................. 67 
 
   

III

Acknowledgement

I would like to thank in advance all those who have supported me in the writing of this

work. Above all, I would like to thank Linda and Tim for their wise comments and Junxi for

the last review and her helpful corrections of the English text. You are the best!

Abstract

Newly developed medical technology, which is supposed to provide information or support

decisions, is increasingly systemically opaque and is thus no longer comprehensible for the

physician. It becomes more and more unclear to the clinical user and also to the developers

themselves what data sources and what information are the fundaments of these technologies

and how the technology is computing its reasoning on this data. In order to better comprehend

the reasoning of these technologies for the actors engaged it is not only necessary to under-

stand the inner processes of the technology but also to get more insights into the assumptions

the technology is built on. This requires a better understanding of the imaginations and ideas

about the ways of use which are inscribed into the technology in the course of its development.

It is known that scenarios play a guiding role in this matter. Therefore, it is important to un-

derstand more about the role of scenarios (which are concrete ideas about future situations of

use) in the development of medical technology and what conclusions can be drawn with re-

gard to the development of systemically opaque technologies in medicine. To answer these

questions, the author uses a case study of the development of such a medical technology,

namely a so-called Clinical Decision Support System meant to support treatment decisions in

cardiology. This system differs from previous versions in that it is data-driven and partly com-

putes this data in a systemically opaque way, for example by using artificially intelligent algo-

rithms or highly complex simulations. In combining and extending the theoretical concepts of

situational scenarios in technology development as well as scripts written into technology it

becomes clear throughout the work that – due to the different disciplinary backgrounds of the

developers – the development of medical technology is often guided by partly disparate sce-

narios about who the target user is, how the technology should be used, what it should do,

how it should look like and how all this is to be achieved best. Accordingly, the building of

the prototype and the negotiation about the scenario’s components co-evolve, leading to a

more dominant scenario apparent in the technology and to specific scripts influencing the en-

visioned user to use the technology in particular ways. In the case studied it was particularly

the engineer’s perspective and less the cardiologist’s one about the application context that

was implemented, which ended in less recognition of the patient’s role in the consultation as

well as an assumed passivity on the part of the clinician as recipient of information delivered

by the technology.

Zusammenfassung

Neu entwickelte Medizintechnik, die Informationen liefern oder Entscheidungen unterstützen

sollen, ist zunehmend systemisch intransparent und damit für den Arzt nicht mehr nachvoll-

ziehbar. Welche Datenquellen und welche Informationen diesen Technologien zugrunde lie-

gen und wie die Technologien ihre Schlussfolgerungen aus diesen Daten berechnen, wird für

den klinischen Anwender und auch für die Entwickler selbst immer unklarer. Um die Funkti-

onsweise dieser Technologien für die beteiligten Akteure besser nachvollziehbar zu machen,

ist es nicht nur notwendig, die inneren Prozesse der Technologie zu verstehen, sondern auch

mehr Einblicke in die Annahmen zu erhalten, auf denen diese Technologien aufgebaut sind.

Dies erfordert ein besseres Verständnis der Vorstellungen und Ideen über die Nutzungswei-

sen, die der Technologie im Laufe ihrer Entwicklung eingeschrieben werden. Es ist bekannt,

dass Szenarien dabei eine leitende Rolle spielen. Deshalb ist es wichtig, mehr darüber zu ver-

stehen, welche Rolle Szenarien (das sind konkrete Vorstellungen über zukünftige Nutzungs-

situationen) bei der Entwicklung einer Medizintechnik spielen und welche Schlussfolgerun-

gen im Hinblick auf die Entwicklung systemisch opaker Technologien in der Medizin gezogen

werden können. Um diese Fragen zu beantworten, verwende ich eine Fallstudie über die Ent-

wicklung einer solchen Medizintechnik, nämlich ein sogenanntes klinisches Entscheidungs-

unterstützungssystem, das Behandlungsentscheidungen in der Kardiologie unterstützen soll.

Dieses System unterscheidet sich von früheren Versionen dadurch, dass es datengetrieben ist

und diese Daten teilweise in einer systemisch opaken Weise verarbeitet, zum Beispiel durch

den Einsatz künstlich intelligenter Algorithmen oder hochkomplexer Simulationen. Durch die

Kombination und Erweiterung der theoretischen Konzepte von Situationsszenarien in der

Technikentwicklung sowie von in die Technik eingeschriebenen Skripten wird im Laufe der

Arbeit deutlich, dass - aufgrund des unterschiedlichen disziplinären Hintergrunds der einzel-

nen Entwickler - die Entwicklung der Medizintechnik oft von zum Teil disparaten Szenarien

darüber geleitet wird, wer der Zielnutzer ist, wie die Technik eingesetzt werden soll, was sie

leisten soll, wie sie aussehen soll und wie all dies am besten zu erreichen ist. Entsprechend

entwickeln sich der Bau des Prototyps und die Verhandlungen über die Komponenten des

Szenarios gemeinsam, was zu einem dominanteren Szenario führt, das sich in die Technik

einprägt, und zu spezifischen Skripten, die den angedachten Benutzer beeinflussen, die Tech-

nik auf bestimmte Weise zu nutzen. Im untersuchten Fall wurde vor allem die Perspektive der

Ingenieure und weniger die der Kardiologen in Bezug auf den Anwendungskontext umge-

setzt, was dazu führte, dass die Rolle des Patienten in der Beratung weniger berücksichtigt

wurde und eine Passivität des Klinikers als Empfänger der von der Technologie gelieferten

Informationen angenommen wurde.

1. Introduction

Recently, the German-based management consulting company Roland Berger Holding GmbH

published a study

which concluded that within the next five years up to 20 percent of jobs in

the medical sector could be replaced by programs and robots labelled as to some extent artifi-

cially intelligent respectively data-driven (Roland Berger 2019: 13). In addition, the field of

personalised or individualised decision making and therapy is attributed a major role in near

future medical decision-making. According to the study, individualised therapies will be used

in about 30 percent of all medical cases by 2025, and so-called digital twins of patients will be

used in as many as 40 percent of cases in order to improve medical insights and simulate ther-

apy options before they are actually performed (Roland Berger 2019: 10). The future will show

whether these estimates are realistic or rather optimistic. What can indeed be stated is that the

promises of artificially intelligent methods, complex simulation as well as the conduction and

usage of big amounts of data have also entered the field of medicine and healthcare. They are

linked to hopes of for example improving medical decision-making, responding to current

challenges (for example demographic change) and personalising medical care. Supporting this

perspective but taking a more critical standpoint, in his book Digital Health and Technological

Promise – A Sociological Inquiry from 2019 the Australian sociologist Alan Petersen investigates

a shift towards a new way medicine will likely be delivered and enacted in the future, what

he calls “algorithmic medicine” (2019: 44). According to him

“[i]ncreasingly, policies and programs in healthcare are oriented towards a

new future medicine, which may be called algorithmic medicine, drawing

on big data analysis assisted through the use of AI, including machine learn-

ing, along with data generated by citizens themselves, who increasingly are

expected to connect with health and medicine via websites, apps and wear-

able technologies. [It] … presupposes and demands specific selves, social re-

lations and forms of citizenship, and distinct ways of thinking about and en-

acting medicine, risk management and care … [as well as] that people will

The study was conducted in two waves. On the one hand, 400 experts in the healthcare sector were

surveyed in a standardised way on questions concerning the digitalisation of the healthcare sector. Sec-

ondly, these results were validated by individual interviews with "leading representatives" of the

healthcare sector. The selection mainly represents Europe (80%), the rest refers to other countries not

specified further (Roland Berger 2019: 7).

play an active role in collecting, interpreting and acting on data about them-

selves as well as participating in big data projects.” (2019: 44-45)

Petersen looks at the level of policy making and (inter)national project funding. He postulates

a change in every aspect of medical care and treatment, aroused by the active push towards

the establishment of data-driven medicine into medical contexts. He chooses the macro level

as a perspective to critically examine and sociologically reflect far-reaching, society-wide

changes.

Keeping this in mind, the author wants to focus on a smaller field, the area of the development

and envisioned application of data-driven medical technologies. In particular, in this work a

class of medical technology, the so-called Clinical Decision Support Systems serves as an ex-

ample. They have a long history. While the aim of early examples (mostly in the 1970s and

80s) was to “build a computer program that could simulate human thinking” (Berner/La

Lande 2016: 3) and therefore replacing the job of the clinician to figure out the right diagnosis

or treatment, recent-developed versions of these systems are connected with a different ap-

proach. On the one side they are claimed not to simulate the clinician’s brain but to support

his or her decision-making and enhance their medical knowledge. This enhancement, on the

other side, is not solely based on established medical knowledge but often uses a big amount

of heterogeneous data sources, both conventional and non-conventional in medical contexts.

This new generation of Clinical Decision Support Systems are called “data-driven” in the con-

text if this work. As such they are to some extent systemically opaque.

In connecting the empirical interest about the way data-driven medical technologies, espe-

cially the new generation of CDSSs described, are developed with the aspiration to connect

two sociological concepts with each other: the concept of the script firstly established by

French sociologist Madeleine Akrich back in 1992 and the concept of situational respectively

prototype scenarios recently developed by German sociologists Ingo Schulz-Schaeffer and

Martin Meister the aim is to demonstrate how imaginations and envisions of the interrelations

between the future medical technology and its assumed application context that underlies sce-

narios are guiding the developers in building and therefore scripting the medical technology

under development. Given the usually multidisciplinary nature of such development teams

(Lehoux et al. 2011), which means they bring in different backgrounds and knowledge and

therefore see things differently what Lehoux et al. call “lenses”. A focus also lies on the nego-

tiation of different scenarios among the team members. Therefore, a case study is used in

which the development of such a data-driven Clinical Decision Support System was the pro-

posed. Relying on interviews with some of the developers and on project publications the au-

thor shows underlying assumptions about the envisioned use context, about the data-driven

approach used in the project and how these are combined to a dominant scenario which, again,

mainly serves as a guidance for the developers inscribing interrelations of the technology, us-

ers and use contexts.

Therefore, in the following section (2.) the epistemological interest of the author is further in-

troduced. Thereafter (3.), the perspective from which the subject is approached is brought in:

The importance of scenarios in the development process of technology (and medical technol-

ogy in particular) for this very process of development and, through this, for the potential

implementation in practice. Herein, also a connection is made with the STS-research on scripts.

Scenarios, regardless of whether they are prototypically realised or exist in another, more im-

plicit, form, always contain field- or discipline-specific scripts, mostly assumptions about the

field of application of the technology. These, which then become part of the scenario, are fur-

ther integrated into the technical artefact by inscription. This is followed (4.) by the subject of

study: What exactly are Clinical Decision Support Systems and what is special about the data-

driven versions currently under development? Finally, the focus lies on the case study (5.) and

the application of what has been worked out in the sections before (6.). Which scenarios played

a role in the project, which scripts were used or rather not used? This is followed by a conclu-

sion (7.).

2. The Epistemological Interest

To start by returning to Petersen, he summarises the changes cited in the introduction under

the term “digital health”. He asserts that “regardless of whether digital health evolves in ways

imagined, related policies and programs are profoundly refashioning conceptions of self, so-

ciety and citizenship, and impacting on related notions of truth, privacy, trust, rights and re-

sponsibilities” (Petersen 2019: 4). In this regard, although Petersen talks about general concep-

tions in the broader public, the basic assumption he concludes for the level of policy-making

and the concept of digital health itself might also be, in a slightly different way, applicable for

the development process of new medical technology. That is, imaginations, for example about

future medical healthcare supply and also about arrangements of medical work after the ap-

plication of new technology, are playing an important role in understanding not only changes

in a sociocultural or -political way but also on a smaller level of the development of a new

medical technology. On this level one might not use the terms imagination or, what is related:

vision. Rather it might be more promising and therefore necessary to look at already more

concrete perceptions which can be called scenarios (Schulz-Schaeffer/Meister: 2015). In differ-

ence to the former terms, scenarios, especially when they are situational, are more elaborated

ideas about specific constellations (Schulz-Schaeffer/Meister: 2015). For example, a possible

situation in which the so far developed or supposed to be finalised medical technology could

be applied.

Hence, my certain interest lies in how sociotechnical processes of medical decision-making

and therapy-planning in the treatment of diseases, that are already established and to some

extent routinised, are becoming subject of change during the process of developing a so-called

Clinical Decision Support System, which is meant to be an active part in those medical decision

processes. To be more specific, empirically of particular importance are the development pro-

cesses of supposed to be established Clinical Decision Support Systems (CDSS) that are at least

partly not based on common medical expert knowledge. Expert knowledge is thereby

knowledge that is evidence-based and/or derives from medical experts and mainly is the basis

for and thus is represented by clinical guidelines. Instead, to some extent these systems are

using other reasoning techniques, for example based on self-learning algorithms or elaborated

modelling and simulation, thereby using additional data sources which are not used conven-

tionally. They are supposed to help the clinical practitioner in making the most appropriate

medical decision, by supporting the clinical practitioner with more or less artificially processed

information. This information derives from a data corpus that usually contains a broad variety

of data sources. How and to what extent do processes of artificial intelligence or simulation

included vary? They can be an active part of analysing the inputted patient data or be used for

example to evaluate what kind of information is likely to be beneficial for decision-making in

general. Either way, how the information is processed remains systemically opaque. The de-

velopers of such systems usually emphasise the potentiality of saving costs and enhancing the

delivery of best-informed medical decisions and therefore improving the quality and effi-

ciency of medical treatment as such. But besides those, more abstract statements about proba-

ble improvements that might go along with the application of the proposed CDSS under de-

velopment, developers are presumably also following ideas about how the imagined technol-

ogy or prototypically existent parts of it would be a part of specific social situations. As

mentioned before, these ideas are becoming manifest in scenarios. At the same time, they are

subject to change throughout the development process. Thus, they likely influence for what

kind of imagined purposes the CDSS is built. Therewith, of interest is the question in which

ways a built CDSS would or could be part of medical real-world situations and which role the

development process of the CDSS plays in this regard.

Hence, the reason behind picking newly developed Clinical Decision Support Systems that are

supposed to help clinicians in their medical decision-making and planning of a therapy as the

empirical focus has two reasons. On the one hand, the Clinical Decision Support Systems

which are the subject of this thesis should be seen as a part of the outlined future medicine

stated by Petersen, that is to say they are (also) developed within the scope of the broader

vision of digital health. On the other hand, the development of CDSSs is usually associated

with specific fields of medical application, which makes this broad vision more concrete and

therefore CDSSs particularly suitable as a research object for my research interests. This both

concerns envisioned changes in the decision-making processes of medical professionals, as

well as the chosen focus on scenarios in the development process of these systems. So far, no

attention has been paid to particular questions of a scenario’s role within medical technology

development, both by traditional sociology and by Science and Technology Studies (STS). This

study is a first step to fill that gap by asking how developers of a Clinical Decision Support

System (CDSS) are guided by scenarios in scripting the use of the medical technology.

3. The Perspective: The Role of Scripts and Scenarios in Tech-

nology Development

To put the development process as the focus of my work, an important reference are the works

of Ingo Schulz-Schaffer and Martin Meister who wrote about the guiding role of what they call

situational scenarios (in their narrative, implicit/tacit or prototypical form) for technology de-

velopment in the field of ubiquitous computing (Schulz-Schaeffer/Meister 2013; 2015; 2017;

2019). As a consequence, their subject of study is technology development carried out by en-

gineers. According to the authors, especially the physical realisations of scenarios, as proto-

types in laboratory settings, are of certain importance for constructing sociotechnical constel-

lations, including new sociotechnical arrangements of work. Of special interest for the pur-

poses of this study is that the authors also put a focus on the role of the imagined user (Schulz-

Schaeffer/Meister 2019) who is supposed to work together with the new technology in specific

work settings. In their recent publication, Schulz-Schaeffer and Meister differentiate between

four ways of how envisaged future users are represented in the development process, partic-

ularly in prototypical scenarios: by representatives of the imagined future users, by independ-

ent expert knowledge mainly derived from literature, by the developers themselves and/or by

everyday notions and common-sense assumptions (Schulz-Schaeffer/Meister 2019: 49-51).

In this regard, the field of medical technology research and development (and even more the

subfield of CDSSs) is particular in nature: It is not uncommon that the research or development

team is multidisciplinary, for example that medical engineers are working together with clini-

cians; the team is also confronted with a wide range of national and international directives

and regulations that have to be applied with, and it becomes problematic when there is a lack

in the regulations, which is currently the case here; and, as previous research suggests, the area

of medicine and healthcare is highly professionalised and characterised by sophisticated ex-

pert knowledge and well-established practices and routines which have to be taken into ac-

count during development. For the field of CDSS development, it should also be noted that in

most cases concrete fields of application are established from the outset, that means the in-

tended support of decision-making processes in a specific area of medicine, for example car-

diology. It is therefore interesting whether and in which ways the findings of Schulz-Schaeffer

and Meister can be helpful in the area of the development of medical technology and CDSS in

particular.

Hence, the theoretical concept that is underpinning this work is mainly going hand in hand

with the epistemological interest described above. In addition to the works of Schulz-Schaeffer

and Meister a second focus lies on the concept of the “script”, which I intend to combine with

the concept of situational scenarios. Thereby, the conception of inscription firstly developed

by Madeleine Akrich (1992) and the approach of user configuration drawn up by Steve Wool-

gar (1990) serve as the main references here, as well as works done by Nelly Oudshoorn and

Trevor Pinch (2003) as well as to the concept of the new production of users by Sampsa

Hyysalo et al. (2016), who particularly wrote about user representation in technology devel-

opment.

3.1. Users and Use Contexts in Technology Development – The Concept

of the Script

With the SCOT model of social construction of technology (Pinch/Bijker 1984) we have learned,

at the latest, that although technology development is a more or less open process, the tech-

nology developed nevertheless has an obviously restrictive character (and indeed is in another

way also action-enabling). What can be done with a certain (medical) technology is relatively

fixed by technical inscriptions. These inscriptions are determined primarily in the course of

the development process, as suggested by earlier works (for example see Akrich 1992). Made-

leine Akrich was the first to write about inscriptions, which according to her are ideas of the

designers about a context of application including what is done with the device, into what she

calls the script, meaning inscriptions of these ideas into a material thing. Of central importance

for her argument is that, in doing so, designers of technology also envision the users together

with imagined situations of use. In her own words, what the designers do becomes quite far-

reaching:

“Designers thus define actors with specific tastes, competences, motives, as-

pirations, political prejudices, and the rest, and they assume that morality,

technology, science, and economy will evolve in particular ways. A large

part of the work of innovators is that of ‘inscribing’ this vision of (or predic-

tion about) the world in the technical content of the new object […] Thus like

a film script, technical objects define a framework of action together with the

actors and the space in which they are supposed to act.” (Akrich 1992: 208)

It can be derived from this statement, that the process of inscription of the designer’s imagina-

tions of users and use contexts into the developed technical artefact is not a rather vague un-

derstanding about probable application arrangements. Rather, it can become strikingly de-

tailed and wide-ranging. This can be claimed, like Akrich does, for technology development

in general. Thus, it indeed counts for the development of medical devices as well.

But it would be rather simple and only half the way if it stopped here. Instead of being too

deterministic and overestimating the power of inscription, Akrich (1992: 208-209) conceptual-

ises the development process as a continuous back and forth “between the designer and the

user, between the designer’s projected user and the real user, between the world inscribed in the

object and the world described by its displacement.” Whereas the developers of a certain technol-

ogy inscribe their imaginations into the object it is in turn the user who is describing the script

of the object in its actual use environment. When developing a Clinical Decision Support

System, for example, the developers may have in mind a well-trained and generally innova-

tion-friendly physician in a particular medical field who knows how to interpret the data pre-

sented. They therefore develop it relatively presuppositional. The actual user, on the other

hand, might not be as well-versed as imagined. Limited in their possibilities to use the system,

however, they sometimes develop evasive strategies and deviating actions, so-called descrip-

tions. That means, and its going in line with other approaches emphasising the importance of

the practices and handlings in real situations outside the laboratory, the object’s script is noth-

ing pre-fixed. On the contrary, Akrich (1992: 207) underlines that the scripts are nevertheless

“open to question and may be resisted.” Together with Bruno Latour (Akrich/Latour 1992:

261) she developed the concepts of ‘de-inscription’ and ‘antiprogram’ to meet the approach of

technology development as a co-constructive process. Whereas the former explicates the user’s

reactions towards the developer’s inscriptions, for example that they underwrite, reject or re-

negotiate those; and the latter captures “the users’ program of action that is in conflict with the

designers’ program” (Oudshoorn/Pinch 2003: 11) meaning that the proper use of the system is

failing.

Steven Woolgar follows a similar but slightly different approach. In contrast to Akrich and

Latour he is not putting the same focus on the real user in the process of technology develop-

ment. At the same time, however, he cannot be accused of exaggerating the power of the de-

velopers. Instead, he speaks in terms of the 'configuration' of the user. In so doing, he is partly

following the same line stating that, by constructing the technology, the developers are also

constructing the potential users and their possible actions. Expressed with the words of Wool-

gar (1991: 61): “Consequently, it is better to say that by setting parameters for the user's actions,

the evolving machine effectively attempts to configure the user.” To put it into the terms of

Akrich, the prescriptions are not only written into the technology, the technology reveals the

script or its purpose to the user, it is setting delimitations. The user is therewith always able to

flexibly interpret the script, but the developers bound or delimit this flexibility. Hence, also in

the understanding of Woolgar it is more accurate to consider the developers as setting a frame

that contains possibilities and restrictions about, for example, potential ways of application,

interaction, intervention or collaboration between the developed technology and envisioned

users. Woolgar exemplifies his approach with a case study in which he took part in the devel-

opment process of microcomputers in a company where multiple professions and department

members were participating in the construction of the technology. This is a peculiarity that

Woolgar also encounters in his analyses. The multidisciplinary and multiperspectively collab-

oration within the company concerns in particular the forms of technology development and

thus also the ways in which users and contexts of use are represented in (or inscribed into) the

technology. In other words, what the script looks like. How the technology was built in the

company is described by Woolgar as follows, using the metaphor of writing and reading a

text

“Certain characters become central to the story and others peripheral; groups

of actants join forces while others disperse; the activities and achievements

of some are highlighted, while others are relegated to the background, si-

lenced and unnoticed. The reader […] of the text is invited to join with certain

groups and disassociate herself from others.” (Woolgar 1991: 69)

At another paragraph he adds:

“These different groups and individuals at different times offered varying

accounts of 'what the user is like'. Knowledge and expertise about the user

was distributed within the company in a loosely structured manner, with

certain groups claiming more expertise than others in knowing what users

are like.” (Woolgar 1991: 69)

What we can capture from these two remarks is that the prescriptions about the expected char-

acteristics or attributes of the user, the way the technology shall ‘correctly’ be used and how

the context of use is supposed to be are subject of complex negotiations and discussions be-

tween various contributors throughout the course of development. Who or which group is

more or less engaged in this matter varies during a project, as well as does the kind of engage-

ment. Who has the interpretative authority or power associated with knowledge and expertise

about users (which is claimed by different actors to be better or worse) is thus not stable be-

forehand, but a negotiation process over time and among different actors. These remarks (as

well as Akrich’s) have been very important for the establishment of critical approaches regard-

ing the way technology is constructed, first and foremost the role of users in the process of

technology development. Anyway, Woolgar is underestimating the extent up to which users

Throughout the article, Woolgar uses the metaphor ‘machine as text’: “My strategy […] is the explora-

tion of a metaphor: the machine as text. The idea is to begin with the supposition that the nature and

capacity of the machine is, at least in principle, interpretively flexible. This then sets the frame for an

examination of the processes of construction (writing) and use (reading) of the machine; the relation

between readers and writers is understood as mediated by the machine and by interpretations of what

the machine is, what it's for, what it can do.” (Woolgar 1991: 60).

can play an active role in these processes. Akrich and Latour gave an early answer to this

omission in emphasising that scripts or inscriptions are of a non-deterministic character (alt-

hough Woolgar never claimed that). Later on, this was elaborated further by others. For ex-

ample, by a group of Berlin-based social scientists (Gläser et al. 2017) who call themselves, in

citing Akrich’s script concept, “The Berlin Script Collective”

. As well as by Sampsa Hyysalo

and colleagues (Hyysalo et al. 2016) who take the notion of the co-construction of technology

and users and state that we now face a significant change in how the users a co-produced in

technology development:

To start with the latter work, a specific focus on the role of users in the technology develop-

ment process is provided by Hyysalo et al. (2016). The authors' thesis is that their role is un-

dergoing a significant change in the course of the early 21st century. This is characterised on

the one hand by the fact "[that u]sers will develop new forms of innovative collectives that

enable their engagement with products and technologies" (Hyysalo et al. 2016: 2) and on the

other hand - and this is of particular interest here - by "creative managers, designers and pro-

ducers who will develop new strategies for involving and analyzing users." (Hyysalo et al.

2016: 2). According to the authors, they use a multitude of methods and resources, on the one

hand to analyse the user in a variety of forms and, on the other hand, to involve the user in

new ways (Hyysalo et al. 2016: 3-4). In their concept of user representation, Sampsa Hyysalo

and Mikael Johnson (2016: 76) take a closer look at the role of these user analyses for the de-

velopment process. From their specific composition the user(s) are conceptualised and repre-

sented as "envisioned users", as future users represented in the present of product develop-

ment. This process of conceptualisation and representation of the later users of a technology

is mainly done in an explicit way, but happens in many ways unconsciously, too. Besides more

strategic, explicit ways, for example the active inclusion of (future) users, consumer studies

and needs analyses or the consideration of cultural habits and characteristics, ideas from

The Berlin Script Collective follows the aim to theoretically capture technologically mediated influ-

ences on human practices. This in order to put influence that is technologically mediated on an equal

level with other social influences (through interaction or social structures) within social theory. They do

this by rendering the agency of different technologies and their function as a medium of influence on

human behaviour comparable. For this they use the script concept from Akrich and, thereby, they come

to insights that are also relevant for this work.

implicit and thus rather less reflected sources usually flow into the imagination about users as

well. For example, the developers incorporate their own everyday experiences and assump-

tions or preferences from past projects or they are using already established technical concepts.

In the same way, aspects of regulatory requirements such as security standards can also have

an impact on the assumptions and ideas about future users (Hyysalo/Johnson 2016: 83). The

specific interaction between all these sources is essentially responsible for the way the user

and possible use cases are represented in the design and development process of a technology

or technical device and, thus, how the technology looks like and how it operates.

A particular focus on the concept of the script is provided by Jochen Gläser and colleagues,

who gave themselves the acronym ‘The Berlin Script Collective’. They concretise why techno-

logical scripts are (usually) not coercive but merely influential (Gläser et al. 2017: 14). Besides

Dewey-informed notions of pragmatic means-at-hand that challenge the developers envis-

aged instrumental means in shaping users’ ends and users’ subversive power in adopting and

challenging ‘the’ script, in referring to Paula Jarzabkowski and Trevor Pinch (2013) they stress

the too simplistic view of the idea that there is just one single script inscribed by the construc-

tors of a technology. Rather, a “technology usually contains multiple scripts, which address

different interactions with devices and may be more or less overt” (Gläser et al. 2017: 14).

Above all, the last notion on the restrained execution of technological scripts is particularly

crucial. This is, because it addresses a two-sided key point in technology development, which

becomes especially visible in multidisciplinary development projects. As stated in reference to

Woolgar – can also be seen in the chapter about situational scenarios in medicotechnological

development – users and use contexts might likely change throughout the course of the con-

struction of a technology. Different professions have disparate images and ideas in mind about

who the target user is, how the technology should be used, what it should do, how it should

look like and how all this is to be achieved best. As a consequence, it is very implausible that

a technology contains and executes just one script. Instead - to use the technology example in

this thesis once again - a technology like a Clinical Decision Support System should be seen as

a hybrid structure of material and immaterial components containing different scripts. Both,

scripts with respect to different contexts of use, and different anticipated users. With regard to

my case study, these would classically be, for example, the attending physician or the medical

assistant and also medical technicians.

While following the aim to provide a framework for comparatively studying technologically

mediated influence Jochen Gläser et al. establish seven dimensions that need consideration in

an analysis of this kind of influence. Their main argument is that

“it is the way in which influence is materially inscribed that produces a spe-

cific accessibility to users, specificity of purpose, distribution of control, kind

and strength of influence used, homogeneity of distribution of control, visi-

bility of the script and embeddedness in situations.” (Gläser et al. 2017: 29-

30, italic letters in the original)

The first four (or five) of the seven dimensions are particularly suitable for a closer look at

technology development itself. These focus on (1) which behaviours the imagined users might

typically enact, (2) in what direction this behaviour should be influenced, (3) in which manner

and with what level of enforcement this should take place, and (4 (5)) how the distribution of

control between the user and the technology should be designed – also in the course of use. In

addition, there may well be perceptions about (6) how visible the inscriptions should be, and

perhaps even (7) the embeddedness in social situations is taken into account. So, if one looks

only at the development process and here especially at the conceptions of the developers them-

selves, the interest would lie in how these two dimensions appear in this process of develop-

ment.

Transferred to the field of medical technology development, it is important to ask the question

about what role this “frame-working” of future users and use cases plays here. This is because,

it is very likely going along with real consequences for how actual (medical) work (with the

supposed technology) will or might be performed in the future, outside the laboratories. In

order to understand what imaginations about future applications, including the users as such

as well as the work situations, are envisioned and are used to develop (partly) artificially in-

telligent and simulation-based CDSSs and how exactly this is done, it is promising to take a

closer look at the development processes of medical technology and devices, which might not

be so surprising at this stage of my argumentation.

For this purpose, a main focus lies on an approach of the technical sociologists Schulz-

Schaeffer and Meister, who have exemplified in the engineering field of ubiquitous computing

how so-called scenarios influence the progress of the development process of a technology. A

connection between the research on scripts and the leading role of scenarios in technology

development does not yet exist. This is somewhat surprising since the term "scenario" and the

concept of development guidance behind it are capable of capturing the actions, practices, and

processes behind the assumptions that are written into the scripts of a technology much more

precise and comprehensive than terms such as imagination or envision. This is, because it is

in these scenarios where the images, perceptions and concepts about the interrelations be-

tween the technology, assumed users and use contexts come into being as subjects under ne-

gotiation. By definition, scenarios are very concrete formulations about the way the technology

under construction will operate. Often, they are situational, which means concrete users and

use contexts are envisioned as well. It therefore can be attributed to them that they play a

substantial role in guiding technology development regarding the scripts inscribed into the

constructed technology. A scenario is in this sense anything but a synonym for a script, as

Akrich implied in her influential article in 1992. Instead, in development processes where sce-

narios play a significant role (Schulz-Schaeffer and Meister show this for engineering, it is also

apparent in medical technology development) it is them giving the developers guidance in

deciding towards which direction to construct the technology or to script the technologies per-

formance and appearance in connection with particular social situations of use. In these cases,

scenarios are the basis for scripts. This does not mean that one script is connected to exactly

one scenario apparent during development, or that a script could be deduced directly from a

scenario, one-to-one. This is particularly the case for scenarios not explicated but guiding the

developers implicitly or tacitly in technology building. But the same applies to scenarios as to

imaginations: They appear in the technology and its application in the form of scripts, which,

as Gläser et al. (2017: 14) note, are often even overtly visible. Consequently, it is about replacing

relatively loose imaginations with more concrete scenarios. These scenarios play a central role

in the empirical part. Finally, a perspective is given to combine them with the script concept.

Not just theoretically reflective, but based on an empirical case. But for now, let us continue

setting the theoretical foundations.

3.2. The Guiding Role of Scenarios in Technology Development

As we have seen, the process of technological development is very much intertwined with the

real application, its environment and its users. Often, this interrelation of the laboratory site

and the real environment “out there” manifests itself in envisions and imaginations about sit-

uations or contexts where the technology in development is or could be part of. These envi-

sions can take many different forms. They might be of a merely abstract and broad kind, only

giving a rough idea about the ways the target technology is supposed to be part of social

situations. Therefore, they are mainly referring to already established future concepts and re-

lated associations. Schulz-Schaeffer and Meister label them as visions (Schulz-Schaeffer/Meis-

ter 2013). Let us take a closer look into them:

Visions: Visions are everything else but uncommon. One can find them in all those places

where the future is being thought about or decisions about future developments are made, be

they more social or more technological in nature. However, they play a particularly important

role where the imagined changes are of a radical type, whether they are of a society-wide scope

or for sub-areas of social life. According to Schulz-Schaeffer and Meister (2013: 3) “[e]specially

the fields of technology, which currently are (or in the near past have been) considered as key

future technologies, are highly affected by visions.” They do not use this term to refer to con-

crete technical objects. Rather, they point to broader or general terms for technological con-

cepts or so-called core technologies. These core technologies can manifest themselves in a wide

variety of technical objects. To give an example: the core technology "artificial intelligence" is

associated with innumerable ideas about how societies or societal sub-areas like the medical

sector will or would probably look like if the principle(s) of artificial intelligence would become

common reality. But here, artificial intelligence itself is not an object under concrete develop-

ment. Of course, one can think of a project where the main goal is the creation of a new self-

learning algorithm in order to solve a certain problem or open up new possibilities. Then,

indeed, this supposedly intelligent algorithm is a real object or is meant to be real in the future.

Nevertheless, artificial intelligence as such is much more abstract and subsumes numerous

approaches and technical solutions under one term laden with images and vague ideas about

its societal impact. For this reason, the authors attribute three main effects to visions in inno-

vation processes (Schulz-Schaeffer/Meister 2013: 4-7): firstly, mobilising and coordinating re-

lated actors, interests and resources; secondly, guiding activities in research and development

in a broader sense; as well as, thirdly, functioning as means for prospective technology assess-

ment.

But envisions can also be more detailed. That means they can contain relatively concrete ideas

of application or about the characteristics of a target user. Schulz-Schaeffer and Meister (2015)

call these more concrete forms scenarios, or rather said: situational scenarios. In contrast to the

previously mentioned forms, which they refer to as visions, situational scenarios are charac-

terised by "specifying for imagined typical situations of use of the new technology how the

components of these situations - the features of the technology, the users with their interests,

preferences and capabilities, other persons, objects or structures of relevance for the situation

- would (or might) interact." (Schulz-Schaeffer/Meister 2015: 166). Thus, situational scenarios

are not just about the technology. Rather, they are about the nature of the context as such,

although the technology plays an important and prominent role within these scenarios. Let us

therefore also look closer into them:

(Situational) Scenarios: Thus, it can be stated that “though visions undoubtedly affect public

and private decisions to engage in technology development, they do not provide pictures of

the future detailed enough to guide specific research and development activities.” (Schulz-

Schaeffer/Meister 2013: 7). In order to be able to have an effect on research and development

processes, concepts of the future have to be very specific in nature. This is what scenarios do.

They tell something about what parts the future technology would be made of, what those

parts or components would be able to do, how they would perform and how they are con-

nected to each other. They serve as a tool for future research in specifying and describing a

possible future. In technology development the future technology and its forms of use. By

referring to Steinmüller (2003: 3), they state that “scenarios act out fictional realities by elabo-

rating coherent chains of cause and effect, which include aims and consequences of human

action and constraints exposed by circumstances” (Schulz-Schaeffer/Meister 2013: 8). Further-

more, if a scenario would be situational in nature, which means it says something about ideas

of future states of affairs, it usually also includes more information about the envisioned con-

text of its application (Schulz-Schaeffer/Meister 2015: 166). Not only the components of the

technology play a role here but also possible users and further elements of the imagined situ-

ation that might be of relevance to the developers. As scenarios are results of imaginations and

ideas of the researchers, they are of a rather fictional kind. Therefore, they do not represent the

current reality. But neither do they represent just the envisioned near or far future. Instead,

they can be seen as hybrids of the present and future – or as containing present and future

components. That is because (not only) in engineering research and development “images of

the future rely on explicit or implicit assumptions about similarities between the imagined

future situations and corresponding present situations.” (Schulz-Schaeffer/Meister 2019: 41)

Schulz-Schaeffer and Meister argue that this is the case, because especially in engineering pro-

jects the scope of an envisioned future technology under development is normally not more

than a few years. In building up a scenario, to a certain degree engineers rely on conditions

that are currently the reality. This could be components of the social context their supposed

technology would be part of or components of the technology which will be set in and shape

not yet real social situations. Therefore, they finalise that “situational scenarios that are em-

ployed in technology development represent always a combination of components from cur-

rent situations and of components that will come into existence only as part of the imagined

future.” (Schulz-Schaeffer/Meister 2019: 40)

More than visions scenarios can take many forms. As narratives they describe a sometimes

more, sometimes less detailed context of use of the technology to be developed. These are

usually found in published papers or deliverables of the researchers. In its narrative form, the

scenario is apparent directly and provides an explicit picture of imagined applications. In the

form of implications, they are much more difficult to capture. They are usually revealed indi-

rectly through verbalisations or technical realisations, but mostly remain on a mental level.

Beyond this, these implications could also be not reflected at all. That means they are tacitly

applied and taken as given. Finally, situational scenarios can take the form of prototypes.

Schulz-Schaeffer and Meister (2015: 169) write that a physical or virtual prototype, together

with a testbed, “embodies a particular idea about how the technology […] and the users, and

other relevant components and circumstances […] should interact in typical future situations

of use.” Prototypes thus also embody a scenario. They serve as a physical implementation or

scripting of the scenario(s) and are therefore more explicit than the narrative form.

We have seen that situational scenarios are extremely various in nature and always mediated

through carriers. They can be quite obvious, printed in papers, they can hide inside the brains

of the involved developers, hide from extern parties as well as from the cautious reflection of

the researchers themselves or they can be built into materiality or virtual models and become

simulated reality the way envisioned. But regardless whether the scenario is of a narrative,

implicit or prototypically realised form, according to Schulz-Schaeffer and Meister (2015: 170)

most scenarios that are represented in these ways are of a certain type: They are called generic

scenarios. With generic scenarios they refer to those kinds of scenarios which represent a to

some extent unspecified context of application. Or the scenario transports a certain generality

whose intended purpose is merely to demonstrate the usefulness of the functionalities of the

technology under development. This by conceiving a social situation (or several), a context of

apply. Here, the imagined social context is not particular. Rather, it is more universal in respect

of those segments of the situation which would be influenced directly by the technology. How-

ever, if there are generic scenarios, of course another category must be distinguished from

them: specific scenarios. While Schulz-Schaeffer and Meister are more interested in the generic

type of scenarios they just spend one paragraph on the specific counterpart and characterise it

as mainly going along with a newly developed technology that is developed for a particular

use-case. For this reason, they do not consider this type of scenario to be equally relevant in

regards of their role in guiding the research and development activities. They write:

“Specific scenarios are about how new technology might be of use within

one particular setting. Thus, they are interested only in the components, re-

lations, and circumstances which define this particular setting and address

only the interactions that should or might occur between the new technology

and these factors. The representations of specific scenarios are self-sufficient.

They address what their authors are actually interested in: a particular new

technology for a particular application situation.” (Schulz-Schaeffer/Meister

2015: 170)

Apparently, in specific scenarios the application context is already known and a technology is

developed in order to influence this context in a certain manner. Thus, possible retroactive

effects by the scenarios on the continuation of the project might be less strong. Yet, very often

specific scenarios can also point to underlying generic scenarios. For this reason, they may

become important. That means, because or although the developers do not have a specific

application context in mind, they construct relatively specific scenarios in order to exemplify

the functions of the technology in a social setting. These may then influence research. For ex-

ample, when components that are actually only required for a specific scenario remain part of

the development which was less specific in the first place. This then might lead to a narrowing

or specifying of the development under the scenario. Hence, the following should be noted:

“[A]ssumptions about the imagined situation of use imply technological re-

quirements, and vice versa, assumptions about technical features affect the

question for which contexts of use the new technology might be useful […]

this characteristic of technological situational scenarios is the crucial reason

why they become a source of cognitive guidance for engineers.” (Schulz-

Schaeffer/Meister 2015: 172)

To come back to the earlier mentioned hybrid character of scenarios, their nature as being a

composition of present and future, this guidance in cognition takes the form of a certain pro-

cess of negotiation between the components which represent the present and those which rep-

resent the future. This applies most to situational scenarios in their prototypically realised

form as well as the connected social setting or testbed.

That is because they are physical real-

ity, though just in a laboratorian sense. As such they are objects of actual manipulation and

testing. Here, the intertwining and cooperation of the scenario’s present and future compo-

nents can be specified, evaluated and demonstrated – and therefore become subject of negoti-

ation (Schulz-Schaeffer/Meister 2017: 207-212). In applying the concept of “arena” as spaces of

negotiation developed by Anselm Strauss (1993: 226-227) Schulz-Schaeffer and Meister (2017,

2019) call these processes of negotiating between actual and fictional reality components of

scenarios “negotiation arenas”. They are these in two ways: Firstly, they “root the imagined

elements of a future application in a working present realisation of this application, and thus

in present technological possibilities and use practices.” (Schulz-Schaeffer/Meister 2017: 213)

Secondly, they act as a rearrangement of these elements from the present and the imagined

future. As such they are always the subject matter of debates and consensus building in order

to, for example, specify the technology and/or its application and guide the engineers through

the development process.

But as sociologists we should ask the question of who is taking action in this process, who is

negotiating? According to the authors (Schulz-Schaeffer/Meister 2019: 63), generally speaking

it takes the form of “a negotiation of different perspectives related to the different social

worlds

, which are present in the negotiation arena.” In the development process these social

worlds (mainly the scientific disciplines of the developers and the application contexts) are

represented by so-called spokespersons (Schulz-Schaeffer/Meister 2019: 47). They differentiate

between four types: imagined future users, independent expert knowledge, the developers

themselves and everyday notions or common-sense assumptions (Schulz-Schaeffer/Meister

2019: 49-52). The spokespersons can hold different negotiation positions, mainly as proponents

of present or future components and are endowed with varying degrees of negotiation power

But nevertheless, they can also be seen in their narrative or even their implicit form.

With the term social worlds Schulz-Schaeffer and Meister refer to a concept developed mainly by Ad-

ele Clarke and expanded to a whole framework by her together with Susan Leigh Star. It “assumes

multiple collective actors – social worlds – in all kinds of negotiations and conflicts, committed to usu-

ally ongoing participation in broad substantive arenas. The framework is relentlessly ecological, seeking

to understand the nature of relations and action across the arrays of people and things in the arena,

representations (narrative, visual, historical, rhetorical), processes of work (including cooperation with-

out consensus, career paths, and routines/anomalies), and many sorts of interwoven discourses.”

(Clarke/Star 2008: 113)

in order to influence which components will be part of and how “to interrelate the components

that make up the scenario.” (Schulz-Schaeffer/Meister 2019: 62) For the purposes of this work

it is more appropriate not to use the term social world but to specify it to scientific disciplines

and connected logics, practices and professional cultures, because those are the “social

worlds” that matter here. With this in mind, three subject-specific additions are discussed be-

low: the direct representation of multiple scientific disciplines, the specificity of medical regu-

lations and guidelines and last but not least the specific schemes of medical work arrange-

ments.

3.3. Scenarios in Context of Data-driven Clinical Decision Support – Three

Additions

The field of medical technology research and development (and especially the CDSS sub-sec-

tor) is of a special nature: firstly, it is not uncommon for the research or development team to

be multidisciplinary. For example, medical engineers often work together with clinicians, but

also with nurses, mathematicians, computer scientists et cetera. Secondly, the development

team is also confronted with a national and international regulatory environment that must be

taken into account respectively reflected upon. The special situation here is that there is a lack

of regulations in this field of medical development. And, as previous studies have shown, the

medical and healthcare sector is highly professionalised and characterised by sophisticated

expert knowledge and well-established practices and routines, which has consequences re-

garding the imagined schemes and conceptions about the probable applications of the devel-

oped technology. What is more, for the area of CDSS development it should also be noted that

in most cases (like the one discussed here), specific medical applications are determined very

early or right at the beginning of the development process, which also affects the schemes

about the medical work arrangements, or rather presumably concretises them in their mani-

festations as scenarios. Therefore, the third addition is the concreteness or specificity of the

schemes of medical work arrangements in the technology development process. Let us take a

closer look on these particularities in the following.

3.3.1. Direct Representation of Multiple Scientific Disciplines

Not much research has been conducted about the particularity of medical technology devel-

opment processes. The circumstance of the involvement of many participants from variant

fields and disciplines is, indeed, acknowledged. But, as Lehoux and colleagues (2011) point

out, less is known about the actual engagement of multidisciplinary project members in the

design or development process of a medical technology or device. Thus, they investigated

“how […] heterogeneous design participants actually combine their expertise to develop a

medical device” (Lehoux et al. 2011: 313). Although their conceptual focus lays on the tradi-

tions of design (design studies) and they focus on the development (or design) of medical

devices in companies, therefore taking a different perspective, Lehoux et al. are able to show

two things important for this work. The first is, that particularly in medical technology devel-

opment project members are not only specialists in the systematic construction and design of

a technical artefact, that means representatives of engineering disciplines. But also, represent-

atives of other disciplines as well as later users are almost always involved in the construction

process of the medical device. They are “intimately involved […] in the design process of a

given innovation.” (Lehoux et al. 2011: 315) In Lehoux et al.’s study it was physicians, nurses

but also computer scientists. In my own case study, they were, besides medicotechnological

engineers, cardiologists, mathematicians and computer scientists, whereas the cardiologists

have had the position of contributing the medical expertise and being spokespersons of the

imagined future users at the same time. According to Lehoux et al. (2011: 313) the different

contributions of the project members “vary in content and intensity over the course of a project

– for instance, identifying clinical needs, testing prototypes, or commenting on a product’s

usability – but they all influence how the design process unfolds and what the ‘final’ technol-

ogy will look like and accomplish”. Which perspectives and contributions the project members

build and “what each design participant sees about the innovation to be designed […] is

framed through a particular ‘lens’” (Lehoux et al. 2011: 316). This lens is filled with the devel-

opers’ knowledge and expertise representing their discipline, their tasks and responsibilities

within the project as well as their own motivations and interests. Transferred to the perspec-

tive of the situational scenario as an arena of negotiation about the nature of the technology-

application nexus, the following can be adopted: the different representatives of multiple dis-

ciplines and probable user groups contribute to the development of the medical device in dif-

ferent ways and with changing intensity. They are doing this by putting on a certain lens that

mainly consists of their scientific discipline (their social world), but in connection with their

individual role within the project as well as own interests and motivations.

This leads me back to the role of power in those development projects, where multiple disci-

plines are directly represented by spokespersons. Lehoux et al. are not addressing it. But when

we take another look at Wagner’s early case study, we can see that power is important to con-

sider. This is, because in directly represented multidisciplinary projects, for example a CDSS

becomes likely another shape: Wagner (1998a: 103) proposes that in projects where medical

expert systems are (partly) developed by medical practitioners the guiding principle would be

the construction of an advising, supporting and assisting expert system, rather than an expert-

replacing one. And Weingarten (1998: 182) emphasises that it is necessary to consider the ten-

sions between the different logics of the (medical) expert and the (medical) engineer within

these processes of development.

3.3.2. Specificity of Medical Regulations and Guidelines

In the case discussed later, the following point had no direct influence on the development.

This is due to the circumstance that the development of the decision support system here had

the character of grounding research and its declared aim was not to necessarily develop the

system to market maturity. This is a step that some of the project partners may want to take in

the future. Nevertheless, as mentioned earlier and becoming apparent later, regulations and

guidelines played a reflective role throughout the project. To know them is therefore essential

in the development process, regardless whether they are to be followed or not. Furthermore,

they set (or in the case of artificial intelligence and simulation do not set) some requirements,

which is quite interesting for this work. For example, as Alex Faulkner (2009: 38) points out,

the European regulations

do “not necessarily require evidence of efficacy in clinical trials, or

even the performance of new clinical trials. Evidence of mechanical performance in laboratory

tests is sufficient for many new devices. [The regulations are therefore] designed to assess

whether a product is safe to use and ‘fit for purpose’.” It is less designed to evaluate whether

a new medical device is ‘better’, for example more efficient et cetera.

This is particularly true for the efforts starting to meet the ‘new’ challenges of software-based

and especially data- and machine learning-based medical devices. In section three it is already

In the following reference is made mainly to the regulations set by the European Union (EU). The

reason behind it is that the project was researching within this European framework and therefore just

these regulations played, although a rather subsidiary, role in the project.

emphasised the circumstance that until now there are no certain established guidelines (glob-

ally) which try to define the development process of simulation- and machine learning-based

medical devices. But regarding the European regulations of Software as a Medical Product

(SaaMP), it can be seen that also here only the safety and the usability of the device as claimed

by the developer are tested or defined. To what extent the devices really improve the medical

practices in the targeted medical field seems to be of secondary importance or not relevant at

all. For example, let us take a look at the key guideline IEC 62304:

“IEC 62304 defines the software development and verification activities

which medical device manufacturers must comply with. Such activities in-

clude software development planning, requirement analysis, architectural

design, software design, unit implementation and verification, software in-

tegration and integration testing, system testing and, finally, software re-

lease” (Carroll/Richardson 2016: 188).

Here as well: What is regulated is mainly the frame of the development process itself. Clinical

trials are not necessarily required. Therefore, developers of such medical devices are, firstly,

building technology under a high degree of uncertainty. Secondly – and more important for

the question of this thesis – the developers might likely incorporate the logic of the regulations

and may thus reflect less on medical implications of the developed technology or device. In-

stead they might rather refer more to scripts already established in the respective scientific

field or discipline, for example ‘healthcare/treatment is improving with the help of new tech-

nical possibilities’, ‘the physician should be able to concentrate on the medically essential’ or

‘ss long as the device is safe and operates the way it should, it makes sense to deploy it’. Some

of them we rediscover in the case study.

3.3.3. Specific Schemes of Medical Work Arrangements

When medical technology developers develop a medical technology, they usually have a rel-

atively or even very concrete application context in mind. In my case study, for example, it is

the treatment of cardiovascular diseases, that is problems of the heart valves. This does not

mean that there are no ideas about other possible applications, but for the purposes of the

development project there is almost always one particular context of use imagined, which the

technology at stake is developed for. Often, the intended use context is defined at the very

beginning of the project, usually already in the research proposal and it is also not subject of

bigger changes during the development phase itself. Therefore, it can be said that in medical

device development scenarios are commonly specific in nature. Additionally, they are also

more often of an implicit or even tacit

kind, rather than formulated explicitly. As medical

technology is mostly developed with a particular purpose in mind and, as we have seen, med-

ical experts in the corresponding field of application are part of the research process, there is

often no need to explicate in more detail about probable situations of use. They are either con-

sidered to be obvious or they are more likely to be circulated internally, as they are quite spe-

cific to one field of application. This means that here the intentions to demonstrate or justify

the development of a device are not very strong.

But how, then, is it possible to get to know about these scenarios? Schulz-Schaeffer and Meister

(2015: 168-169) are proposing two ways: Firstly, they can be communicated verbally. In inter-

views, for example, they can be brought to the surface. Another way would be to get to know

implicit scenarios mediated through prototypes and the corresponding testbeds. They write

that “in test situations […] the prototype represents the new technology […], while the testbed

represents the envisaged context of use […]. Consequently, every constellation of technologi-

cal prototypes and corresponding testbeds embodies an underlying […] scenario.” In analys-

ing the prototype and testbed scenario(s) can be made visible. These are the two paths fol-

lowed in this work. The findings from the interviews serve to find out about what imagina-

tions represented in situational scenarios are brought forward and then use both the inter-

views and the prototype developed in the end of the project for showing how the scenarios

are scripted into the technology.

But first, let us introduce the subject of study: What exactly are Clinical Decision Support Sys-

tems, under which regulatory frame are they developed and what is special about the data-

driven versions?

4. The Subject: Data-driven Clinical Decision Support Systems

When doing social scientific research about new medical devices that involves their technical

development, one thing should not be lost sight of: the regulation of medical devices as well

as their development. Although complying with regulations played a minor role in the course

The term ‘tacit’ means, that the scenarios are not only not articulated (for example, written down or

verbally communicated) but also not actively reflected. But still, they are present during development

(Schulz-Schaeffer/Meister 2015: 168).

of the development of the CDSS developed in the project that serves as the case study

, the

regulatory environment is nevertheless relevant, because the regulatory standards are, to a

certain point, putting the development of the medical product under a frame with certain de-

mands that have to be complied with when developing the device towards becoming a medi-

cal product. Thus, let us take a short look at the current regulatory environment developers of

Clinical Decision Support Systems with a component that uses machine learning or simulation

currently face. In particular at the difficulty of regulating machine learning and simulation in

medical contexts.

4.1. Software as Medical Product and the Current Regulation of Machine

Learning and Simulation in Medical Devices

As is stated on the website of the German Johner Institute

“t]here are currently no laws or

harmonized standards that specifically regulate the use of artificial intelligence in medical de-

vices” (johner-institute.com: 19.11.2019). The same can be stated for simulations. These cir-

cumstances of a lag of regulatory standards are leaving developers of such medical software

alone with a significant degree of uncertainty regarding the standards they should rely on.

While this “leads to risks for patients (medical devices are less safe) and for manufacturers

(audits and approval procedures seem to reach arbitrary conclusions)” (johner-institute.com:

19.11.2019), it also makes it less clear how developers are engineering medical devices with

machine learning or simulation components, respectively, what basic standards and frame-

works have to be met during development.

Whereas in Europe there is yet not even a statement towards medical software based on ma-

chine learning or on simulation, in 2019 the US-American Food and Drug Administration

(FDA) published a document promoting a detailed recommendation for a “Proposed Regula-

tory Framework for Modifications to Artificial Intelligence/Machine Learning (AI/ML)-Based

The aim of this project was to find out how a CDSS for use in the cardiovascular field could look like.

During the public funding phase under investigation, medical and medicotechnological regulations

were not directly addressed, but they were certainly reflected in the course of the project with regard to

how these regulations would have to be addressed (in the future).

The Johner Institute claims itself as a major provider of medical device regulatory services in Europe

and USA.

Software as a Medical Device [SaMD)” (FDA 2019: 2). Although it would be too much to give

a detailed analysis of what is proposed in the document, it offers some intriguing aspects and

directions that bring to light the specialty of machine learning-based medical software. First

of all, the authors of the document differentiate between “locked” and “adaptive” algorithms.

In doing so, they accentuate the challenges in developing medical devices that are typical

when using self-learning algorithms. With locked algorithms they refer to “those [algorithms]

that provide the same result each time the same input is provided. As such, a locked algorithm

applies a fixed function […] to a given set of inputs.” (FDA 2019: 5) Examples given from the

authors are static look-up tables or decision trees.

Compared to locked algorithms, adaptive algorithms are changing their “behavior using a

defined learning process. The algorithm adaptation or changes are implemented such that for

a given set of inputs, the output may be different before and after the changes are imple-

mented.” (FDA 2019: 5) These are the kind of algorithms that are designed in currently devel-

oped data-driven software, like Ada Dx by the German Start-Up Ada Health or in the project

“QuantMed” at the Fraunhofer-Institute for Digital Medicine. Also, the machine learning com-

ponent of the Clinical Decision Support System developed in the research project about sup-

porting cardiovascular diseases, that serves as a case study, used this kind of dynamic algo-

rithms to distinguish data sources which are relevant for medical decision-making from non-

relevant sources. In those cases, what data is used how and when becomes a central role in

analysing the development of these medical devices. The use of adaptive algorithms has also

implications for the certification and evaluation of the medical device, that is that

“[t]he power of these AI/ML-based SaMD lies within the ability to continu-

ously learn, where the adaptation or change to the algorithm is realized after

the SaMD is distributed for use and has ‘learned’ from real-world experi-

ence. Following distribution, these types of continuously learning and adap-

tive AI/ML algorithms may provide a different output in comparison to the

output initially cleared for a given set of inputs.” (FDA 2019: 3)

These changes are categorised into three types, namely changes in performance, in inputs and

in the intended use of a medical device. For this reason, the FDA is focusing on how these

changes or “modifications” can be met by regulations and proposes a regulation of the total

product lifecycle (FDA 2019: 7-15). The document shows some of the special characteristics of

medical software that is based on machine learning, regardless of whether this process is im-

plemented using artificial neural networks, genetic algorithms, support vector machines

and/or natural language processing (Jiang et al. 2017). These characteristics have serious

implications for imagined/prototyped software currently developed as well as for current de-

vices which are already in use. For that reason, the development process of medical devices

which use adaptive algorithms in decision-making and/or simulation of treatments as well as

deciding which treatment would be the best for a particular patient (especially when the indi-

cation is difficult or complex, like in cardiovascular diseases) is playing an important role.

4.2. Data-driven Clinical Decision Support Systems

Although Clinical Decision Support Systems (CDSS) are only sparsely investigated, their ac-

tive use in medical contexts goes back almost 50 years in history. They were often based on

electronic health records (EHR) collected by the respective medical site itself (Berner/La Lande

2016: 2). The basic idea behind CDSSs can already be derived from the term itself, meaning an

expert system that is supposed to help clinicians in making accurate medical decisions, for

example about the right diagnosis or the most suitable treatment for a particular patient. While

the aim of early examples (mostly in the 1970s and 80s) was to “build a computer program

that could simulate human thinking” (Berner/La Lande 2016: 3) and therefore making the job

of the clinicians to figure out the right diagnosis or treatment obsolete, currently developed

CDSSs are expected to fulfil a different purpose. They do not try to replace the decision-mak-

ing process of experts by simulating their way of medical reasoning. Instead, it is argued that

the system should “assist the clinician in his or her own decision making” and letting the cli-

nician “be active and to interact with the system” (Berner/La Lande 2016: 3). For example, a

“CDSS can assist clinicians in decision making by taking over some routine tasks, warning

clinicians of potential problems, or providing suggestions for clinician consideration”

(Göksu/Lalys 2016: 8). The data sources which build the ground stock of the CDSSs are vari-

ous, but usually contain established expert knowledge and experiences of past cases from sci-

entific literature with relevance for the regarding medical purpose and/or official clinical

guidelines as well as clinical and laboratory data and data from EHR. These data can be related

to an individual case by entering specific characteristics of the condition of the particular pa-

tient. In the background these individual characteristics are synchronised with the so-called

knowledge base of the CDSS, supplied with certain rules for the purposes of correct medical

reasoning (Ozaydin et al. 2016: 46). Usually, this is done by a reasoning or inference engine

that, in an abstract understanding, “combines the input and other data according to some log-

ical scheme for output.” (Spooner 2016: 34) According to Spooner (2016), this can be done for

example with Bayes’ rules or a simple IF-THEN-logic combined with Boolean operators. This

means that dependent on the input entered by the clinician the CDSS is reasoning on the base

of the included medical knowledge and presents an output, for example a list of probable dis-

eases.

This is the case for most of the currently developed and used CDSSs. But there is also a differ-

ent approach that is getting more attention in recent years. In difference to the described CDSSs

which base their reasoning on expert knowledge, those CDSSs can be summarised under the

term data-driven CDSSs. The differentiation between knowledge-based and data-driven CDSS

differs from the common distinction usually made by the actors in the field, who are not refer-

ring to data but to non-knowledge, with which not established medical knowledge is meant

(see e.g. Berner/La Lande 2016, Göksu/Lalys 2016, Spooner 2016). This is a bit misleading, be-

cause it implies that the last version of CDSSs is not based on any knowledge, which is not the

case. Therefore, it is more appropriate to emphasise what they are based on: a big amount of

heterogeneous data. According to Bunyamin Ozaydin et al. (2016: 46-48), one of the main dif-

ferences between these two types of CDSSs lays in the way the respective reasoning engine

operates. While a CDSS that is based on expert knowledge operates the way described above,

which means that its reasoning is solely derived from established knowledge, facts, rules and

guidelines from the medical field it is supposed to be applied to, a CDSS that is not based on

this kind of knowledge but uses particular techniques of machine learning or simulation re-

ceives its way of reasoning from recognising patterns within the data this engine is operating

with. This can possibly lead to new findings and discoveries that are not based on pre-existing

knowledge and not represented by clinical guidelines but on (potential) correlations between

data points in a data corpus. These differences in reasoning are considered to come along with

a changing role of the clinician who is working with the CDSS. Thereto, Ozaydin et al. write

that

“[i]n this sense, the [knowledge-based] decision support system requires a

vast amount of a priori knowledge on the part of the decision maker in order

to provide the right answers to well-formed questions. On the contrary, the

[data-driven] decision support systems […] do not require a priori

knowledge on the part of the decision maker. Instead, the system is designed

to find new and unsuspected patterns and relationships in a given set of data;

the system then applies this newly discovered knowledge to a new set of

data.” (2016: 46-48)

Thus, it is assumed that there are particular consequences behind integrating principles of

data-driven reasoning into CDSSs. A reasoning system that is based on clear, pre-defined rules

is replaced by a system that operates more autonomously and, to a certain extent, learns by

itself based on a dataset with an outcome that is no longer entirely predictive and is not solely

informed by pre-given expert knowledge. They are dynamic in themselves, because they learn

continuously (with each new case) and are not only dependent on "external" dynamics, mean-

ing manual updates of the knowledge base, for example medical guidelines. In this respect

they are opaquer than the knowledge-based CDSSs.

Regarding the way they operate internally as well as the kind of information they provide,

data-driven CDSSs should therefore not be seen as a revival of the knowledge machines (Wis-

sensmaschinen) or expert systems of the 1970s to 90s (for a more detailed characterisation of

expert systems as ‘Wissensmaschinen’ see Rammert et al. 1998). But when the question comes

to how situations of medical decision-making with data-driven CDSSs are envisioned, it is

intriguing to refer to earlier observations about the development and operations of CDSSs

within the context of its application. That means how it is operating in interaction with all the

other actors: physicians, nurses, other medical machines etc., in a particular arrangement of

medical work. Thus, again, it was the declared goal back then to analyse and extract special

knowledge of experts and to build up a model of this knowledge in a computing system. This

system should then come to the same conclusions as the human expert but faster and with

higher confidence. In other words, what was at stake was the technical replication of actions

of medical experts. This in order to relief them from routine work, to backup-control their

decisions and, ultimately, to replace or substitute their cognitive work (Rammert 1998a: 16).

From today's perspective, it can be claimed that these early projects were more or less unsuc-

cessful. According to Rammert (1998b: 262), expert systems failed because the gap between

the development and the application contexts has not been considered and bridged, because

differences in the actor’s interests were ignored, because divergent views and cultures of prac-

tice have been challenged or because a powerful profession felt threatened in its position of

power and monopoly by introducing a CDSS. All these potential reasons can be summarised

in such a way that knowledge-based expert systems failed mainly due to the way they have

been implemented. The mentioned visions connected with them mainly remained visions.

German sociologist Gerald Wagner shows this with the example of a knowledge-based expert

system that was supposed to help surgeons in intensive care diagnostics in analysing

malfunctions of important vital body functions of intensive care patients. On the basis of cer-

tain patient data, it gave a diagnosis with therapeutic suggestions derived from the diagnosis.

Again, these outputs have been based directly on input beforehand and the way of algorithmic

reasoning operated only along defined paths. After it underwent a one-year trial in a German

hospital in 1988, the use of the device was discontinued and filed away as "socially failed"

(Wagner 1998a: 101): While some doctors trusted the reliability of the documentation of the

expert system, working with it was rejected by the nursing staff - and also by the other doctors

on the unit - and the input of patient data was refused. Wagner describes the cause of this

rejection as a "competition of memories" (Konkurrenz von Gedächtnissen), a competition be-

tween the nursing staff and the expert system. Comparable stories of failed implementation of

clinical decision support systems can be found in the literature of the 1980s to 2000s. These

followed the hype of the 1970s and 1980s and the hopes and visions of integrating machine

intelligence into medical and clinical practice. As a result of the widespread failure of these

systems (there are a just few exceptions such as the early support systems MYCIN and IN-

TERNIST), things became very quiet around them in the late 1990s and 2000s. The basic idea,

however, did not disappear and is experiencing a revival, as already outlined, in the wider

context of machine learning methods, computational modelling and simulation as well as

data-driven, personalised medicine. Whereas the earlier knowledge-based expert systems

were associated with ideas about being "intelligence enhancers" (Wagner 1998a: 105) of the

physician and the patient as "fully instrumented" or “networked” (Wagner 1998a: 98, 101), the

systems now developed, which are partly data-driven, are connected with ideas of the "digital

or virtual patient" and the system is seen as a supporting system that goes beyond the current

physician’s practice and knowledge.

In this light, it becomes interesting what Wagner and others (1998a: 91, 119) described over 20

years ago. In contrast to the then prevailing image of the expert system as an artificially intel-

ligent simulation of the expert him- or herself, he characterises the role of earlier knowledge-

based expert systems as hermeneutic media in form of a dialogue or communication partner

of the physician. Instead of being an autopilot capable of diagnosing the disease and deciding

over a therapy, medical expert systems are widening the ample scope of diagnosis and/or ther-

apy planning. This, because they take into account more parameters and variables than the

physician would do or would even be capable of. Due to the vast amount of medical

knowledge and potentially treatment-relevant information and data, the technical expert

system is intended to be an informative source of insecurity, a meaningful irritant for the hu-

man expert. The expert system does not compete with the physician's power of judgement,

nor does it relieve the physician of one single decision. It should only be able to contradict, it

should be able to tell the physician: You have chosen this diagnosis, but it could be quite dif-

ferent (Wagner 1998a: 119). Expert systems should thus not be left alone. They are social ma-

chines whose strengths lie in dialogue (Wagner 1998a: 128). Therefore, according to Wagner,

expert systems are not dehumanising medical practice but they privilege the objectively quan-

tifiable and semantically precise form of medical knowledge. However, according to Rüdiger

Weingarten (1998: 182) in the same volume, this leads to a conflict in the socio-technical work

arrangement between the expert system and the human expert, because (medical) practices on

the other side are always opportunistic and situation-specific.

What should data-driven systems be used for in medicine? As can be seen and becomes more

apparent in the analysis part of my work, the ideas and conceptions about the work arrange-

ments including an expert system that are present in Wagner's case study in 1988 and the ones

within the project serving as a case study in this work do not differ that much in this regard,

although over 30 years lie between them. As already outlined, the developers of such systems

usually emphasise the possibility of saving costs and improving medical decisions on the best

possible knowledge base and thus the possibility to improve the quality and efficiency of med-

ical treatment as such. This has not changed throughout the years and centuries. Besides these

rather abstract statements about possible improvements that could be achieved by using the

CDSS under development, the developers usually also have ideas about how the envisioned

technology or prototypical parts of it could be part of specific social situations. This was al-

ready apparent in Wagner's analysis. But what is more, these ideas manifest themselves in the

form of scenarios. These in turn influences the kind of imaginary purposes for which the CDSS

is developed, manifested as scripts.

In order to exemplify this, let us now concentrate on the empirical case study. To give an in-

troduction into the empirical example, we start with answering the question why the case cho-

sen is suitable for the purposes of this work. After that a focus is set on the methodological

approach used for analysing the conducted data (mainly the interviews). In the then following

subsections the examined project is described more detailed, starting with the conventional

treatment of cardiovascular diseases as stated in project material, followed by the project’s

concept of the Digital Patient respectively the usage of a big amount of data sources and

completed by the presentation of the technical functionalities of the developed prototype of a

Clinical Decision Support System.

5. The Case Study: A Clinical Decision Support System for Deci-

sion-making and Therapy-planning of Cardiovascular Dis-

eases

In order to illustrate my approach and to problematise the application of data-driven Clinical

Decision Support Systems (CDSS) the author carried out a case study in January and February

2020. The general goal was to get deeper insights into the development process of a data-

driven CDSS in order to find out (1) what kind of scenarios have played a guiding role

throughout the development, (2) how they were negotiated among the participating research

members, as well as (3) to what extent these scenarios have been inscribed into the CDSS. To

find a project that meets these requirements, the author conducted a systematic search in No-

vember 2019 reviewing scientific publications not older than 2015. This to increase the possi-

bility to find projects that suit the research interests which means that they should have offi-

cially ended not too long ago or are at least at a later stage of development. Furthermore, the

project should include as a main feature at least a component that uses data-intensive methods,

such as self-learning algorithms or simulations of biophysical or -medical processes to support

the decision-making processes of clinicians. In addition, two further requirements turned out

to be useful for narrowing the range of suitable projects: focusing on realisations in the area of

therapy and treatment as well as concentrating on solutions that support medical decisions in

the field of specific diseases, sorting out projects that focus on a broader approach. That is,

because both intelligent decision support in the field of treatment/therapy and those support-

ing certain diseases seem to be further developed than the ones used in diagnosis respectively

those with the intention to support decisions across medical fields and diseases. To find suit-

able projects, the search took place on the platform Google Scholar.

In the following, the quoted interview partners are listed anonymously with ENG (1, 2, 3) for engi-

neers and CAR for cardiologists (1, 2). Publications carry the name of the anonymised project and a

number (for example CardioSimu 1 etc.), the same counts for the project website.

Against this background, the project CardioSimu (project name is changed) turned out to be

particularly suitable, since on the one hand the contents of the project meet the requirements

of this work. At the time of elicitation, the project officially ended half a year ago and the subject

of development was a CDSS that was supposed to support the therapy-planning of a specific

group of diseases and this also partly via techniques that are data-driven. Thus, this project could

provide a more complete picture of the development process as the development has been at

a very advanced stage already. In addition, what made the project particular interesting was

that the project members saw the development process more as fundamental research, where

things can be tried out. Not all project partners have had the same main goals and interests.

This is due to the spatially dispersed members of the project, which also involved respective

main tasks in the process of development. As we have seen, this is also typical for projects

where several disciplines are represented. But the direct representation of many disciplines (of

main interest here are medical engineering and cardiology) in the CardioSimu-project let this

fact become particular interesting as the negotiations between these disciplines can be retraced

directly from the interviews. This is shown in more detail later.

The main aim of the project was to implement, test and validate a CDSS for cardiovascular

diseases that allows simulating, comparing and understanding the effects and risks of differ-

ent treatment strategies. In order to accomplish this goal, the project was a collaboration be-

tween different sites across several countries, combining medical expertise with technical

knowhow. At the time of data acquisition, a sophisticated prototype of a data-driven CDSS

has been developed.

5.1. The Methods of Conducting and Interpreting the Empirical Data

Publicly available materials (reports, scientific papers, videos, the official project-website)

served the purpose of getting deeper insights into the project. These documents were then

used for two purposes: First, to get a detailed understanding about the general course of the

project, with its main achievements and obstacles; how the disease(s) and their treatment(s)

are characterised and portrayed; wherein the developers see the benefit of the support system

to be developed; and of course, how exactly the developed prototype is designed and how it

performs in the end. In other words, on the one hand, the documents simply served as a source

of information. Secondly, they served as a source for gaining insights about imaginations,

ideas, concepts et cetera that either fulfil the characteristics of situational scenarios or point

towards these. As the main source for the latter aim, the author conducted four face-to-face

interviews with five researchers

who have been part of the project, from both the medical

and the engineering side. These interviews took place in Germany and in the United Kingdom

during January and February 2020, whereas the German and one British interview represent

the medical and the other British interviews the engineering expertise within the project. The

interviews have been based on a guideline that served as an orientation scheme throughout

the interview. In order to be able to evaluate them more precisely later, the interviews have

also been recorded. The length of the interviews was between 56 and 114 minutes, with an

average time of 79 minutes. The Germany-based interview was conducted in German, the ones

in the United Kingdom in English. They took place in the working environment of the inter-

viewees, their offices or in meeting rooms.

5.1.1. The Challenge of Anonymisation

In order to provide a high degree of anonymity, the names of the interview partners and also

the title of the project have changed. These measures follow in general the Code of Conduct

“Guidelines for Safeguarding Good Research Practice” of the German Research Foundation

(Deutsche Forschungsgemeinschaft DFG) (DFG 2019) and particularly the Ethics Code of the

German Sociological Association (Deutsche Gesellschaft für Soziologie DGS) (DGS 2017). De-

spite these measures, there is a problem regarding the successful anonymisation of the inter-

viewees. This results from the use of publications which have been published in the context of

the project and contain some of the names of the project members (because they are the authors

of these publications). In order to find a feasible way, the author follows the procedure that

Schulz-Schaeffer and Meister (e.g. 2015) have already established in their project on ubiquitous

computing: In order to provide at least a certain level of anonymity project-related publica-

tions are cited in a way that makes them difficult to identify, although not totally unidentifia-

ble, as this is not possible to achieve. Therefore, instead of citing the names of the authors these

One interview was conducted with two researchers together. The reason behind this decision was due

to the inflexible schedule of the author, as the visit of the Sheffield site was only for one day. However,

as it was important to talk to both interview partners, the author decided to conduct a double interview.

There are limitations, especially regarding the mutual influence of the interview partners on each other.

This was taken into account in the interpretation of the interview.

publications are given numbers. This encryption can only be decrypted by me, so it remains

principally assignable. These measures should provide an acceptable level of anonymity, even

though in this particular case it cannot be guaranteed entirely.

5.1.2. Combining Qualitative Content Analysis and the Grounded Theory

Method

The evaluation or interpretation of both the publications and the interviews is done in a fo-

cused way. The material was specifically examined for statements and indications that provide

or could provide an answer to my research question. The focus lied on preconceived categories

that are theory-driven. In this case - not surprisingly - the evaluation of the empirical material

was based on the theoretical background of situational scenarios and on scripts, the concepts

introduced before. Nevertheless, this does not mean that the interpretation was made blindly

and just in the mission of pregiven categories. Instead, a special focus was put on the specific,

already elaborated, context of this case. This means the focus was on aspects that came out

from the case itself and have proven to be important. This is shown more detailed in the anal-

ysis section (chapter 6). Hence, in analysing the material the author follows a middle way of

the methods of Qualitative Content Analysis based on the understanding of Philipp Mayring

(2019) and Grounded Theory Methodology, firstly developed by Anselm Strauss and Barney

Glaser (1967).

To briefly outline the first, Mayring describes the approach of Qualitative Content Analysis as

follows, emphasising the creation and application of (pregiven) categories as the main ad-

vantage compared to other approaches: The characteristic of being guided by categories is the

central criterion that distinguishes Qualitative Content Analysis from other text analysis ap-

proaches. Categories express aspects of analysis in a short form, are more or less closely ori-

ented to the source material and can be organised hierarchically. The category system (as the

compilation of all categories) is the essential instrument of analysis. It is used to analyse the

material and only those parts of the texts that refer to the categories are taken into account.

(Mayring/Fenzl 2019: 634). What Mayring describes as the approach of Qualitative Content

Analysis is a procedure in which categories are generated primarily from already existing

knowledge about the object of study. What the researcher wants to find out is usually already

known beforehand and thus are also most of the questions that the text shall answer. Once the

categories have been established, they serve, as the quote shows, as analytical tools and the

text is scanned for relevant material. This ensures a high level of intersubjectivity, but there is

also the risk of ignoring or missing interesting facts that are not covered by the categories.

this approach was not applied in a strict way but combined with the methodological approach

of Grounded Theory, which particularly focuses on the creation of in vivo codes, that means

codes that are developed directly from the material. Here - while reflecting own prior

knowledge – the in vivo codes are generated in the form of open coding of the material. If

necessary, these codes are supplemented by so-called borrowed codes, codes that originate

from the background knowledge of the interpreting person (Strauss et al. 1996: 50). However,

in the spirit of the approach this should be avoided as much as possible.

Since this bears the risk of theoretical blindness, also this approach was not applied in its most

consequent understanding. Instead, a pragmatic approach was used. The categories used to

analyse the source material for this study are partly theory-driven and partly derived from the

characteristics of the case. This means, during the content analysis the author was informed

and guided by theoretical assumptions and perceptions. These were used as a loose frame.

Therefore, the search was conducted within and also without the framework.

For a more detailed explanation, on the next pages an overview of the project is given, putting

the focus on three aspects: the specifics of the disease and its conventional ways of treatment

as portrayed in the project; the concept of the so-called Digital Patient, that is the underlying

database of the development and the operation of the support system; and the ways the sup-

port is supposed to be technically provided by the CDSS. Here, the main focus lies on docu-

ments and project deliverables. This is followed by a section about the primary research ques-

tion about how scenarios guide developers in constructing and scripting a medical technology.

In the last part a reflection is given upon the special empirical case of data-driven Clinical

Decision Support Systems. It is argued that these are not only systemically opaque in nature,

but are also scripted in this way. An end is set with the open question about possible implica-

tions for medical practice.

5.2. The Disease and Its Conventional Treatment

The project locates itself in a specific medical subdiscipline, namely the treatment of the dis-

eased heart valve within the field of cardiology. According to the project description, the field

of cardiovascular or valvular heart diseases is dominated by two conditions, aortic stenosis

and mitral regurgitation, both of which are associated with significant morbidity and

mortality, yet which pose a truly demanding challenge for treatment optimisation. The medi-

cal term of aortic stenosis describes the condition where the aortic valve opening becomes

narrow (stenotic), limiting the amount of blood pumped by the heart. The term mitral regur-

gitation refers to the medical state where the mitral valve does not close completely, meaning

that blood can flow backward, reducing the heart’s ability to pump blood (EC 2019: 1). Thus,

in the project these two conditions were the subject of matter, whereas in the end of the project

in January 2019 only the developed models for aortic stenosis have been already integrated

into a CDSS (EC 2019: 2). After an individual got diagnosed with aortic stenosis and/or mitral

regurgitation that is severe enough to consider a surgical intervention it becomes the main

challenge for the clinician to decide over the timing and nature of interventional treatment.

Regarding the right timing of operational intervention, the clinician has to reason and decide

whether it is not too early or too late to operate, because operating on patients too late carries

the risk of development of irreversible heart failure. Operating too early exposes patients to

unnecessary risks and adverse events, conceivably causing short- or long-term sequelae. Cur-

rently, the way cardiologists are reasoning over the perfect timing of intervention is by (man-

ually or with the help of technical tools) analysing relevant clinical symptoms (usually meas-

ured via echocardiography in the process of diagnosing), the blood pressure pre and post the

aortic and/or mitral valve, the ejection fraction rate as well as the size of the relevant ventricu-

lar chamber. This is the common standard according to the corresponding clinical guidelines

of the European Society of Cardiology (ESC).

Concerning the type of intervention, the whole

replacement of the aortic valve is still the standard treatment as it is for the mitral valve, alt-

hough recently there are also approaches to repair the respective valve, for example by im-

planting a transcatheter. These are becoming more widely used but are still less common. Ac-

cording to the project website, there is a consensus among cardiologists that different types of

valve prosthesis (size, shape) or repair techniques will have different functional results. De-

ciding which option of treatment would be the indicated one, that means having the most

For example, whether a surgical intervention is indicated or not is recorded in respective guidelines

of the European Society of Cardiology (ESC), a non-for-profit organisation which, among many other

activities, publishes clinical practice guidelines on a regular base that “present relevant evidence to help

physicians weigh the benefits and risks of a particular diagnostic or therapeutic procedure” (www.es-

cardio.org) in the field of cardiovascular diseases. Their observance is therefore not mandatory, but in

the spirit of evidence-based medicine they are generally used as standards that should be followed.

promising outcome, is therefore a highly complex and complicated process, as this includes

the planning of the whole therapy procedure.

Keeping this in mind, the approach of the project consortium is to considerably enhance the

process of the clinician’s decision-making and therapy-planning in this specific medical field.

This by using technological means: The planned CDSS is supposed to go clearly beyond pa-

rameters conventionally used by looking at the cardiovascular system at a more “holistic” and

multi-scaled way. In addition, the CDSS shall allow for better personalisation of treatment

strategies. This approach is connected with the idea of the so called Digital or Virtual Patient

a concept that transports a broader vision as well as real data-based manifestations. In the

following let us elaborate on this in more detail.

5.3. The Underlying Concept of the Digital Patient – Using Big Amounts

of Data

In the summary section of the project’s website the project members state that the major ad-

vance of this CDSS over current practice is that it integrates and interprets all heterogeneous

data available about the patient, integrates population data where needed, and provides a

consistent, repeatable, quantitative and auditable record of the information that contributes to

the decision process. Behind this formulation lies a concept that takes the name “the Digital

Patient” (CardioSimu 2). It was supposed to underpin the whole project. The Digital Patient is

not the actual human patient itself or a medical version of the person. Rather it is a corpus of

data about the patient, that derives from many different sources and constitutes the patient

inside the CDSS. As this is the case, the scores of many of these input data points are, like the

patient itself, not stable but subject to change. In addition, the degree of representation would

become denser with each additional data point that is added to the system. Or, according to a

project deliverable, the Digital Patient data on any particular individual evolves over time,

becoming an increasingly accurate representation of the individual, as new data is available

(CardioSimu 2). This data corpus was meant to be a main part of the CDSS. It is supposed to

The term of the concept is not stably used within the project and among the project members. In order

to avoid confusion, the term “Digital Patient” is used when referring to the underlying data concept of

the project.

be interpreted by a computational model partly based on machine learning. This in order to

enable a more effective quantitative characterisation of the disease state and to predict the

effect of intervention (CardioSimu 2). In a deliverable that was published at the beginning of

the project (CardioSimu 2) the developers present a list of the data that was supposed to con-

stitute the Digital Patient. They are listed in the following:

- Meta data (about the current medical state of the patient)

- Demographics

- Medication

- Risk factors

- Diagnoses

- Physiological and laboratory measurements

- Echocardiographic measurements (the main tool to diagnose cardiovascular diseases)

- Computer tomography measurements

- Operative data

- Computational measures and concepts.

As can be seen, the data corpus was meant to contain basic medical health records (de-

mographics, medication, diagnoses etc.) as well as data that is of particular importance to the

cardiologist in order to make informed decisions about the need, time and nature of the med-

ical intervention. The latter is mainly measured during the course of diagnosing, that means

before the planning of a particular therapy option. It primarily consists of data from medical

imaging, meaning echocardiographic and computer tomographic images as well as magnetic

resonance imaging of the heart and the heart valves.

The above listed sources and types of medical data contain more information than is required

for therapy planning, referring to the clinical guidelines mentioned earlier. In addition – and

not mentioned in the cited early project deliverable – the project partners decided to measure

and wanted to include the patients “Quality of Life”, in doing so referring to variables estab-

lished by the World Health Organisation (WHO), in short WHOQOL. These measures are

meant to capture the overall quality of life of individuals as well as populations. It includes a

wide range of measurements about physical health, psychological health, the level of inde-

pendence, social relations, measures about the broader environment of the individual as well

as information about personal beliefs, including spirituality and religion (www.who.int). But

this has not been undertaken at the time of conduction, according to one interview partner

(CAR 2). Furthermore, during the project the researchers also decided to conduct the activity

rate of the treated patients before and after the therapy, this with wearable devices which con-

stantly measure their physical activity in their everyday environments (for example meters

walked within a day). At the same time some data sources have been excluded or made less

important in the CDSS itself. This out of different reasons, for example because certain data

was not available or not easy to collect from all participating hospitals. Or they turned out to

be of less or no additional advantage compared to the data conventionally used.

In the end of the project the final prototype of the developed CDSS contained five different

sources of information which represent the Digital Patient. That is, firstly, the current guide-

lines which bear reference to the treatment of cardiovascular diseases, secondly the already

established risk scores, thirdly the method of case-based reasoning, fourthly the activity rate

of the patients and fifthly a whole visual simulation of the patient’s heart valve functions (Car-

dioSimu 3). The next chapter is going to expand on the individual functions.

5.4. The Prototypical CDSS and how it Operates

At the final stage of the project a prototype of the CDSS has been developed, including the

components described before. After typing in all the relevant information that constitute the

Digital Patient inside the CDSS it processes them in a particular way. In the end, the system

presents more abstract data of information, those that make up most of the accessible compo-

nents of the CDSS. As the fifth component in the actual prototype of the CDSS, the simulation

of the individual heart valves of a patient is based on all or most of the other information. This

was seen as the main innovative component supporting the cardiologist’s decision-making

within the project. The components give information with different levels of abstraction. The

interpretation work remains on the clinician’s side. And still it is up to the physician to decide

over the further course of the therapeutic treatment. The types of information which are deliv-

ered and displayed to the clinician by the system are the following. Let us take a closer look

into them as some of them play a bigger role in the analysis part:

Clinical guidelines: These are shown to the user of the system first. This component

is rather simple, as it offers the possibility for the user to click

through all the relevant clinical guidelines that matter for the

therapy of the disease. This part of the system (as is the next one)

cannot be claimed as being data-driven. Rather, it represents, as

a component of the bigger system, the knowledge-based ap-

proach. The function only lies in presenting the guidelines as

such, without further interpretation or (hidden) computation.

The primary benefit is seen in putting the guidelines back to the

mind of the user, at the time when their exact content can become

important – directly in the situation of therapy planning. Addi-

tionally, the system shows the relevant guidelines to the user in

a condensed way, which means with the system it is possible to

access all the guidelines that might be important at one point.

Risk scores: The second component is also an already established functional-

ity. In cardiology so-called risk scores exist. These are scores that

calculate the risk of a patient regarding their morbidity and mor-

tality. Several risk score systems have been established. Exam-

ples are the euroSCORE and the STS-Score developed by the So-

ciety of Thoracic Surgeons (STS). In both these scores a certain

number that represents the weight of the particular risk within

the system is assigned to every single risk factor. Filled in with

data of individual risk factors the system will calculate the over-

all mortality risk of an individual patient if an operative proce-

dure is applied. Just like the guidelines, the functionality of the

risk score system is implemented into the CDSS without any

changes.

Case-based reasoning: In contrast, the component of case-based reasoning was devel-

oped within the project, although the general idea is well-known

in cardiovascular treatment. The function of this component is

the reasoning of the patient’s risk regarding particular operative

procedures. But conversely to the component of the risk scores,

this is based on the comparison of individual cases. A cardiolo-

gist, who was part of the project, describes this function as fol-

lows: On the basis of a patient who is recorded with all the com-

ponents that have been classified as important at some stage, a

comparison is made between how similar this patient is to

patients who have already been recorded in the database (CAR1,

55). Basically, the aim is therefore to find cases within a database

which are similar to the case at hand. Often this involves distinct

characteristics of the anatomy of the patient’s heart or other fac-

tors that might influence the short- or long-term outcome of an

individual patient. This is put into a similarity score ranging be-

tween ‘zero’ and ‘one’, where ‘one’ is the case of total similarity.

The most similar cases within the database can then be studied

in more detail, regarding characteristics of the patient, operative

procedures, outcome for the patient, remaining symptoms et

cetera.

Activity rate: The (significant change of the) physical stamina of an individual

with a heart valve disease is considered as an important indicator

for the right timing of an operative intervention. Therefore, con-

ventionally the patient has to absolve tests that measure their

physical stamina. This on a regular base. An example is the six-

minute walk test. Here, the patient has to walk on a self-paced

level for six minutes in order to simulate the movements in their

everyday environment. The comparison between several tests

over a longer period thus might show signs indicating a worsen-

ing of the disabilities of the heart valve(s). Within the project, an-

other approach has been followed. Instead of using data from for

example the walk tests, patients have been equipped with mobile

health devices (health watches) which were measuring their

heart frequency rate (and other activity data as well). The pa-

tients were supposed to use or wear these in their actual every-

day environment. The idea behind using wearable devices in-

stead of established methods was to find out, whether these data

can predict the results of standardised tests that would otherwise

be done by study nurses or performed by nurses in the outpa-

tient clinic (CAR1, 59). As this proved to be the case according to

statements from the interviews, the activity rate was included as

a component in the CDSS.

Heart valve simulation: According to the project members, this component is meant to be

the core functionality of the CDSS. Here, a part of the heart valve

is simulated using data from imaging procedures usually made

during the diagnosing process. This includes, for example, im-

ages from magnetic resonance imaging (MRI) or computed to-

mography (CT), as well as echocardiography (an ultrasound of

the heart). The CDSS creates a virtual image of the relevant area

of the heart and the clinician can then analyse this image and also

manipulate it accordingly by importing data records. Or, for ex-

ample, the clinician can insert a laser-scanned model or geometry

of various artificial heart valves into the virtual model and is then

able to try out different placement angles of these. This can be

combined with patient-specific flow profiles of the blood inside

the patient’s heart

, as measured by the MRI. In combination

with the heart valve models, the respective surgical result (e.g.

would aneurysms occur or not) can be simulated or predicted.

To figure out which parameters are important to be included in

the simulated model a machine learning approach was used.

One cardiologist (CAR1) described it as a “holistic” approach,

meaning the approach was to include not only data that is con-

ventionally used but also using new sources.

6. The Analysis: An Implicit Scenario under Negotiation

In what now follows the example of the development of a prototype of the described Clinical

Decision Support System created in the course of the project CardioSimu, is taken as a case. It

is particularly shown what assumptions about the reality of the social situation at stake have

This is called pressure volume loop and it shows how and how much blood is pumped by the heart

at a certain volume.

been part of the project and in which ways they found their way, as scripts, into the CDSS. To

give a first note, let us start with wherefrom the members got their knowledge about what

cardiologists usually do when they decide over and plan a treatment (6.1.). Thereafter, we

separate the assumptions into assumptions about the decision-making and therapy planning

work cardiologists conventionally do (6.2.), implications about the integration and application

of big amounts of data – the so-called Digital Patient (6.3.) – and imaginations about how the

work of cardiologists would look like if they would work together with a decision support

system like the one developed in the project (6.4.). For the last a dominant scenario is unveiled

that lies behind the imaginations brought forward in the interviews and scientific articles and

is inscribed into the CDSS. After this main part of the analysis, a final conclusion is given (7.).

6.1. Wherefrom Do the Developers have the Assumptions?

First of all, as this project was a collaboration of multiple disciplines, the knowledge base of

the technical members on the one side and the medical members on the other was quite dif-

ferent. This is rather obviously the case as these members represent very different disciplines.

Therefore, it was mainly the technical members within the project who were interviewing the

cardiologists being part of the development team, as the quote of an engineer shows:

“[T]he information that I have about the process [of diagnosing and therapy

planning] is from cardiologists. So, we were looking at the data that we had

that were routinely gathered, and what was not routinely gathered, what we

needed to ask for extra. And [for this reason we were] talking to cardiologists

from [the participating hospitals] about what they are doing.” (ENG3, 32)

Throughout the project several meetings and discussions took place where the cardiological

work was the subject matter broadly discussed among the project members. In these meetings

it was the main goal to find out about key issues cardiologists are currently facing in order to

get an idea about how a CDSS could possibly be helpful for the clinician: “I think what we did

get, it was a long discussion with the clinicians, was an idea about what their challenges were.

You know, what are the difficulties in diagnosing the patient and deciding where to go”

(ENG2, 61). The outcome or the conclusion drawn from these discussions have been described

as “a general feeling”, for example about “that the tendency was to overtreat, perhaps treat

too soon” (ENG2, 61). Furthermore, the intuition of the cardiologists, which means their expe-

rience-based knowledge, played an important role in evaluating the data and the outcome of

the systems computation. One technical developer told a story about a clinician who was

involved in the project and was not believing the numbers presented to him by an earlier ver-

sion of the support system. It is said that this cardiologist knew the patient by himself and had

much more information about him than the system got. So, the technical developers tried to

make more use of the experiences and knowledge of the clinicians who were part of the project

(ENG3, 52), for example by putting more effort on the case-based reasoning component of the

system. As a consequence, among the technical team(s) within the project the knowledge about

cardiological decision-making and therapy planning was bounded, or like one technical de-

veloper explicated it, they “had limited access to the information about what actually the car-

diologists do” (ENG3, 32). Hence, to say it with Schulz-Schaeffer and Meister (2019) the

knowledge about the cardiologist (and other clinicians) as users and about cardiological deci-

sion-making mainly derived from the professional knowledge of the involved cardiologists as

potential users themselves as well as from everyday notions or common-sense assumptions of

the involved engineers.

6.2. Assumptions about how Cardiologists Conventionally Decide

Among the project members many assumptions existed about how cardiologists actually de-

cide over a treatment and plan a therapy. As already mentioned in the section about the dis-

ease and its current treatment the members of the project CardioSimu explicate a clinical mo-

tivation behind their approach of developing a technology. They see their motivation in the

need of assisting the cardiologist in making the right decision regarding whether they should

do an intervention or not and claim two aspects as particularly important in making these

decisions: It is the timing and the nature of the intervention (CardioSimu website). The cardi-

ologist is the one making the final decision and is planning the treatment and is therefore also

the main reference or “target user” (CardioSimu website) addressed by the project members.

It is the clinician’s work which is supposed to be supported by the developed system. So, be-

sides the broad understanding of the main difficulties currently apparent in cardiological

Whereas one interview partner contradicted this assumption that was brought forward by everyone

else and also stated in the documents: This person put the healthcare assistants to the frontstage and

claimed them as the main or target user, the ones who have to be able to understand the whole system,

the input as well as the output, because “the clinician him- or herself simply receives the additional

information which they seek to assimilate into their process” (ENG1, 64). The one the clinician receives

the information from is the professional health staff.

decision-making, how is the cardiological work assumed or imagined among the project mem-

bers? Firstly, it is important to divide between the technical and the medical members, as the

clinicians who took part in the development have been cardiologists themselves. This is also

apparent in the interviews. Different assumptions or estimations about the actual work cardi-

ologists are doing have been stressed and brought to the surface by medical and the technical

interviewees.

Assumption one: Cardiologist’s decision-making is characterised by an interplay between previ-

ous experiences and clinical guidelines

What is stressed by every interview partner is that cardiologist’s decision-making is charac-

terised by an interplay between previous experiences of the clinicians and the guidelines

counting for cardiological interventions. Although this is not exclusively the case for cardio-

logical decision-making, it was mentioned most often by the interview partners and therefore

deserves attention. Among the interviewees both sides, the personal experience of the clinician

and the following of the guidelines that are evidence-based, are seen as important resources

for the decision-making of the cardiologist. The predominant view is that of a complementary

relationship they have for the decision-making process, as treatment decisions vary “from per-

son to person”, as one cardiologist explains. Further he states that “[w]e are guided by evi-

dence in guidelines, but a lot of clinical decisions are guided by our own previous experience.

So, if you have managed a similar case, eventually with a positive outcome, you are more

likely to do that again” (CAR2, 32). The clinical guidelines are seen more like “a good starting

point”, however it is assumed that a lot of clinicians “often do follow guidelines blindly”

(CAR2, 63). This is considered as counterproductive for the decision-making process and thus

for the potential outcome for the patient as well.

But at the same time, it is also supposed that too much reliance on own experience is not ad-

vantageous either, turning it into intuition which is considered as risky. An interviewed engi-

neer stated that “throughout the project I got the idea that there is […] too much intuition

involved in decision-making” (ENG3, 38). It was concluded that this intuition has to become

more robust, which means getting supported by additional data and modelling, in short: by a

Clinical Decision Support System. But still, the information from the clinical guidelines as well

as the knowledge gained from individual experience are seen as being of considerable im-

portance for decision-making, although the solely reliance should lay on neither of them. Re-

lying too much on the guidelines is seen as losing sight of the individuality of the patient, as

“you [as a cardiologist] are following a path to make a decision for the individual, but they do

not take into account […] an individual profile, because they cannot […]. There simply is not

the information in analysis that is being done to support that” (ENG1, 53). On the other hand,

relying too much on one’s own experience is seen as problematic, because for the developers

it indicates a lack of reliable, evidence-based and therefore to some extent objectifiable sources

for making the clinical decision. Instead, for the engineers, it is associated with randomness.

An example is the decision on what measurements to rely on, like one engineer describes as

“when we asked, so we have five pressure measurements, which one to take. […] In some

cases, it was random, […] the decision […] which one is the most valuable […] was not con-

tinuous. […] Through experience they knew […] and for us it was a confusion” (ENG3, 32).

For the development team, a path in between had to be found, hence making use of both the

knowledge contained in the guidelines and the experience contained in the heads of the car-

diologists.

Assumption two: There are variations in measurements which need to be scrutinised and filled

with medical meaning

Another estimation was mentioned in the interviews: a variation in measurements, for exam-

ple MRI or CT scans. This was only broad forward by the technical members and not men-

tioned at all by the medical interview partners. But according to the engineering side “they

[the cardiologists] did different measurements of the same parameters at different times and

in different states” (ENG3, 32). The measurements can tell the clinician different things at cer-

tain times of conduction, which is seen as, to some extent, reflecting a kind of variation in the

meaning of measurements. Nevertheless, this variation in measuring body signs is connected

to the assumption that cardiologists strongly rely on their own previous experience. The two

following statements of two engineers about measuring the heart rate of a patient using dif-

ferent methods explains this connection in more detail:

“A […] clinically descent concept is measured using different methods and

the results are different. So, […] you measure […] with magnetic resonance

imaging or measure it with ultrasound and they are just different. So, which

is right? Well, probably neither. Which is better? We do not know. It all de-

pends on how you interpret it.” (ENG1, 38)

And:

“There is heart rate measured during CT or MRI scan, which is different,

because it is a claustrophobic, stressful environment with loads of things

going on. And there is heart rate measured in some other tests as well. And

there is a difference between them. [..] I imagine that the clinicians looking

at that see a pattern of what is going on through the experience that they had

with other patients and much better understanding their physiology.”

(ENG3, 34)

Here, the assumption about cardiological work is that there is a connecting item or action

needed between the variation in the meaning of measurements and a reliance on previous

clinical experiences, and this is the act of interpreting the data. This “interpretational work”

(Mort et al. 2005: 2033) is considered to have an important position in applying the experience

a clinician made throughout their carrier and the fact that measurements taken are not speak-

ing for themselves but need some analyses to become meaningful. Even whether the running

of certain tests and the conduction of particular clinical measurements are “relevant to the

conditions under which your symptoms would be manifest” (ENG1, 26) or not has to be taken

into account. Thus, what kind of tests the clinician and their medical staff are deciding to run

and under what condition the patient is during these tests (for example the process of MRI as

claustrophobic and stressful) is therefore assumed to have a significant influence on decision-

making and it is seen that it needs to be scrutinised and filled with medical meaning by med-

ical experts derived from the interplay of experience and guideline knowledge mentioned

above.

Assumption three: There are differences between routine and borderline cases and the last are the

ones that matter

Another assumption that was relatively prominent, but only stressed in the interviews with

the cardiologists, is that there is a difference between the clinical routine and those cases that

are at the borderline of deciding if and how to intervene. On the one side there are plenty of

cases that are “in between” (CAR2, 68) which means clinicians connected them neither with

good nor with bad memories. These cases have not been difficult in a medical sense, “they are

just routine” (CAR2, 68). These routine cases are mainly treated following clinical guidelines

which tell the clinician what to do. Everything that can be done with the patient and what the

clinician should do is classified there. This is divided into degrees of evidence with regard to

how evident the guideline already is or which data basis is used. These are the standard ap-

proaches (CAR1, 40). Cases that appear as routine can thus easier be treated by following a

guided path presented in guidelines. On the other side there are borderline cases. These are

cases which show inconsistencies or ambiguities (in the measured data or the broader medical

appearance of the patient) and might therefore not be represented by clinical guidelines. In

cardiology, these cases involve a meeting of several clinicians from different professions work-

ing in the field of cardiological medicine, the so-called heart team. In the words of a cardiologist:

“[U]sually when it is about borderline decisions in cardiology, we sort of consult a heart team.

We have different specialties, we also have different interests, that may have an opinion about

how a patient is managed.” (CAR2, 36) The heart teams have an outstanding importance for

the decision-making. The experience of the cardiologists plays a main role here, too,

“because […] you are influenced by your own previous experience, which

why the heart team is so important, really, in cardiology. You have sort of

different cardiologists, different surgeons, people have different experience.

And then […] they come up with that sort of hopefully more holistic sort of

management plan for that patient” (CAR2, 36).

These so-called heart team conferences about borderline cases are an established institution in

cardiology. Both interviewed cardiologists emphasise its significance in cardiological decision-

making and in a widely noticed paper from 2013 David Holmes et al. claimed that “this […]

approach will become the standard of cardiovascular care” (903). In these heart teams all

measures taken are considered and discussed by a multidisciplinary team. According to one

cardiologist these team conferences are the place where also less conventional information and

more uncommon measures are part of making a decision. But there is no standardisation

(CAR1, 70). This lack of standardisation is supposed to be addressed by the developers.

Assumption four: The cardiologist has to deal with too much medical information

Although not mentioned as prominent as the other assumptions, there is still the idea of the

clinician who has to deal with too much information to make a wholly informed decision.

Deciding about the positioning of the valve, meaning where to position the artificial valve

optimally and how to turn it best in terms of the angle; what are the optimal hemodynamic

adjustments after valve replacement; is it possible to optimise the blood flow; is an avoidance

of extra turbulences and calcification possible; and when is the best time to perform the pro-

cedure? These are all questions that are seen to be particularly relevant for the decision-making

and the therapy planning afterwards. It is assumed that there is too much information to be

able to easily decide about these and other medical questions, as this citation of an engineer

shows:

“The big problem they [the cardiologists] have now is that they cannot as-

similate all the information they need. So, there must have been a sweet spot

some time in history where clinicians […] were exposed to the amount of

information they can sort of integrate in their heads. But now it is increasing.

They got huge piles of information papers that are coming in every day from

journals, clinical trials, et cetera. Some of them are very conflicting results.

They have got to integrate a lot in their heads and then remember all the

patients they have ever seen.” (ENG2, 67)

This widely and well-known image of the clinician (here the cardiologist) who has to deal with

too much information and who is not able to retrieve all of it in the process of decision-making

played a major role for the engineering side of the development team. Because of the complex-

ity and sheer quantity of the information that is needed under best circumstances, it is a widely

accepted assumption that “nobody can make a clear decision. That is definitely right, every-

body agrees on” and in the project this was the main reason “why we wanted to provide more

data to make that decision”, whereas “it is a complex task […], because how do you know that

your opinion is the best opinion” (ENG3, 43), reflecting the huge amount of information and

therefore possible facts not included in the decision made respectively the data provided to

support making the decision.

6.3. Implications of the Digital Patient Concept

We have already seen that the concept of the Digital Patient is represented in the CDSS in the

form of various data from different sources, conventionally and non-conventionally used in

cardiological decision-making and therapy planning. But the Digital Patient also comes along

with a broader vision about the influence of newly added and newly combined data and data

sources affecting the process of decision-making of clinicians respectively cardiologists. The

vision behind the Digital Patient concept can be deduced from the following statement in an

early deliverable of the project:

“The [concept of the] Digital Patient […] will develop new ways of combin-

ing rich patient information in a highly visual, coherent and meaningful

way. In the short-term, this will enable new clinical information to be gener-

ated by the blending and fusing of existing data but, ultimately, it will lead

to the creation of a powerful ‘patient avatar’ capable of supporting the med-

ical professional by producing the new clinical knowledge which will

emerge from the integration of patient-specific and population-specific in-

formation. These innovative information technologies will impact how med-

ical professionals can access simulations of the progression, treatment, and

outcome of a disease to support diagnosis, prognosis, and choice of treat-

ment” (CardioSimu 2).

What can be deduced from this statement? First of all, the concept of the Digital Patient means

the combination of big amounts of data that contains traditionally measured data and newly

conducted data sources. These data are “rich”, which means having a potential that can be

brought to light by (intelligently) combining them with each other and thereby generating

new, not to say better, information to serve medical decision-making. This combination can

mean using simple algorithms or statistical methods operating along pre-given standards and

weightings, like statistical regression. But it also includes the usage of artificially intelligent

methods combining the various data in an opaque way and the process of simulating based

on a model with inputted individual data, whereas for the user of the system a direct relation

between the inputs and the output is difficult to spot. For the developers this, consequently,

leads to a digital version of an individual patient inside of a model. With this digital version it

is possible to run, or simulate, treatment strategies which would not be possible with the real

patient him- or herself. The following quote explains and exemplifies this a bit further: “[Y]ou

can do whatever you want to that virtual patient. You can perform an intervention and see

what would be the outcome or you can make the virtual patient perform exercises which

would be too dangerous because of the state of the [real] patient” (ENG3, 26). That means,

with the simulation of an individual patient, turning them into a virtual version, it is possible

to also simulate, and therefore predict, possible treatment strategies as well as probable out-

comes and thus supporting the decision-making process of cardiologists. The combination of

information of the individual patient and information abstracted on a population level makes

this possible, so it is stated by the developers. Implied is a possibility to extensively represent

the real patient by the virtual avatar using at least partly intelligently combined data and sim-

ulations that are built on this data. The potential opacity behind it is only modestly reflected,

although the usage of artificial intelligence and simulation in general is partly seen critically

respectively as to be treated with caution: “[T]he question is how do you slow that develop-

ment down a little bit without hindering innovation. Because I think you do need to not be too

ambitious with those things” (ENG2, 27). Nevertheless, the developers mainly connect posi-

tive associations with intelligent combinations of big amounts of data. Let us take a closer look

into this vision of the Digital Patient and its implications:

Within the project the concept of the Digital Patient is seen as a solution addressing the chal-

lenges cardiologists currently face regarding the developer’s understanding about cardiolo-

gist’s work. But, as we have seen in the section before, this understanding is not equally

distributed among the project members. Besides individual differences there are certain as-

sumptions that have been primarily or even exclusively brought forward by either the engi-

neers or the cardiologists. This indicates disciplinary differences within the project. Neverthe-

less, after we have seen that these disciplinary differences have played a role in the matter of

assumptions about the decision-making work cardiologists do, it can be stated that it also ap-

peared regarding assumptions about the Digital Patient concept. The main difference lies in

the assumption about in which way and to what extent it is possible to represent the real indi-

vidual patient in its complexity within the CDSS. Let us exemplify this with two statements.

The first one comes from a cardiologist. He describes the concept of the Digital Patient as a

tool that makes it possible to represent the patient in an analogous, but a simplified way. For

him it will never be feasible to achieve a whole representation of the real patient, because the

patient’s physiology is too complex, regardless whether the artificial reasoning engine is intel-

ligent or not:

“[The Digital Patient] will always be a simplified version. Because […] no

matter how good the computer model or how complex it can be, it can never

truly represent physiology of a patient. […] I mean, the human body is so

complex, it cannot represent all, especially when we talk about the patient’s

outcomes. We cannot represent someone's thoughts in a computer algo-

rithm. […] So, the whole […] changes of blood pressure, heart rate responses,

you can try and simulate. But there are so many different influences on that,

both physical and emotional, that you could never model in a perfect way.

So, I think the idea of the Digital Patient is that it is nice, but you should

probably read it as a digital simplification of physiology. So, […] it cannot

represent the patient, it can represent maybe some basic principles of their

physiology” (CAR2, 46).

Compared to this statement, the engineering side is more optimistic about the possibilities of

a data-driven support system like the one developed in the project. The following statement

is thus from an engineer. He characterises the concept of the Digital Patient differently. As a

virtual representation of a real individual inside the CDSS here the virtual patient gets closer

to what is stated in the deliverable: a patient avatar and therefore an adequate representation

of the patient. One with which medical procedures can be tried out without harming the real

patient him- or herself:

“So, the Digital Patient, as I understand it, is a computational being inside of

data and procedures that represents a specific person. And [because] that

being [is] digital, you can do whatever you want to that virtual patient. You

can perform an intervention and see what would be the outcome or you can

make the virtual patient perform exercises which would be too dangerous,

because of the state of the patient. So, getting it up to higher heart rates and

exercising till failure, which you cannot do in reality, what is happening in

industry, where you crush cars against walls to make sure that they are safe.

So, with the Digital Patient […] you could kill the virtual patient to see, or

that is how far it can be pushed and whether that is acceptable or not. And if

it is not acceptable, […] how do we need to intervene [so that it] is on an

acceptable level” (ENG3, 26).

Whereas the cardiologist emphasises the restrictions that lead to an imagination of the support

system, what could be called bounded representativity, the engineer stresses the ability of the

support system to be able to represent the patient to an extent detailed enough to do a simu-

lation of interventions or exercises with the virtual surrogate and directly deduce medical

knowledge and conclusions out of them in order to help in medical decision-making. The anal-

ogy to safety tests in the automotive industry illustrates this idea quite well: Under protected,

that means controlled conditions, the automobile respectively the patient can be exposed to

influences or pushed to limits that would not be acceptable or feasible in the real-world envi-

ronment. Findings from this can then be more or less directly incorporated into further deci-

sion-making or planning towards which direction to go. This direct transfer of insights from a

simulation to the real world is not shared by the quoted cardiologist.

As this is the case what also becomes quite apparent is that although the cardiologist holds a

more critical position towards the extent of representativity of the Digital Patient model, both

are rather uncritical regarding the potential non-traceability of the implications of the infor-

mation displayed in the CDSS. This is evident in all interviews, even though it is acknowl-

edged that at least a basic understanding of simulation should be acquired for a competent

use of the CDSS, or at least when using the fifth component.

A difference becomes also apparent when looking at the component(s) of the Digital Patient

that are considered as being most important or most influential. On the engineering side it was

the simulation part of the system, as this was the component the engineers interviewed have

been working on primarily. On the medical side instead, the component that was thought of

being most useful was the case-based reasoning, which was also seen as the most useful tool

by participants in the cardiological experiment where the development team presented addi-

tional information to one group of cardiologists, whereas the other group had to make a deci-

sion on cases only using conventional data. What is more, in contrast the simulation compo-

nent was seen rather sceptical by the medical participants. The explanation for this difference

given by the engineering side is the following: The simulation approach is the newest and

therefore the clinicians have less experiences with this component and have been more scep-

tical about it. This idea was brought forward several times. In the portrayal of the interview

partners it reflects remarks by Schulz-Schaeffer and Meister (2019). While the technical devel-

opers present themselves as spokespersons of future components of the technology (later we

see: of the scenario), the medical test persons and to some extent also the cardiologists involved

are given an advocacy for currently existing components, being rather sceptical about unfa-

miliar parts of the technology.

Not so with the idea of case-based reasoning as the idea of comparing a (difficult) case with

similar cases of the past, treated by the clinicians themselves or by others, is already present

in the idea of the heart team. This is considered to be significant for the decision-making in

borderline cases. Hence, case-based reasoning is assigned a role similar or comparable to that,

as the following statement from a cardiologist shows:

“I am not saying that the clinical support tool sort of replaces that heart team,

but some of the features within it sort of did that. So, we had the case-based

reasoning decision tools that looked at what other clinicians may have done

with similar cases in the past and that would help guide what you may [do

now]” (CAR2, 36).

It can therefore be said that both preferences are based on disciplinary interests: The engineers

see their field of study, the individual modelling of the heart valves and the connected simu-

lation of heart flows under the influence of different interventions, as the primary innovation

promising great benefit and is therefore pushed by the engineering side, while the cardiolo-

gists see the main helpful element in the access to experience-based data that would otherwise

be far more complicated to obtain, which is represented by case-based reasoning.

However, what is assumed among all members of the project was that the concept of the Dig-

ital Patient is, generally speaking, good, which means helpful. It is claimed to be an advance-

ment for the cardiologists making the medical decision and it is assumed to be an improve-

ment for the patient’s outcome as well. But whether the representation of the concept of the

Digital Patient inside the CDSS is actually helpful for the treated patient is, however, an open

question, as this was not a subject matter in the project. Nevertheless, it is imagined this way:

“Wenn man sich überlegt, ein Patient, der hinterher schwerstbehindert, der

hinterher einen Schlaganfall durch diese Operation erleidet, der möglicher-

weise sehr lange im Krankenhaus ist, hinterher sehr immobil ist, vielleicht

hinterher eine deutlich schlechtere Lebensqualität hat als vorher. Da kann

man sich vorstellen, dass das nicht nur individuell belastend ist, also dass

ein Patient am Alltag weniger teilnehmen kann und dass er sich da

irgendwie schlecht dabei fühlt, das sind ja messbare Faktoren, da kann man

irgendwie von ausgehen. Aber es ist natürlich auch, es gibt da mehr Kom-

plikationen, es gibt mehr Krankenhausaufenthalte, es gibt Folgeeingriffe,

Folgeaufenthalte in Kliniken, die unnötig wären. Ich denke, das ist erstmal,

würde erstmal auf der Hand liegen, zu sagen warum finden wir es besser,

eine Intervention mit mehr Informationen zu planen” (CAR1, 82, translated

version in footnote 16).

The above statement shows that the added information and the outcome from the combination

with one another as well as with conventionally used data is assumed to be better for making

an informed decision and are therefore also seen as being an improvement for the patient’s

outcome and even for the whole patient management in the hospitals and clinics. Accordingly,

for the support of the clinician the approach of the developers is considered as being helpful.

There is also a consensus among the project members about to what extent the system working

with the concept of the Digital Patient can or should be part of the decision-making, which is

analysed in detail in the next section. For the developers (the cardiologists as well as the engi-

neers) an algorithm computing big amounts of medical data will not be able to precisely pre-

dict medical outcomes or events, for example surgical complications. This means, it is seen

that not everything can be captured with data. Also, with a decision support tool the decision

should not be “completely binary”, it rather should “provide information to the clinician to

make their own decision” (CAR2, 42). Or the way an engineer was putting it: “We will not

replace all clinicians with big data, because big data is not big enough.” (ENG3, 54). This refers

back to the statement discussed at the beginning. Although the CDSS provides new infor-

mation through the application of methods that are in part potentially opaque, it is not in-

tended to replace the clinician in his or her power of decision-making, but to support him or

her. How to support them is the subject of the next chapter.

“If you think about it, a patient who is severely disabled afterwards, who suffers a stroke as a result

of this operation, who is maybe in hospital for a very long time, who is very immobile afterwards, per-

haps has a significantly worse quality of life afterwards than before. One can imagine that this is not

only stressful individually, that a patient can participate less in everyday life and that he feels somehow

bad about it. These are measurable factors, so you can somehow assume that. But of course, […] there

are more complications, there are more hospital stays, there are follow-up operations, follow-up stays

in clinics that would be unnecessary. I think it would be obvious at first to say why we think it is better

to plan an intervention with more information.”

6.4. Imaginations of Use, the Scenario behind Them and Its Scripting into

the CDSS

The two sections before have been about the technology itself and the envisioned context of

its application separately. Now it is time to bring them together. This section is about a situa-

tional scenario (Schulz-Schaeffer/Meister 2013). One about the imagined application of the

CDSS and its context of use. This section is also about what role it played in scripting the

form(s) of use of the system. As a reminder, scenarios should tell something about (1) what

parts the future technology is made of, (2) what those parts or components are able to do, (3)

how they perform and (4) how they are connected to each other. This was shown in section

5.4., but there it was not established as a part of a scenario, which is the aim now. Furthermore,

if a scenario is situational in nature, it (5) usually also includes more information about the

envisioned context of its application (Schulz-Schaeffer/Meister 2015: 166). Thus, not only the

components of the technology play a role but also possible users and further elements of the

imagined situation that might be of relevance for the developers. This was also demonstrated

showing assumptions about the cardiologist’s work.

6.4.1. The Dominant Narrative Scenario

It was not possible to find these imaginations of use sufficiently in the literature published by

the developers (except for the vision about the Digital Patient, which remained broad and ab-

stract). This might be due to the assumption made earlier about the nature of situational sce-

narios. Namely, that they are of an implicit, even tacit kind and thus not easy to find explicated

in publications or in other narrative forms like the project’s website. Therefore, the following

analysis relies mainly on verbalisations from the interviews. Although this needs more inter-

pretation work it unveils (a) scenario(s) which played a role among the project members in

scripting the use of the CDSS. After extracting statements that bring to the surface assumptions

about the integration and application of the CDSS, its context of use, they were condensed to

imaginations about the type of relationship(s) between clinicians and the support system.

These imaginations again were combined into a concrete, more complex situational scenario.

This procedure involves a greater degree of pre-interpretation and the presented scenario or

scenarios have never been formulated in this complexity and do not appear in this condensed

form in the project publications. The scenario is supported by statements made by all interview

partners in the course of the respective interviews. They represent rather fewer individual

opinions, but can be considered with sufficient certainty as ideas shared among the develop-

ers. They also reflect assumptions and imaginations of the two sections before. Nevertheless,

there are differences and inconsistencies. At this point, however, only those are mentioned

that are significant, i.e. those that occurred several times but were not necessarily shared by

everyone. Let us now look at the dominant scenario:

The dominant narrative scenario:

The clinical decision support system in CardioSimu is an additional step in the

decision-making and treatment planning process for cardiovascular diseases, after

the process of diagnosing and before the beginning of the treatment. During a clin-

ical consultation the cardiologist is sitting together with the patient in the practice

and after some minutes, because it has to be time efficient in an already time pres-

sured workplace, receives the condensed individual information based on the pa-

tient’s and population data in order to make a decision about the treatment. As

such the clinical decision support system is a module in already existing clinical

imaging systems and can deliver high-level complex information about an indi-

vidual patient within a few minutes. It serves the cardiologists as a condensation,

refreshing and extension of their knowledge, memory and experiences. Based on

their knowledge, the decision support system enriches the information and

knowledge base for medical decision making with more and newly combined clin-

ical information that digitally represents the individual patient for the cardiologist.

The cardiologist can click through five different components: clinical guidelines,

risk scores, case-based reasoning, activity data and model-based simulation of the

individual heart valve. This relieves the individual cardiologist from the manage-

ment of the medical information overload and allows him/her to better concentrate

on the decision-making process. In other words, the system thus guides, helps and

positively influences the cardiologist in his or her decision-making in giving more

and more individual-based information. This means, in the decision-making pro-

cess the former is the deliverer, and the latter is the recipient of information that

may or may not be incorporated into the decision-making process. It is up to the

cardiologist to decide which components are considered helpful. Where the

decision is considered certain, the system provides additional assurance. Where

the decision is considered uncertain, the system helps to find the best decision, as

the heart team traditionally does. But it is never the system that decides, but always

the cardiologist.

6.4.2. The Different Role of the Patient

It has to be said that the developers never carried out a test situation of this scenario. The only

experiment they did was a controlled study about the response of cardiologists to the pre-

sented features of the CDSS prototype making a decision with their help. Therefore, the situa-

tional part of the scenario, or the envisions behind it, was never really reconciled in an actual

testbed (Schulz-Schaeffer/Meister 2013). Thus, the situational scenario can, indeed, be de-

scribed as implicit. It is even unequally distributed among the developers, although basic im-

ages and ideas could be found in every interview. It is the details which matter in this case.

For example, what is excluded from the scenario, because it was highly inconsistent among

the interview partners, was the role of the patient to be treated. This inconsistency can, again,

be drawn along the line of the discipline. Whereas the engineers treat the patient as the subject

matter of the decision-making process, cardiologists assign a more active role to the patient,

both in terms of receiving the information that is central to the decision-making process and

in terms of their own input of and access to the relevant data. Against this background, the

patient consultation has a significant importance. The scenario suggests that the clinician is

consulting the patient to discuss his or her condition based on the information given by the

CDSS. The idea is to type the patient-specific parameters in, which are known by the patient

or performed in the process of diagnoses, and to receive the processed information right away.

This means in particular similar cases to the patient in front of the clinician and the simulation

of the patient’s heart valve as well as, if conducted, information from the activity monitoring.

Therefore, for the engineers it was important to develop the system’s components fast compu-

ting, as this statement exemplifies:

“[I]f you have a situation where a patient presents and you do some imaging

and some work and you make a decision and then they will come back in

three weeks or three days or whatever it is. And then it is possible to run the

very computationally expensive simulations to assist with the decision. But

it is often the case, the patient is with you for one hour or five minutes and

you have to, if you are going to make use of those processes, you have to do

it now. […] So, really you need to think a lot about what your clinical

workflow is and what your timing is. You also need to think a lot about what

level of accuracy is adequate” (ENG1, 26).

As can be deduced from this statement, although the engineering position was taking into

account the specific situation of the cardiological patient consultation and the ideas about the

workflow of the clinician, considered was only the relationship between the doctor and the

CDSS. The physical presence of the patient him or herself was only seen as a variable necessi-

tating the computation of the CDSS to be more time efficient. Other considerable questions are

mainly medicotechnical in nature (for example level of accuracy), which means reflecting the

medical context, but with the lens of their own discipline (Lehoux et al. 2011), what kind of

consequences this has for the development of technical components. The imagined distribu-

tion of roles in the envisioned situation also becomes important. To whom does the system

present the information? Who should be able to read it and how should decisions be made?

Who, above all, is involved in the decision-making? For the cardiologists, it is clear that the

decision is not just made by the clinician but is made together with the patient, because “es-

sentially, as a good clinician, you are supposed to explain to the patient the risks and benefits

of the surgery. So, informing the patient is important. Ultimately, the decision about what

treatment they undertake […], they have to consent for it” (CAR2, 38). So, for the cardiologist

it is important to be able to discuss the results with the patient during the consultation and

make “swift decisions” (CAR2, 50). It is therefore even important that the CDSS is "almost

patient-facing" (CAR2, 50). Not only that, but the possibility of greater direct influence by pa-

tients is also seen as an improvement for the decision-making process. That this was not taken

into account is seen critically: “patient reported measures, patient reported outcomes, we did-

n't really include that in our decision support tool and that might have been more beneficial.”

(CAR2, 38) Here, differences regarding estimations about how the real-world situation looks

like become apparent. Recalling Schulz-Schaeffer and Meister (2019: 51) “practices, under-

standings and beliefs constituting […] social worlds guide their members to view and interpret

certain components and their characteristics differently”. While the engineering perspective is

envisioning the situation as follows: the clinician (and clinician is equated with cardiologist) receives

processed information from the CDSS and assimilates these into his or her own decision-making, the

cardiological point of view is including the patient as an active part into the context of appli-

cation. This can be described as: the clinician (and clinician can mean cardiologist or general sur-

geon), with the help of the patient, types in the information needed and receives the processed

information from the CDSS in order to discuss them and decide over the next treatment steps. What

thus comes into light are differences between disciplines. These differences have to be negoti-

ated between the developers, in the terms of Schulz-Schaeffer and Meister (2019): spokesper-

sons representing the different social worlds, in this case mainly the scientific disciplines of

medicotechnological engineering and cardiology. This negotiation takes place “in the pro-

cesses of building, specifying and evaluating scenarios” and entails “which components and

features will win through and which will have to be adapted” (Schulz-Schaeffer/Meister 2019:

51). In the project discussed here, the cardiological view of a more active involvement of the

patient did not materialise in the prototype, as can be assumed from the interview statements.

Consequently, this position has not prevailed. The vast majority of statements consider the

cardiologist as the sole target user, who only receives the information and carries out intended

manipulations with the displayed material. As already mentioned, the patient basically ap-

pears only as a variable to be taken into account – as the subject of the decision and as part of

the information basis for calculating the Digital Patient, and not as an active part of the imag-

ined situation of decision-making.

6.4.3. Different Envisions about the Clinical User of the CDSS

The same counts for the envisioned clinical user of the CDSS. For the interviewed cardiologists

it is mandatory that the support system is simple to use and its components are easy to com-

prehend. This is also due to the assumption that the target user of the CDSS would not only

be a cardiologist trained in specifics of cardiovascular diseases and open to unconventional

methods, but also, for example, surgeons who are not this familiar with cardiological graphs

and methods or simply cardiologists working in a more traditional way, which according to

the developers view means less catheter-based and more surgical interventions. An example

brought forward is the visualisation of pressure volume loops. Not everyone is equally famil-

iar with them. Clinicians who work with a catheter (which is still a minority) may better be

able to interpret them than those who primarily do surgery and therefore do not pay as much

attention to pressure volume loops. In the case under consideration, it must be noted that the

final product of the project was a prototype and not a product the developers thought of being

ready for implementation. Nevertheless, it appears that not much attention was paid to the

graphical presentation, for example in the pressure volume loop simulation. This was pointed

out by an interview partner of cardiology during the presentation of the prototypical software.

And with reference to the randomised experiment with practising cardiologists, another car-

diology interviewee states that even the simplified version used in the experiment required at

least half an hour to sift through the information in the components and draw conclusions

from them, and that "it can [thus] still take a considerable amount of time in an already time-

pressured workplace" (CAR2, 54). Even though the developers, across disciplines, agreed from

the very beginning that there has to be trust in the system on the part of the clinicians (and, by

the way, the cardiologists also emphasise here that system trust must also be there on the part

of the patients) in order for the CDSS to be used in a way that is beneficial, in the course of the

experiment it became apparent that the respective indication of individual parameters needs

to be explained and displayed more clearly. However, as the project officially came to an end

at that time, no further action was taken.

6.4.4. The Cardiological and the Engineering Sub-scenario

In addition to these variations in the scenario, the interview data contains indications of further

differences. For example, there are some contradictory statements about the general time pres-

sure in cardiovascular work. For example, this work is described by one side as already char-

acterised by time pressure, but by another side as relatively leisurely and in principle without

urgency. Furthermore, there also seem to be different views on who actually inputs the patient

data into the CDSS. This is described by one of the interviewees (a cardiologist) as a situation

in which during the consultation the clinician types the relevant parameters of the patient into

the system in order to have the results available a few minutes later. A divergent view (from

an engineer) of this situation is that the clinician simply receives the information and remains

very passive. The hospital staff is supposed to insert the data (as explained above) before the

consultation.

There are therefore two different sub-scenarios concerning the situation of the use of the CDSS.

They can be characterised as the cardiological and the engineering sub-scenario. Above, the

main part of the engineering perspective is already presented as the dominant scenario. For

purposes of comparison, let us again take a look at the first part of the scenario, which is es-

sential:

The clinical decision support system in CardioSimu is an additional step in the

decision-making and treatment planning process for cardiovascular diseases, after

the process of diagnosing and before the beginning of the treatment. During a

clinical consultation the cardiologist is sitting together with the patient in the prac-

tice and receives the condensed individual information based on the patients and

population data in order to make a decision about the treatment.

What follows is the cardiological sub-scenario that was also envisioned. The changes to the

first sub-scenario are in bold letters:

The clinical decision support system in CardioSimu is an additional step in the

decision-making and treatment planning process for cardiovascular diseases, after

the process of diagnosing and before the beginning of the treatment. During a clin-

ical consultation the clinical decision maker is sitting together with the patient in

the practice and types the patient information into the CDSS. After some

minutes, because it has to be time efficient in an already time pressured work-

place, the condensed individual information based on the patients and population

data is displayed and the clinical decision maker can discuss them with the pa-

tient in order to make a decision about the treatment.

Many components referring to the social context of application apparent in the interviews with

the cardiologists have turned out as not being dominant in the development of the prototype.

A possible explanation could be the more dominant role the engineering of the technology

played in the course of the project. This does not determine less recognition of the medical

specifics – in general there was a high consistency in the statements among the disciplines

regarding the basic idea of what the CDSS should do and how this can be beneficial for the

clinician and the outcome for the patient. The specifics of the disease have been recognised

quite thoroughly. Not so regarding the work context of the clinician. Nevertheless, coming to

a conclusion that during the development the game of negotiation (Schulz-Schaeffer/Meister

2019) was played only in the arena of the engineers would be misleading. Although several

components of the perspectives of the cardiologists got lost in the building of the system, oth-

ers prevailed, first of all the perspective of time pressure, which was the main reason why a

fast computing modelling (physics-based 0D- and 3D-modelling) was chosen. Ultimately,

therefore, it can be said that multidisciplinarity was manifest in the project in the form of par-

tial exchange of knowledge, which has been limited primarily to the specifics of the disease

and to decision-making as a self-contained process. The wider context of the consultation was

considered less important, but seems to be important to the cardiologists involved.

7. Conclusion

What should be concluded after the case analysis? This is done in a three-part step. Firstly,

important findings are summarised. Thereafter, they are discussed regarding the question

how situational scenarios and scripts are connected. In the end, an outlook is given about how

systemically opaque CDSSs (and other medical devices) might change medical decision-mak-

ing and thereby hypothesise that it leads to a work arrangement of collaborative cognitive co-

working between intelligent human and technological actors, a collaboration that is based on

different knowledge-bases.

7.1. Summary

As demonstrated, different versions of the scenario presented above could be deduced from

the interviews. Building the final prototype of the CDSS can be, in line with the concept from

Schulz-Schaeffer and Meister, characterised as an arena of negotiation between representatives

(Lehoux et al. 2011) or spokespersons (Schulz-Schaeffer/Meister 2019) of different disciplines,

mainly cardiology and medicotechnological engineering, about the shape of the scenario, its

components and its situational context. This negotiation took a particular form within the pro-

ject. First of all, knowledge exchange between the engineering and medical members of the

development team, which is strikingly necessary in medicotechnological development, mainly

took place during meetings of the project members. As the development was distributed

among several sites across Europe, working together, physically, was not possible most of the

time. Direct learning from each other was therefore also restricted simply by separation in

space and was thus limited in general. Hence, and secondly, the concrete processes of the de-

velopment of some of the components took place without direct involvement of the cardiolo-

gists, although regular updates and discussions took place in the course of the project.

As already stated in the earlier course of this work, the cardiologists had an ambivalent role

in the project. They spoke for the developer role as well as for the user role. They were both

advocates of change and interested in preserving existing components of the application situ-

ation (Schulz-Schaeffer 2019). The engineers were not completely indifferent to this, they saw

a need in basing the system on cardiologist’s knowledge in order to make it work and to build

up trust in the system’s operation. But the cardiologists had a specific personal interest in

maintaining certain routines, whereas the engineers were mainly advocating the new compo-

nents of the CDSS (in the interviews mainly the modelling and simulation). This reflects the

tension between experts and engineers in medical technology development mentioned by

Weingarten (1998: 182). As stated, it was not possible to counteract this tension sufficiently

due to spatial and institutional separation. In the end, as apparent in the interviews and visible

in the prototype, it was more the engineer’s perspective about the application context that was

implemented, especially regarding the patient’s role during consultation. Consequently, it was

the cardiologists who took a more (self-)critical perspective on the developed prototype and

the development process.

7.2. Discussion

Through knowledge exchange, discussions and most notably through building the prototype,

not only images about the technical specifications of the CDSS, its performance and the inter-

relation of its components have been inscribed into the technology, but also potential users

and the use context were inscribed into the CDSS (Akrich 1992). Most of the time the users and

the characteristics of the possible use context were not represented by actual users and con-

texts. They were represented by parts of the development team who also acted as competent

users by themselves (Schulz-Schaeffer 2019: 50) informed by own everyday experiences and

assumptions whereas both were also influenced by preferences from past projects and pre-

ferred technical concepts, like physics-based modelling and case-based reasoning

(Hyysalo/Johnson: 83). The inscription did not happen in a determined and straightforward

way but in negotiating the components of the scenarios between spokespersons of different

disciplines. These practices of negotiating the scenario’s components served as a guide for the

actual development of the prototype’s scripts.

But the dominant scenario has not been the only possible socio-technical arrangement in-

scribed into and fixed in the technology. Instead, more than one scenario or different versions

of a scenario have been present during the project and have been under negotiation. So, the

development team was guided by partly disparate scenarios about who the target user is, how

the technology should be used, what it should do, how it should look like and how all this is

to be achieved best. Accordingly, the building of the prototype and the negotiation about the

scenario’s components co-evolved, leading to scripts influencing the (envisioned) user to use

the technology in certain ways. With Gläser et al. (2017: 14) it can be stated that there will likely

be more than one script inscribed into a technology. This can only be assumed for this case,

since the developed system could not be studied in use. However, it is very likely to be the

case here as well, since a negotiation process on (components of) scenarios, as in this case,

unlikely reaches a final conclusion. Therefore, it would be wrong to assume only one scenario

and therefore one script inscribed into the CDSS, although one dominant scenario is present

in the finalised prototype.

As Akrich and others point out, an object’s script is nothing pre-fixed, but also a co-construct-

ing of inscription and description. The CDSS prototype is defining “a framework of action

together with the actors and the space in which they are supposed to act” (Akrich 1992: 208) –

the framework that was apparent as an implicit, even tacit, scenario in the course of develop-

ment. Within this framework actions of de-scription or re-interpretation by users are likely

possible. Whereas the developers inscribe their imaginations into the object it is in turn the

users who are de-scribing the script of the object in its actual use environment. For example, a

cardiologist might develop an antiprogram (Oudshoorn/Pinch 2003: 11) and is still be able to

decide explaining the figures and graphs displayed on the CDSS to the patient during consul-

tation, even though the patient was not expected to have a significant role during decision-

making. The technology containing the scenario might offer this freedom. However, it be-

comes more difficult if the measurements and graphical presentations displayed are challeng-

ing or at least very unfamiliar for the treating cardiologist (or even when it is a surgeon). The

given framework is derived from the scenario in which a well-informed cardiologist aware of

for example pressure volume loops is envisioned. Therefore, just loose explanation and a more

technical graph is included. The scenario’s component of the well-informed cardiologist in-

scribed into the system could likely be too narrow for the treating clinician. Instead of finding

a workaround or a different way of use, non-usage or rejection (Akrich 1992: 208) could be a

possible consequence.

Therefore, the following can be stated. The concept of situational scenarios has proven to be

helpful in describing and explaining how scripts arise or where assumptions about the internal

interdependency of a technology and its embedding in social situations of application come

from. With this concept it is possible to understand in detail which assumptions have played

a role in the development, have combined to form a scenario and how this process was co-

evolutionarily negotiated between multidisciplinary parties during the construction of a tech-

nology.

It was also able to show that this process can also be found in medical technology develop-

ment, although in my case study it became clear that scenarios are sometimes more difficult

to identify because they are implied or only present tacitly. In contexts like these, a lot of in-

terpretation work is needed. Critical reflection is also needed on the fact that the data sources,

publications and above all interviews, are retrospective sources, this work is dependent on

narratives. However, elaborating implicit or tacit scenarios may well be more successful if pro-

cess data can be collected, if the project can be followed while the technology is being built.

Thus, a lot of effort had to be made to work out leading scenarios, based on post-reflective

statements of the interview partners, which might not have been presented in this form in

earlier stages of development, but were also shaped by experiences and knowledge exchange

during the project. Furthermore, the concrete influence of the regulatory environment on the

scenarios could not be taken into account in the intended notoriety, as it did not play a direct

role in the project, but nevertheless the circumstance that there is a lack in the regulations of

medical devices like Data-driven Clinical Decision Support Systems was reflected upon, and

interview statements suggest that it has always played a background role during develop-

ment, although not taken into account directly.

In order to be able to work this out more clearly for the area of medical technology develop-

ment, following research should focus empirically on development processes that would fol-

low the situation considered here, namely the further development of the project-based pro-

totype into a medical device. Further interesting questions would arise in this context. What

influence do scripts written into the prototype have on the further development? Which actors

play a role in market-oriented development? Here, one would therefore consider another stage

of development. The experimental phase would be left behind and the real world would be

more present. As a follow-up of this work, this would be of great value.

7.3. Outlook

To give a final outlook, it is important to point out the following: Medico-historically seen,

medical reasoning became an interplay between medical knowledge a physician develops

over time, based on the experiences a physician makes throughout a carrier and on intershar-

ing knowledge with colleagues (experience-based knowledge) and medical knowledge that is

mainly based on established medical evidence, rules and guidelines, the ones that feed the

knowledge-based CDSSs (rule- or evidence-based knowledge). Over the last centuries there has

been a development towards an increased relevance of the latter, and this to the chagrin of the

former. However, with the appearance of data-driven CDSSs classical evidence- and

experience-based medical knowledge is getting company by a third way of creating

knowledge. Experience-based knowledge can be located at the level of the individual physi-

cian and maybe also at the level of the direct collegial environment (the heart team) and evi-

dence-based knowledge can be seen as standardisation of medical knowledge applying strictly

scientific methods. Both are comprehensible to humans. Knowledge generated intelligently by

machines is opaque to humans in the process of its generation. It is not completely transparent

and cannot be verified by the physician. He or she just sees the output and might know the

whole input, but even that is not necessarily the case. The knowledge base of the early expert

systems was the same as the knowledge base of the physician, so the traceability of the deci-

sion-making process of the CDSS was much easier for the physician, what, in principle, also

increased the level of trust in the systems reasoning. What came along even with these earlier

versions was a change of the “thinking styles” in medicine, its perceptual apparatus and its

criteria of reality (Wagner 1998a: 125). But the new systems are (partly) operating on a different

base, so for the physician the systems reasoning is not as traceable as before. This makes it,

generally speaking, more difficult to develop trust in the systems operation (e.g. Gretton 2018).

Whether this new form could be characterised as a resurface of experience-based medical

knowledge in a new, technical form remains to be seen. But nevertheless, this new way of

generating knowledge might, again, reshape how medical reasoning and decision-making is

done in practice. How the developers and manufacturers of those systems build these becomes

therefore a central role.

Therefore, it is very likely that not only the ways of reasoning and decision-making of the

medical staff would change but that the whole sociotechnical constellation of medical diagno-

sis and/or treatment will undergo or is already undergoing changes as well. As the degree of

autonomy of the supporting system rises as well as the produced knowledge is different the

whole medicotechnological arrangement of planning a therapy or deciding over a treatment –

for example deciding over a therapy of a patient with a heart valve disease – might become

more a character of collaborative cognitive co-working between human and technical actors. This

was partly reflected by the interview partners but remained on rather general comments on

risks and benefits of artificially intelligent and simulation-based methods in medical work-

places. As this already is and going to be much more relevant in the near future, it is necessary

to conduct more critical and social scientific research in this area.

Bibliography

Akrich, M. (1992). The De-Scription of Technical Objects. In Shaping Technology/Building Soci-

ety: Studies in Sociotechnical Change (pp. 205-224). MIT Press.

Berner, E. S., & La Lande, T. J. (2016). Overview of clinical decision support systems. In Clinical

decision support systems (pp. 1-17). Springer.

Carroll, N., & Richardson, I. (2016). Software-as-a-Medical Device: demystifying Connected

Health regulations. Journal of Systems and Information Technology, 18(2), 186-215.

Clarke, A. E., & Star, S. L. (2008). The social worlds framework: A theory/methods package. In

The handbook of science and technology studies. Third edition (pp. 113-137). MIT Press.

Faulkner, A. (2009). Medical technology into healthcare and society: A sociology of devices, innovation

and governance. Palgrave Macmillan.

FDA, U. (2019). Proposed regulatory framework for modifications to artificial intelligence/ma-

chine learning (AI/ML)-based software as a medical device (SaMD).

Glaser, B. G., & Strauss, A. L. (1967). Grounded Theory. Von der Methodologie zur Forschungspra-

xis. Weinheim/Basel.

Gretton, C. (2018). Trust and Transparency in Machine Learning-Based Clinical Decision Sup-

port. In Human and Machine Learning (pp. 279-292). Springer.

Holmes, D. R., Rich, J. B., Zoghbi, W. A., & Mack, M. J. (2013). The heart team of cardiovascular

care. Journal of the American College of Cardiology, 61(9), 903-907.

Hyysalo, S., & Johnson, M. (2016). User representation: A journey towards conceptual matu-

ration. In The new production of users: changing innovation collectives and involvement strategies

(pp. 75-100). Routledge.

Hyysalo, S., Jensen, T. E., & Oudshoorn, N. (Eds.). (2016). The new production of users: changing

innovation collectives and involvement strategies. Routledge.

Jarzabkowski, P. & Pinch, T. (2013). Sociomateriality is ‘the New Black’. Accomplishing repur-

posing, reinscripting and repairing in context. M@n@gement 16(5), 579-592.

Lehoux, P., Hivon, M., Williams-Jones, B., & Urbach, D. (2011). The worlds and modalities of

engagement of design participants: A qualitative case study of three medical innovations. De-

sign Studies, 32(4), 313-332.

Mayring P., & Fenzl T. (2019). Qualitative Inhaltsanalyse. In Handbuch Methoden der empirischen

Sozialforschung (pp. 633-648). Springer VS.

Mort, M., Goodwin, D., Smith, A. F., & Pope, C. (2005). Safe asleep? Human–machine relations

in medical practice. Social Science & Medicine, 61(9), 2027-2037.

Oudshoorn, N. E., & Pinch, T. (2003). Introduction: How users and non-users matter. In How

users matter: The co-construction of users and technologies (pp. 1-25). MIT Press.

Ozaydin, B., Hardin, J. M., & Chhieng, D. C. (2016). Data mining and clinical decision support

systems. In Clinical Decision Support Systems (pp. 45-68). Springer.

Petersen, A. (2019). Digital Health and Technological Promise: A Sociological Inquiry. Routledge.

Pinch, T. J., & Bijker, W. E. (1984). The social construction of facts and artefacts: Or how the

sociology of science and the sociology of technology might benefit each other. Social studies of

science, 14(3), 399-441.

Rammert, W. (1998a). Was sind Expertensysteme? Maschinen, Medien und Mittel der Macht.

In Wissensmaschinen. Soziale Konstruktion eines technischen Mediums. Das Beispiel Expertensysteme

(pp. 15-25). Campus.

Rammert, W. (1998b). Resümee und Ausblick: Von der Funktion zum Funktionieren. In Wis-

sensmaschinen. Soziale Konstruktion eines technischen Mediums. Das Beispiel Expertensysteme (pp.

248-265). Campus.

Rammert, W., Schlese, M., Wagner, G., Wehner, J., & Weingarten, R. (1998). Wissensmaschinen.

Soziale Konstruktion eines technischen Mediums. Das Beispiel Expertensysteme. Campus.

Roland Berger Focus (2019). Future of Health. Eine Branche digitalisiert sich – radikaler als erwartet.

Roland Berger GmbH.

Schulz-Schaeffer, I., & Meister, M. (2013). Scenarios as patterns of orientation in technology devel-

opment and technology assessment. Outline of a research program. STI-Studies.

Schulz-Schaeffer, I., & Meister, M. (2015). How situational scenarios guide technology devel-

opment: some insights from research on ubiquitous computing. In Practices of Innovation and

Responsibility. Insights from Methods, Governance and Action. Studies of New and Emerging Tech-

nologies, (pp. 165-179).

Schulz-Schaeffer, I., & Meister, M. (2017). Laboratory settings as built anticipations: prototype

scenarios as negotiation arenas between the present and imagined futures. Journal of Responsi-

ble Innovation, 4(2), 197-216.

Schulz-Schaeffer, I., & Meister, M. (2019). Prototype scenarios as negotiation arenas between

the present and imagined futures. Representation and negotiation power in constructing new

socio-technical configurations. In Socio-Technical Futures Shaping the Present (pp. 37-65).

Springer VS.

Spooner, S. A. (2016). Mathematical foundations of decision support systems. In Clinical Deci-

sion Support Systems (pp. 19-43). Springer.

Strauss, A. L. (1993). Continual permutations of action. De Gruyter.

Strauss, A. L., Corbin, J. M., Niewiarra, S., & Legewie, H. (1996). Grounded theory: Grundlagen

qualitativer Sozialforschung. Psychologie-Verlag-Union.

Steinmüller, K. (2003). Szenarien. Instrumente für Innovation und Strategiebildung. Z_punkt

GmbH, www.conspect.de/jonas/PDF/SzenarioWS_Reader_2003.pdf.

The Berlin Script Collective (2017). Comparing scripts and scripting comparisons: toward a system-

atic analysis of technologically mediated influence. TUTS Working Papers.

Wagner, G. (1998). Die Verfertigung des Wissens: Die Konstruktion der Maschinen im prakti-

schen Umgang. In Wissensmaschinen. Soziale Konstruktion eines technischen Mediums. Das Beispiel

Expertensysteme (pp. 85-128). Campus.

Weingarten, R. (1998). Die Aushandlung von Praktiken: Kommunikation zwischen Fachex-

perten und Medieningenieuren. In Wissensmaschinen. Soziale Konstruktion eines technischen Me-

diums. Das Beispiel Expertensysteme (pp. 129-188). Campus.

Woolgar, S. (1991). Configuring the user: the case of usability trials. The Sociological Review,

38(1), 58-99.