Abstract
Our paper is a case study of the making of data-driven healthcare and anticipation work done by developer-experts in a project for implementation of an integrated patient data management platform in Finland. We focus on ‘personalised treatment plan’, a trope that experts regularly use when talking about the objectives of data management reform and their wishes for datafication of healthcare. We conceive of the personalised plan not primarily as a future vision or an outcome, but rather a tool of anticipation of work. Our analysis demonstrates two purposes for which the developer-experts used this tool. First, the plan enabled them to reconfigure the general expectations of datafication actionable and adoptable in the actual world of healthcare and to articulate datafication technology-to-come as concrete hopes and wishes, plans and assessments in the contexts of clinical practices and administration. Second, experts used the idea of a personalised plan for reasoning over and management of their own work. Among the fuzziness and commotion of the complex project, the plan helped them to create and maintain a workable order between the expectations, tasks and functions that the datafication technology should accomplish in healthcare in the future. Furthermore, we discuss the limitations of anticipation to take the specific political and economic contexts into account, which made the developers unprepared for the political interruption of the project.
Keywords
Introduction
When we interviewed medical, ICT and project management experts working in a project for the planning, acquisition and implementation of a new-generation integrative system for the management of patient and client data in healthcare and social services in a Finnish county, we frequently came across the idea of a personalised treatment plan closely associated with future data-driven healthcare and its promise of ‘properly planned execution of care and treatment that would be more automated, self-regulative, and personalised to the patient’ (developer, nurse 2019). They expected and hoped that the personalised plan would cover the entire path a patient goes through in healthcare from prevention to recovery, and it would guide the patient, the professionals involved and the healthcare organisation.
The project in which the developer-experts were involved was part of a greater endeavour to implement data-driven healthcare and social services for a county with more than 300,000 inhabitants in Finland (see below for a more detailed description). As such, it was one of many projects and initiatives for adopting and utilizing advanced data management technology and artificial intelligence in healthcare. Throughout the world, professional, political, administrative, academic and commercial stakeholders attach expectations of efficiency, accuracy and savings to these efforts (e.g. NAS, 2011; ESF, 2012; Pentland et al., 2013). The promises particularly concern personalised treatments and care, precision in medical decision-making and diagnostics, enhanced professional practices and fluent and cost-effective functioning of the healthcare organisations, including considerable reduction in public expenditures.
Our paper examines how these expectations are reconfigured actionable in the context of a healthcare organisation under a considerable long-term reform. We do not focus on the hype of big data, advanced data mining and AI in healthcare, with which policy and business reasoning have been impregnated during the past decade (Hoeyer, 2023; Prainsack 2017; Tarkkala et al., 2019; Tupasela et al., 2020). Instead, we study hopes and expectations of healthcare and ICT experts who concretely contribute to the development of and experimentation with technical solutions and new practices in data-driven healthcare. The subject of our analysis is ‘personalised treatment plan’ as it was discussed in experts’ interviews and project documents. It was a recurrent figure of expert speech, a trope in terms of literature studies (e.g. Baldick, 2001: 264). This trope provides us with a loophole to look at anticipation as reasoning and work (Adams et al., 2009; Clarke, 2015) that is indispensable for the actualisation of the visions of data-driven healthcare. Seen from this perspective the personalised plan was not primarily a vision or an outcome, but a tool.
The experts’ discourse on ‘personalised treatment plan’ allows us to approach two aspects of anticipation: First, we can find out what healthcare and ICT professionals engaged in planning, experimentation and implementation of data-driven healthcare make of the general promises of datafication. Second, we get a glimpse into how they reason over their work of planning and implementing new technology. In particular, we seek answers to the following questions: How did the experts make the visions and expectations actionable and adoptable in their organisation? How did they reason over the complex and labile organisational milieu in which considerable changes are to take place? In short, our study focuses on anticipation as work and practical reasoning. We analyse this topic in the context of a healthcare organisation in which experts attempted to actualise the expectations of datafication through a trope of a personalized treatment plan.
Our analysis contributes to discussions on the promises of datafication in healthcare (e.g. Hoeyer, 2023; Hogle, 2016) by highlighting the modification of future visions and expectations of data-driven healthcare doable and adoptable by professionals dedicated to implementing new data management technology in concrete healthcare settings. Our findings underline that the implementation of advanced data management systems, algorithms and machine learning – or even the pursuit of the use of those technologies – in healthcare requires and results in anticipation work (Clarke, 2015) within particular healthcare organisations and clinical practices. In addition, our analysis touches upon the limits or even failure of anticipation to take wider political and economic context of the deployment of datafication technology into account, as the project we studied was never completed, and its political cessation was completely unexpected by the developers (see below).
Our paper unfolds as follows: in the next section, we discuss the conceptual framework of our analysis; then, we present our case, research data and methods; after that, we proceed to our findings on the developer-experts’ usage of the ‘personalised plan’, and then we discuss the interruption of the project and limitations of anticipation in this case; and finally, we conclude by summarizing the main points of our analysis and discussing both the facilitating impact of anticipation work and its limits in the making of data-driven healthcare.
Anticipation: work to make datafication work
Our interviewees worked and spoke in the context of building an integrative data management platform for regional public healthcare. This project was influenced by the pursuit of data-driven healthcare and social services in a Finnish county (see below). Thus, we present a case of the datafication of healthcare (see Hoeyer, 2023; Hogle, 2016; Ruckenstein and Schull, 2017). Datafication (e.g. van Dijk, 2014) refers to three interlaced dimensions of the use of digital technology in medical research, clinical practice and the management of healthcare organisations. First, organisations, clinical professionals and even patients collect vast amounts of digital data in everyday practices; second, the utilisation of data and advanced data management technology is routinised in their everyday work; and finally, the management and functioning of organisations, healthcare practices and even the patients’ conduct are extensively data-driven. Thus, datafication covers data sourcing and routine utilisation of data in healthcare practices, administration and management, as well as the solutions and applications enabling and serving such utilisation. All of these dimensions of datafication can be seen in our case.
Datafication technology – systems of computing devices, algorithms that steer the functioning of computers and computer systems and digital data for algorithms to work with – affect practices, organisations and people within them. But, how to conceive of this influence of datafication? As a mainstream STS view on the social and organizational impact of new technologies (e.g. Felt et al., 2017) suggests, we conceive of datafication technology as embedded in healthcare practices and institutions. In other words, what data and algorithms do, how they affect us, what are the needs they serve and how they are deployed are constituted by practices, contestations and power relations prevailing in healthcare settings. Reciprocally, practices, social orders and power relations are affected and modified by the adaptation of the datafication technology.
Our approach is in line with the views of critical data and algorithms studies, which sets as its task the unpacking of complex sociotechnical data and algorithmic assemblages (Dalton and Thatcher, 2014; Kitchin, 2017, 2021; Kitchin and Laurialt, 2018). Talking of data or algorithms as assemblages (on the concept, see Marcus and Saka, 2006) implies a presumption that ‘data are never simply neutral, objective, independent, raw representations of the world but situated, relational, contextual, and do active work in the world’ (Kitchin and Laurialt, 2018: 7; see also Dalton and Thatcher, 2014; Kitchin, 2021). Likewise, ‘algorithms perform in a context – in collaboration with data, technologies, people etc. under varying conditions – and therefore their effects unfold in contingent and relational ways, producing localised and situated outcomes’ (Kitchin, 2017: 25).
Our study concentrates on how data, algorithms and other data management technologies ‘do work in the world’ (Kitchin, 2017: 25). We follow Galloway's (2006) and Kitchin's (2017) lead that people who use – or plan, experiment with, or implement – systems or solutions for data sourcing or management, algorithms or AI are ‘learning, internalizing, and becoming intimate with the technology’ (Galloway, 2006: 90). This means that their professional practices, routines and reasoning become subtly modified through engagement, while simultaneously the capabilities of the algorithms, data and data management platforms are conditional on the input from the users, planners and developers of the technology. A line of study sketched by Kitchin (2017: 26) describes quite accurately our case study as well: ‘(…) to conduct ethnographies of how people engage with and are conditioned by algorithmic systems and how such systems reshape how organisations conduct their endeavours and are structured’. The subject of our study is work in the world as a result of which algorithms, data, AI and alike technologies are expected to work in the world.
We study the planning of data-driven healthcare not yet operating. This future healthcare would be embedded in massive data mining and algorithmic steering of clinical work, administration and logistics with the help of an integrative data management system. Currently, datafication has a much more limited role in the practices and organisations of healthcare than the vision suggests. Despite such a state of latency, datafication bears significant influence in professional practices and organisations through expectations and anticipation regarding the changes that the adoption of new data management technology will bring and require. As many studies in sociology of expectations have pointed out (e.g. Borup et al., 2006; Brown and Michael, 2003; Fujimura, 2003; Helén, 2004; Sunder Rajan, 2006; van Lente, 2000; 2012), expectations concerning novel technologies have the power to affect reality in the settings like our case by directing interests, justifying specific research and development (R&D) projects or technological reforms and making them appealing to funding institutions, investors and policy makers. As Borup et al. (2006: 286) summarised: (…) expectations can be seen to be fundamentally ‘generative’, they guide activities, provide structure and legitimation, attract interest and foster investment. They give definition to roles, clarify duties, offer some shared shape of what to expect and how to prepare for opportunities and risks.
The developer-experts we interviewed worked precisely in such key positions in the regional project. What they said in the interviews and workshops reflected the fact that they were working with device under development and therefore incomplete and highlighted the mediating and facilitating character of their work; they interpreted, assessed, evaluated, modified and reflected the general promises and goal-settings of the project to make the expectations of datafication reasonable, actionable and adoptable in the actual world of healthcare. When the developer-experts spoke about and discussed the personalised treatment plan, they articulated datafication technology-to-come as concrete hopes and wishes, plans and assessments. This usage of the plan resembled activities discussed in STS as construction of doable problems and tasks (e.g. Fujimura, 1987; Henriksen and Bechman, 2020; Juul Lassen et al., 2015). Such articulation was entangled with measures, activities, and related reasoning for keeping expectations alive and feasible, as well as making people, their practices and routines and organisations receptive and adaptive to new technologies – even before any piece of new data management systems or data mining devices was in use in the clinics or hospital district's administrative divisions. All that developer-experts said, reasoned and did in this context was work facilitating, or even nurturing, the new technology not yet in operation. In essence, this work was anticipation (Adams et al., 2009; Clarke, 2015).
In our approach to the anticipatory aspect of datafication, our concept of anticipation is much more modest than the all-encompassing definition by Adams et al. (2009) who present anticipation as today's Zeitgeist, that is, the epistemic, moral and political form for reasoning and action in our era. In contrast, we conceive of anticipation as efforts and reasoning by which healthcare practices and institutions are inclined and expected to change so that they may, first, support and maintain the promise of data-driven healthcare and, second, be ready for the implementation of datafication; moreover, we use of the concept as embedded in the empirical analysis, and in this sense, it is concrete. We conceive of expectations and anticipation as entangled together: the datafication technology-to-come and associated expectations require anticipation to bear influence in existing healthcare practices and organisations.
Adele Clarke (2015) underlines that anticipation requires action and practical measures and is essentially work. She highlights the tacit, often taken-for-granted and as-if invisible everyday activities that are both preparing and being prepared in their orientation. She calls such activities anticipation work and claims that this work is indispensable for complex and extensive future-oriented endeavours and projects because it manages messiness and uncertainties inherent in complexity of such evolving assemblages. Anticipation work has several dimensions, and Clarke discusses three specific modes for handling messiness and uncertainty in future-oriented worlds: abduction, simplification and hope. She also describes anticipation work by quoting what Anselm Strauss (1991) said about articulation as ‘the specifics of putting together tasks, task sequences, task clusters …’ (Clarke, 2015: 104). Clarke's approach helps us in situating the experts’ trope of the personalised plan in the practical context of anticipation. Seen from this perspective, the personalised plan was a tool of anticipation work by which the developer-experts created, maintained and communicated a workable order between the expectations, tasks and functions that the datafication technology should accomplish in the future. As a tool, the personalised plan also helped them to manage and carry out their own work.
The case, data and methods
The case under study is an endeavour to implement data-driven healthcare – including social services – in a region of over 300,000 inhabitants in Finland. For more than a decade, several initiatives and projects towards this objective took place in the region, and therefore, the endeavour was more of an amalgam than a unified project with clear-cut design and organisation. A variety of stakeholders was involved, and the building up of data-driven healthcare (and social services as a supplement) appeared to be in a constant state of morphing and evolving.
At the time of the fieldwork of this study in 2017–2022, public specialised medical care in Finland was arranged by regional hospital districts which were joint organisations of municipalities in a county. The core element of our case study is the plan of the hospital district of a Finnish county to standardise and unify the data management system for basic and specialised healthcare and social services and to build a new central hospital with cutting-edge ICT as if a flagship of data-driven healthcare. In 2012, the healthcare district started to plan a profound reform of EMRs and other clinical and administrative data management systems. The top management set the objective to acquire a data management platform that would do three things: first, integrate databases and IT solutions used in clinical and patient work in basic healthcare, specialised healthcare and social services and in the administration of healthcare and social services throughout the county; second, allow seamless circulation of information and data among the different sites of clinical and administrative work in real-time; and finally, allow more intense sourcing of patient and administrative data. The effort was launched with an expectation that the new data management platform would enable the realisation of the promises of digitalisation and datafication in the form of more cost-effective, precise and personalised healthcare. Alongside this effort, numerous projects by the ICT faculty at the local university, in close partnership with the AI platform of a multinational ICT corporation, actively promoted and experimented with the use of machine learning and advanced data mining in healthcare.
In spring 2020, after over 2 years of preparatory work, the healthcare district and three other healthcare districts decided to order a joint integrated patient and client data system (APTJ) and chose a multinational healthcare ICT corporation as the supplier. In autumn 2020, joint team and project organisation from four healthcare districts, with a total of 700,000 inhabitants, started planning an APTJ system, called Sirius, 1 and preparing its implementation with experts and consultants from the supplier company. Within a year, the planning phase was finalised, and the project organisation and its developer-experts were preparing to put the system into ‘production’. Then, regional politics intervened: in October 2021, municipal councils in the county decided one after another to withdraw from the Sirius project, and the hospital districts closed it down at the end 2021. The reason for this political decision was an estimate that the risen costs of the new APTJ would have caused too heavy an economic burden for the municipalities.
Our analysis is based primarily on 31 interviews with ICT and medical experts at the Sirius project and local university conducted from 2017 to 2022. Recruitment of interviewees happened along with the fieldwork. Ilpo Helén, one of the authors, entered the site of the study by interviewing ICT academics at the local university ICT faculty and the director of the hospital district who collaboratively advocated data- and AI-driven healthcare in the region. They informed him about managers and executives working on the data management reform and Sirius project at the hospital district who, in turn, directed him to meet and interview rank-and-file developers of Sirius. In the end, most of our interviewees were either full-time or part-time planning Sirius, or involved in the project because they were in charge of the ICT at the hospital district. Among out interviews, there were professional project managers and executives and developers with expertise in either ICT, medicine or social work. Many of the non-ICT developers were nurses or social workers by training, and only few developer-experts were physicians. In the interviews, we asked the experts about their assumptions and expectations for the impact of datafication technology in clinical and patient work and healthcare administration and their experiences in the planning of the new data management system. We also used documentary material from plans and reports related to Sirius project and more widely to data-driven healthcare in the region and Finland and field observation notes from the Sirius planning workshops in autumn 2020 and spring 2021 in which the Sirius developer-experts and the experts from the supplier company together planned, defined and negotiated over the details of Sirius and its implementation; the workshops were organised online in Teams due to COVID-19 restrictions. With and document data and field notes we complemented the interview data and juxtaposed our findings with them.
For our analysis, we deployed thematic close reading (e.g. Brummett, 2018). We began by mapping the central themes in the interview and other research material. In this mapping, the trope of the ‘personalised treatment plan’ clearly stood out, and we decided to focus our second round of analysis on it. We read the interviews and other material again and conducted an analysis resembling tropological criticism (Childres and Hentzi, 1995), and we focused on sorting out two themes: first, how the experts described the functioning and impact of the personalised plan and, second, in which contexts they situated this master trope. In the third phase of our analysis, we took inspiration from material semiotics (Law, 2009) in the sense that we thought of the plan not only as a figure of speech but as a tool. More precisely, we examined, first, what kind of usage and influence the experts imagined the personalised plan would have in future healthcare and, second, we analysed how the developers talked about utilizing the trope and imaginary of the plan in planning and making of the data management system. Our analysis resulted in finding that the experts used the ‘personalised plan’ as tool of anticipation for two purposes: adjusting expectations and maintaining order and orientation of their own work amongst the messiness and complexity of the project.
Framing expectations by the personalised plan
Almost all medical and ICT experts involved in the planning of Sirius we interviewed talked about ‘personalised treatment plans’ or ‘paths’ that would enable anticipation of services and care provided to a particular patient. This plan would consider everything in terms of the patient's illness or condition, health risks, proper treatment, or interventions, as well as the resources needed. An executive project manager described the ideal by explaining how a patient is inscribed to the patient record system and a suitable form of treatment is attached to the patient. Then, ‘the IC system knows that he is of a certain size, and that this man needs a certain sort of clothes, bed, and diet’ (Executive project manager, 2019). Moreover, the system knows what laboratory tests and medical examinations need to be booked for the patient and when, as well as what sort of personnel are needed. All in all, a system functioning through personalised plans would allow clinical professionals and hospital managers to ‘know exactly how many physicians with what specific skills, how many nurses, and what support services’ are needed at a certain time (Executive project manager, 2019).
In experts’ talk, phrases referring to the personalised plan designated plenty of things or ideas. For example, the personalised treatment plans would improve quality of patient care because medical personnel ‘would know what they are doing, for real’ (Clinical developer, physician 2019). With this, the informant referred to model treatment plans that can be activated and tailored for each patient: A certain plan for diabetes, for instance; another plan for a broken ankle; and if a person becomes unemployed, a specific plan to manage that, too. And all of these would come together in a personal client plan, and the patient would also see what will happen to her or him. (Clinical developer, physician 2019) When a woman knows she is pregnant, she might book appointments for her child for vaccinations and for the maternal and child health centre for the next 18 years in advance, as a blueprint for production management (…) which implies a treatment plan for the whole life course, combining healthcare and social services (…). We could adopt a sort of process view to individual human beings and [outline] a treatment plan for the entire life span of a person. (Clinical developer, physician 2019) Someone is satisfied with being able to walk daily to the mailbox, while someone else would like to run a half-marathon (…). On the basis of data for all these factors we could give a prognosis to the patient for how well the knee may heal if the arthrosis is treated by a surgical operation or by other means without an operation. (Clinical developer, physician 2019) She may feel pain in her hip, which leads her to the hip-pain path. She may receive some initial instructions from Omaolo [national health portal], which contributes to the making of the personal path. When she comes here for an X-ray examination, and when imaging results indicate a clinical finding, she moves on to the hip arthrosis path, and so on …. Yeah, we could outline such paths from cradle to grave.
Yet, this future seemed multiple. There were versatile conceptions of the essential features and lines of improvement of data-driven healthcare among the experts. Many saw that medicine-to-come will be predictive, preventive and pre-planned, as in a vision of an ICT expert who said that algorithms or AI could be used to see ‘who belong to a potential risk group’ or ‘use healthcare or social services extensively’. He continued: If we would be able to mine weak signals or potential risks on the background and draw a conclusion that here we possibly have a patient who will, with a certain probability, need some medical assistance, then the IC system could suggest to a professional that, on the basis of these factors, you may think of starting a suitable treatment path [for this particular person]. (Healthcare ICT expert, 2019) (…) if all professionals follow the same model when they start to treat, for example, a person with diabetes, it wouldn’t matter if it is Monday, or the first day at work after vacation, or if you had not slept at night while tending your child or old mother, or whatever (…). (ICT executive, physician 2019). The patient will get more power to make decisions when we have more time, and we can ask what s/he really wants. We can profoundly explain what the benefits and side effects for them will be and if we choose this or that treatment. When the gizmo takes care of the physician's memorisation tasks and the writing tasks of her or his fingers, the patient will have more power because we have more time to discuss the core issue, namely, the choice of treatment. (ICT executive, physician 2019) the data generated by [service] processes will enable us to analyse and evaluate if this or that service path uses our resources in a sensible way, or whether we have resources not properly utilised in our service paths. (…) APTJ is the system that steers the actions of the clinical process and runs the treatment paths, and ERP system runs the resources needed to make them. (ICT project executive, 2019) The idea is that the patient enters a path relevant to her or his health, and the APTJ signals to commence the track. For example, a lab result indicates that the patient seems to have diabetes, and the system asks from clinical personnel if this patient should be placed on the diabetes path; or an imaging assessment could be constructed so that it suggests a diagnosis, i.e., the system asks the physician – because the physician has to make the diagnosis – that this finding is an arthrosis coxae, isn’t it? All you have to do is to choose ‘yes’, and the path materialises automatically, with the suggestion ‘you’ll activate our usual treatment path, won’t you’? And you’ll answer ‘yes’, and the patient is on the appropriate path, moving on. (ICT executive, physician 2019)
Keeping bearings in anticipation work
As discussed above, the developer-experts, managers and medical professionals at the Sirius project deployed the ‘personalised plan’ in their anticipation work (Clarke, 2015) to articulate expectations actionable by giving them concrete meanings in the everyday healthcare practices. Yet, there was another facet of Sirius experts’ anticipation work, more acute and tacit. When managers and medical and ICT experts engaged in planning and tuning the new APTJ and preparing its implementation, they needed to anticipate – i.e. prepare and be prepared for (Clarke, 2015: 90) – profound technological reforms and major changes in healthcare practices, and therefore they inevitably faced a large set of manifold tasks. Interviews with experts and fieldwork at workshops revealed the immense scope and complexity of the work the experts did when paving the path for datafication in healthcare, even before the technology was ready for use: In acquisition phase, we described service processes by making some 3000 demands. In the planning phase, we make use of these as we defined concretely what the data management system should accomplish and how the practices would be actually developed and changed – and now we have been diving into it more deeply, indeed. We went through some 200 service processes in different areas of healthcare and social services and between them – which is less than 10% of the service chains we should handle in the actual production and implementation of the system. (Project executive, 2021) The system ought to understand specific instructions for actual actions, so that it could actualise in the system automatically. So, we have to inscribe – in zeros and ones – everything that a clinically solid and desired model includes. (…) It should function so that a professional can launch the treatment path; for example, if there is a planned model, the system asks: ‘Will you activate type 2 diabetes path?’, and you just push the button, and the path activates: lab tests will be ordered, x-rays will be ordered, control appointments will be reserved. But the system must understand all this. For this reason, our plan is that when the coders come here, a clinical expert or at least someone who understands the instructions of clinical work will sit down beside the coder and interpret them to the coder who then writes zeros and ones into the machine. (ICT executive, physician 2019)
Amongst the maze, mingling and commotion of the project, the trope of personalised treatment plan appeared not only as a means of framing expectations, but, essentially, experts’ reasoning tool by which they were able to assemble ‘tasks, task sequences, task clusters …’ – as Clarke (2015: 14) describes anticipation work – when planning and tuning the Sirius system. The ‘personalised plan’ enabled framing and ordering what needs to be changed and what will change in healthcare, to what direction and with which possible consequences. It also helped the experts to figure out what measures the change to more standardised healthcare model would need in current practices, work habits, organisations and technical solutions.
More concretely, the experts carrying out the reform for data-driven healthcare – in our case, planning an integrative APTJ – used the ‘personalised treatment plan’ to arrange clinical activities and patient work into definite and clear-cut practices. With the formulation and building up of personalised plans or pathways, they reasoned over, communicated and argued for expectations and demands about what data management and algorithms should accomplish in healthcare facilities. This was not only about communication among the healthcare, ICT and administration professionals; in addition, the plan – with associated expectations, tasks and practices – was also a means to communicate the healthcare districts’ requirements to the supplier company and its experts: We have tried very hard to insist that a longer plan must be embedded in the data management system. Not just capability to reserve the next control but pre-booking control appointments for a year or so (…) But we don’t know what we will eventually get, but we have asked and wished for and written in definitions and one-liner demands that the system should be capable of accomplishing this [longer treatment plan]. (ICT executive, physician 2019)
Hopeful simplification
According to Clarke (2015), abduction, hope and simplification are three key characteristics of anticipation work. Sirius experts thought of their work as seeking and developing new ideas, models or solutions or shaping the old ones in a new form and then iterating and experimenting with these novelties. In Sirius experts’ discussion and reasoning, however, this element of abduction – experts’ attempt to find inventive ways to conceive of the existing reality through a sort of back and forth thinking and experimenting with tentative ideas – was overshadowed by hope and simplification. As their anticipation work was forward-looking and focused on the mediation of expectations and visions, which in itself included the element of hope. Moreover, the developer-experts expressed in many ways that they were hopeful and optimistic about the capabilities of the new data management platform to significantly help healthcare practitioners and improve healthcare: I do believe that this will be of benefit to the professionals, the patients and the clients. (…) For once, the professional's work concept will hopefully change; at the surgery, you don’t have to write all down by yourself, and you have more time to spend with the patient, when you don’t need to fiddle with the machine so much. I hope that the new system would facilitate increasing fluency in clinical work and enabling planned care in practice. Especially, artificial intelligence may be beneficiary in helping the professional in their work … (Clinical developer, public health nurse 2019) The most important and challenging task is the modelling our processes, i.e., our work trajectories, into the IC system, which hopefully would result in standardisation up to a certain level; thus, we could avoid unnecessary variation especially at the beginning of service pathways. (Clinical developer, physician 2019)
All-encompassing simplification was not a straight-forward task. Each demand expressed in a simple sentence and each set of demands required a lot of collective, repetitive tinkering and negotiation among experts and stakeholders about the formulations of the sentences, their meaning and their feasibility, as we witnessed at the planning workshops. Paradoxically, work done for anticipatory simplification was complicated because it was not only about articulation, communication and negotiation of the existing practices and arrangements, but also about reforming and improving those practices and making the technical features and capabilities of the APTJ match with both dimensions of the demands: We’ve done quite detailed descriptions of the system requirements, user cases and functionalities that should be included in the system. For example, when we do documentation – inscribe certain information – the information should be in such a form [in the system] that it can be used in many sites – there are single case documentation and secondary use … Nowadays, we have to inscribe the same information in many different systems, while our objective is that in the future, the system will have such capabilities that you inscribe the information in the system once the system has been told that use this information then and there … (Clinical developer, nurse 2019) If we think of the integration of healthcare and social services on the most general level, the client plan has been a new concept, and it has been on board from the beginning of the acquisition phase. The client plans as a whole and the malleability and configurability of the [data management] system, they form the entire concept of health and social services integration; it is about the planned care and utilisation of cooperation, so that each municipality and region does not make their own hypertension treatment path, but we make it together … this will [to integrate] has remained solid throughout the project. (Clinical developer, physician 2021) In the last week, a problem was solved; we have presented a demand that the patient should be able to add information to the system while in the hospital – for example, a diabetic would mark when s/he had taken insulin or measured her or his blood sugar. The company understood the demand line so that the patient should be given user access to the system and responded with no. Then I explained that we do not suggest giving user access to the patient, but an option for hospital patients to self-report has to be included in the system – now the patients mark information about insulin dosage, for example, on paper, and this has to be possible in some electronic form. When the company representatives understood what we actually meant by this demand, they said that ‘yes, we can deliver that’. (Clinical developer, nurse 2021)
An excerpt from a demand list for Apotti (2015), an integrated data management platform for healthcare and social services in use in Southern Finland (see Grön, 2021). The Excel matrices of one-liner demands in Sirius were similar to the ones compiled in the Apotti project, available as appendices of the Apotti contract (www.apotti.fi).
All in all, the personalised treatment plan was a tool of anticipation work in the phase of the Sirius project preparing ‘pseudo-coding’ (Kitchin, 2017), that is, the making and modifying algorithms that guide the coding of healthcare tasks into the data management platform. As a reference point for the rationale of patient work, the idea of the personalised plan enabled dismantling clinical activities and related data management (which experts often called ‘paperwork’) into simple one-liner demands. By doing so, the ‘plan’ also facilitated organisational development of clinical work since it enabled imbedding certain objectives like standardisation or systematic, and even automatic steering of the clinical practices and practitioners in the APTJ. Thus, the plan paved the way for and sustained the expectations of datafication in healthcare. This aspect an ICT executive described in the following: Commercial studies of healthcare systems show a clear trend of change in EMR systems so that the systems will be embedded in AI 10 years from now. The cutting-edge systems will become mentors to the physicians. Or in the first phase, the patient data management systems function like a colleague, and in the next phase they’ll become mentors which direct the physician like ‘okay, maybe you shouldn’t do this but choose this or that test, instead’, or ‘this test result indicates this line of action’.
Anticipation imploded
In early summer 2021, the Sirius developers and their company colleagues were finalising together the planning phase of the new APTJ, and both parties seemed quite pleased and waited for the production phase to begin after the holiday period. In the autumn, the project faced a dramatic turn: in October 2021, municipal councils in Sirius’ home county decided one after another to withdraw from the Sirius project, which was then interrupted. After that, the healthcare districts ended the Sirius acquisition, and the project was closed down at the end 2021. The reason for this political decision was that the estimated costs of the new data management system had considerably grown, and the local politicians considered them too heavy an economic burden for the municipalities. In addition, uncertainties of the ongoing nationwide reform by which public healthcare and social services in the county and municipalities were integrated under one regional organization made local politicians reluctant to such a big commitment the new APTJ required.
For the developers and the whole Sirius organization, this political decision was completely unexpected, and they seemed to be taken by surprise in an ultimate way. Being unprepared to such a political backlash is quite understandable, but it also reveals limitations of Sirius developers’ anticipation work and its tools. As our analysis shows, the developer-experts at Sirius were resourceful to adapt visionary expectations doable in the healthcare context, and they were aware of the winding course of the acquisition and planning process and prepared to manage with all the iteration and changes involved; yet it appears that they could not possibly anticipate the twist and turn that end the project before its time. A likely reason for this is the fact that they stuck to adjustment of the technical system and healthcare practices to each other in their work and were not supposed be concerned with overall expenditure on the new data management system or higher-level decision-making. Therefore, their anticipation work was solely focused on sociotechnical feasibility and actualisation of the APTJ and detached from – and therefore insensitive to – economic uncertainties of the project and political tensions involved. Signs of such uncertainties and tensions were apparent throughout the project, as the local media regularly reported and raised questions about Sirius’ costs, and there were plenty of criticism and protesting against the Sirius project among the local hospital physicians.
The personalized plan as a tool of planning and anticipation was affirmative to this implicit disregard. When it was a lamb post allowing the developer-experts to focus on making Sirius work properly and fulfil multiple expectations, its light eclipsed the wider view of economic and political factors affecting the data management reform; and while, as a means of communication within the project, the plan facilitated making precise definitions and negotiating over the ‘demands’ for the APTJ functioning, it casted out concerns over politics and expenditure. Thus, when developer-experts used the personalised plan they consolidated, assumingly not deliberately, bracketing political and economic accountability out of the technical and organizational development work of the system, which arrangement is quite typical of the endeavours like the Sirius Project. Here, the plan as an anticipation tool reached its limit, as it did not provide to developer-experts any means for anticipation of the ultimate closure.
There is some irony in the destiny of Sirius: the project and its ambition to implement data-driven healthcare was meant to be anticipation and preparation for the data management integration which, in turn, was seen as a basic requirement for a successful integration of regional public healthcare and social services, a grand reform that was in full speed at the time Sirius was planned. Since the project ended unfinished, the anticipatory and preparatory effort and resources spent were lost, and the challenges in healthcare data management Sirius was supposed to solve remained unsolved and were left to haunt the new regional organisation, called Wellbeing Services County, perhaps in a more complicated context than before.
Conclusion
In this paper, we studied anticipation work (Clarke, 2015) performed by developer-experts in an acquisition and planning project of an integrated healthcare data management platform for four hospital districts in 2017–2022. The Sirius project was part of a grand endeavour to develop data-driven and AI-utilizing regional healthcare and social services. Our analysis was focused on the ‘personalised treatment plan’, a trope the Sirius experts regularly used when they talked about the objectives of the data management reform and their wishes about data-driven healthcare. This trope as a loophole, we looked at tacit, everyday project activities as anticipation work (Clarke, 2015) and related reasoning indispensable for managing messiness and uncertainties inherent in extensive and manifold future-oriented technology projects.
Seen from this angle, the personalised plan was not primarily a vision of future or an outcome, but rather a tool of reasoning in anticipation work. In our analysis, we found two purposes to which the Sirius experts used this tool. First, the ‘plan’ enabled them to reconfigure the general expectations of datafication actionable and adoptable and articulate datafication and technology-to-come as concrete expectations, plans, and assessments in the context of clinical practices, preventive healthcare and administration.
Second, the Sirius developer-experts used the idea and trope of personalised plan for the management, reasoning over and execution of their own work, which in essence was anticipation. Amongst the fuzziness, mingling and commotion of the complex project, the ‘plan’ helped them to create and maintain a workable order between the expectations, tasks and functions that the datafication technology should accomplish in healthcare in the future. While planning and iteration of the rather incomplete Sirius system was under way, the ‘personalised plan’ provided the experts of vanishing point for framing and ordering what needs to be changed and what will change in healthcare, in what direction and with which possible consequences. It also helped the experts to ascertain what measures the change will need in practices, organisations and technical solutions.
In both usages, the ‘personalised plan’ was a tool to frame and make the objects, tasks and objectives of the Sirius project actionable and, thus, make the anticipation work possible. As such a tool, the plan was simultaneously loose enough to allow diverse ideas about the data-driven and algorithmic personalisation of treatment and care and structured enough to provide a concrete framing for future medicine. This combination of flexibility and rigidness made it useful also when the experts attempted to keep their own work on the right track in the twists and turns of project iteration. The ‘personalised plan’ provided the experts the reference point for checking their bearings in those moments when it was not quite clear which direction and how the planning of the data management system was proceeding; thus, it helped them prepare and manage tentativeness and unfinished businesses in a complex project.
Our main conclusion is that the tools of anticipation function in two ways: they help healthcare organisations and professional practices to adjust to new technology, and the technology to adjust to organisations and practices in a flexible, but predictable way (at least to some extent). In other words, tools of anticipation like the personalised plan allow for imagining and assuming pathways to utilising new technology.
Yet, anticipation work and its tools, the ‘plan’ included, met their limits when the Sirius project was suddenly closed down. As wider political and economic context was seemingly bracketed out of the scope of anticipation, the local politicians’ decision was completely unexpected by the Sirius organization and developers. This fate of Sirius has some similarities with Aramis, the project to develop an automated urban train system in France in the 1970s and 1980, famously narrated by Bruno Latour (1996). Both projects went through a passage from a firm belief in the improvement new technology will bring and commitment of the developers for actualizing the expectations to ending the project uncompleted as the political support vanished. Seen against Latour's narrative, two aspects of Sirius become apparent: first, the project and developers worked upon an object, or assemblages of objects, that did not exist, namely data-driven healthcare, and they used the ‘personalized plan’ as a tool both to imagine the non-existent object so that it can be planned and handled, and to translate ideas of datafication technology in the new environment of healthcare; second, while doing this forward-looking and anticipatory work the project and developers proceed with planning as if refusing to acknowledge potential problems of the technology and its implementation and immune to the signs of technical, professional and political controversy lingering around Sirius. However, Sirius is different from Aramis because it never came even near the implementation and no prototype of the system was built nor any piloting conduct. Sirius and the idea of personalized plan were never tested, and thus they did not actually fail; they just remained a plan, maybe with potential to be invigorated when data-driven medicine will be advocated in other projects.
Footnotes
Acknowledgements
We are grateful to our interviewees and informants for their participation in this study and all the help they gave us and to our research assistant Heta Konttinen for her contribution to data management and analysis.
Declaration of conflicting interests
The authors declared no potential conflicts of interest with respect to the research, authorship, and/or publication of this article.
Funding
The authors disclosed receipt of the following financial support for the research, authorship, and/or publication of this article: This work was supported by the Research Council of Finland (grant number 317303).
