Public Procurement

Interoperability is often discussed in technical terms. In practice, however, interoperability is determined by contractual choices. Every time a public authority procures a case management system, a registry platform, an eHealth application, a digital identity interface, a cross-border data exchange gateway, it makes decisions that will structure how data is stored, exchanged, licensed, modified and reused for many years. 

Once contracts are signed and systems are implemented, interoperability constraints can become costly and difficult to reverse. Procurement is therefore the decisive moment at which interoperability can either be embedded, supported, or inadvertently undermined. 

The IEA does not regulate procurement procedures directly. However, procurement choices may affect: 

• whether an interoperability assessment is required or useful under Article 3; 
• whether a procured solution can later be shared, published, adapted or maintained in line with Chapter 3 of these Guidelines; 
• whether the prioritisation rule in Article 4(6) can be applied effectively where equivalent solutions are available; 
• whether later reuse is facilitated or hindered by contractual rights, documentation, licensing terms. 

This chapter therefore provides cross-cutting procurement guidance on planning, specifications, award criteria, contractual rights, licensing, proportionality and capacity-building.

• It is recommended for the contracting authorities to embed interoperability considerations directly into the early stages of procurement planning and system design, rather than treating them as a standalone compliance exercise carried out at a later stage. This can be supported by introducing an initial assessment step when defining needs and preparing technical specifications.
• Where it appears that an interoperability assessment would be beneficial, authorities are advised to define the scope of the system in a practical and proportionate manner, focusing on how the system interacts with its environment rather than producing overly complex documentation. 
• To ensure consistency with EU-wide practices, authorities are encouraged to structure the assessment in line with the European Interoperability Framework, which provides a common model for analysing interoperability across multiple dimensions:

• To support alignment and avoid fragmentation across the Union, contracting authorities are encouraged to consider the reuse of existing European interoperability solutions or standards, in particular Interoperable Europe Solutions, before developing new ones.
• Authorities are also encouraged to consider the potential impact of the procurement on cross border interoperability, particularly where systems may interact with services in other Member States.
• For transparency and reusability, authorities are encouraged to document the outcomes of the assessment under Article 3 in a structured but proportionate manner.
• To ensure practical impact, authorities are encouraged to reflect interoperability considerations directly in procurement documentation, so that they become enforceable rather than purely descriptive.
• Finally, authorities are encouraged to apply a proportionate and risk-based approach, ensuring that interoperability is considered ‘by design’ without creating unnecessary administrative burden.

Contracts should include: 

• data export obligations in structured, documented formats; 
• documentation of all interfaces, customisations, and key configuration choices; 
• clear licensing and intellectual property terms; • knowledge-transfer obligations covering architecture, configuration, build, deployment and operating procedures, where relevant 
• exit and transition assistance clauses; 
• rights and practical arrangements enabling a replacement maintainer or provider to operate, maintain, adapt and migrate the solution; 
• provisions requiring compatibility maintenance during updates.

Minimum interoperability requirements set out in technical specifications can help establish baseline compliance, but do not guarantee long term adaptability, cross-border scalability, ease of reuse by other public authorities, avoidance of lock-in or sustainability over time. Award criteria allow authorities to differentiate between basic compliance and solutions that actively enhance interoperability in a robust, future-proof and reusable manner. 

If interoperability is not reflected in award criteria, suppliers have limited incentive to go beyond basic conformity. By contrast, when interoperability is rewarded, the market is encouraged to internalise public policy objectives.

Award criteria should be formulated in a way that enables verifiable and reproducible evaluation. Vague or discretionary formulations (e.g. ‘innovative interoperability approach’) without defined assessment parameters should be avoided. Instead, award criteria should identify the specific aspects to be assessed and, where appropriate, the expected level of performance.

Contracting authorities may combine mandatory minimum interoperability requirements with scored quality criteria. Where a feature is indispensable for lawful, secure or workable integration, for example the existence of usable API documentation, it may be preferable to set a pass/fail baseline in the technical specifications or procurement documents and reserve comparative scoring for quality features that go beyond that baseline.

However, scoring scales should not be applied mechanically across different criteria. Contracting authorities are encouraged to define criterion‑specific descriptors that reflect the subject matter of the contract. The scoring methodology should be sufficiently precise to allow evaluators to justify the scores awarded and enable bidders to understand how their proposals will be assessed.

Union entities and public sector bodies are required, under the conditions laid down in Article 4(1), to make interoperability solutions supporting trans-European digital public services available to another Union entity or public sector body that requests them. However, this obligation does not apply where making available an interoperability solution would infringe intellectual property rights or licensing conditions agreed with third parties. 

Contracts should therefore be drafted to secure rights that enable sharing and reuse, while also identifying and appropriately managing cases where exceptions apply.

Contracts should: 

• clarify ownership of deliverables;
• secure rights to share and reuse solutions, including adaptation by other public organisations where applicable; 
• require delivery of technical documentation, including manuals and documented code; 
• ensure source code access where appropriate; 
• define clearly whether deployment assistance, onboarding, hosting, support, trial access or other operational services are included, optional, or excluded; 
• where relevant, distinguish the rights in the interoperability solution itself from any separate paid service or support components.

The Act requires Union entities and public sector bodies to prioritise interoperability solutions without restrictive licensing terms where those solutions are equivalent in the sense of Article 4(6).

Where two solutions offer equivalent functionality, the one allowing reuse without restrictive conditions better supports interoperability and should be prioritised.

It is important to note that prioritizing solutions without restrictive licensing should not be understood as mandating an open source procurement. It requires prioritisation where equivalent solutions without restrictive licensing terms are available, but it does not prescribe a specific procurement technique for giving effect to that rule.

Interoperability requirements should not be designed in a manner that: 

• favours specific vendors or technologies without objective justification; 
• indirectly exclude certain economic operators without proportionate reasons. 

Where open standards are referenced, authorities are to allow equivalent solutions and provide objective criteria for assessing equivalence. This is of particular importance in the context of open source solutions, whose promotion within the framework of a procurement procedure cannot be conducted to the general exclusion of non-open source solutions.