© European Commission.
In November 2022, the European Commission published its proposal for an ‘Interoperable Europe Act’ to strengthen cross-border interoperability and cooperation in the public sector across the EU (the ‘IEA Proposal’, or ‘IEAP’) . The IEA Proposal seeks to revamp and strengthen the current European Interoperability Framework, which has seen very limited uptake since its inception in 2004, as detailed in the Communication ‘Linking public services, supporting public policies and delivering public benefits. Towards an “Interoperable Europe”’ (the ‘IEA Communication’).
The IEA Proposal thus seeks to introduce mandatory obligations and support mechanisms to foster the creation of a network of sovereign and interconnected digital public administrations and to accelerate the digital transformation of Europe's public sector, as an attempt to achieve Europe's 2030 digital targets and support trusted data flows. It also seeks to stimulate public sector innovation and public-private GovTech projects.
The IEA Proposal has a few procurement implications, some more evident than others. In this post, I try to map them, and offer some comments.
Some basics of the IEA Proposal
The IEA Proposal seeks to create a toolkit to promote increasing levels of interoperability in the network and information systems that enable public services to be delivered or managed electronically, with a primary focus on cross-border digital public services (Arts 3-14). The toolkit is complemented by institutional mechanisms for the governance of cross-border interoperability (Arts 15-18), as well as some central planning and monitoring instruments (Arts 19-20).
From a procurement perspective, some elements in the toolkit are particularly relevant, including: (i) an obligation to carry out interoperability assessments; (ii) an obligation to exchange information on ‘interoperability solutions’ and to cooperate with other public sector bodies; (iii) innovation measures with a GovTech focus; and (iv) regulatory sandboxes. Other measures, such as the creation of a portal for the publication of information on ‘interoperability solutions’, the possibility to set up Commission-driven policy implementation projects, provisions on training, or peer review mechanisms, are of lesser direct relevance. The rest of this post focuses on the four elements with a more direct procurement link.
Using procurement to trigger interoperability assessments
Interoperability assessments are one of the main elements in the IEAP toolkit. Recital (8) stresses that
To set up cross-border interoperable public services, it is important to focus on … interoperability … as early as possible in the policymaking process. Therefore, the public organisation that intends to set up a new or to modify an existing network and information system that is likely [to] result in high impacts on the cross-border interoperability, should carry out an interoperability assessment. This assessment is necessary to understand the magnitude of impact of the planned action and to propose measures to reap up the benefits and address potential costs.
Recital (10) then adds that
The outcome of that [interoperability] assessment should be taken into account when determining the appropriate measures that need to be taken in order to set up or modify the network and information system.
The minimum content of the interoperability assessment is prescribed and includes specific analysis of the ‘level of alignment of the network and information systems concerned with the European Interoperability Framework, and with the Interoperable Europe solutions [a new form of recommended interoperability standard]’ (Art 3(4)(b) IEAP). The purpose of the assessment is clearly to promote convergence towards European standards, even if there is no strict obligation to do so. The outcome of the interoperability assessment must be published on the public sector body’s website (Art 3(2) IEAP). Such transparency may support convergence towards European standards.
The IEA Proposal uses the likelihood of a procurement process as one of three triggers for the obligation to carry out an interoperability assessment. Article 3(1)(b) IEA Proposal indeed makes it mandatory to carry out such interoperability assessment ‘where the intended set-up or modification [of an existing network and information system that enables public services to be delivered or managed electronically] will most likely result in procurements for network and information systems used for the provision of cross-border services above the threshold set out in Article 4 of Directive 2014/24/EU’.
This trigger raises the question why the same obligation is not imposed when other EU procurement rules may be applicable — notably Directive 2014/23/EU on concessions, but also Directive 2014/25/EU as the infrastructure for digital public services may not be directly procured by an entity covered by Directive 2014/24/EU — although it is possible to carry out interoperability assessments on a voluntary basis.
Be it as it may, as a first procurement implication, the IEA Proposal would create an add-on regulatory obligation to carry out an interoperability assessment for (likely) procurements covered by Directive 2014/24/EU. It may be worth noting that the obligation to carry out an interoperability assessment is also triggered where ‘the intended set-up or modification affects one or more network and information systems used for the provision of cross-border services across several sectors or administrations’ (Art 3(1)(a) IEAP), so the obligation would not be circumvented in eg cases of public-public cooperation or in-house provision, whether they are considered covered and exempted, or excluded, from Directive 2014/24/EU.
The obligation to carry out the interoperability assessment can have a knock-on effect on the setting of technical specifications for the future procurement, to the extent that it promotes the adoption of Interoperable Europe solutions as standards. In that regard, it is worth noting that the IEA Proposal highlights that ‘Interoperability is a condition for avoiding technological lock-in, enabling technical developments, and fostering innovation’ (rec (22)), and also establishes a clear link between its objectives and the standardisation of technical specifications. In Recital (18), is stresses that
Interoperability is directly connected with, and dependent on the use of open specifications and standards. Therefore, the Union public sector should be allowed to agree on cross-cutting open specifications and other solutions to promote interoperability. The new framework should provide for a clear process on the establishment and promotion of such agreed interoperability solutions in the future. This way, the public sector will have a more coordinated voice to channel public sector needs and public values into broader discussions.
Therefore, a secondary procurement implication is that the IEA Proposal can have implications for the setting of technical specifications, in particular to promote the use of Interoperable Europe solutions. These can propagate beyond cross-border digital public services to the extent that such standardisation can also generate functional and financial advantages in a strictly domestic context. Moreover, as Interoperable Europe solutions are developed, they can simply become de facto industry standards.
obligations to exchange information: need for new or additional clauses in public contracts?
Another of the key goals of the IEA Proposal is to facilitate (cross-border) information exchanges between public administrations on the interoperability solutions they have implemented. Such exchange of information is meant to promote sharing and reusing proven tools as a ‘fast and cost-effective approach to designing digital public services’ (IEA Communication, at 2).
In that regard, Recital (12) of the IEA Proposal programmatically stresses that
Public sector bodies or institutions, bodies or agencies of the Union that search for interoperability solutions should be able to request from other public sector bodies or institutions, bodies or agencies of the Union the software code those organisations use, together with the related documentation. Sharing should become a default among public sector bodies, and institutions, bodies and agencies of the Union while not sharing would need a legal justification. In addition, public sector bodies or institutions, bodies, or agencies of the Union should seek to develop new interoperability solutions or to further develop existing interoperability solutions.
Such a maximalist approach would generalise a practice of ‘EU-wide’ ‘software code’ and technical documentation exchange that would likely raise some eyebrows, especially in relation to proprietary software and in relation to algorithmic source code protection. The IEA Proposal justifies this in Recital (13) on grounds that
When public administrations decide to share their solutions with other public administrations or the public, they are acting in the public interest. This is even more relevant for innovative technologies: for instance, open code makes algorithms transparent and allows for independent audits and reproducible building blocks. The sharing of interoperability solutions among public administration should set the conditions for the achievement of an open ecosystem of digital technologies for the public sector that can produce multiple benefits.
However, the IEA Proposal is much more limited than the recitals would suggest. The information exchange regime created by the IEA Proposal is regulated in Article 4. It needs to be read bearing in mind that Article 2(3) defines an ‘interoperability solution’ as a ‘technical specification, including a standard, or another solution, including conceptual frameworks, guidelines and applications, describing legal, organisational, semantic or technical requirements to be fulfilled by a network and information system in order to enhance cross-border interoperability’.
Depending on its interpretation, this definition can severely limit the scope of the information exchange obligations under the IEA Proposal, in particular due to the (functional) requirement that the covered ‘interoperability solutions’ refer to ‘requirements to be fulfilled by a network and information system in order to enhance cross-border interoperability’ (emphasis added). It should be noted that ‘cross-border interoperability’ is defined as ‘the ability of network and information systems to be used by public sector bodies in different Member States and institutions, bodies, and agencies of the Union in order to interact with each other by sharing data by means of electronic communication’. The IEA Communication and several aspects of the IEA Proposal seem to indicate that the purpose is not to restrict the relevant obligations to cases of existing cross-border interaction, but to facilitate potential cross-border interoperability. In that regard, it seems that it would have been preferable to define the scope of application as concerning information on any ‘solutions’ adopted by a public sector institution, so long as the information request was based on the potential interoperability of such solution with that (to be) adopted by the requesting institution. Nonetheless, it also seems functionally necessary for the information exchange mechanism not to be constrained to interoperability solutions already addressing issues of cross-border interoperability.
According to Article 4(1), ‘A public sector body or an institution, body or agency of the Union shall make available to any other such entity that requests it, interoperability solutions that support the public services that it delivers or manages electronically. The shared content shall include the technical documentation and, where applicable, the documented source code.’
Importantly, though, this obligation is excluded in the crucial case of interoperability solutions ‘for which third parties hold intellectual property rights and do not allow sharing’ (Art 4(1)(b)). It is also excluded regarding interoperability solutions that support processes which fall outside the scope of the public task of the public sector bodies or institutions, bodies, or agencies of the Union concerned (Art 4(1)(a)), and those with restricted access due to the protection of critical infrastructure, defence interests, or public security (Art 4(1)(c)).
So, what is left? Primarily, exchanges based on open source interoperability solutions, or exchanges of proprietary information permitted by the IP holder — eg through a licence that allows for the reuse by other public sector bodies or institutions, bodies or agencies of the Union, or other contractual means. In that regard, the obligation to exchange information is much more limited than may at first seem and does not create significant new technology governance duties on public buyers—other than the primary duty to disclose which solution is being used and to participate in the exchange of open (or permissioned) information, which can be done through a new portal to avoid multiple bilateral interactions (see Art 4(3) IEAP).
It may however be necessary to develop contractual clauses to clarify whether IP protected interoperability solutions can or cannot be shared (and in which terms), along the lines of some of the obligations regulated in the standard contractual clauses of the procurement of artificial intelligence, currently under development. Such contractual regime is also necessary in relation to software source code in any case, as a result of the CJEU Judgment in Informatikgesellschaft für Software-Entwicklung, C-796/18, EU:C:2020:395 (the ‘ISE case’, see here for discussion).
‘mandatory’ public-public cooperation
To support the reuse of (exchanged) interoperability solutions, Article 4(2) IEA Proposal includes an interesting provision on cooperation between the requesting (reusing) and the disclosing (sharing) public sector bodies:
To enable the reusing entity to manage the interoperability solution autonomously, the sharing entity shall specify the guarantees that will be provided to the reusing entity in terms of cooperation, support and maintenance. Before adopting the interoperability solution, the reusing entity shall provide to the sharing entity an assessment of the solution covering its ability to manage autonomously the cybersecurity and the evolution of the reused interoperability solution.
The sharing and reusing entities can also ‘conclude an agreement on sharing the costs for future developments of the interoperability solution’ (Art 4(5) IEAP). However, this cooperation obligation is excluded if the ‘sharing’ public sector body has published the interoperability solution in the relevant portal (Art 4(3) IEAP), which seems like a clear incentive to publish open source or broadly licensed interoperability solutions.
It is worth noting that, where arranged, such cooperation agreements (especially if they deal with future development costs) can in themselves constitute a public contract and thus be subject to compliance with Directive 2014/24/EU if the (wide) boundaries of public-public cooperation are exceeded—again, by reference to the ISE case. This seems an unlikely scenario given that the remit of the IEA Proposal is primarily concerned with networks for the cross-border (joint or linked) provision of digital public services, but it cannot be excluded if the broader interpretation of (potential) cross-border interoperability is adopted, especially in the context of reuse of a solution for a purpose (slightly) different than that for which the ‘sharing’ public sector entity implemented it.
Importantly, it is also necessary to consider whether the sharing of non-open access interoperability solutions under a cooperation agreement can have the effect of placing the IP holder in a position of advantage vis-à-vis its competitors, in which case the cooperation agreement would be in breach of Directive 2014/24/EU, once again, by reference to the ISE case. It can well be that this is a further disincentive for the sharing of IP protected interoperability solutions, even if a broad licence for public sector re-use is available.
In general, it seems like most of the mechanisms of the IEA Proposal can only really work in relation to open code and software. This is an important, general point. The IEA Communication stresses that interoperability assets ‘need to be open in order to be readily reusable by public administrations at all levels, that create interoperable systems and services, and by private sector and industry partners working with these administrations … This is why the proposed Interoperable Europe Act provides for access to reusable solutions, including code, where appropriate and possible.’ The main issue is that the IEA Proposal does not contain any explicit requirement for Member States’ public sector bodies to use open source solutions. Therefore, the effectiveness of most of its mechanisms ultimately depends on the level of uptake of open source solutions at national level.
innovation measures with a GovTech focus
Another procurement-relevant aspect of the IEA Proposal is its attempt to foster GovTech (peculiarly) defined as a ‘a technology-based cooperation between public and private sector actors supporting public sector digital transformation’ (Art 2(7) EIAP). The IEA Communication stresses that
Public-private ‘GovTech’ or ‘CivicTech’ cooperation stimulates public sector innovation, supports Europe’s technological sovereignty and opens pathways to public procurement. Gaining access to public procurement is a core concern for smaller companies, to be able to scale up and gain recognition and stable operating income (at 8).
Along the same lines, Recitals (24) and (25) of the IEA Proposal stress that
All levels of government should cooperate with innovative organisations, be it companies or non-profit entities, in design, development and operation of public services. Supporting GovTech cooperation between public sector bodies and start-ups and innovative SMEs, or cooperation mainly involving civil society organisations (‘CivicTech’), is an effective means of supporting public sector innovation and promoting use of interoperability tools across private and public sector partners. Supporting an open GovTech ecosystem in the Union that brings together public and private actors across borders and involves different levels of government should allow to develop innovative initiatives aimed at the design and deployment of GovTech interoperability solutions.
Identifying shared innovation needs and priorities and focusing common GovTech and experimentation efforts across borders would help Union public sector bodies to share risks, lessons learnt, and results of innovation support projects. Those activities will tap in particular into the Union’s rich reservoir of technology start-ups and SMEs. Successful GovTech projects and innovation measures piloted by Interoperable Europe innovation measures should help scale up GovTech tools and interoperability solutions for reuse.
However, there is little detail in the IEA Proposal on how GovTech uptake should be promoted. Article 10 indicates that the Interoperable Europe Board may propose that the Commission sets up innovation measures to support the development and uptake of innovative interoperability solutions in the EU, and that such measures ‘shall involve GovTech actors’. Such measures can be regulatory sandboxes (below). The Commission is also tasked with monitoring ‘the cooperation with GovTech actors in the field of cross-border interoperable public services to be delivered or managed electronically in the Union’ (Art 20(2)(c) IEAP).
None of this is very precise. The lack of detail on how to promote GovTech leaves many questions unanswered. This is particularly problematic because it is clear that engaging in GovTech requires rather sophisticated and advanced procurement, commercial and digital skills (see eg this report for the European Parliament) — even if only to understand the limits to pre-commercial procurement and other procurement-compliant ways to create a ‘route to market’ for GovTech companies.
It is also clear that existing support mechanisms (eg the Commission’s Guidance on Innovation Procurement) are insufficient. It remains to be seen whether the Commission can develop effective innovation measures under the IEA Proposal, which implementation will likely require overcoming the non-negligible obstacles to cross-border procurement under Directive 2014/24/EU — as the scope of the IEA Proposal is primarily constrained to cross-border digital public services and, more generally, to facilitating interoperability in different Member States.
regulatory Sandboxes and procurement?
As mentioned above in relation to GovTech, the IEA Proposal also includes the creation of regulatory sandboxes in its toolkit. Article 11 establishes that ‘Regulatory sandboxes shall provide a controlled environment for the development, testing and validation of innovative interoperability solutions supporting the cross-border interoperability of network and information systems which are used to provide or manage public services to be delivered or managed electronically for a limited period of time before putting them into service’. The aims of the sandboxes are specified, and include facilitating ‘cross-border cooperation between national competent authorities and synergies in public service delivery’; and facilitating ‘the development of an open European GovTech ecosystem, including cooperation with small and medium enterprises and start-ups’ (Art 11(3)(b) and (c) IEAP).
To me, it is unclear whether there will be much uptake of the possibility to participate in a sandbox to develop interoperability solutions for the public sector that are (tendentially at least) to be open source, as the economic incentives are not the same as those for participation in regulatory sandboxes that have as a sole purpose to exempt compliance from applicable regulatory obligations for the development of (otherwise) marketable products and services—eg in relation to FinTech services, or the pilot regulatory sandbox on Artificial Intelligence.
It seems to me more likely that the IEA regulatory sandboxes will be used in conjunction with a procurement process or for the implementation of public (services) contracts. In that case, it is unclear how the two mechanisms will interact. The IEA Proposal’s provisions on sandboxes only have detailed rules on data protection compliance, which clearly is a focus of legal risk. However, more could have been said in relation to coordinating the sandbox with the rules on cross-border procurement in Directive 2014/24/EU. Additional guidance seems necessary.
Final thoughts
The IEA Proposal has clear and not so clear interactions with public procurement. Notably, it forms part of a broader soft approach to fostering the procurement of open source digital solutions. As such, its effectiveness will be mostly constrained by the Member States’ willingness to embrace open source by default in their domestic procurement policies, as well as their proactive participation in the publication and cooperation mechanisms included in the IEA Proposal. It will be interesting to see how far such a change in public sector technology governance goes in coming years.
