Data Frictions in Medical AI Development and Implementation
Completed research paper, SCIS 2026 (Varmaland, Iceland)
The implementation of AI in hospital settings remains limited, with data-related challenges being a major barrier. This paper examines these challenges as ‘frictions’ between data-dependent AI technologies and the existing sociotechnical installed base of healthcare, investigating how they shape AI development and implementation in Norwegian public hospitals. Based on interviews with experts in the Norwegian healthcare sector, our findings reveal frictions in three areas: in generating data, ensuring its quality, and putting it to use. We argue that these frictions stem from a fundamental mismatch between care-driven healthcare arrangements and the computation-driven requirements of AI, and discuss how they shape efforts to bring AI into hospitals. We contribute a data-centric perspective on these challenges, showing how they are rooted in the underlying logics of the sociotechnical installed base of healthcare.
AI, Healthcare, Data, Frictions, Installed Base
In het kort
Dit artikel richt zich op de rol van data bij het ontwikkelen en invoeren van AI in Noorse ziekenhuizen. AI verschilt van andere medische technologie doordat het zijn functionaliteit uit data haalt. Ziekenhuisdata is echter geproduceerd voor patiëntenzorg, niet voor rekenwerk. Op basis van kwalitatieve interviews met experts uit de Noorse gezondheidszorg, veelal ontwikkelaars, projectleiders en clinici in AI-projecten, beschrijven we de fricties die ontstaan waar de datavereisten van AI botsen met de bestaande zorgpraktijk, verdeeld over drie gebieden.
Data genereren. De hoeveelheid data wordt bepaald door patiëntenstromen en door hoe vaak een aandoening voorkomt. Voor hersenbloedingen duurt het maanden om honderd gevallen te verzamelen. Datasets zijn bovendien scheef: één project had 75.000 ECG’s van gezonde mensen en maar enkele duizenden van zieke. Toegang tot data is volgens de informanten de belangrijkste drempel. Verschillende instanties geven tegenstrijdige antwoorden, functionarissen gegevensbescherming leggen regels verschillend uit, en ziekenhuisdata, registers en onderzoeksdata vallen elk onder eigen wetgeving. Sommige onderzoekers vermijden Noorse data daarom helemaal.
Datakwaliteit. Clinici moeten data handmatig annoteren, in één project zo’n 3.000 casussen. Vaak is er maar één annotator, zodat de kwaliteit niet te controleren is. Klinische kennis is bovendien contextueel: twee radiologen beoordelen dezelfde scan in tien procent van de gevallen anders, en zelfs “hartinfarct” moest door een cardioloog opnieuw worden gedefinieerd op een manier die voor AI bruikbaar is. Daarnaast zijn modellen gevoelig voor verschillen in apparatuur en protocollen. Een Amerikaans model voor beroertedetectie faalde op Noorse scans vanwege de lagere stralingsdosis, en metalen implantaten worden soms als bloeding aangemerkt.
Data gebruiken. Ook gekochte, gecertificeerde AI moet lokaal gevalideerd en bijgesteld worden. De keuze tussen zelf bouwen en kopen vervaagt daardoor. Ziekenhuizen hebben eigen ontwikkelexpertise nodig om commerciële producten te kunnen beoordelen, en eigen modellen kunnen, anders dan statische commerciële producten, steeds verder verbeterd worden. Multimodale AI die beelden, dossiers, labwaarden en genomische data combineert, wordt gezien als de volgende stap, maar de ziekenhuissystemen zijn silo’s die niet met elkaar praten. De vaak genoemde Noorse datarijkdom staat ver af van de werkelijkheid van het koppelen van bronnen.
De kern van de discussie is dat de installed base niet “verouderd” of “gebrekkig” is. Gescande papieren ECG’s, strenge toegangsregels, silo’s en variërende protocollen dienden en dienen de zorg goed. Pas de datavereisten van AI maken ze achteraf tot een probleem. De fricties komen voort uit een mismatch tussen een zorglogica en een rekenlogica, en zijn daarom hardnekkig. Opvallend is dat de fricties vooral tot aanpassingen leiden (handmatig annoteren, lokale validatie, eigen datapijplijnen) en niet tot verandering van de onderliggende structuren, terwijl de literatuur over fricties die transformerende werking wel suggereert. Waarom dat zo is, blijft open: mogelijk door de traagheid van de installed base, mogelijk omdat zulke effecten meer tijd nodig hebben dan deze studie beslaat. Vervolgonderzoek bestaat uit casestudies van twee AI-projecten in 2026, over hersenbloedingen en een acuut hartinfarct, om te zien hoe deze fricties in de praktijk worden gehanteerd en onder welke omstandigheden ze wel tot transformatie kunnen leiden.
1 Introduction
AI technologies are expected to address many current societal challenges, with healthcare being a prominent area of focus. AI holds considerable promise in multiple aspects of healthcare, from automating tasks to supporting clinical decisions and improving diagnostic outcomes (Kaul et al., 2020). The most profound developments within medical AI are currently based on Machine Learning (ML) and Deep Learning (DL) for image analysis, positioning fields like radiology and pathology at the forefront of these developments (Rajpurkar et al., 2022, p. 31; Wang et al., 2019, p. 293). However, despite these expectations, the implementation of AI into real-world hospital settings remains limited and in its early stages (Aristidou et al., 2022).
This implementation gap is often attributed to a range of challenges including inadequate organisational governance of AI systems (Kim et al., 2023), shortcomings in AI evaluation frameworks (Wells et al., 2025), concerns for data security and privacy (Khan et al., 2025), mismatches between expectations and actual outcomes (Kannelønning, 2024), and the role of the pre-existing sociotechnical environment (Soetens et al., 2025, 2026). Studies also show that challenges related to data are particularly prominent (e.g., Sun & Medaglia, 2019; Aung et al., 2021). Data are central to AI technologies: unlike traditional medical technologies, AI systems derive their very functionality from data, making their development and deployment dependent on the availability, quality, and governance of vast datasets. In hospitals, this data is typically stored across siloed information systems in separate, specialised systems serving distinct clinical departments and purposes, which adds complexity to data integration and reuse for AI. This study builds upon these previous insights by specifically investigating data issues that arise in the work of developing AI tools and bringing them into hospital settings.
In this paper, we make use of the analytical concept of ‘frictions’ to examine the specific points of tension at the intersection of data-dependent AI and the healthcare installed base. The sociotechnical installed base perspective helps to analyse how the pre-existing environment of technologies, work practices, and regulations can both enable and constrain innovation (Aanestad et al., 2017). Based on this, we address the following research question:
How do data-related frictions between novel AI technologies and the existing sociotechnical installed base shape the development and implementation of AI in hospitals?
To answer this question, we conducted an interview-based study with experts in the Norwegian healthcare sector, most of whom are directly involved in medical AI projects, alongside others working in governance, project management, or policy roles. Our findings show that data-related frictions arise at multiple points where AI’s data requirements encounter established healthcare arrangements: in generating data, ensuring its quality, and putting it to use.
This paper contributes to the literature on AI development and implementation in healthcare by offering a detailed, data-centric perspective on the challenges, showing how the data practices, governance structures, and technical infrastructure of healthcare, built for clinical care rather than computational reuse, produce persistent tensions when confronted with AI’s data requirements. The paper is structured as follows: first, we position our paper in relation to the critical perspective on data in IS research. Then we describe our conceptual framing focused on the concepts of sociotechnical installed base and frictions, followed by our research methodology. Finally, we present our findings, followed by a discussion of their implications, and we identify directions for future research.
2 Literature on Data and AI
Recent research has problematised the data-dependent nature of AI, pointing out that while AI cannot be effectively trained, evaluated, and meaningfully deployed without data, data are not commodities, available and ready for use. Seminal work has shown that data are both dependent on their context of production (Berg & Goorman, 1999) and embedded in social and organisational contexts (Bowker & Star, 1999). More recently, Gitelman (2013) argued against the naturalness of data: data is never ‘raw’ but always the product of disciplinary practices. This also implies that data is frail (Gitelman, 2013) because they require constant work. As argued by Ribes and Jackson (2013) “data are ephemeral creatures that threaten to become corrupted, lost or meaningless if not properly cared for” (p.147). Attending to and caring for data entails recognising that data practices are not just technical but grounded in social meaning and embed values and assumptions that originate in human practices (Dourish & Gómez Cruz, 2018).
In addition, data shape, and are shaped by, the larger sociotechnical context they are part of. For instance, Leonelli (2016) shows that the meaning of data and their evidential value are not intrinsic to the data themselves and are not predetermined. Rather, they depend on local practices through which they are generated, processed, packaged, and used. Edwards (2010) also shows that what counts as evidence (data), in his study on weather data, is shaped by data infrastructures. The practices and infrastructures through which data are handled are constitutive of the quality, reliability, and scope of the knowledge that is produced from and through them. These practices for data collection, storage, sharing, or deletion are not incidental but shape which analyses can be performed, their results, and which claims can be made (Edwards, 2010).
In IS research, this critical take on data, their role, value, and practices, has received attention (e.g., Aaltonen et al., 2023). Researchers have for instance questioned and investigated the nature of data arguing for understanding data as digital objects with material and organisational properties and as semiotic artefacts (Alaimo & Kallinikos, 2022), and as infrastructures of knowing (Monteiro & Parmiggiani, 2019). Jones argues for the importance of examining how data come into being, and the selective character of the representations they provide (Jones, 2019). This argument foregrounds the political character of data and data practices: the selection and processing of data are not neutral but intentional, value-laden practices. In addition, what becomes represented reflects those aspects of phenomena that lend themselves to datafication, while other dimensions remain overlooked and neglected (Jones, 2019). Data practices involve continual negotiation of standards, quality, and meaning, as well as the work of crafting, curating, massaging, and cleaning data (Parmiggiani et al., 2022; Monteiro & Parmiggiani, 2019). In healthcare specifically, data practices enable new forms of work (Grisot et al., 2019) while also triggering tensions constitutive of how data become actionable (Pedersen, 2025).
This research shows that while data are essential for AI, they are also a complex resource that cannot be ‘simply’ generated and made available to AI tools when these are implemented and deployed in organisational contexts. Instead, they emerge from situated practices of collection, classification, and curation, are entangled with legacy systems and heterogeneous infrastructures, and are shaped by institutional constraints, governance arrangements, and professional norms. As a result, securing ‘appropriate’ data for AI involves extensive work—negotiating access, reconciling formats, addressing quality issues, and managing ethical and legal concerns—which has implications for AI implementation. Our aim in this paper is to contribute to this line of research by examining further how the contextual nature of data and the data-dependent character of AI technologies impact on, and shape, their implementation. Specifically, we focus on the ways in which the data-dependent nature of AI clashes with established organisational and work practices and sociotechnical infrastructures. With this aim, we suggest understanding these ‘clashes’ as frictions, as presented in the next theory section.
3 Theory: Sociotechnical Installed Base and Frictions
To understand the data-related complexities of developing and implementing AI in hospitals, we use the concept of the sociotechnical installed base (Aanestad et al., 2017). As a central concept in the Information Infrastructure perspective (e.g., Hanseth & Lyytinen, 2010; Grisot et al., 2014; Grisot & Vassilakopoulou, 2017), it focuses on how pre-existing work practices, technologies, and regulations can simultaneously enable and constrain digital innovation. This perspective may reveal inertia that is inherent in change processes, but could also uncover opportunities for transformation (Aanestad et al., 2017).
The installed base represents “all that there is” (Aanestad et al., 2017, p. 28). Basically, it is the combination of existing tools, routines, divisions of labour, and regulatory frameworks. It includes not only IT capabilities and their user communities (Hanseth & Lyytinen, 2010), but also institutional and organisational structures (Lanzara, 2014). From this viewpoint, infrastructures are not built from scratch, they evolve over time. As Star and Ruhleder (1996, p. 113) state, “infrastructure does not grow de novo, it wrestles with the inertia of the installed base and inherits strengths and limitations from that base”. This ‘evolutionary’ dynamic means that any innovation, such as new AI systems, must simultaneously fit into and transform the existing sociotechnical arrangements.
To analyse the encounter between novel AI technologies and the installed base, we use the concept of ‘frictions’. In innovation studies, friction is often seen as the resistance that emerges when a new technology meets established arrangements that are ‘cemented’ together, making change difficult (Håkansson & Waluszewski, 2011; Hoholm & Olsen, 2012). Håkansson and Waluszewski (2011, pp. 176–177) define it as the force that arises at the interface of interacting resources, acting as “both a stabilizer and a de-stabilizer”. This resistance is relational, as it appears when a force is applied between surfaces; it is time-dependent, as its effects may vary over time; and lastly, it is transformative, as it ‘reshapes’ the interacting elements (Håkansson & Waluszewski, 2011). This dual nature of friction (simultaneously resisting and enabling change) is central to understanding innovation processes (Nowotny, 1993; Hoholm & Olsen, 2012).
This dual nature means that while friction is often seen as a negative force to be overcome, its absence is not necessarily ideal. The pursuit of perfectly ‘frictionless’ processes can lead to overly rigid systems that lack the ability to adapt to unexpected events (Márton, 2026; Biggs et al., 2012). In this sense, some friction may be productive; it can build resilience by slowing down processes, encourage reflection, and create space for learning and adaptation (Biggs et al., 2012; Laamanen & Mikołajewska-Zając, 2024). Friction can then be ‘generative’ meaning that it can be transformative (i.e. the opposite of adaptive), and also de-stabilising (i.e. the opposite of preserving the status quo). In this paper, we understand generative frictions as those producing changes that go beyond the workarounds and adaptations needed to make AI fit within existing arrangements. Whether frictions actually become generative in this sense, or remain mostly constraining, depends on the nature of the encounter between the installed base and the new technology.
In this study, we use the concept of friction to analyse the encounter between novel AI technologies, with their specific relation to data, and the sociotechnical installed base, including the established healthcare practices and systems designed for clinical care rather than computational reuse. This allows us to examine not only where data-related frictions arise, but also why they tend to persist and what kinds of responses they elicit in practice.
4 Research Methodology
Our research uses a qualitative, interview-based design. The findings presented here are derived from 18 semi-structured interviews conducted with 14 experts from the Norwegian healthcare sector between 2024 and 2025. One of these interviews was a paired interview involving two informants at the same time. Informants were purposefully selected based on their expertise and direct experience with AI initiatives in Norwegian hospitals. Most informants were directly involved in medical AI projects (as developers, project leads, or clinical collaborators), while others held governance, policy, or consultancy roles relevant to AI in healthcare. While informants represent various positions across the entire sector, most are affiliated with two major public hospitals in the South-East Region of Norway. Initial contact was made through direct outreach, and additional informants were recruited via snowball sampling. Two of the informants were in key management positions where they supervised a wide range of AI initiatives at large hospitals, which is why these informants were interviewed more than once across the data collection period. An overview of the informants and their roles is displayed in Table 1. Given this composition, our empirical material is currently most informative about frictions that arise in the work of developing AI tools and bringing them into hospitals, rather than frictions that emerge once AI tools are in routine clinical use.
| Informant ID | Role in the healthcare sector |
|---|---|
| #01 | Relevant management function at a Regional Health Authority |
| #02 | Part of the deployment team at a procurement project |
| #03 | Involved with research and development of several projects |
| #04 | Working in certification and classification of medical AI |
| #05 | Involved with research, development and procurement projects |
| #06 | Part of the deployment team at a procurement project |
| #07 | Manager of AI projects at a major hospital |
| #08 | Working for the Norwegian government on medical AI |
| #09 | Manager of AI projects at a major hospital |
| #10 | Developer in several medical AI projects at a major hospital |
| #11 | Developer in several medical AI projects at a major hospital |
| #12 | Developer in several medical AI projects at two hospitals |
| #13 | Radiologist involved with several AI projects at a major hospital |
| #14 | Radiologist involved with several AI projects at a major hospital |
We used semi-structured interview guides to ensure consistency while also allowing for flexibility. The interviews covered the informants’ professional backgrounds, their roles in the various AI projects, their experiences with these projects, and their perspectives on current strategies and potential improvements. Each interview lasted approximately one hour and was conducted either online or in-person, according to the informant’s preference. Ethical standards were followed, and the study received approval from The Norwegian Agency for Shared Services in Education and Research (SIKT)1. Prior to their participation, all informants were briefed on the study’s purpose and how we handle the data and gave their written informed consent. To safeguard privacy, we anonymised all collected data by removing or modifying any personal identifiers, ensuring confidentiality without affecting the data’s integrity.
With the informants’ consent, all interviews were audio-recorded and transcribed. For the analysis, the first author used a thematic analysis approach to systematically identify and code recurring patterns across the interview data. This process was guided by the six-step method proposed by Braun and Clarke (2006, pp. 86–93), which involves an initial phase of getting familiarised with the data, then generating initial codes, searching for broader themes, reviewing and defining those themes, and finally, producing the analysis. This structured process provided us with a systematic identification of key themes. Figure 1 illustrates the thematic analysis process, showing how selected data excerpts were grouped into first-order codes, which were then aggregated into broader second-order themes.
In line with the interpretive research tradition (Walsham, 2006), our goal was to develop a deep understanding of the informants’ perspectives on AI development and implementation, using the concept of frictions as our main analytical lens. We identified frictions in the empirical material as moments where AI’s data requirements encountered established healthcare practices, infrastructures, or governance arrangements, producing observable resistance, workaround, or adaptation.
5 Findings
Our findings on data-related frictions are structured into three themes, each describing how care-driven healthcare arrangements encounter the computation-driven requirements of AI: in generating data, ensuring its quality, and putting it to use.
5.1 Frictions in Generating Data
This first theme covers the process of obtaining data for AI development, from its initial creation to getting access to it. Informants describe this as the foundation of any medical AI initiative. Two main frictions emerged: the availability of sufficient and appropriate data, and the governance structures that control access to it.
5.1.1 Data scarcity and imbalance vs. AI’s high-volume data requirement
A major friction highlighted by informants concerns the availability of data for AI development. AI models require large datasets to learn patterns and make accurate predictions, but in healthcare, data is generated through clinical care, meaning its volume and composition are determined by patient flows and disease incidence rates. For less common conditions, this creates a natural bottleneck. As one developer working on cerebral haemorrhage detection explained: “in Norway [...] there’s not so many patients [...] so we need to wait one month or two months, maybe half a year, to collect like 100 cases” (#10). Similarly, another informant noted that “one of the biggest problems in healthcare is the amount of data. It’s usually quite low” (#11).
Besides scarcity, clinical data can also be skewed in ways that are problematic for AI training. One developer described working with approximately 75,000 ECGs from healthy patients but only “two or three thousand ECGs from actually sick people [...] so we have a really skewed dataset” (#12). While a hospital naturally sees more healthy patients than critically ill ones, this imbalance is not problematic for clinical care but poses a challenge for training AI models that need to be able to reliably detect rare conditions. Also, several informants noted that commercial developers with access to larger, sometimes international datasets, have an advantage over in-house projects working within the limits of their local patient populations (#8, #10).
5.1.2 Restricted data access vs. AI’s need for streamlined access
Even when there is sufficient data, gaining access to it is consistently described as a significant barrier. As one informant stated: “the main barrier is and has always been access to data [...] that has to be streamlined” (#5). Navigating governance frameworks that involve multiple regulatory bodies is challenging, each with their own purposes and procedures. One informant described the confusion this creates: projects could “pose questions to one directorate, and then they answered something [...] and then they asked another [...] and then they said something else. It was very confusing” (#8).
This is further complicated by inconsistent interpretation of rules across institutions. As one informant pointed out: “different data protection officers interpret the rules in different manners” (#5). Furthermore, different types of data fall under different legal frameworks; hospital data, health registries, and research data are all governed by separate regulations (#9). Several informants expressed a need for national-level standardisation of data access procedures, arguing that this would significantly enable AI development. As one informant put it, “I actually know researchers who don’t want to use Norwegian data in their research because they have so many bad experiences with the process of getting access to healthcare data” (#5).
5.2 Frictions in Ensuring Data Quality
Once data is accessed, it is not immediately ready for use. This second theme concerns the extensive work required to make clinical data suitable for AI training. Informants described this process as a significant friction, involving manual labour to establish a reliable ‘ground truth’ and to address compatibility issues between data from different sources.
5.2.1 Contextual interpretation vs. AI’s need for categorical labels
Before data can be used for AI training, clinicians have to manually annotate it, which refers to the process of labelling the conditions that the model should learn to identify. Informants described this as the most labour-intensive part of the AI development pipeline. As one developer put it, “the whole job is actually to make those labels right” (#12). The scale of this work is considerable, as one project involved re-labelling approximately 3,000 patient cases to ensure better accuracy (#12). Ideally, multiple clinicians annotate the same data to verify accuracy, but resource constraints mean this is not always feasible. As one informant put it: “sometimes it’s only one annotation, so we cannot verify the annotation quality” (#10).
This challenge also goes beyond labour. Establishing a reliable ground truth can be a complex challenge (Lebovitz et al., 2021), which is further complicated by the fact that clinical interpretation is not always unambiguous. Two radiologists annotating the same CT scan may produce labels that are “90 percent the same, but 10 percent different [...] one doctor said there is no bleed, another said there is a bleed” (#10). More fundamentally, translating clinical knowledge into defined categories suitable for AI can be a major challenge in itself. As one informant working on acute myocardial infarction detection stated: “I thought you’d know if someone has a heart attack or not, [...] but it’s not that simple” (#9). Their project required a cardiologist to work on defining heart attacks “in a way that it’s applicable for AI” (#9). Clinical conditions are understood through contextual and often narrative knowledge, and do not always map neatly into the distinct categories that AI models require.
5.2.2 Equipment and protocol variation vs. AI’s need for data consistency
Even when data is annotated, inconsistencies in how it was originally produced can make it problematic for AI development. For example, medical imaging protocols can vary between hospitals and even between machines within the same hospital. AI models are sensitive to these variations. One informant described how an American commercial stroke detection tool failed on Norwegian data because Norwegian protocols use lower radiation doses: “we use a much lower dose than what these models were trained on [...] and it just performed really badly. And that was like a shock to this American company because they’d never seen data like this before” (#7).
This problem goes beyond imaging protocols. Informants described other sources of variability that affect AI performance, such as differences in image intensity (#13), differences between machines of different manufacturers or ages (#9, #11), or patient movement or metal implants introducing artefacts: “if there’s metal, it will change the scans [...] it can take that and mark it as a bleed” (#14), all confusing AI tools. These examples illustrate that clinical data contains characteristics of the specific equipment, settings, and circumstances under which it was generated, and these characteristics can significantly affect AI model performance.
5.3 Frictions in Putting Data to Use
The third and final theme concerns how data is put to use in AI model development and the challenges of integrating diverse data types for more advanced medical AI. This involves frictions related to how models need to be adapted to local contexts, and the difficulties of combining data across a siloed hospital information infrastructure.
5.3.1 Build-or-buy dichotomy vs. AI’s need for ongoing local data work
One recurring finding is that AI tools require ongoing local data work, regardless of whether they are developed in-house or procured commercially. Even commercially available, certified AI tools cannot be expected to work well with local data, for example due to the variations described above. Hospitals therefore perform local validations and fine-tuning. As one developer stated: “if you buy commercial AI models, I think you still need to fine-tune the model with your own hospital data, otherwise [...] you have a risk to miss some detections or segmentations” (#10). Another informant added another concern: “we don’t trust the numbers that we see from the commercial vendors, we would like to validate it on our own data before we start to use it” (#5).
This need for local data work blurs the traditional build-or-buy dichotomy. Several informants argued that in-house development is important not only for creating better-adapted tools, but also for building the expertise needed to evaluate and use commercial products: “we have to do development and one of the reasons why is that then we get the in-house competence on AI and with that competence we can actually learn to evaluate what are the best CE-marked tools” (#5). In-house models also allow for continuous improvement, as one informant pointed out: “the big advantage of in-house models is that you can iteratively make them better. A commercial AI tool by all intents and purposes is a static product” (#7). These findings suggest that hospital AI may require a ‘hybrid’ approach where local data work and expertise are still essential, regardless of whether tools are developed in-house or procured commercially.
5.3.2 Siloed systems vs. AI’s need for cross-system integration
Looking ahead, several informants described a vision of multimodal AI (models that integrate multiple data types such as medical images, electronic health records, lab results, and genomics) as the next major development in medical AI. Unlike current narrow, single-task AI tools, multimodal systems would approach clinical reasoning more holistically: “it looks at all the data, so it’s more trying to do the work of the doctor, whereas the weak AI is just a tool for them” (#9). Some informants saw in-house development as the only viable path to achieve this since commercial vendors currently lack access to the needed variety of hospital data (#5).
However, achieving multimodal data integration faces substantial frictions. Hospital data is stored in separate, specialised systems that serve distinct clinical departments and purposes. As one informant pointed out: “these systems do not talk to each other in a good way” (#7). While Norway’s healthcare system is often described as data-rich, informants pointed to a gap between this perception and the reality of connecting data from different systems: “they talk a lot about having really good healthcare data [...] but no one has ever looked into how the hospitals actually work. Like, how are you going to connect all these data sources?” (#9). Connecting these data silos requires not only technical work but also solving the governance and regulatory complexities described earlier, as combining data from different clinical systems and registries only raises more legal and ethical challenges (#7).
5.4 Overview
Table 2 presents a summary of the findings. For each friction, it unpacks the care-driven logic and computation-driven requirement on either side, and describes the responses observed in practice.
| Friction | Care-driven logic | Computation-driven requirement | Observed response |
|---|---|---|---|
| Generating data: Data scarcity and imbalance vs. AI’s volume requirement | Data is generated through clinical care, so its volume is determined by patient flows and disease incidence (naturally limited for less common conditions) | AI requires large training datasets to learn patterns reliably, which includes the case of rare conditions | Practitioners wait longer for cases, seek external or international datasets, or attempt to work with smaller training sets |
| Generating data: Restricted data access vs. AI’s need for streamlined access | Hospital data is governed by frameworks designed to protect patients’ privacy, with multiple regulatory bodies and inconsistent interpretations across institutions | AI development requires reliable, streamlined access to data across registries and institutions | Practitioners navigate multiple bodies and work through inconsistent interpretations |
| Ensuring data quality: Contextual interpretation vs. AI’s need for categorical labels | Clinical knowledge is contextual and often narrative; experts may interpret the same data differently | AI requires consistent, categorical labels to learn from | Manual annotation by clinicians, multiple annotators where feasible, work to define clinical conditions in AI-applicable categories |
| Ensuring data quality: Equipment and protocol variation vs. AI’s need for data consistency | Imaging protocols and equipment vary across hospitals and machines for valid clinical reasons | AI is sensitive to variation in how data is generated and requires consistent characteristics across sources | Local validation, fine-tuning on local data, cleaning pipelines. In some cases, it has led to change in data production practices (e.g., move toward digitised ECGs) |
| Putting data to use: Build-or-buy dichotomy vs. AI’s need for ongoing local data work | Medical technology has traditionally been built or bought, with each pathway leading to a stable, validated tool | AI’s performance is tied to data and requires ongoing local data work, blurring the distinction between in-house development and procurement | Hybrid approaches combining procurement, in-house development, and continuous local data work; in-house development valued both for tool adaptation and for building the expertise to evaluate commercial products |
| Putting data to use: Siloed systems vs. AI’s need for cross-system integration | Hospital information systems are siloed because each serves distinct clinical departments and purposes | Multimodal AI requires data integrated across systems that originally serve different functions | Custom data pipelines, integration work, navigating governance complexities of combining data |
6 Discussion
Our study provides an in-depth look into the data-related complexities of developing and implementing AI in Norwegian hospitals. By using the concepts of sociotechnical installed base and frictions as analytical lens, our findings show how the data-dependent nature of AI clashes with established practices and infrastructures. We identified three main areas of friction: data generation (availability and access), data quality (annotation and compatibility), and data utilisation (model development and integration). Across these areas, our findings show that the resulting frictions tend to produce adaptive responses rather than more transformative effects; practitioners work around the encounters they describe, and the underlying healthcare arrangements remain largely unchanged.
Our findings align with the literature that challenges data being neutral resources readily available for new purposes. As Gitelman (2013) argues, data are never ‘raw’ but always products of disciplinary practices, and as Ribes and Jackson (2013) point out, they require constant work to remain meaningful. Our empirical findings show this in the context of AI development and implementation; clinical data is generated through care practices, shaped by diagnostic protocols, governed by regulations designed to protect patients, and stored in systems built for clinical workflows. The data practices, standards, and infrastructure that make data meaningful for clinical care (Edwards, 2010; Leonelli, 2016) are exactly what makes the same data problematic for computational reuse. This observation can be seen through all areas of friction we have identified. Data governance frameworks were designed to protect clinical data and patients, not to facilitate its reuse for AI development. Data quality standards were established for clinical purposes, where a scan that is ‘good enough’ for a radiologist may be insufficient for an algorithm. Imaging protocols vary across hospitals for valid diagnostic reasons, yet these variations may confuse AI models. And hospital information systems are siloed because each serve distinct clinical departments, workflows, and purposes. They were not intended to support the kind of cross-system data integration that multimodal AI requires.
What is considered as “outdated” or “inadequate” in the installed base depends on the perspective from which it is viewed. Scanned images of paper ECG printouts are not outdated from a care perspective; they served human clinical work well. Governance frameworks are not deficient but designed to protect patients. Siloed systems are not poorly designed but fit for the purposes of distinct clinical departments. Varying imaging protocols exist for valid diagnostic reasons, and were not necessarily problematic before. The installed base perspective we use in this paper is well-suited for revealing this relational nature of what is otherwise taken for granted as “given” (Aanestad et al., 2017); each element of the installed base made sense, and in many cases still makes sense, for its original clinical purpose. It is only the introduction of AI’s data requirements that retroactively ‘reframes’ these arrangements as inadequate.
This points to what we see as a mismatch between the logic of the installed base, which is built for care, and the demands of AI technologies, which are built for computation. The installed base was not designed to resist AI, it was simply designed for a totally different purpose. While the literature on frictions suggests that frictions can be generative forces that trigger transformation, learning, and adaptation (Biggs et al., 2012; Laamanen & Mikołajewska-Zając, 2024; Håkansson & Waluszewski, 2011), our findings suggest that the generative potential of data-related frictions in healthcare is, currently, limited. This characterisation of course also depends on how ‘generative’ is interpreted. As discussed in our theoretical framing: we adopt the interpretation of generative as transformative (going beyond mere adaptation). Under a different interpretation (for example, generative as the opposite of stabilising) the same data might produce a different reading. Practitioners are discovering that clinical data does not easily serve computational purposes, and they are working around this (through manual annotation, local validation, custom data pipelines, et cetera), but these are adaptations, not transformations of the installed base itself. The governance structures, clinical protocols, siloed systems, remain mostly unchanged. This is not necessarily active resistance to change. The existing literature offers several possible explanations: the inertia of the installed base (Star & Ruhleder, 1996), where structures and practices aligned with clinical care have little reason to shift in the direction that AI requires; or the time-dependent nature of frictions (Håkansson & Waluszewski, 2011), where transformative effects may emerge over longer time periods than our study currently captures. Other mechanisms may also be at work. The empirical observation itself (that frictions in this context produce adaptive rather than transformative responses) is still meaningful in itself, but also warrants further investigation to distinguish between these explanations.
This research contributes to the literature on AI in healthcare by providing a data-centric perspective on the challenges of bringing AI into hospitals that moves beyond simply describing ‘data issues’ as barriers. By connecting the data-related frictions to this care-computation ‘mismatch’, we provide an explanation for why these frictions are persistent and difficult to resolve; they reflect a deeper tension between the purposes underlying healthcare data practices and what AI requires. This suggests that addressing these challenges requires not just technical solutions but a deeper engagement with these underlying logics. A related observation (which we develop further below as a direction for future research) is that the frictions we identify appear to produce adaptive responses rather than the transformative or generative effects sometimes suggested by the friction literature.
7 Conclusion and Future Research
This study has examined the data-related frictions that emerge when developing and implementing novel AI technologies within the sociotechnical installed base of Norwegian public hospitals. By analysing interviews with key stakeholders and practitioners, we identified three main areas of friction: data generation, data quality, and data utilisation. We argue that these frictions are rooted in a ‘mismatch’ between the logic of the healthcare installed base (designed for clinical care) and the computational demands of AI technologies. Notably, in our data, these frictions appear to produce adaptive responses (workarounds, manual labour, custom pipelines) rather than the transformative or generative effects sometimes suggested by the friction literature. Why this is the case remains an open question that we aim to develop further in our planned future research. Friction in data proved to be a useful sensitising concept for analysing the challenges of bringing AI into hospitals and deserves further attention. Our future research plan involves expanding on these findings through more in-depth research on specific cases. We will conduct case studies of at least two specific AI projects in Norwegian hospitals during 2026: one focused on cerebral haemorrhage detection, and another on acute myocardial infarction detection. These case studies will allow us to investigate how data-related frictions are navigated across the development and clinical use of these AI tools, and to examine more carefully why the encounter between AI and the installed base appears to produce adaptive rather than transformative responses. We aim to collect additional data that enables us to explore which mechanisms (the inertia of the installed base, the time-dependent nature of frictions, or others) best explain these findings, and under what conditions the encounter might produce more transformative effects. Beyond these empirical questions, our analysis raises a conceptual one: what ‘generative’ actually means in the context of friction theory. Different interpretations exist in the literature (generative as transformative, as de-stabilising, or something else) and which is most useful for analysing AI in healthcare is another reason for further engagement with this body of work.
References
Footnotes
The Norwegian Agency for Shared Services in Education and Research (SIKT) is the main governmental body overseeing research ethics in Norway.↩︎