Public organisations can decide themselves how to organise the assessment process, but the legal text of the IEA sets very clear requirements for the assessment report, which:
-
has to be published at least on an official website;
-
has to be machine-readable;
-
has to present the outcome of the assessment (including the items listed in the Annex to the IEA);
-
has to be shared electronically with the Interoperable Europe Board;
-
must not contain sensitive information.
The following subsections explain these requirements in further detail.

1. Publication on an official website


The assessment report must inform not only decision makers and implementers but also anyone else who might need to carry out related assessments in the future. It should therefore be publicly available on at least one official website. An official website in this case means a public website that is under the permanent responsibility of a public organisation, but it does not have to be the website of the organisation performing the assessment. The national competent authorities designate such a public location.
There is no legal requirement to set up a new website for this purpose. The report will also be available on the Interoperable Europe portal. Ideally, there should be links to the report on all websites where those that can benefit from reading the assessment report would usually go and find such information. Additional publication can also happen in other forms (e.g. in paper or specific journals).
2. Machine-readability


Machine-readable means that the information is provided in a way that machines can easily process and understand. This means that it is not enough for this information to be open and digitally accessible. Machine-readable data conforms to specific structures or formats that allow automated systems to interpret it without requiring human intervention.
Machine-readability for the purposes of assessment reports can be ensured using an appropriate metadata schema. In addition, comparability and reusability of the data reported can be enhanced by reusing standardised ways of representing the data (e.g., aligning it with corresponding semantic models currently under development). Using the tools offered by the Commission can help ensure machine-readability in the future. Such tools will include an online tool to provide the report directly on the Interoperable Europe portal. An API and its documentation could also be developed to exchange machine-readable data by plugging this API into any server.
Keep in mind that the requirement to issue the report in a machine-readable format does not cancel the obligation to make the report accessible on a website in a human-readable format designed to allow people to understand it directly.
3. Minimum content of the report

The minimum content of the report is set out in the annex of the Interoperable Europe Act. This present guide only covers minimum content and does not cover any other elements. As one of the supporting tools for interoperability assessments, the Commission is also preparing a data model for assessment reports to be published on the Interoperable Europe portal. The table below contains some suggestions to help you issue the information in a machine-readable format. As already mentioned, this does not exclude simultaneous publishing in other formats.
Item | Usable data models |
---|---|
1.General Information | |
EU entity or public sector body providing the report and other relevant information | Core Public Organisation Vocabulary |
Initiative, project or action concerned | This item should help the user understand the context of the interoperability assessment. It can, for example, provide links to other official websites where a legislative proposal or a call for tender will be published. EU institutions can, for example, link to the Have Your Say portal. For legal resources a relevant solution is About ELI - EUR-Lex. |
2. Requirements | |
Trans-European digital public services concerned | Core Public Service Vocabulary Application Profile |
Binding requirements assessed | There are different standard practices to define and model requirements (e.g., user stories, use cases, UML diagrams). These add value in different contexts (see also Chapter 3). A potential starting point: Core Criterion and Core Evidence Vocabulary, Core Assessment Vocabulary |
Public and private stakeholders affected |
In this item, it might be enough simply to state the category of stakeholder rather than each specific stakeholder. The tools currently under development by the Commission will provide a structured way to capture this information. As a semantic interoperability solution, one could use controlled vocabularies on public and private entities (e.g. core business) and a domain ontology such as NACE (Nomenclature des Activités Économiques dans la Communauté Européenn: a European industry standard classification system to encode business classifications) or COFOG (classification of the functions of government). |
Identified effects on cross-border interoperability | The tools provided by the Commission will capture this information by interoperability layer to follow the logic of the EIF. |
|
Use the NIF or the EIF as a baseline and tick the most appropriate, providing an explanation if necessary (at least for the human-readable format):
|
|
Use the NIF or the EIF as a baseline and tick the most appropriate, providing an explanation if necessary (at least for the human-readable format):
|
|
Use the NIF or the EIF as a baseline and tick the most appropriate, providing an explanation if necessary (at least for the human-readable format)
|
|
Use the NIF or the EIF as a baseline and tick the most appropriate, providing an explanation if necessary (at least for the human-readable format)
|
3. Results | |
Interoperable Europe solutions identified for use |
These are not yet available but are planned to come with unique identifiers as well as links to the relevant pages on the Interoperable Europe portal. The report should include a list of Interoperable Europe solutions that have been identified as relevant when implementing the requirements. If no solution is assessed as relevant, this should also be noted. |
Other relevant interoperability solutions, where applicable (including machine-to-machine interface) |
The report should include a list of interoperability solutions other than identified Interoperable Europe solutions. The report should ideally include links to respective solutions on the Interoperable Europe portal, national or other relevant portals. |
Remaining barriers to cross-border interoperability | The report should include a list of the remaining detected barriers to cross-border interoperability linked to the assessed binding requirements. Structured information could be combined with a brief explanation of why they cannot be addressed and what would be needed in order to overcome them. |
4. Sharing with the Interoperable Europe Board

The data in reports is not only relevant for the decision that they prepare and for implementers of such decisions but is also very interesting steering data for the Interoperable Europe Board. If the reports contain high-quality data, this can be used to take data-based decisions on the coming priorities (e.g. through the Interoperable Europe agenda).
The IEA therefore requires reports to be sent electronically to the Board. Reports shared through the online tool for assessment reports provided on the Interoperable Europe Portal will be considered as sent to the Board. The shared data would feed monitoring and become available to other interested parties through the Interoperable Europe portal. In the future, the data could be improved by API-driven data in order to provide updated assessment statistics (as shown in this example from France). The version shared with the Board electronically should not contain sensitive information.
The version shared with the Board electronically should not contain sensitive information.
5. Protect sensitive information

Before publishing the report, public organisations should make sure that publication would not compromise protected personal data, intellectual property rights or trade secrets, public order or security. If binding requirements concern critical systems of Member States, the content of the report should remain sufficiently high-level that it does not contain information that could compromise the security of such systems (e.g. the description of the requirements could be relatively high-level and written in a way that does not compromise security). Another option would be to simply omit sensitive information. If the mere existence of a requirement is already sensitive information, then the report need not be published in its entirety and could instead be published in a redacted form together with an explanation of the legal basis for the exclusion (e.g. the reason why it is considered sensitive). The report nevertheless needs to be produced and securely shared with the concerned parties.
Summary

The report should summarise the binding requirements that have been assessed; the trans-European digital public services that have been identified; the identified effects on cross-border interoperability; and the recommended Interoperable Europe solutions or other interoperability solutions. It should also highlight any remaining barriers to interoperability that were identified during the assessment.
The Commission is required to provide technical tools to support the interoperability assessment, including an online tool to facilitate the completion of the report and its publication on the Interoperable Europe portal. All tools are planned to be based on an open data model derived from the common checklist for interoperability assessment reports (provided in the Annex of the Act).
The use of the tools is not mandatory but is highly recommended because they will also be embedded in the wider context of the Interoperable Europe portal, where the reports are published – thus making them accessible to more stakeholders such as public organisations and thereby increasing mutual learning and the reuse of data, concepts and solutions.