In 2022, the Department of Health and Social Care (DHSC) released its data strategy, “Data Saves Lives: Reshaping Health and Social Care with Data,” to improve how the National Health Service (NHS) uses data [1]. A key goal of the strategy was to develop the appropriate technical infrastructure to ensure that the data architecture underpinning the NHS works in unison, enabling more effective and efficient use of data. The data strategy would be carried out via a commitment to develop and publish a draft of the standards alongside an interoperability strategy to ensure that fit-for-purpose standards are widely adopted across health and adult social care. The anticipated standards would reuse and build upon international standards where applicable. However, the NHS’s current ability to fulfill this strategy across hospitals and other facilities is not well understood due to a lack of visibility into its digital development capabilities.

The Global Digital Exemplar (GDE) program was conceived in 2016 by NHS England to achieve digital transformation in select NHS trusts. It was hoped that the program would create a knowledge-sharing ecosystem to spread learning to other NHS trusts [2]. The program resulted in the creation of 16 GDE acute trusts [3,4], 3 GDE ambulance trusts [5,6], and 7 GDE mental health trusts [7].

While the GDE program improved the use of digital within the NHS, studies carried out since have highlighted that NHS trusts and social care providers still lack digital maturity [8], and that a digital divide has emerged between NHS trusts with and without GDE funding [9,10].

The “Data Saves Lives” strategy uses user stories to describe various systems that can work together in a secure, safe, accessible, and interoperable manner. Within this strategy, the UK Health Security Agency (UKHSA) aims to prioritize FAIR (findability, accessibility, interoperability, and reusability) principles [11]. In the context of FAIR, interoperability is defined as “the data need to interoperate with applications or workflows for analysis, storage, and processing.” However, interoperability should not be viewed solely from a data perspective; it must also encompass system interfaces, the methods by which data are produced and consumed across the NHS ecosystem. While a universal approach to the architecture of NHS systems is impractical, achieving interoperability requires a commitment to key design considerations across data and application interfaces. This ensures the secure, safe, and effective use and reuse of data and information across system and organizational boundaries.

To complement interoperability, NHS England’s Transformation Directorate is also in pursuit of making source code within the NHS freely available and downloadable through the use of open-source. Both open-source and interoperability can save NHS services from duplicating effort and help them build better services faster through shared resources [12]. The NHS Transformation Directorate presently promotes the open-source languages Python (Python Software Foundation) and R (R Foundation for Statistical Computing) through their network and engagement communities as common standards for programming [13].

The digital capabilities of NHS services in England are diverse, with ever-evolving services providing differing levels of digital capability, open-source use, and interoperability standards. Official recommendations and advice struggle to unify the NHS effectively. NHS trust application development teams play a vital role in uptake in these areas, but in the present landscape, the NHS has limited visibility of these teams and their capabilities. NHS trust application development teams are focused on the creation and deployment of digital technologies designed to improve clinical care, patient outcomes, health system efficiency, and user engagement. This includes the development of software applications for clinical workflows or patient self-management, websites that provide access to health information or services, and innovative technological solutions such as artificial intelligence tools, remote monitoring systems, or digital diagnostics that address existing challenges or create new capabilities within health care delivery. The key objective of this paper is to illuminate the current state of NHS trust application development teams in England by documenting their capabilities and technologies, while comparing standard trusts with those that have received extra funding via the GDE program, thus providing a starting point for the evaluation of current practice.

We documented the capabilities and technologies used in the NHS to develop digital products and services. Our data source was Freedom of Information (FOI) requests sent to NHS trusts in England. In our FOIs to NHS trusts, we asked for the disclosure of all departments and teams handling application and software development, websites, and technical innovation, along with the number of team members and roles. Further information regarding the teams was requested, covering technologies and software design methodologies used, use of open source, development of service user websites and apps, innovative collaboration with clinical staff, tenders for system development, developments for others, selling systems commercially, and use of innovation grants. Eleven of the 14 FOI questions were designed to elicit clear binary responses (1=yes, 0=no), which made them straightforward to answer and reduced the potential for variability or interpretation bias across NHS trusts. Respondents could still provide additional detail if available, but the core data remained consistent (Table 1). To ensure the information received was relevant, focused, and reflective of genuine NHS digital capabilities, all trusts were appraised against the inclusion criterion of having teams and departments handling application and software development, websites, and technical innovation. To meet this criterion, the NHS trust had to respond “yes” to question 1 (Table 1). The explicit exclusion criteria were trusts without dedicated teams handling application and software development, websites, or technical innovation; trusts that did not respond or declined to provide information; and those that submitted their FOI response after December 31, 2020.

All technologies were appraised against the inclusion criterion of being a programming language, framework, library, database, query language, interoperability standard, application programming interface, web service, or version control and collaboration platform. To meet this criterion, it had to be possible to find the technology via a Google search when the technology’s name was entered as the search term, and the returned results identified the technology as matching one of the inclusion criteria. Examples of matches that were deemed acceptable included legitimate sources such as developer websites, corporations, and media outlets.

On June 8, 2020, a list of NHS trusts in the United Kingdom was requested through an FOI email to NHS England, asking for the contact details of all NHS trusts within the United Kingdom. This yielded a list of 226 NHS trusts. During July 2020, the FOI email address and FOI contact form for each trust were identified, and an FOI email request was sent to the Freedom of Information Act (FOIA) officer or department of each of the 226 trusts. The questions asked are reported in Table 1. Each initial question had a further open-ended subquestion asking for more details when a trust confirmed the existence of any associated information. Since FOI responses vary in format and structure across NHS trusts, the data had to be interpreted on a case-by-case basis rather than through a uniform extraction template. According to the FOIA, requests must be answered within 20 working days of receipt [14]. Due to the COVID-19 pandemic, the author allowed until December 31, 2020, for a response to keep all data within the same year. Retrospective ethical approval was requested from the Aston University Department of Business and Social Sciences Ethics Committee.

A conceptual content analysis methodology was used to conduct the data analysis. This approach facilitated the extraction of both quantitative and qualitative insights from the open-ended responses obtained via FOI requests. Specifically, it enabled the generation of a high-level statistical overview of digital capabilities across NHS Trusts, as well as a more granular examination of the technologies and methodologies reported by these institutions in relation to the study objectives.

To support systematic analysis, a codebook was developed to categorize the FOI responses (Textbox 1). Based on this codebook, the lead author designed and implemented a bespoke data management system through which the FOI response data were processed. Following data entry, the coded responses were exported as a complete dataset for statistical analysis using SPSS (IBM Corp).

A detailed classification of the types of data extracted from the FOI responses is provided in Table 2, as categorized using the codebook. The dataset predominantly consisted of dichotomous variables.

To establish whether the answers to these questions differed as a function of trust funding (standard or GDE), tests of association were used. A series of chi-square tests was conducted as an additional layer of validation to enhance the robustness of the findings for questions 1, 3, 4, 6, 7, 9, and 11. For analysis, “No” and “N/A” responses were collapsed into a single category, and only “Yes” and “No” responses were included in the final tests. Assumptions were checked, and when violated, a Fisher extract was used instead. All analyses were conducted using SPSS for Windows (version 25; IBM Corp).

The Aston University Department of Business and Social Sciences Ethics Committee has reviewed and granted approval for the study. The study used UK FOIA data from NHS trusts, a process that supports transparency and public access to government-held information. The ethical considerations primarily focused on ensuring adherence to FOIA guidelines and that the requests were legitimate, appropriate, and respectful of the privacy rights of individuals and NHS trusts involved.

As the study did not involve human participants directly, and the data requested were publicly available, there were no concerns regarding private or sensitive data. Ethical issues related to informed consent and participant confidentiality were not applicable. However, all data requests were made in alignment with the principles of transparency, fairness, and public accountability set out by the FOIA.

In addition, the study adhered to best practices for data handling and reporting, ensuring that the requested data were used responsibly and in compliance with data protection laws where applicable. Any personal or sensitive information was either excluded or anonymized to protect confidentiality. To ensure fairness and safeguard the identity of NHS trusts, all reporting was done in a manner that made it impossible to trace data back to individual organizations, unless the FOI responses were requested directly from the NHS Trusts.

We present the data pertaining to (1) response rates, (2) capabilities, (3) technologies, (4) open source, and (5) interoperability standards.

Out of 226 trusts, 191 (84.5%) completed the FOI request, 23 (10.2%) acknowledged receiving the FOI request but never provided followed up with answers, 7 (3.1%) had merged with another NHS trust, 2 (0.9%) sent partial information consisting of an organizational plan, 2 (0.9%) refused the FOI because it would take too long to complete, and 1 (0.4%) FOI email address no longer accepted emails. In total, 161 (84.3%) met the inclusion criteria by having teams or departments handling application and software development, websites, and technical innovation. The final sample comprised 83% (134/161) standard trusts and 17% (27/161) GDE trusts.

Overall, 138 out of 161 (86%) trusts with teams disclosed the technologies they used. A total of 84 technologies were identified: 27 programming languages, 19 frameworks, 10 libraries, 11 databases, 1 query language, 7 interoperability standards, 5 application programming interfaces or web services, and 4 version control and collaboration platforms. All technologies are summarized in Table 3.

Python, the programming language used and promoted by NHS England and the NHS Transformation Directorate, was disclosed by 7 out of 138 (5.1%) trusts with teams that disclosed technologies. R, the programming language used for statistics and data science, was disclosed by 2 out of 138 (1.4%) trusts with teams that disclosed technologies. The most disclosed query language was Structured Query Language with 88 out of 138 (63.8%) trusts, and the most disclosed programming language was C# with 81 out of 138 (58.7%) trusts.

Overall, 25 out of 138 (15.5%) trust teams said they always used open-source technology, and 9 out of 138 (5.6%) said they used open-source sometimes. In total, 119 (73.9%) trusts said no, 6 (3.7%) said the question was not applicable, and 2 (1.2%) declined to answer on the grounds of security. There was a nonsignificant association between team type and open-source use (χ²₁=0.014; P=.91). This suggests no difference in the use of open source between standard and GDE teams. Eight out of 138 (5.8%) trusts with teams that disclosed technologies indicated they used version control and collaboration platforms. A total of 4 platforms were identified in this review. The most used was Git, reported by 5 out of 138 (3.6%) trusts with teams that disclosed technologies.

Overall, 24 out of 138 (17%) trusts with teams that disclosed technologies referred to interoperability standards in their responses. A total of 7 interoperability standards were identified. The most disclosed interoperability technology was HL7, mentioned by 11 out of 138 (8%) trusts.

This study is the first attempt to document the capabilities and technologies of NHS trust application development teams at a particular point in time. While these capabilities and technologies are changeable, the paper provides future researchers, commissioners, and policy makers with a baseline from which to build. The data presented raise several interesting questions relating to capabilities, open-source use, interoperability use, and programming languages.

The study was reliant on the provisions of the UK FOIA (2000) for data collection. Approximately 85% of NHS trusts responded to the request. Although this represents a large sample of trusts, it is difficult to ascertain the extent to which they are representative of all trusts. FOI requests rely on the expertise of those responsible for handling them in any given NHS trust, and the author was unable to determine how accurate and thorough individual responses were. During the data collection period, trusts were under immense pressure due to the COVID-19 pandemic, meaning that many may not have had the capacity to respond accurately. While most trusts addressed the questions posed, some declined to respond on security grounds. These data gaps, however, were minimal.

Digital maturity across NHS trusts is presently considered to be underdeveloped, with previous reports highlighting the need for the NHS to bridge the digital divide to avoid the creation of a 2-tier secondary care system [10]. While this may still be true in some cases, the data presented here highlights that in-house processes to develop digital capability are well established in 84% of responding trusts. Overall, no statistical differences were found between trust types and these results. This may indicate that increasing in-house capability to carry out digital projects was not a consideration when trusts received GDE funding. These results also highlight an issue with digital maturity measures such as HIMSS EMRAM (Healthcare Information and Management Systems Society: Electronic Medical Record Adoption Model). The measure exclusively focuses on technological functionality, such as electronic health records, and does not consider human and organizational capabilities [2]. The apps lead to an incomplete picture of a trust’s digital maturity. While no significant differences were found between trust types, the overall results for each question highlight some interesting findings.

A review by Sood and McNeil [15] highlighted that it would be impossible for the NHS to become a modern, effective, and efficient health care system without fully embracing the digital agenda. The results of this survey reveal that trusts are working toward overcoming Sood and McNeil’s [15] concern, with 69.6% of respondents reporting the creation of websites and apps to help service users.

A study by Asthana et al [16] investigated how, despite having a tax-funded NHS and a strong policy toward eHealth innovations, the English NHS had been limited in the extent to which it exploited digital potential. The survey results indicate that 93% (150/161) of respondents help clinical staff formulate innovative ideas. So, despite the suggestion of limited exploitation, NHS trusts are actively working to enable their clinical staff to innovate. However, the data do not reveal why, if this practice is commonplace, it has not been exploited to its full potential. Possible reasons may include limited resources regarding time, staffing, and funding.

The NHS Global Exemplar program was implemented to establish a knowledge-sharing ecosystem to spread learning among NHS trusts [2]. The survey results indicate 34% (55/161) carry out this practice. NHS England needs to do more to promote digital collaboration between trusts. Encouraging more digital development between organizations would help innovation and the leveling up of digital NHS services. Making trust teams aware of collaboration platforms such as the FutureNHS, that is used to support the right technology solutions to health and social care [17], could enable better sharing of technical innovations between trusts.

Innovation is critical in NHS England achieving the ambitions set out in the mandate, to increase the pace and scale of change. The NHS’s Accelerated Access Collaborative (AAC) reported 2708 innovations being developed in 2019/2020 [18]. Survey data indicate that only 21.7% of respondents had applied for innovation grants. NHS England needs to do more to promote the innovation funding available to trusts. Academic Health Science Networks (AHSNs), now known as the Health Innovation Network, were established by NHS England in 2013 to spread innovation, improve health outcomes, and generate economic growth [19]. If the Health Innovation Network were made more accessible to trust development teams, the internal potential of trusts to unlock innovation could help to maximize their benefit and better fund digital maturity. In addition, trusts could use the funding streams advised by the Health Innovation Network to independently create new digital innovations. Unfortunately, there is a limited amount of investment available, and not all trusts can benefit from this type of funding, but more should be done to encourage trusts to apply for these grants.

NHS England has tried to instill open-source technology within the NHS for nearly a decade through multiple strategic programs such as the Open-Source Program and Code4Health. The latter aimed to serve as a vessel for promoting open-source technology through clinicians [20]. The survey results revealed that 73.9% of trust development teams do not use open-source approaches, suggesting that previous initiatives have had limited cultural influence, with developers still opting for closed-source methods. Recent publications, such as the report by Goldacre et al [21], have helped to put forward proposals for using open-source implementation and draw focus to NHS data analysts.

GitHub is the NHS’s preferred platform for publishing open-source code [13]. However, the results of the survey show that only 5.8% of respondents listed using version control and collaboration platforms, and none of these gave reference to GitHub. NHS England needs to better communicate its desire for the NHS to use GitHub and open source and to work to promote this across all services. Without a unified approach to implementation, GitHub and open-source practices will continue to be used inconsistently across the NHS. The NHS data strategy has committed to making all new source code that is produced or commissioned open and reusable by default [1]. For this commitment to succeed in the NHS, the DHSC needs to go beyond publication of policy and digital guidance. Training and tools will be required to enable this at a regional level, meaning significant investment would be required, as services currently do not have the funding capacity.

There are presently 3 network and engagement communities run by NHS England’s Transformation Directorate: Analyst X, NHS-R, and NHS Python [22]. The NHS Python community is focused on the promotion of open-source practices. However, this is done purely in conjunction with the Python programming language. Survey results showed that only 5.1% of respondents disclosed using Python. For open-source to be more widely adopted, a new open-source program of activity is required for the NHS. This should be aimed at the full spectrum of roles within the data process cycle and focus on dominant technologies used by NHS services. This, in turn, will make the community more inclusive to all NHS services and help to increase the adoption of open-source technology. The program should be coordinated at a regional level, with open-source champions that have both technical knowledge and understanding of data processing at the helm. The actions required to carry out this recommendation would be a large undertaking, and whether NHS England has the time or capacity to do this in the current climate should be considered; it may not be feasible. It will also be reliant on trusts being willing to involve themselves in the program.

The objective to improve interoperability has been included in several NHS plans, and the end benefits of advanced interoperability are well recognized [23]. The primary benefit of interoperability is the ability to offer safe and reliable information transfer across the care pathway, reducing the possibility of adverse clinical outcomes [24]. The survey showed 17% listed interoperability standards in the technologies they disclosed. The DHSC has emphasized that it wants the NHS to use Fast Healthcare Interoperability Resources (FHIR) to achieve interoperability (DHSC, 2020). Unfortunately, the most disclosed standard was HL7, the predecessor to FHIR, disclosed by 8% of trust teams. Better promotion of the NHS Digital Interoperability Toolkit would benefit NHS trusts by helping them to standardize their technology and interoperability specifications [25]. Uptake, however, would be reliant on trust and willingness to use the toolkit.

Interoperability is reliant on the NHS using technologies that are capable of communicating with one another. The most used programming language named in the survey was C# with 58.7%, a language that differs from NHS England’s preferred programming language of Python, which was disclosed by 5.1% of those in the study. The difference in programming language standards puts the Transformation Directorate’s push for open source and code sharing at odds with the wider NHS. There is still a benefit to code sharing, but some of this is lost because of the overhead involved in migrating between programming languages. A focus on the most consistently used languages across the NHS services would help to unify the NHS. There will be a strong reliance on the languages they have become accustomed to, and moving away from these is difficult to implement. Any coding examples NHS England develops should be written in the programming languages most appropriate for NHS services. Ensuring the use of modern languages will enable the NHS to keep a competitive advantage and help to retain staff looking to work on more relevant and modern languages over time.

Some of the insights derived from the study and related discussion suggest that the NHS has a solid foundation in certain areas. While trusts may not yet be fully aligned in their use of shared code, source control systems, or in leveraging all available opportunities, such as relevant grants, there is clear evidence of technology utilization across the organization. To build upon these foundations, this paper offers the following recommendations as steps toward achieving a more comprehensive digital maturity.

Future research should analyze digital innovation across NHS trusts, focusing on barriers such as limited resources, organizational culture, and technical expertise. Understanding these challenges is crucial for creating strategies to reduce disparities and promote equitable progress. Research should also explore ways to increase the adoption of open-source technologies, evaluating programs such as NHS Python and Analyst X, and expanding their reach. Investigating the programming languages and digital tools used across NHS trusts, aligned with NHS England’s standards, can enhance interoperability and improve code sharing. In addition, assessing the feasibility and impact of unified programming standards within the NHS’s digital infrastructure is essential. Research in these areas could significantly accelerate the NHS’s digital transformation, ensuring services remain efficient, innovative, and inclusive, thereby improving health care delivery and stakeholder satisfaction.

Interoperability principles enable the use of data and information across system and organizational boundaries. Embracing interoperability addresses the unrealistic expectation for a one-size-fits-all system for the NHS, or that heterogeneous systems will communicate with one another out of the box. Interoperability reduces the need for greater oversight across the spectrum and allows the NHS to demonstrate maturity at crucial sinews and joints between systems and services.

Without interoperability, much-needed digital maturity will not be gained, and the divide between NHS trusts with and without GDE funding will continue to grow. As the NHS continues to advance its plans for the use of digital, open-source technology and interoperability standards, it is essential that a unified approach is followed. This study has provided a snapshot of the digital development technology landscape and the areas of digital implementation policy that need the most refinement to improve their success.