Data sources and data collection

Interviews.

The interview schedule and approach were informed by principles of episodic [61] and realist interviewing [62,63] and by the guidance on interviews of Brinkmann and Kvale [64]. The interviews sought to identify challenges and drivers to the development, implementation and uptake of the EoLC data sharing project. The core interview schedule and further detail on the methods and theories underpinning the interview approach can be found in S1 File.

Interviews were conducted by MP between October 2013 and October 2015. Data were collected over four periods, reflecting distinct stages of the service development project:

1. ○ initial development, when the project tools and systems were still a work in progress: Oct 2013 – Mar 2014, 10 interviewees, all of whom project team and steering group members.
2. ○ several months after the formal launch of the project (Apr 2014) when GP and specialist services uptake was expected: Aug – Nov 2014, 13 interviewees, 12 of whom GPs and palliative care specialists.
3. ○ stage at which patients and carers were expected to have experienced care involving the sharing of data: Dec 2014 – Apr 2015, 10 interviewees, 9 of whom patients and carers.
4. ○ stage at which the urgent and emergency services were expected to have integrated the data sharing tools into their workflows: Jun 2015 – Oct 2015, 10 interviewees, 7 of whom working in urgent and emergency services.

We did not observe stage-related differences of perceptions of challenges and drivers. Further detail on interviewees whose roles did not fit the stage descriptions (5) or were interviewed outside of the above campaigns (1) can be found in S1 File.

We acknowledge the length of time which has elapsed since data collection (versions of this paper have been in the peer review process of different journals since 2019). We are not reporting on dated issues, such as: challenges around local organisational entities which no longer exist (e.g. Local Commissioning Groups); claims for the need of a “culture change”, with the latter achieved by the COVID-pandemic; IT-specific challenges which are likely to have been resolved since data collection due to the level of infiltration of technology in everyday life and COVID-related digital gains (e.g. lack of basic IT skills in some staff groups); and claims associated with events which had prominence in the then social discourse but have now faded away (e.g. the Liverpool Care Pathway scandal in palliative and end of life care).

The sample was purposive, aiming at maximum variation of roles, contexts and types of use of the data sharing tools. Written informed consent was obtained by all participants. All non-patient/non-carer participants received, as compensation for their time, a £30 gift voucher or the opportunity to donate the equivalent to a charity of their choice. The total number of interviews was 40 with 44 primary participants. The interviews lasted between 35 m and 1h 36 m; average length 56 m. The word count of the transcripts was close to 300,000 words. Table 1 and S1 File provide further detail on the sample and recruitment approach.

Download:

• PPT
  PowerPoint slide
• PNG
  larger image
• TIFF
  original image

Table 1. Sample characteristics.

https://doi.org/10.1371/journal.pdig.0000470.t001

Interview analysis and synthesis of interview and literature review data

The verbatim transcripts were checked against the audio-recording, corrected, anonymised and annotated by the first author. The analysis of transcripts and their linking to literature review data then progressed through four stages, each of them involving multiple iterations. Data were coded primarily in NVivo (versions 11 and 12) [67], with additional mapping and re-organisation carried out in Microsoft Excel and Word. Coding in NVivo was consistently “pluralist”, following Dupré [68,69]: excerpts were often attributed to three-five parameters rather than one or two most fitting ones. The four key stages of data analysis were as follows:

1. Thematic analysis was undertaken after nine interviews with the six project developers. The aim of that analysis was partly practical: to inform the day-to-day work of the service development team. Both the analysis and feedback on it led to the original analysis framework, which was then expanded through coding the contents of the literature reviews.
2. The resulting framework underpinned the analysis of the remaining 31 interviews, i.e. the analysis moved towards “framework analysis”[70]. Over 1,800 challenges and drivers to data sharing were identified in the process. These were then reduced to a set of over 800.
3. The latter 800+ parameters, together with their best illustrative quotes, were mapped in Excel, with a focus on pairing challenges and drivers. We also developed a framework of six main themes (the IT solution, project team, health professionals, patients, contextual and temporal parameters, and a set of “co-created” parameters), including 29 components across the six themes. Each of the 29 components was accompanied by a numerical coefficient of the ratio of challenges and drivers within it. The coefficient was used to prioritise areas for practical action.
4. As we felt that the above quantitively derived prioritisation was too contingent on our data and the framework still lacked coherence, parsimony and distinctive character, we followed threads from the work on pairing challenges and drivers. We re-coded in NVivo the 800+ challenges and drivers in terms of more formal characteristics, such as whether a challenge or a driver appeared in a pair or stood alone and what the nature of the relationship within a pair was. Finally, we refined the framework and re-attributed the illustrative quotes to it (in Word).

Stages 1, 2 and 3 of the analysis were conducted in 2016-2017. Stage 4 was conducted in 2019, after peer reviews of the original version of this paper.

Ethics approval

NRES Committee East of England – Cambridge East approved the study (Ref 13/EE/0291).

Patient and Public Involvement (PPI)

The study was supported by a study-specific PPI group. S1 File reports on user involvement using the GRIPP2 short form [71].

1.1. Radical innovation challenges

Of all pure challenges, the challenges of radical innovation were represented through the largest number of distinct subtypes: 1) magnitude of repetition involved in implementation; 2) multiplicity of available alternatives; 3) vicious circles likely to be experienced during innovation implementation; 4) uneven involvement of different stakeholders; 5) overvaluing the uniqueness of one’s work; 6) securing external support (e.g. a sponsor or host); 7) impact of delayed external innovation; and 8) slipping timelines. Below we discuss in some detail the first four of the subtypes, as these received the most attention in the interviews.

1.2. A health service “on the edge”

The challenges inherent in the very context of (UK) healthcare appeared to be the most prominent topic in the whole study, even if not data sharing specific and even if emerging without a specific prompt in the interview schedule. These fell into four main types: 1) resource limitations, 2) fragmentation, 3) constant transformation, and 4) environment deprioritising “extras”/ only focusing on “core business”. All those challenges are not only well known in health services research but are often elements of the everyday social discourse on healthcare. Here we describe only issues of fragmentation, as they were most often explicitly linked to the particularities of the EoLC data sharing project. The remaining subtypes of challenges are presented briefly in S3 File. Relevant quotes can be found in S2 File.

The high level of fragmentation within an otherwise national system was identified as a source of generic but, potentially, uniquely harmful challenges, as data sharing projects are by definition cross-organisational. Mostly, the fragmentation arises from and feeds back into the significant levels of autonomy of organisations and, to some extent, professions within the UK health service; the lack of clear mechanisms for driving multi-setting projects; the multiplicity of simultaneously running and often overlapping projects; and the lack of sufficient central/ national leadership.

A range of further aspects of fragmentation were discussed less frequently. The targets of different organisations could come into conflict with one another. Health professionals often lacked an overview of a patient’s end of life care journey and/or understanding of the role of their colleagues in it. The requirement for involvement in many cross-organisational projects was perceived as problematic: involvement may not be resourced from new funds but still be expected on the grounds of “we are the NHS”. Not only patient services were reported to be fragmented, but also local structures aiming to provide organisational support, such as IT support teams or training initiatives in end of life care.

The impact on data sharing of the health service fragmentation was experienced even more acutely in geographical and administrative boundary areas, which were often moving backwards and forwards in their belonging to local healthcare structures. Also, services with a broad geographical coverage, such as the major referral hospital for the region, had large numbers of patients not covered by the EoLC data sharing project, as such patients were coming from “other” Clinical Commissioning Groups.

1.3. Work in large impermanent teams

The third most frequently mentioned type of pure challenge arose from working in a large impermanent team, which had a loose hierarchy and limited shared lines of reporting and accountability. Participants in multi-setting data sharing projects have a key common goal. Yet they also have further sub-goals for data sharing that would benefit their organisations and staff while variably benefitting, making no difference to, or endangering the goals and practices of other organisations and teams. In this study, collaboration between organisations and teams within the health service was seen overwhelmingly negatively. (Note though that this negative perception did not apply to the core project team, see “2.2. Pure drivers internal to the project development and implementation team”.)

With minor exceptions, the discussion of this subtype of challenge remained at a highly specific level. Interviewees expressed frustration with specific people or organisations, without considering the possibility that these were presenting as “difficult” because of deep-seated, structural problems of interaction amongst elements of the health system. Issues discussed most often included: “politics”; the importance of watching out for the interests of one’s own team and organisation; the lack of action to match promises given; and differences in language. The language of IT was, expectedly, perceived as a particular challenge.

Most stakeholders involved in the data sharing project belonged to external teams and organisations (relative to the core project team). Their contribution was unpaid for by project resources. This created precarious involvement arrangements. There was always a background risk that an individual or team might disengage. Concerns about disengagement also limited the project leads’ capacity to manage or arbitrate in cases of conflict or performance falling below expectations.

Disengagement could be particularly hard to detect from individuals and organisations that were inconsistently represented on the working group. In several interviews it became clear that actions agreed upon or even proposed by some such organisations were not initiated. At the same time, the project team were progressing the work as if such actions had been completed or were at least underway (see “Uneven involvement” above).

1.4. IT work, narrowly construed

The multiplicity of non-interoperable clinical IT systems and the complexity of Information Governance (IG) were the two leading challenges in the IT work, narrowly construed category, in terms of degree of attention given to them by interviewees. IG is not discussed here, as the level of detail around it demanded a separate paper.

Arguments around choice, variety, and competition as drivers of continuous improvement are taken for granted in many contexts. Yet if a health professional interviewee commented on the variety of clinical IT systems, it was in terms of it being at best incomprehensible (“it’s just daft, isn’t it”; “makes no sense” [Out of hours professional 4, GP]; “I just don’t know how that could have happened, but I’m sure there must be some vested interest” [GP 7]; “it’s a shame”; “just seems bizarre" [Out of hours professional 1, Nurse]).

A small number of interviewees warned that technically enabled integration may not be meaningful practical integration. For instance, the movement from one “integrated” system to another could be unidirectional. Alternatively, the forwards-backwards switching was not necessarily possible without complex, and potentially unsafe, workarounds.

In addition to the multiplicity of systems and their lack of interoperability, several further and familiar aspects of a digital environment lacking maturity were discussed. These included: unresolved challenges around mobile working; “stickiness” of old clinical IT systems and software more broadly; the lagging behind with the implementation of comprehensive IT solutions in key settings; the presence of pockets across the health service where paper notes were still the norm; or generic signal issues.

Inadequate users’ knowledge and skills were also identified as a challenge. These related mostly to generic IT skills, particularly in some staff groups, and a limited understanding of record sharing. Importantly, it was impossible to convene a project team where all members would have high levels of IT skills in addition to their primary expertise, whether in a clinical area or project management in the health service.

Rarely, it was pointed out that IT systems are, after all, “work in progress”. Even the best amongst them may not necessarily live up to their promise; may not be improved upon fast enough; and ultimately fail for the needs for which they were sought, developed or bought, often after significant financial investment.

1.5. Rules, laws and algorithms in spaces also calling for humanity, flexibility and art

In discussing data sharing and health IT more broadly, several interviewees touched on their “orderly nature” – of rules, algorithms, logic, rationality, 1s and 0s, clear boundaries, etc. – and the ways in which it did not match the nature of health care. The latter was perceived as anything but orderly. The organisation, pathways and decision-making processes of healthcare are exceptionally complex. At times, they are not only complex but potentially irrational, primarily because of the endurance of historical patterns of organisation of services. Crucially, healthcare deals with embodied humans whose pain, suffering, needs and behaviours cannot be easily slotted into templates. It often requires as much art and creativity as it requires science and logic.

Even health professionals who were self-professed “techie” and loved “fiddling” with computers and new software, expressed significant frustration with some of the set-up around data sharing, with the sequencing of operations in the software being poorly synchronised with the flow of a clinical encounter. Some were proactive to engage with developers in looking for resolutions to challenges, but a positive outcome was not a given.

At other times it was less clear whether the clinical IT system was not “smart” enough in mimicking real-life processes or whether those processes were unnecessarily complex, with the challenges of representing them in an IT tool serving to highlight an improvement need.

1.6. Core tasks—Peripheral tasks

The EoLC data sharing project was expected to serve both experts/specialists in palliative and end of life care and non-experts, such as General Practitioners, other types of specialists, and even the so-called “low-skilled” workers, such as care home staff. It was an example of a project where the specialists are expected to lead the way, but are too few, and where the non-specialists are numerous, with various levels of pre-existing knowledge, learning needs, ability to shape their role by themselves, and motivation to become engaged in professional development that may not be crucial to their role. The challenge of simultaneously meeting the needs of users for whom an area of work is a core task or a peripheral one came from two directions – both end of life care and data sharing.

1.7. Work with highly sensitive issues

In a similar way, the project was a double exemplar of work which carries the risks of touching on highly sensitive, emotive, incendiary issues: death and dying on the one hand and personal space, privacy and confidentiality on the other. Respectively, the knowledge and skills needed for a successful, thorough implementation were complex and time-consuming to learn.

1.8. Technology—Human users

A little discussed but well-defined source of challenges concerned the interaction between technology and users, with the former, no matter how automated, doing nothing fully by itself. The challenge was particularly prominent with regard to the quality of clinical record keeping and especially its underpinning coding.

1.9. Market forces in public services

Challenges around the presence of market forces in a publicly funded health service were not specific to the EoLC data sharing project (which was non-commercial, funded by a research and innovation grant) but had an impact on it too. Perceptions of the impact of market principles and forces were contrasting: some interviewees saw them as infiltrating healthcare in ways that were harmful to its goals, while others saw them as insufficient for what it needs. In the whole study, no other name of an organisation or person external to the project was mentioned as frequently as the name of a UK supermarket chain – both as an example of efficiency in collecting and using consumer data and as a face for the fear of data sharing.

Box 2 and Box 3 offer, respectively, illustrative quotes and recommendations associated with the challenges discussed above. S2 and S3 Files provide further detail.

2.1. Pure drivers internal to the IT solution

Of the types of factors which propelled end of life care data sharing forward and which were internal to the IT solution itself, the interviewees highlighted: 1) the vision for the solution and its expected benefits; 2) the quality of the solution in terms of functionalities, performance and user friendliness and 3) the nature of the clinical domain.

Of these, the vision for and expected benefits of data sharing were by far most frequently addressed. Amongst themselves, the interviewees identified almost 60 major and minor advantages of the broad sharing of patient data. Major perceived advantages were:

1. ○ avoidance of unnecessary and unwanted hospital admissions
2. ○ improved medication decisions and increased confidence in making them
3. ○ reduction of errors and improved patient safety
4. ○ benefits to coordination and communication in broad multidisciplinary teams
5. ○ difficult conversations at the end of life handled more sensitively, without shock or repetition
6. ○ duplication of work reduced
7. ○ resources used more efficiently and processes made more reliable and smoother.

The brevity of the core data sharing template (where users who initiated a sharing process could enter data, some of them prepopulated) was repeatedly highlighted, alongside its simplicity, intuitiveness and good structure. They obscured all other functionalities, features and performance parameters of the broader solution.

Importantly, the nature of the thematic domain – palliative and end of life care – was seen as facilitating high level of commitment to data sharing.

2.2. Pure drivers internal to the project development and implementation team

The personality and leadership style of the project clinical lead, the composition of the core team, and the working style of its members as individuals and as a group were, with minor grievances, evaluated highly positively by both team members and external collaborators.

This positive overall picture did not mean that conflict and tensions were not present. The latter were more notable in early stages of the project and also appeared disproportionately more often in expanded formats of the team when, for periods of time, external colleagues were involved intensely to advance the project in specific ways or settings. Such challenges were partly discussed under “Large impermanent teams” above and are considered again under “Ambivalent forces” below.

2.3. Pure drivers at the interface between the internal and external

Significant work was required by team members to make the project fit with a range of features and requirements of the external environment, including: a national information standard for data sharing in end of life care; national and regional service monitoring and reporting requirements; local work on standardising data sharing; the local information management strategy; and local incentive structures (e.g. through adding fields to the template that would make its use the easiest way to implement a positive process and also report on it). Such work gave credibility to the project. It also aided its pragmatic attractiveness by allowing the simultaneous achievement of numerous goals if its tools were taken up.

Apart from the IT solution, the team or individual members also needed to “fit with” key structures in the external environment. Team members brought in pre-existing networks and connections or the “go-between”, “boundary-spanning” nature of their role as resources to the project. They also did new work to link with and influence external structures capable of advancing or slowing down the project.

2.4. Pure drivers external to the IT solution and team, but internal to the broader health IT ecosystem

In a small number of cases, interviewees mentioned the beneficial impact of developments within the broader health IT ecosystem, happening without any involvement from the core project team. These included the development of new functionalities in the main clinical IT systems; the trailblazing work of other data sharing projects; and the thoughtful practices of certain organisations and health professionals around consenting patients to data sharing. Most importantly, such a pure driver was the “crest of the wave” of interest in data sharing across the health economy, which had grown exponentially since the beginning of the project. This included some highly positive attitudes of health professionals and patients.

Box 4 and Box 5 offer, respectively, illustrative quotes and recommendations associated with the pure drivers. S2 and S3 File provide further detail.

3.1. Oppositional forces, temporary

We called “oppositional forces” challenges and drivers which appeared as a negation of one another. Typically, the driver was a head-on attempt to resolve a challenge. In the case of temporary oppositional forces, the driver resolved or would resolve a problem. For instance, the challenge of a major upheaval within a collaborating healthcare setting, namely the introduction of an electronic patient record, was addressed by changing the intended timing of rollout. The risk of “saturation” with local end of life care projects was addressed by integrating the educational intervention of the data sharing project with a pre-existing local educational intervention in end of life care. Solutions entirely external to the project could also resolve a challenge once and for all with a single, be it complex, programme of work: e.g. the challenge of additional and multiple log-in processes, passwords and user profiles was envisaged as resolved, in the future, by a single log-in solution.

3.2. Oppositional forces, reoccurring

In most cases, however, the challenge-solution battle needed to be integrated into routine services or efforts needed to be renewed at regular intervals. Most prominent examples of such pairs of challenges and drivers were:

1. ○ The lack of knowledge, skills and awareness, whether in end of life care or data sharing, vs. the provision of appropriate training initiatives.
2. ○ The lack of information and/or the presence of negative communication patterns vs. the reliable provision of information and the engagement in good, effective communication.
3. ○ Acting from the “wrong motives” (such as hitting organisational targets, meeting the requirements for additional financial incentives, or focusing “on what keeps the Board in a job”) vs. acting in view of the patients’ needs and interests.

Interviewees discussed such problems and solutions in the abstract, with only a few making a comment of their recurring nature. Even when the recurrence of the need was mentioned, it was primarily as something frustrating and inconvenient, rather than as a natural feature of certain types of work.

3.3. Ambivalent forces: legitimate differences in clinical contexts or contexts requiring clinical information

A very small number of interviewees (conceivably, because this was an “obvious” consideration) highlighted how different patient conditions would necessitate different choices with regard to data sharing. This concerned primarily circumstances where a patient’s record contained information about, for instance, sexual health, mental illness, sexual abuse, domestic violence, criminal convictions as well as conditions which limit access to certain professions or compromise rights to insurance claims. Such cases could be identified and circumscribed for special data sharing arrangements. Yet the selective withholding of information from the whole of a patient’s record was reported to be unfamiliar or difficult and to create challenges of its own.

In a further set of clinical contexts, data sharing could be largely irrelevant, e.g. in cases of seasonal illnesses or bone fractures. The presenting acute situation (over-)determined the course of action. Circumstances of extended hospital stay could also limit the value of accessing information from community services or sharing information back with them.

Most consequentially, there are irreducible differences between the record keeping needs of a health professional who generates information for their and their organisation’s needs and the informational needs of other potential users. Information which enables one’s own work can be irrelevant, too much, or too little for those receiving it. To address this challenge, specialist palliative care teams, for instance, were completing two templates – one for sharing and one for their internal needs, with the cross-population of information enabled in one but not in the other local specialist setting. The mismatch of needs became even more significant if the recipients were the patients themselves. While some solutions could bridge the gap, it would always remain a question of “squaring a circle”.

3.4. Ambivalent forces, divergence or complex entanglements of values

One of the richest subtypes of “ambivalent forces” had its roots in differences of perspective, values, evaluation criteria, views, preferences and similar value-laden phenomena of which most people would argue, from a rational stance, that they vary legitimately from person to person and are a matter of personal choice. Yet most people again, when emotionally involved, would find it hard to countenance values, perspectives, views, etc. which are polar opposite to theirs without experiencing them as wrong or misguided. Such diversity and conflicts of values were relevant to core features of the EoLC data sharing project.

Most clearly, it was observed in relation to the nature of the data sharing template and in terms of opposing preferences for detail vs. simplicity. Some respondents argued for the benefits of the comprehensive capture of information. Others saw ultimate brevity as crucial for uptake by busy practitioners. Some preferred the template to be multifunctional, for instance including frailty and old age in addition to palliative and end of life care. Others wanted a clear end of life care scope. Some asserted the gains in shareability, monitoring and evaluation of more structured formats. Others preferred the detail and context added by accommodating more free text in the template.

Conflicts of values were observed also in relation to the very possibility for data sharing. Some organisations would see more benefits in keeping their in-house templates, far better tailored to their own needs, while others would convert to templates standardised for use across the local health economy and enabling better (or even any) data sharing. The relative preference for independence, including independent faster improvement, vs. collaboration, the price for which may be slower progress, was in this case the underpinning tension of values that hinder or drive data sharing.

Conflicts of values also affected the particular type of data sharing advanced. For instance, some interviewees argued for the benefits of planning future care and consulting existing care plans, while others prioritised the immediate, adaptive response to the clinical situation at hand (with consequences for whether a care plan was included as a data sharing field or not). Differences of values and evaluation criteria also affected assessments of more diffuse characteristics of the data sharing project, such as its progress and success or the support structures in which it was embedded or which it had set up.

Each of the above extremes could advance some opportunities and goals (act as a driver) and constrain or block others (act as a challenge). No interviewee argued for any of the extremes, such as a tick-box only or a text-only template. Not infrequently, they acknowledged some advantages of the alternative perspective or described their own trajectory from practising differently (such as using an in-house template) to their current preference (endorsing a locality template to enable data sharing). Yet with the exception of one interviewee, who discussed pros and cons in an equitable manner and did not commit to a personal conclusion, all had clear current preferences for one or the other side on the above continua.

3.5. Ambivalent forces, unintended consequences

In a key pattern of a driver-challenge relationship, overall highly positive outcomes of data sharing could have harmful unintended consequences, for instance:

1. ○ The greater ease with which GPs could obtain specialist palliative care advice, by having specialists access the GP record, could mean that more GPs felt their work was interfered with or judgement questioned.
2. ○ The provision of more informational support to clinicians who were uncertain in their judgement could mean that they experienced greater pressure to make decisions by themselves. Alternatively, there was a risk that non-specialists became unjustifiably confident in their ability to make decisions requiring expert input.
3. ○ Informing colleagues, through a shared record, that one had initiated an aspect of care (e.g. conversations around the end of life) could result in the other side taking such aspects of care as addressed as opposed to initiated.
4. ○ Being able to see a well-established clinical history could prevent the fresh perspective which would have provided the solution.
5. ○ Crucially, having up-to-date external information could be highly valuable, but having outdated information, which could be the case even if the record appeared up-to-date (e.g. because services unrepresented on the record were involved), could be far more dangerous than acting from the situation at hand.

Box 6 and Box 7 offer, respectively, illustrative quotes and recommendations associated with oppositional and ambivalent forces. S2 and S3 Files provide further detail.

Summary of main findings

Here we presented a comprehensive yet parsimonious framework of challenges, drivers, and oppositional and ambivalent forces to patient data sharing, with a focus on data sharing at the end of life. The framework was derived from a rich dataset, consisting of in-depth interviews with 44 maximum variation participants. Findings from the interviews were mapped against findings from four literature reviews on health information technology and health information exchange, covering 135 studies. Our final proposal was for a 9-component framework of “pure challenges”, drawing parallels between patient data sharing and other broad and complex social and sociotechnical domains; a 4-component framework of “pure drivers”, defined in terms of their internality or externality to the IT solution and project team, and thus the level of control of the latter over them; and a 9-component framework of “oppositional or ambivalent forces”, reflecting the persistent tensions in challenge-driver pairs and the fact that many parameters can be simultaneously a challenge and a driver, depending on context, goals and perspective.

In addition, we derived recommendations for practical action based on or informed by the data, also building on findings from other arms of the broader study, the broader research and IT literature, and our participation in the applied aspect of the project. These are well grounded proposals but, nonetheless, require further refinement, testing and evaluation.

Comparison with the existing literature

There is a broad range of frameworks in the field of implementation practice and science, which, in comparison to the framework proposed here, have been far more extensively articulated and researched, and widely tested in implementing innovations, whether in healthcare or other fields. Some of them have already been incorporated in this study through the inclusion of conceptualisations from the four literature reviews. In Box 8, we describe five highly influential frameworks in some detail to contextualise better the distinctiveness of the framework we are proposing.

All of the above frameworks share a focus on entities and contexts (e.g. the IT solution, the organisations, the internal and external environment), on actors and stakeholders, on phases/ timepoints, and on complex cognitive, motivational or outcomes-related constructs in need of operationalisation (e.g. knowledge, attitudes, success, value proposition, impact, performance) in addition to an emphasis on processes, strategies and actions. Our interim model (briefly noted under “Interview analysis and synthesis of interview and literature review data”) followed similar conceptual lines. The framework we ultimately proposed has three main features which give it a distinctive character. This distinctiveness, we argue, justifies its application, whether as a supplementary tool or as a standalone one if further developed:

1. ○ Emphasis on the form of challenges and drivers and a lesser concern with where they appear in terms of entity, context, or actor type (e.g. the IT solution, certain organisations, certain stakeholders); when they appear (e.g. preparation stages); what cognitive, motivational or outcomes-related construct they concern (e.g. knowledge, impact, ownership, etc.), or what activities they pertain to (e.g. designing and adapting the IT tool, resource mobilisation, or evaluating progress).

For instance, we suggest that there is value in considering “vicious circles” as one type of challenge, even if the specific vicious circles we have identified can also be considered challenges of the early stages of implementation, challenges of user attitudes, or challenges of adequate resourcing, amongst others. One of the benefits of focusing on the form here is that it alerts implementers that it is almost automatic to get trapped in a challenge unless it is addressed systematically and meticulously. Similarly, we suggest that it is helpful to see the “magnitude of repetition” as a challenge of a type, whether it concerns the repetition of setting up computer systems or the training of staff. This not only supports being realistic about resources and timelines, but also leads to expecting attrition of motivation and turnover of staff in specific tasks. Actions in response can then be proactively planned, such as job rotations, secondments or mid-project handovers. To add an example from the drivers category, we suggest that there is value in grouping together drivers which focus on “fit”, whether it is the IT solution adhering to a variety of national and local standards and requirements, or members of the project team participating in and weaving relevant stakeholder networks. Attending to a more abstract form in this case underscores the importance of also “fitting in” in a context where, typically, “standing out” is considered the road to success.

1. ○ Emphasis on ambivalence, ambiguity and persistent tensions as fundamental forces in the field of innovation implementation.

Most clearly, this emphasis on ambivalence, ambiguity and persistent tensions is seen in the formulation of the category of oppositional and ambivalent forces. It is also reflected in the form of four of the nine high-level challenges (e.g. core tasks – peripheral tasks, market forces – public good) and a number of the subcategories of challenges (e.g. rationality of IT tools revealing irrationalities in the system, variety of languages, etc.).

Consistently formulating parameters with a view to perduring tensions emphasises the complexity, recalcitrance, and reoccurrence of certain challenges around data sharing and helps guard against naïve implementation planning that is suited for projects of lesser complexity. In some cases, the formulations of parameters point towards an ultimate irresolvability of a challenge, even if radical improvements are always possible. In other cases, the formulations suggest that the effective actions are not only beyond the scope of a single project, but beyond the scope of implementation work more broadly.

For instance, the “Unintended consequences” (a subtype under ambivalent forces) demonstrate some of the ways in which even the most successful form of data sharing will lead in its wake negatives that need to be controlled for. The parameters under “Technology – Human Users” (“The quality of data sharing is irreducibly determined by the record keeping practices of users” and “The quality of data sharing is irreducibly determined by the quality of classification systems and ontologies underpinning clinical IT systems”, see S3 File for detail) remind us that some challenges which every data sharing project will encounter are unlikely to be successfully resolved at the level of project implementation. Low-level solutions can be offered in individual projects, such as training in adequate code assignment in patient records. Yet the long-lasting effective action is further upstream, e.g. in medical education or research on biomedical ontologies.

1. ○ Attention to external and longer-standing parallels as a source of fruitful learning

Finally, all nine types of pure challenges other than the “IT, narrowly construed” category are shared with multiple other areas of social or sociotechnical practice, from the arrival of the railways, through working with dangerous equipment, to teaching mixed abilities classes (examples of parallel areas are offered in Box 1). Many of these areas have a long history as well as everyday presence in our lives. As such, they are potential sources of easily accessible learning, whether from ongoing implementation efforts; theoretical, empirical or historical research; or even artistic representations. If, in the context of this study, nine types of shared challenges were experienced as overwhelming, it makes sense to seek lessons outside of the field of health IT, despite the discomfort of crossing disciplinary boundaries.

Implications for practice

Most broadly, this study underscored how important it is for data sharing project teams to look outside of the IT tools they are building and refining. Over three-thirds of the drivers and challenges we identified at the level of the 800-component intermediary framework did not pertain to the IT solution at all. While the nature of the study sample is likely to have affected the ratio observed (users and implementers were more than IT developers), the number and magnitude of non-IT challenges and drivers identified was substantial. This seems to justify a recommendation that teams working on data sharing project need to focus persistently and intentionally on shaping the social interactions and structural and contextual parameters in the midst of which their data sharing tools are implemented, not only or primarily on perfecting them.

A high-level finding was also that challenges and drivers form a broad range of relationship patterns. The loose understanding of challenges as “negative factors” and drivers as “positive factors” that also tend to stand in simple opposition to one another is not only conceptually inaccurate (see S4 File) but also prevents us from identifying opportunities for practical action. The frequency with which complex factors can function, or appear, as both challenges and drivers highlights the vital importance of skills in eliciting the assumptions of stakeholders; in managing conflict; facilitating good decision making processes; and navigating multiple needs, interests and even worldviews, amongst others. It can be argued that “bridge-building” skills and “go-between” roles will often advance a data sharing project far more than high level IT skills and domain-specific clinical and practical knowledge.

It is also important to acknowledge that certain tensions between “a driver perspective” and “a challenge perspective” towards the same issue will never be resolved. There will always be situations when that which advances one valued goal in data sharing or patient care simultaneously blocks another valued goal. Perhaps most notably, informational needs may differ significantly across types of health professionals and contexts. It is often sorely inadequate to simply share the data. Instead, the data may need to be selected, reorganised, re-conceptualised, condensed, expanded, or otherwise enhanced so that their sharing is genuinely beneficial. This requires time and resources, both of which are in short supply in overwhelmed health systems.

More positively, organising the “pure challenges” around features and tensions familiar from other types of human endeavour points to a wide range of domains from which data sharing initiatives can draw lessons and inspiration. The IT world is unique and new (though, arguably, no longer that new) but it is still more akin to other forms of human endeavour than may be typically acknowledged.

Implications for research

By now, the data of the study are dated, even if the framework we propose is at a level of generality where most issues are persistent, recurrent and will remain so for decades to come. The big picture we have drawn misses potentially crucial new elements, such as general advancement in IT and data sharing; opportunities which developments in AI may be offering; the impact of more recent legislation, such as the GDPR; new expectations for interoperability[72,73] and, crucially, the effects on digital health of the COVID-19 pandemic. Such changes may have, for instance, substantially reduced the number of “pure challenges” we formulated and this needs to be explored. The framework requires further conceptual specification, including through case studies from other clinical domains. Its practical utility also needs testing and evaluation. Whether our proposal has the potential to grow into a credible standalone implementation framework, including beyond data sharing, or can only serve to support other frameworks is, ultimately, an empirical question.

Strengths and limitations of this study

To our knowledge, the broader study of which this sub-study is a part is the most multi-layered study on Electronic Palliative Care Coordination Systems and patient data sharing conducted to date, combining in-depth qualitative work, embedded in findings of pre-existing literature reviews, and also involving quantitative, conceptual and critical arms reported on elsewhere.[48,58–60] The rich qualitative dataset used here and the depth of both questioning and analysis are a particular strength of this work, in a field where qualitative research is rare and of limited quality. The framework of challenges, drivers and oppositional and ambivalent forces offered is, as sought, comprehensive yet parsimonious. It was rigorously derived from the data, yet it also has a degree of conceptual discipline and coherence which many data-driven outputs lack.

This was, however, a single case study in a single locality in England, concerning a particular type of data sharing – data sharing for individual care at the end of life. Some of its findings are unlikely to be generalisable, even if we aimed to increase generalisability through including findings from literature reviews that addressed data sharing more broadly (outside of end of life care) and health information technology other than data sharing. As the depth and richness of the interview data was much higher than that of the reviews, the primary data retained a dominant role.

There are aspects of a more comprehensive picture that are missing from our work by virtue of the nature of the case study and its context, namely:

• The project relied almost fully on functionalities of pre-existing clinical IT systems. The challenges experienced in ground-breaking IT development are thus missing.
• The project has been taken forward in close collaboration with the local health economy, with many of the links with its decision makers pre-existing or with known routes to forge them. For many developers and start-ups in the context of health IT, lacking access to decision makers in the health service will be one of the biggest, if not the biggest, challenge they are experiencing.
• The UK health service – a national health system free at the point of care and with a relatively limited role of the private sector – is not a setting conducive to exploring the numerous drivers and challenges around market forces, commercialisation and competition in patient data sharing, while such factors may be leading in other countries. It is plausible, however, that they have a decisive role in a UK context too, even if insufficiently detected by this study.

The study also had both strengths and limitations in terms of sampling:

• We achieved the maximum variation we aimed for in terms of roles; contexts (including of healthcare settings and organisations but also of rurality and deprivation); clinical IT systems; types of use of the data sharing tools; background and levels of experience of health professionals; age groups, gender, conditions and type of relationship for patient and carers, etc. (see Table 1). However, we did not have as an explicit aim to achieve maximum variation in terms of aspects of Equality, Diversity and Inclusion (EDI) such as race and ethnicity, gender non-conformity, or sexual orientation. The study was set up in 2013, when such parameters of diversity could be overlooked in favour of maximising variability along other parameters.
• The narrow IT and IG specialists in the sample were six (respectively 4 and 2), even if many participants were clinicians or commissioners with notable interest in health IT and associated formal or informal roles. From the perspective of elucidating IT-specific challenges, the study may not have had enough interviewees of the right technical background. On the other hand, the maximum variation sampling approach, which meant that IT specialists were only one of the subgroups of interest, allowed for a more comprehensive picture of challenges and drivers to emerge.

As noted on several occasions and discussed in more detail under Implications for Research, the datedness of the data is also a key study weakness. The data (both interviews and literature reviews) were analysed in 2016-2017, with further conceptual analysis conducted in 2019. Since then, the paper has travelled the peer review system of several journals. It was beyond the capacity of the authors and the funding available to them to strengthen the study through the analysis of more recent data. Nonetheless, this was a rich dataset from a sensitive period in the development of data sharing solutions, complemented by literature reviews spanning publications from over two decades. Conceptual frameworks are also less prone to the detrimental effects of time and, if good enough, will both withstand new empirical tests and allow for further development and refinement.